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.
Related
Current State: I have a mobile application that signs users into Azure AD via OAuth using the PKCE flow. Once authenticated, the app uses a token to get various forms of data from some APIs.
As the application has evolved, the need to integrate SSO with another web application has come up (and there will be further service providers added as we move forward). It will act as a service provider and it supports IDP initiated authentication via SAML.
Question: once this service provider is configured under the AD tenant, is there a way to exchange or translate our OAuth token for something that can be passed on to the the SAML SP without having to re-authenticate? Am I even thinking about this in the right way? I'm mainly curious if we will need to re-implement authentication in the mobile app to support SAML (i.e. stand up some sort of web-based SAML service that can act as a proxy for the mobile application)? If that route is a necessity to accomplish our requirements, I'm assuming there's a way to still get a valid OAuth or equivalent token we can use to send to our APIs.
Apologies if this is a repeat question, but I couldn't find anything with similar specifics. Thanks in advance!
You can surely use the OAuth 2.0 OBO flow that allows an OAuth2-based application to access web service API endpoints that consume SAML tokens. You can read more here and it has some really good guidance on how to achieve the same:
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow#saml-assertions-obtained-with-an-oauth20-obo-flow
Make sure that you SAML request is well formulated per the details mentioned here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol
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'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.