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.
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 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.
I have an ASP.NET solution that acts as the primary customer portal for my customers. On this website the users can log-in access their important financial information and more. The website uses a custom authentication scheme that checks the user's username (their email) and their password (salt-hashed) against a Users table in a local database.
I am building a new MVC.NET solution that is more of a web-app tool to be used by these same customers for ordering. I want to re-use the sign-on mechanism of the ASP.NET portal to authenticate users. The goal is to save the user from remembering two log-ins or even having to supply the same log-in twice.
What are my options for allowing users who sign on to the ASP.NET solution to then be auto authenticated to the MVC.NET solution? I've listed some ideas below but are these "bad" or is there a more elegant solution? I'd love your input.
Common Cookie I could create a common cookie that the ASP.NET site creates and the MVC.NET site looks for. But is that secure enough?
Token in Query String I could create a token id on the ASP.NET site that is stored in the local database and is then passed in the query string of the link to the MVC.NET site which takes the token id and validates it against the same database.
Hybrid A bit of both?
Other? Got a better idea?
I've recently done something quite similar (the major difference being that it was internal to the company rather than for external customers) using OpenId.
The implementation of OpenId for .NET is called DotNetOpenAuth which should be suitable for your purposes.
It did take me a while to implement; but it works very well, is very flexible, and extremely secure.
More information about openid (from Wikipedia):
OpenID is an open standard that allows users to be authenticated by certain co-operating sites (known as Relying Parties or RP) using a third party service, eliminating the need for webmasters to provide their own ad hoc systems and allowing users to consolidate their digital identities.
Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication. The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the "relying party").2 An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).
The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics).
Oh, and if you'd like further encouragement, Stack Exchange uses it!
#Jmrnet: in response to your last comment:
Perhaps I was unclear. OpenId in and of itself is simply for validating credentials from one location to another (more or less). It's entirely possible to implement as an SSO model where users do nothing different whatsoever - they don't have to choose a provider, or register, or anything like that. For example, in my setup, the user enters a username and password in a web portal, and then clicks a button to launch another site being automatically logged in by OpenId. Nothing different for the user at all! OpenId can be used with any initial authentication model you can think of (note the bolded section in the snippet from wikipedia).
Take a look at SAML:
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
It works using XML and supports encryption.
I am currently implementing two SSO solutions for the same project.
In one, we are interfacing with an external partner and are using SAML.
In the other, we are allowing logged in users access to our Sharepoint and using the "Token in Query String" approach, since we trust Sharepoint to access our membership tables. This approach is much easier than dealing with SAML tokens.
There are many methods you can use, Mansfied described OpenID and RandomUs1r described SAML. Also, you can store relevant information in localStorage or in the session. I believe you should store relevant information with session.
It is not safe to put this in the query string, because if I register and log in, I will see something like UserID=1234 in the URL. If I change that to UserID=1235 and the ID is existent, then I can do some things in the name of the other user. This is called identity theft, which should be prevented by any means possible. So you should never have this kind of info in your URLs. Also, if you store the id of the user, you should obfuscate it somehow. For instance if you store the value in local storage and instead of 1234 you store encrypt(1234, salt), then the consistency of user action will be maintained.
I'm developing a WCF service that will host business logic of the application. The application is mostly for intranet, but can be accessed from internet. We have an active directory domain up and running, so I plan to authenticate and authorize users according to their username and groups they are in. This service will be used mostly be an ASP.NET MVC site
So, first question is how to authenticate and authorize users based on their AD profile?
Secondly, I need to store additional info about each user. The problem is that I can't modify AD scheme. The number of added fields is about 10 or so.
Can I somehow use SQL server for profile storage? Of course I can, but how to tie this with AD auth?
You can use WIF for this.
You would configure your WCF service for WIF in the normal way and then use a custom ClaimsAuthenticationManager class deriving from the base ClaimsAuthenticationManager and overriding its Authenticate method. This is a normal extensibility point of WIF. WIF will
get hold of the security token from the incoming request and add claims for each of the relevant AD properties. In your override of the Authenticate method, you will add new claims to represent your extra properties.
The basic use of WIF for WCF services is described here:
http://msdn.microsoft.com/en-us/library/ee748476.aspx
To see how to use ClaimsAuthenticationManager, start here:
http://msdn.microsoft.com/en-us/library/ee748211.aspx
Well, I think you have a couple of choices here, but you will have to carefully consider the implementation.
The primary issue with using active directory authentication is that by default a user's credentials can only be passed successfully between two machines. In the case of a web application, this means that the user's credentials can travel between the end user's machine and the web server, but no further.
However, this behavior can be changed through the use of Kerberos authentication, which essentially allows an authentication ticket to be passed among all of the trusted machines in the chain (i.e. from the web server to the application server to the database, for example). Successfully configuring Kerberos can be extremely challenging, especially if you have had no prior experience with it.
I think your best bet is to configure your web site to accept only Windows Authentication. This means that IIS will perform the validation of the user against active directory. In your ASP.Net application you can pickup the domain name of the authorized user from Request.ServerVariables("logon_user").
At this point, you can log the user on with FormsAuthentication, for example, without requiring them to login again.
You could then either implement the SQL Server Membership Provider or create your own interface to your database for further user validation and extra information storage. We have used both mechanisms, but I prefer the self-built one due to the additional control it provides and, in this case, you won't need a lot of the functionality (password reset, recovery, etc) that the membership provider offers.
Client requires major applications to provide users with “single sign on” authentication feature based on the corporate solution (Active Directory).
This means the business application trusts the credentials provided by the browser and does not request user to provide standard login/password pair. The server/browser trust is built on Windows Integrated Authentication mechanism.
Ours is an ASP.Net Web application on dot net framework 2.0 hosted on IIS 5.We need to implement the SSO feature.How do we do it?
I'm pretty sure this is the same requirements that almost all intranet apps follow.
If you just enabled Windows Integrated Logins in IIS, then you'll be set for the #1 item.
I don't know if #2 is even possible, because it conflicts with your other requirement. The browser only passes the locally logged in user's credentials (as required by #1). If you built a web form to authenticate via AD, then you would be in violation of the requirements listed in your narrative/paragraph.
What do your clients think #2 really means? What do they want here? A way to log in as a different user? They can just log off the computer and log in as the other user.
In general, SSO requirements are best addressed by Claims-based protocols such as WS-Federation or SAML 2.0. In principle, you can implement these protocols yourself since they are open standards, but it requires a lot of specialist knowledge.
The new Windows Identity Foundation (formerly known as Geneva framework) contains protocol implementations that can enable SSO scenarios, although it will require you to upgrade your platform.
Use Custom Forms Auth instead that wont ask user to enter ID and password.
Prerequisites:
1> Database table having user details such as email, role etc
2> Enterprise active directory where user profiles are stored
3> Write a VBCOM or ActiveX or other components that can read user's domain and name from the windows machine through browser.
Steps:
On pageload for all the forms call the component<3> to connect to Active Directory<2>. That method should read current user's name, domain from windows system.
Search AD with these details. If exists then query and extract the email address or whichever is the unique key in the AD user profile.
Using this key query the database<1> where you stored application specific user details such as email, roles.
If user email from AD match with email in Table then grant the user appropriate rights else deny access if user does not exist or role is null/restricted.
If valid user then create a cookie that is encrypted and can be read by other applications to really implement any sort of SSO.