I've been browsing a lot on both StackOverflow and a bunch of different Microsoft associated sites and looking at examples etc but I think I'm missing a few key point to the problem in hand.
Scenario:
I'm developing a site that uses Yammer (Facebook style page for those of you who don't know) as a Identity Provider together with ACS to provide the security for my site.
Now Iv'e been trying to follow along with a bunch of exercises from MS on how to build those custom providers (Identity Developer Training Kit) but to the question, do I actually have to build them? Isn't there a way to configure ACS to handle my tokens from Yammer (Powershell commands?)? Or do I have to create a STS provider site and "bridge" Yammer and actually provide ACS with my "own" tokens.
So this question is a little bit on an extension on another one.
The ACS does not support OAuth 2.0 for authentication.
As I understand it; OAuth it for Authorization, the ACS is for Authentication.
It does support WS-Federation and OpenID (although only through the API) identity providers, you just need to add the configuration in the ACS.
So if Yammer has an OpenID or or WS-Federation, you're in business.
If not, it's fairly straight forward to build your own identity provider (thinktecture have one you can use as a starting point: http://weblogs.thinktecture.com/cweyer/2009/05/thinktecture-security-token-service-starter-kit---or-look-ma-even-i-can-have-a-sts.html) which you could use to 'bridge the gap' between some other authentication method and the ACS. You would just need to register it as a WS-Federation identity provider in the ACS using it's FederationMetadata.xml file. Your identity provider would then need to determine whether the user is authentic or not.
Related
I couldn't find any clear indication of whether ACS provided this functionality or not.
I would like to leverage ACS to do most of my authentication work, but I would also like access to the identity provider's access/refresh token that was sent to ACS. I can then make API calls to the identity provider to access the user's data such as calendar or profile information (assuming I've requested this access during the application authorization steps).
Is this possible using ACS? It seems as if ACS abstracts most of the underlying identity provider information out, and only provides an ACS token used purely for authentication purposes, not for use in talking directly to the identity provider.
Yes and no :)
ACS does support this feature for the providers that do support that. It is not explicitly documented, because it is not special. ACS does not "just create own token for pure authentication purposes".
If you take the FaceBook IdP, ACS does provide you the FaceBook token, which you can use to query the FaceBook Graph API. And what permissions for the API you will get, depends on what permissions your FaceBook Application will require from authenticating user. I am not sure about the level of sophistication of FaceBook consent framework, but the last I plaid with it, the authenticating user could only Accept all required consents, or reject all. He was not able to selectively chose which consents to grant to your application, out of all requested.
Having said that, from Google Authentication Provider, you do not receive additional tokens. At least with the old OpenID 2.0 imeplementation. Now with the deprication of OpenID 2.0 and moving Google to OpenID Connect, there is a requirement that you explicitly register your ACS Namespace as application with Google. At that point, I assume (speculation of mine) you may declare requested consents, just as you do with FaceBook. And if Google sends the token, you will definitely receive it in your application through the ACS.
ACS is super powerful service that will not die. As in the referenced blog post, all of its features will sooner or later be moved to Azure AD itself. And a migration plan will be provided (hopefully :) ).
But also, note that ACS do only talk with Yahoo, Google, Facebook, Azure AD and any WS-Federation IdP. And WS-Federation protocol is not known for being very flexible and giving you the flexibility you want. ACS in theory also supports OAuth 2.0, but its support does not include Federation, only local identity management (identities local to ACS self).
Also, note, that ACS is being used by a lot of Microsoft owned services, like Visual Studio Online, Azure Service Bus and others. ACS is neither dead, nor will just die letting all its customers on the wild.
You can decide to use it today. Or you can decide to use whatever features are today available in the Azure AD itself. Or wait until ACS is fully migrated to Azure AD.
I understand ACS is being phased out in favor of WAAD. As I prepare to delve into Azure for the first time I have a few questions. I already have an Azure account (linked with my MSDN account).
Under ACS, I would create a namespace for my application, configure it with Idps and claims mapping. I would point my application (a RESTful API via WebAPI2) to the ACS federation endpoint for my namespace.
Under WAAD, I've seen where I can add my own application. When I create the new application, is this creating a tenant in my directory? I dont see where I can register my Idp's and configure the Idp's for my relying party. In addition to authenticating via social networks (like facebook/google/etc), I'm going to want to write a custom Idp to hit against my on-premesis user store. Is this possible in WAAD? Finally when creating the application (tenant) in WAAD, its prompting me for a Signon URL. Isn't WAAD supposed to manage the signon, the way it did under ACS? when I defended a website via ACS, the user was redirected to the ACS sign in page, where they could choose from a list of Idp's for login. Why then, under WAAD, do I, the app developer, need to code a sign on page? I'm pretty confused about this.
WAAD does not replace ACS. WAAD is a single identity provider (IdP), whereas ACS can act as a Security Token Service (STS) for multiple IdPs, but is not itself an IdP. Think of ACS more as a broker that has taken some of the work out of integrating with some of the common identity providers out there (Facebook, Google, Yahoo, Live, etc) so that you as the application developer can code to one interface instead of multiple.
My suggestion would be to continue to use ACS as your single point of contact for federated identities and add WAAD as an additional IdP to those applications in your suite that require it. This is a pattern we follow in a number of our applications where we use ACS as the main STS and then expose one or more of the IdPs to an application depending on our needs.
As to your question about a custom IdP pointing to an on premise user store you might consider using Thinktecture Identity Server instead of rolling your own. You can expose Thinktecture Identity Server from ACS just as you would any other IdP in your suite.
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?
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)
I am looking at Windows Azure ACS as an alternative to implementing my own username / password scheme in my app. This will be a publicly available website.
In addition to using SSO providers such as Google or Facebook, can I use Windows Azure ACS to support username/password authentication?
I see that it supports Active Directory as a provider. I am not sure this is the right thing as I have always thought of Active Directory as an "enterprise" provider.
Windows Azure ACS does not support username/password authentication in the form you need. Shahin outlined it in details.
Your options really are:
Windows Azure Active Directory (WAAD)
Identity Server (IdSVR)
While classic on-premises Active Directory deployed with a Domain Controller option is indeed quite enterprisy, WAAD is not exact copy of the same in the Cloud. I would actually recommend that you give a shot and try out. Using the WAAD Graph API you can fully automate user management in WAAD.
Your second option is based on IdSVR. This is full-featured Identity Server and Security Token Service. It is developed against the best practices in security and is quite easily extensible! While it does not provide out of the box support for user management (user registration, password reset, etc.) it is ASP.NET MVC 4 application. So you can very easily add this features yourself. There actually is an open enhancement planned for User Management API and UI.
Both WAAD and IdSVR integrate well with ACS, so you can provide seamless support for social identities along with own login.
Another service that is still in Beta/Preview is the SocialSTS project. It is kind of extension to Azure ACS and is designed to help you add more identity providers (such as LinkedIn, Twitter, GitHUB, Amazon Login, etc) to your Access Control Service.
You can authenticate directly with the ACS by using Service Identities, but they are not intended to be used for end-user authentication, as the page explains:
Service identities are not intended to be used as end-user credentials. In ACS, service identities are most commonly used in REST web service scenarios, over the OAuth WRAP protocol, where a client requests a SWT token directly from ACS to present to the web service.
I believe this is the only way to directly get a token from the ACS.
I understand that WAAD is meant for internal organizational accounts. I understand the concepts behind ADFS and other "AD in the cloud" related topics. But is there really anything that is preventing WAAD to be used for public accounts?
I want to build a public facing web site using ASP.Net MVC. I will use WIF to implement claims authentication and plan to use ACS as a claims federation provider. I want to allow the end users to login using Social Network Accounts (out of the box with ACS). But I also want to allow users to register their own user name and passwords for my web site. Can I use WAAD for this part?
Of course I could build my own custom STS. Or I could use Thinktecture IdentityServer for this purpose. But there are some clear advantages of sticking with WAAD:
simplicity (to set up WAAD as a STS to ACS takes just few clicks)
performance, security, reliability guaranteed by Azure SLAs
Is there any disadvantage to this approach?
You certainly can use WAAD for creating user accounts. You, also of course, have to force users to use e-mail style logins.
There is however one (BIG in my opinion) disadvantage of WAAD against ThinkTecture's Identity Server: WAAD does not have a user registration / password management / password reset flow.
UPDATE (29.07.2014)
Today WAAD provides Self-service-password-reset as part of Premium Features. However still no self-service-user-registration. Frankly I do not expect to ever see self service user registration, as WAAD is targeting enterprises, and not your specific scenario.
To implement mentioned flow in WAAD, you have to developed your own MVC App from scratch, that uses the Graph API for all mentioned scenarios.
On the other side, you have Identity Server, which has thousands of downloads, which is developed by the Gurus of Claims based authentication and security. Identity server has very rich and easy to use extensible structure. While it also does not provide the user registration and password reset flows out of the box, it is already an MVC 4 application with very rich extensibility points.
Setting up an Identity server for run in Azure is also extremely easy. And setting up Identity Server as Identity provider in Azure ACS is just couple of clicks on the management portal.
You say that WAAD is SLA backed, highly available, etc. But your Identity Server deployment on a Cloud Service will be SLA backed too if use at least 2 instances of a Web Role.
If I have to chose whether to extend Identity Server to support user registration etc, or to create entirely new application from scratch that uses WAAD GRaph API for that feature - I would use Identity Server.
As of September this year the Azure B2C preview is there. This should satisfy the scenerio of self service user registration and different identity providers (Facebook, Google, Microsoft...). These are all serviced from AzureAD.
Azure AD b2c
There is als a complete MVC sample available
Azure AD b2c MVC Sample