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.
Related
I have an ASP .Net Core 2.2 Web API hosted as an Azure App Service. Then there is an Angular SPA which consumes this API, hosted on Azure Storage as a static website.
I am currently using Auth0 as our authentication and identity server. I am looking at replacing Auth0 with Azure, but I've spent a couple of days now trying to figure out what I should be doing and I am completely lost.
So, the purpose that Auth0 is currently serving, and which I would like Azure to serve instead, is to protect my Web API, as well as give it identity services so that the API knows which user is logged in. So when the front end makes a call to the API, Auth0 automatically redirects it to a login page. Here the user can log in using an existing account (including social accounts) or she can create a new account. Once logged in, Auth0 provides the front end with an access token. The front end then includes this access token in the header of every API call. The access token includes identity information which the API uses to know which user is making the call. All users are stored in Auth0. So when a new user uses the front end web app, Auth0 redirects them to the login screen, where they select "Sign Up", and create an account in Auth0. Any user can do this btw - it is a public web app which anyone can sign up and use.
So, when looking at using Azure instead of Auth0, what first confuses me is that there are various authentication services:
In the Azure portal, under my app service, under "Authentication / Authorization", there is a toggle switch labelled "App Service Authentication". If I turn this on, I can set up Authentication Providers.
In the Azure portal, there is Azure Active Directory, which I guess ties in with the above?
There is also Azure B2C.
What is the difference between Azure App Service Authentication and Azure B2C? Which one should I be using? What is the difference between points 1 and 2 above? Some examples I've seen use point 1 and some use point 2.
Sorry if this is a very vague question. I am just struggling to figure out in which direction to head. I found Auth0 quite simple, but unfortunately I cannot say the same about Azure authentication. I basically just want to figure out which Azure option would be best suited to replace Auth0 as I am using it now. Thanks
Azure B2C is the proper option to replace user authentication, however you would have to go with OWIN or another solution to actually provide application specific identity/authorization pipeline.
For public-facing site I would not go with straight up azure AD for customer logins, that’s targeted more towards enterprise customer with identities in federated, office365 or on prem Active Directory.
To be honest I’m surprised you’re planning on moving from auth0 to AAD. I’m thinking about doing the opposite.
I think the "replacement" would be using Identity Server, but there's no PaaS version for it on Azure. So you should go with Azure AD or Azure AD B2C.
If you want just to create users and groups you should use Azure AD. But if you have plans to enable 3rd party identities to access your app (such as Facebook, Google or Linkedin), then you should use Azure AD B2C. For more info, please read: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-overview
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.
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
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.