We've got a few apps that authenticate with the traditional username/password or email/password approach using forms authentication. We would like to slowly migrate these accounts to Windows Identity Foundation (WIF).
Mixing forms authentication with WIF is (for what I've seen) not easy. Basically it comes down to creating an STS to supply claims from the built in database.
If we chose to build another STS for hosting the accounts, are there ways to "merge" accounts from different authentication providers? (i.e. someone is already logged on and wants to merge an additional account from a different authentication provider.)
The idea is that we let customers merge accounts and after that slowly remove the old account database.
Mixing forms and WIF is not too hard:
http://leastprivilege.com/2012/02/02/mixing-forms-and-token-authentication-in-a-single-asp-net-application/
http://leastprivilege.com/2012/02/02/mixing-forms-and-token-authentication-in-a-single-asp-net-application-the-details/
Related
I'm working on integrating Azure AD authentication with various apps on different platforms.
Is there a way to get an authentication token id from a user logging in through a web api like 'azureadlogin.com/login?user=ted&password=passwordhash'
There seems to be ways of doing it through node or javascript or C# apps but I'd really like to just have a simple web request way of doing it as there are many different apps on different platforms that need to make use of this feature.
No.
There is a way to authenticate with username + password by doing a POST request and using Resource Owner Password Credentials flow, but I don't recommend it.
ROPC will not work if:
User's password has expired
User is MS account/federated from on-prem AD
User has multi-factor authentication enabled
You have a wide selection of authentication flows which work in all these scenarios too, and don't involve the user giving their password to you.
For example:
Authorization code flow
Implicit grant flow
Device authentication flow
You can use username/password authentication. But if your app has user interface, so it could popup the regular Azure AD login page, I would recommend not to use it. A major reason for using Azure AD (or other identity providers) is that the user doesn't want your app to know his password.
There's a sample which does what you want. The code in question is here.
The sample uses .NET and the ADAL.net library, but you can do similar stuff on other platforms.
Is there a service which would allow me to securely manage user accounts?
I see that I can use IAM to manage federated users with providers such as Facebook and Google. (see link below) But I am not seeing any guidance on managing user credentials for the web and mobile apps. Normally these details are stored in the database with everything else but I'd prefer to instead using an Amazon service if that is an option. Given all of the compromises in the last few years I'd like to take every measure that I can.
Manage Federation: http://aws.amazon.com/iam/details/manage-federation/
Once I have a user account I can use Token Vending Machine or the newer option Security Token Service to allow that user to access other services as that user such as S3. It does not look like I would use IAM to store user accounts for the website or mobile apps.
Should I just store user credentials in my own database and set it up with an OAuth 2 Provider so I can use them as federated user with AWS?
No, there's isn't any service that will allow you to manage users in your app.
If you don't want to store credentials in the database you can go with either OAuth 2 or OpenID. It's supported by all the main websites: Google, Facebook, Twitter, etc. You'll find that most web frameworks have third party libraries that support OAuth and OpenID. Wether you want to store your credentials in your local database or use OAuth/OpenID depends on how much you trust your server to be secure and how well are you backing up your database. Oauth/OpenID are generally pretty secure, they are widely used by thousands if not millions of apps.
The Manage Federation link only applies to users in AIM and how they can access the AWS Console or the AWS Apis only.
I am wondering if anyone has faced a similar issue. We are working on enterprise client portal that would be sitting on the internet. We also would like to add managements/client services portal that would be sitting on the local network and would use the same core libraries. For the external clients we would like to use forms authentication and for the internal application we would like to use windows authentication. Right now we are leaning to use sql membership provider on the external site and active directory membership provider on the internal site. We are working with mvc 4 so we use claims principal throughout the app.
The questions are:
1. Is there a way to combine users so we can enforce username uniqueness using existing providers?
2. We are considering using user email as the key. Is this a security issue. Can I get user email from AD membership provider?
I have looked into simplemembership provider. I thought that I could utilize webpages_OAuthMembership table to store "LDAP" users. But there is no oauth provider for that so I would have to write our own.
On another hand it seems that simplemembership is just a temporary solution until ASPNET.Identity come out in Nov.
Do you have any suggestions?
Have you looked into Windows Identity Federation (WIF), ASP.NET Identity, MVC5?
All your cases can be implemented using above.
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