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.
Related
I have identity server and 2 asp mvc applications.
I'm using openId Hybrid flow to authenticate. Each application has it's own client id.
Both applications are not connected and both are using different user account to log in.
Is it possible to sign in to app A without having access to app B which is the case. Currently SSO kick in when I log in to one of the apps(either A or B).
Is it possible to disable SSO ?
I assume your requirement is to perform some sort of Role check before allowing the user to access MVC APP 2. This is possible in IdentityServer3 using extensibility point called ICustomTokenRequestValidator.
For further details refer to this discussion here. Also a similar SO question here
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
I have a few websites that are running mojoPortal and Yet Another Forum, and several custom websites with ASP.net web forms (vb.net). I plan to add additional ASP.net websites too. I would like to have a single sign on for all sites, be able to setup groups and roles per site, and store the user's full name, phone, email, and other custom fields.
Each website currently has its own ASP.net membership database. There are about 1000 total users. It would be nice to be able to import the current members into Azure AD, but it will be OK if each user has to create a new login account. I've never used active directory but it sounds like Azure AD will do what I want. I plan to move all websites to an Azure virtual machine.
Before I start testing, I want to find out if single sign on will work with various ASP.net websites, and how complicated the setup and configuration will be. Can I import users to AD? I guess if a website supports AD or LDAP, then AZure AD will work? I'm hoping it will be as easy as adding the AD connection string in web.config?
Thanks!
It probably wont be as easy as adding the connection string. The Ad SSO service needs to be implemented using WIF (Windows Identity Framework) in your application. If you are already using WIF then it could be that simple. If not then you will need to implement WIF.
See this blog post to help you get a better understanding of what is involved.
http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing-the-developer-preview-of-windows-azure-active-directory.aspx