I am implementing Authentication using Azure AD in C# MVC 5.0 application. I've created Azure AD B2C tenant , My tenant is having three application registered in it.
I would like to implement Single Sign-on so if user is logged in any one of one application he will be directly logged in other applications as well.
I tried to find solutions on the web but found no clear help on how I can start with it and implement.
Any help from the community would be appreciated. Thanks in Advance.
if user is logged in any one of one application he will be directly logged in other applications as well
Logging into one of applications doesn't make the user automatically logged in in other applications. This happens only after the user browses to the application and the SSO protocol takes control over the browser for the handshake sequence.
From the user perspective this doesn't make any difference. They navigate to any of your apps and they are logged in, they usually don't even notice the redirect/response sequence.
Think in terms of a ticket office in a movie theater (the SSO identity provider, Azure in your case) and multiple entrances to the theater (your applications). Buying a ticket (loggin in the identity provider) doesn't automatically make all ticket inspectors aware (you are not automatically logged in everywhere). Rather, when you approach particular entrance and you show your ticket, the particular ticket inspector accepts the ticket and you are allowed to enter (you log into one of applications and it accepts the token from the identity provider) without other inspectors noticing (other applications are not aware you just logged in somewhere).
As for the technical part, Azure implements both OAuth2 and WS-Fed protocols. You can find numerous tutorials on how to integrate a web app using either of the two. If you need assistance in specific technical issues, feel free to create new specific questions. Remember only to focus on specific issues, questions about possible recommendations (Should I rather use OAuth2 or WS-Fed? or Which specific client library should I use for OAuth2?) don't quite fit here and are likely to be closed.
If you have browser session cookies then you should be able to get SSO across all the app. You should also consider using Microsoft Authentication Library (MSAL) available at https://www.nuget.org/packages/Microsoft.Identity.Client. This library is still under preview.
Related
We have a client that currently use a ERP-system to store all their clients. This is a closed source ERP so they can not change the authentication flow. Right now they have an authentication API that various other APIs use but development is slow. They are now facing a challenge in that they need to bring more systems in and given the current structure this takes time since their APIs are tightly coupled with the rest of the systems. They absolutely wan't to avoid other departments from creating applications with their own authentication simply because they cannot keep their pace up.
They wan't to keep SSO for all their customer systems but have better control which users are allowed to do what.
I have been reading about Azure Active Directory B2C and it seems really great. We use Azure Active Directory (AAD) authentication for our internal applications and it works flawlessly most of the time.
Here comes the two part question:
Is it possible to use Azure AD B2C and still keep users in the ERP? For example if we can connect Azure AD B2C to send a request to a service that responds with user data if that user exists given that the credentials are correct.
Extension of question 1. The current ERP-systems gives the user an access token and refresh token. Is it still possible to use Azure Active Directory B2C in this case? Basically add our own Identity Provider that will refresh the access token when needed. Is this a feasible thing to do and are there any guides in creating this? Perhaps IdentityServer4 could be used or can it be simplified? http://openid.net/developers/certified/#OPLibs https://github.com/IdentityServer/IdentityServer4
Given these words on their website I think it should work:
Support all platforms and open standards
https://azure.microsoft.com/en-us/services/active-directory-b2c/
Yes, it is possible. As Miroslav mentions, you should use custom policies. This requires a ramp up on custom policies which can have a steep learning curve, but essentially you would take the starterpack (see getting started) and you would modify the userjourney to not write to the B2C directory (basically remove this step). Instead, you would do a call out to wherever the users are. This call out can either be an OIDC identity provider or a REST API, which are specified using technical profiles.
I'm trying to find a solution to handle authentication on my new application, and I like the approach of IdentityServer3. I would like to hope my requirements are met by IdentityServer3 and it's just my lack of understanding due to my newness with the technology.
My requirements are as follows, and in order of desired execution:
1) If a user requesting authentication is a local (domain) user, they should be authenticated automatically using Active Directory.
2) If a user requesting authentication is not found in Active Directory, they should be authenticated against our own User table.
3) If a user requesting authentication is in neither Authority, we may choose to grant access via Google or Facebook credentials, but that's not a Phase I requirement.
I currently have a working proof of concept using IdentityServer3 as a standalone security server pulling records from the InMemoryUsers, InMemoryClients and InMemoryScopes, and I'm fairly sure I'll be able to expand on those concepts for pulling from our own database.
This problem comes when I try to use Active Directory as the first checkpoint.
I've looked at a couple of resources in an effort to accomplish the Active Directory, but I'm getting all tripped up as I'm not seeing any concise demo that shows the AD piece of the puzzle.
TJ Robinson has a Gist of an ActiveDirectoryUserService that implements IUserService, and that looks to be the most promising, but because of my n00b status, I can't seem to figure out how to roll it into the scheme.
I would really appreciate any suggestions, and, perhaps, links to examples of how to do AD authentication first with a fallback to local authentication.
Thanks in advance,
Ric
In regard to your first requirement...
I believe you should examine the Windows Authentication Service. This is essentially a mini security-token-service that can work as an external identity provider to IdentityServer to provide Windows Authentication (over the WS-Fed protocol).
If you follow that link to the GitHub page, you will find two links to samples that can you get started with this component. One sample has both Identity Server and the Windows Authentication Service hosted separately and the other sample has them hosted together.
A separate option could be to use ADFS (if you have one) as an external identity provider.
Those samples include a custom user service (ExternalRegistrationUserService) that shows those windows users being mapped to an in-memory collection of users (in Identity Server). Your requirements will obviously demand a different implementation of that user service, but I hope this might help get your started with the Windows Auth part.
When I went through this exercise recently, I found a lot of good information in the closed IdentityServer3 issues (for windows auth). Lots of good info on Stack Overflow as well; good luck!
I am working for the DOD. The application they have requested is web based, and will be on their internal network. The request is for CAC authentication, which is easy enough... The remaining problem is authenticating a user. The CAC authentication is happening at the IIS level, so by the time the user gets to the application, all I am doing (or had planned on doing) is checking the ID on the CAC, and comparing it to a user table in the database. If the user exists (and has been approved), then they are off and running in the system. If they do not exist, then they are pushed to the registration screen.
Given my lack of experience with web development, I am unsure if I need to actually authenticate the user in some way beyond the CAC authentication, or if I can just manually assign roles to the user and let the roles dictate what can or cannot be done in the application. Windows authentication is not an option; while this application is internal for the military, it is accessible from different mil networks.
If I do indeed need to authenticate a user... this is where I run into trouble. I have not found anything that says there is a way to manually authenticate a user. I could use the standard ASP tables in the database, but it seems... messy... to include things that won't be used (meaning the password field would always be an empty string - why include it in the db if it isn't being used?).
Thanks in advance for any help... If there's links to where I can read more about the authentication process, those would be very much appreciated as will.
I'm working on several DOE projects that use the same idea. What we normally do for web applications is to enable Windows authentication on the app. This will allow pass-through of user credentials and keep out anyone without credentials.
I also like to add role based authorization into the mix and then use AD groups to allow/deny users on specific apps.
I have four systems running on the same server. I want to let the users to log in once for all the systems. I made one user-management system to create users and edit them.
I tried to save in the session but it didn't help.
Any suggestions? I am working on asp.net.
There are two approaches.
Most resolve around the login happening at a central site, which then returns with an identity information field (login token) that the target site uses to retreive the user.
When you go to another site, the site redirects you shortly to the central site and if you are logged in (persistent cookie) you get back the identity of you.
Alternatively you can do a lot with referrers and playing around.
YOu want to do some research on the internet - what you loo kfo is "Single Sign On".
http://www.codeproject.com/Articles/27576/Single-Sign-on-in-ASP-NET-and-Other-Platforms
has some technical discussions.
Across complete separate websites (domains) you can read up on
http://aspalliance.com/1513_Cross_Site_Authentication_and_Data_Transfer
howw to do it - obviously shared cookies will not work there.
The best way to do this is with Federated Security. If you were using Windows Authentication then you could use Active Directory Federation Services (ADFS). In this model, users reference a Web application and the principal on the current thread is checked. If the value is null then information stored in the web.config will redirect the request to a login page automatically. This is assuming there is no a Windows security context, otherwise the user can be automatically logged in.
After the user is successfully logged into the environment, the principal on the thread is populated and a set of claims are issued that are specific for that user. Since the claims are associated with the principal and not with a specific application, they can be used across the board by any claims aware application.
If you aren't using Windows Authentication, you can still accomplish the same thing, the only problem is that you cannot use ADFS. Instead, you'll have to implement your own Identity Provider to replace ADFS. The .NET Framework does provide base classes and interfaces to help you accomplish that.
I would suggest looking into ActiveDirectory or any LDAP server for single signon to access all applications. If you cannot (or do not wish to) use LDAP, you could implement similar functionality (but with more development work/time spent) with any memory/disk store. If this is not possible, please share why as it might be useful to others.
Hope this helps.
We have several customer using our web application (not intranet), some customers want their login should be integrated with their organizations Active Directory.
They just want that user should login to their windows account and can access the web application without entering any user credentials.
I have read some articles regarding ADFS, but still not sure how to integrate that or implement it.
Any proposed solution ?
Thanks!
If you develop a .NET based application, Microsoft provides a library called WIF, which is used to communicate with the AD FS in a +- comfortable way (configuration + little code adaptations to get the claims from the authentication message provided by the AD FS).
There are few protocols that both AD FS 2.0 and WIF support, to make the SSO work, the most common ones are (afaik) SAML 2.0 and WS-Federation. Both are built on XML messages, but you are not required to know the details, if you use WIF.
For WS - Federation, the WIF library provides a plugin for Visual Studio, which allows you to configure your site as the relying party with your AD FS.
You CAN use the credentials within your DB to identify users, you can actually customize AD FS's entire login page and authentication events. However the basic installation requires each user to be defined within your Active Directory. You can also use your DB as a claims store (another data base AD FS will use to provide the relying applications with information about users). Note that if you intend to use an AD behind the AD FS, your AD FS service must be able to access it and LDAP query it, which I'm not sure will work for you, if your users login to their local domain that the AD FS is not familiar with.
IF you are not required to support industry SSO standard protocols (SAML 2.0 I've mentioned), I'm not sure implementing AD FS will be such a good solution. It forces you to work in a certain way, which is not always that comfortable.
Your question doesn't explicitly state that whether you are limited to using ADFS for implementing SSO. ADFS is certainly one way of doing this. You may want to look at OpenID-LDAP (was at www.openid-ldap.org, but project is now defunct) and other identity providers as alternatives for implementing SSO.
One alternative is to implement an OpenID provider that uses integrated windows authentication. They can install it in their DMZ exposing that to the internet, instead of ADFS. It may allow single sign on from Internet Explorer and Chrome.
Implementing an OpenID provider is a non trivial matter. You'll have to pay close attention to security. Fortunally, there are a number of frameworks like DotNetOpenAuth that may help you.
When using OpenID, your "cloud" application will act as an OpenID rely and get a claimed identifier amongst other attributes from the OpenID provider. You should store this in your database to uniquely identify the user. You may choose to implement the OpenID provider such that it can also provide your cloud application with the minimal information like email address, the person's name etc.
The benefit of using OpenID is that your "cloud" application can continue to support other well known OpenID providers like Google and Yahoo without much change.
In the end you'll need to ask your customers what technologies they are comfortable with. You'll find that a lack of trust (a business trait) between organizations is more often than not the challenge rather than technology.
More detail needed as per comments.
There's a good source here: AD FS 2.0 Content Map.
The "e-book" is here.
I could imagine one scenario where you bind your cloud application to Azure ACS, your customers install ADFS on top of their AD and federate their ADFS with ACS. That would give you the functionality you require.
Update after comment:
ADFS can only authenticate against AD. It cannot authenticate against a DB. It can get attributes from a SQL Server DB which it can then transform to claims i.e. it can use a SQL DB for authorisation.
If you want to authenticate against a SQL DB, you can two choices.
Create a custom STS
Use an existing "custom" STS like Identity Server which allows this functionality.