This is a follow up to my question on ASP.NET MVC / Web API Custom Authentication. The answers I was given told me to investigate claims-based authentication protocols and I've been reading through the following book to try and gain a better understanding of Microsoft technologies that will allow me to do this.
According to the linked book, you can use Active Directory Federation Services (ADFS) 2.0 to issue claims. What isn't clear is whether the users are required to be stored in Active Directory. Let's say I have an existing legacy application which handles authentication and in which user information (username, password, email, etc.) is stored in an Oracle database (as per my previous question), can I still use ADFS to issue claims or will I need to build my own claims issuer (STS) into this existing application?
Given the Active Directory in Active Directory Federations Services it would seem that having the users stored in AD is a requirement but the book also has the following image
and also this
ADFS requires users to have an account in Active Directory or in one of the stores that ADFS trusts.
which is adding to my confusion. Can someone help shed some light on this?
You can use an ADFS Attribute Store and then create a Claims Provider Trust that has claim rules that query the attribute store. This post has someone using a SQL attribute store to SQL and then a linked server to Oracle. There's also a recommendation to use a custom attribute store and query Oracle from it. I've used both types of stores and it's maybe a bit of a question of what do you want to manage and maintain over time, code or SQL. I may lean towards the custom attribute store.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/3418078f-1bb5-4f5f-9d6e-6907d0222600/using-an-oracle-database-as-an-attribute-store?forum=Geneva
In ADFS 2.0, 2.1 and 3.0, it is mandatory to have users in Active Directory for authentication.
Once authentication is performed, ADFS can retrieve user information from any sources to create the token; these sources are called "attribute stores". As shown in your diagram, ADFS provides attribute store for AD, ADLDS and SQLServer. If you need to access other systems such as Oracle, you'll have to build a custom attribute store (there are examples on technet on how to do this).
Note: in the upcoming version of ADFS on Windows Server 2016, you'll be able to authenticate users in any LDAP store.
Related
What is the best method of securing a REST Web API with the following requirements. The system has an Angular JS frontend with the REST APIs implemented in ASP.net.
There are two "roles" in the system, users will have one of the
roles. One role should allows access to some APIs (call it "VIEW"),
the other role allows access to other APIs
All users are in Active Directory, so if I have a username, I can check what role they are in- Some clients are on Windows boxes, the others are on Linux
I would like to persist the session so I don't have to look up AD for every API call
I would like single sign on. On the Windows machines, I don't require them to enter user and pass as I already can retrieve their username using Windows Authentication.
I believe that Oauth would be my best option.
There are two "roles" in the system, users will have one of the roles.
One role should allows access to some APIs (call it "VIEW"), the other
role allows access to other APIs
For role based authentication, you can use [Authorize("Role" = "Manager")]. The token will be provided by the identity server and will contain the claim as Role.
All users are in Active Directory, so if I have a username, I can
check what role they are in- Some clients are on Windows boxes, the
others are on Linux
If you have ADFS then you can have an Identity server that trusts the ADFS. The ADFS will provide a token which will have the claim for role and your Identity Server will do the claims transformation and will return the same Role claim back to angular app.
I would like to persist the session so I don't have to look up AD for
every API call
For this while requesting the token, you can ask for offline scope so the Identity server will provide the Refresh Token with Access Token so you don't need to ask for AD again and again.
I would like single sign on. On the Windows machines, I don't require
them to enter user and pass as I already can retrieve their username
using Windows Authentication.
For this one, you can have your Identity sever trust the WSFederation for windows Authentication.
So basically you need to setup Identity server that will provide you with the token and the REST API will use that token to verify claims to return the correct information back to the user.
I am not sure what you expect exactly. Anyway, first I'm gonna reformulate your question with requirements:
you accounts and role are in active directory
you want to manage roles based on an active directory group
you want anybody whatever the system (windows, linux, mac, mobile...) to connect on your application using the same authentication
you want to avoid your AD to be hit constantly (not at any call for example)
if the user is connected on an application that uses the authentication system, he doesn't have to do it so again on another application that uses the same authentication system
If these requirements are yours. I believe the only standard (and clean) solution is to use OAuth. I'm not gonna go in detailed description of OAuth, but this authentication protocol is the most standard one on the net (facebook, google, twitter...). Of course as you don't want to use facebook, google or twitter accounts in your business applications but your active directory accounts you'll have to install/setup/develop your OAuth identity provider using accounts of your active active directory server. Your choice will depend on how well you know ADFS protocol and its different flows (code, implicit, assersion) You have two solutions for it:
Use ADFS: install ADFS; it provides a OAuth portal that will work out of the box with asp.net mvc. This uses the code flow of OAuth that is the only OAuth flow supported by ADFS. For roles and its related AD groups, you'll have to map role claims with AD groups. (it's in the setup of adfs, you'll find many tutos on the net). You'll find lot of tutos as well about how to use ADFS with asp.net mvc/asp.net webapi. I mention .net here, but every technology has an implementation for OAuth authentication (nodeJs/express, php, java...).
Use thinktecture identity server (.net technology). This will provide all the foundation to implement a custom identity server with the least effort: http://www.thinktecture.com/identityserver / https://github.com/IdentityServer/IdentityServer3. It contains an addin to plug its accounts to active directory. With this, you can use implicit and assertion flows.
Use oauth2orize (for nodeJs): https://www.npmjs.com/package/oauth2orize. This will permit you to make the same than thinktecture identity server but in nodeJs. Apparently you'll have to make all the wirering with ad manually. With this, you can use implicit flows (not sure about assertion flows).
At application side, most of frameworks can authenticate easily using OAuth with a lot of existing frameworks. For example, even if you make a single page application, you can use adal.js or oidc.js for angular if you use angular. As I mentioned above, all this is taken in charge by asp.net mvc/webapi out of the box but I know it's the case for other server technologies. If you have more questions, don't hesitate as I'm not sure of what you expect exactly.
We have a hosted .NET web application (Windows Server 2012 R2 environment) and we need to provide Single sign-on (SSO) to users from a corporate LAN environment. We have used ADFS to enable SSO and it is working as expected thus when a user hits our web application login page URL he is authenticated against ADFS and is automatically logged in to the application.
We have an additional requirement where we need to obtain a list of all users, their groups, email addresses some additional information periodically from their Active Directory so that this information can be bulk loaded into our web application however since ADFS is implemented we do not have direct access to the Active Directory.
Is it possible to connect to ADFS and obtain a list of all users, their email addresses etc. programmatically?
If the above is not possible then what is the recommended approach for this kind of a setup?
Thank you.
No, this is not possible. There is no such API because with SAML and WS-Federation, users can come from anywhere. This does not have to be AD, technically it's possible create a "Log in with Facebook" implementation.
What would you need the information for? The user's claims contain all information which you might need (user name, e-mail address, group memberships).
If you really need that information about all users in your application, perhaps ADFS is not the solution you are looking for.
As Alex mentioned above - the way it works, ADFS does not provide any way of importing data from the AD or other trust stores. It just gives you the information that are carried over with the token.
In case you need more information, you should extend the number of claims being issued by ADFS. You can then collect the information - when the user comes for the first time, use the data from the token and fill the profile. If it is returning user - update the information if necessary.
The other solution (but I wouldn't say it's recommended - rather a workaround) would be to implement custom solution for importing information from AD to your application. I'd say it's fair as long as you use your local AD for reading this data. In the moment you decide to extend the access to third party (e.g. partner company), which might be using different identity provider, which doesn't have to be backed by Active Directory any more - you find yourself in tough spot.
I'm trying to set-up ADFS as a relying party, and I've read several tutorials which requires me to install ADDS first before I can configure ADFS.
Question: Is it possible to configure ADFS as a relying partner without utilizing ADDS? The user info will be validated from an SQL server instead and not from ADDS.
Based on this link:
https://technet.microsoft.com/en-us/library/cc758187%28v=ws.10%29.aspx
Claims-aware applications do not require a local user store. All information about a given identity is contained in the token that is presented by the application. The application may store additional information that links to the identity that is presented in the token, but a user account in Active Directory is not required.
I think this answers my question.
I am using VS 2013 Asp.net 4.5.1 and created an internal webforms app using the Individual User Accounts option for Authentication. I want to use LDAP to authenticate the users and use the SQL DB that was created for Individual User Accounts option to hold the users info and roles. We don’t have Active Directory Federation Services (AD FS) so I can’t use the On-Premise Authentication method.
The AD username will be stored in the SQL DB
How can I authenticate the users using LDAP and then use the AspNet.Identity.EntityFramework to get to the users info and roles from the SQL DB?
You can use this implementation like an example, it is a customer UserStore for RavenDB:
Customizing ASPNET Authentication for RavenDB
There's this series of videos explaining how to work with security in .NET (the second video explains how to do it).
Customizing ASPNET Authentication with Identity
Brock Allen discusses how to implement an "external login" in his comprehensive article on the new identity patterns using External Logins.
Active Directory Federation Services (ADFS) supports a lot of identity protocols including SSO. However, If it's just POWA (plain ol' windows authentication), IIS will support that out of the box. You would simply specify your Active Directory(AD) user/AD Group in your web.config Authentication node and leverage the Identity.Name field to look-up users' info in a lazy-load and / or request-cached fashion.
If 's claim's based authentication using ADFS, you can emulate how that works using the Identity and Access Tool and choosing the "Use Local STS" option.
Why not keep the profiles and roles in LDAP (ADLDS) as well? ADLDS does an excellent job of tracking multi-valued attributes which I find useful. The role (group membership) in ADLDS is reflexive (you can query the role for members or query a user for their membership in roles). ADLDS also insures the referential integrity - you cannot have a member in a role if the member doesn't exist. I think you are facing some severe referential integrity problems by having accounts and profiles in two separate stores or learn to love the distributed transaction coordinator.
I have an existing production application that uses vanilla ASP.Net Membership for authentication.
However, I'd like to provide other means of authentication as well as the current ASP.net membership system, such as Facebook.
The Windows Azure Access Control Service makes this extremely easy and straight forward. Provided, that is, you're starting a new web application from scratch.
So, in this case, how do I
Integrate the Access Control Service authentication into my app without affecting the current login system and its users?
Migrate users over or Link logins? ( not sure if this is even possible)
Thanks all
Roberto
You need to create a custom identity provider based on your membership database. See this article on custom WS-Federation Identity Providers that can be integrated to access control: http://msdn.microsoft.com/en-us/library/windowsazure/gg185933.aspx
Also see this article on one that was written on top of the membership database: http://blogs.msdn.com/b/vbertocci/archive/2009/04/23/enhance-your-asp-net-membership-based-website-by-adding-identity-provider-capabilities.aspx
Approach of creating an identity provider (IP) based on your ASP.NET membership database which Paul Tyng suggested is valid.
However, it means that if you just create an IP you'll allow log in to all people who are authorised with other IPs (e.g. Google or Facebook). I'm guessing it's not what you want - you'd still want people to first register (either plainly with username-password or with their external identity). If that's the case then your task is the following:
Add a data store for users' external identities which is related to your existing Users table.
Modify the ACS login handling within your application to check that the identity returned from ACS actually exists in your members database.
Perform member log in (instead of federated log in) if you found the returned identity in your db.
Add external identity tie in during the registration process so your Identities table can be actually populated.
(optional) Re-use the bulk of the #4 mechanism to provide an ability to attach external identity to existing user accounts (i.e. I already have a normal membership with you and now want to add an ability to log in with Google as well, for example).
There is no one single tutorial/walk-through to achieve this (or I have not found one) so I had to pull bits from a variety of sources to make it work. Please let me know in the comment if I understood your requirement correctly and I'll add a guide on how to set this up. Cheers!
Might be a bit late, but check out the following blog posts by fellow Windows Azure MVP - Dominik Bayer:
Mixing Forms and Token Authentication in a single ASP.NET Application
Mixing Forms and Token Authentication in a single ASP.NET Application (the Details)
Replacing ASP.NET Forms Authentication with WIF Session Authentication (for the better)
Invaluable readings which will help you in any way!