We have a few .NET based web applications. The user base for the applications include mobile subscribers who enroll to check their bills. The plan is to provide Single Sign-On across my applications. We are exploring using Windows Azure ACS with Active Directory as identity provider for my application users for the purpose. Are we going in the right track with using Windows Azure ACS with Active Directory as identity provider?
2 回答
Windows Azure Active Directory is a good option for single sign-on, but it does not have to be used with ACS, as can be seen here
http://msdn.microsoft.com/en-us/library/windowsazure/dn151790.aspx#BKMK_Connecting
The advantages of ACS are that
- It can be used to perform claims transformation without having to write any code (e.g. in a custom ClaimsAuthenticationManager). You will not be able to handle complex transformations, but simple ones are fine.
- It can provide federation with multiple identity providers, so if you users would rather use Facebook, instead of your WAAD, it is more flexible.
However, on the down side
- It is more complex to configure and is another moving part in your solution that can go wrong
- ACS namespaces are tied to a single Azure region so a failure in a data centre will be harder to recover from
I had to use ACS with WAAD in a previous application I worked on because (for some reason) the ASP.Net MVC anti-forgery protection relies on a claim of type
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
which is not issued by WAAD. I used a simple claim transformation rule in ACS to transform the WAAD issued claim of type
http://schemas.microsoft.com/identity/claims/identityprovider
into an equivalent claim of type
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
This was the only way I could think of to fix my issue at the time so it made it worth using ACS in my case. I never found out whether you could do this purely with WAAD (maybe using the graph API) because of time pressures on the project at the time.
In answer to the extra question in your comment, there is no way to replace the sign-on page if you are using WS-Federation or OAuth 2. A crucial point of those approaches is that the user only enters their credentials into the (trusted) UI provided by the identity provider. I think you can replace the image with one of your own though. Maybe you could gather the users credentials with your own UI and get a token using the WS-Trust endpoint, but this would not give you genuine web SSO in the sense that the sign-in session would not be automatically flowed between your different web applications.
Actually, there is a workaround to provision AAD as identity provider in ACS. http://www.cloudidentity.com/blog/2013/10/03/provisioning-a-windows-azure-active-directory-tenant-as-an-identity-provider-in-an-acs-namespacenow-point-click/
Basically, what has to be done is add the FederationMetadata.xml url when AAD is created as Identity provider in ACS.
After (in VS 2012) there is anew utility Identity and Access that will let you choose the IPs, and will create a new group in ACS, in which it has to be add the claim(s) transformation rule that we need (it is said in the post should be checked in code because claim changes)