We have a client using SSO already with us, they post SAML assertions to one of our .aspx pages, which decodes the assertion and authenticates the user. We have been asked by a second customer to user SSO as well, but they use Active Directory Federation Services.
Having read through the documentation, I can't figure out how to use my existing solution for AD customers too, as they don't seem to send SAML assertions, but "claims", which at the moment I'm not sure what the difference between this and a SAML assertion is. Anybody could shed some light on this? If I need to write a new aspx page for my new AD customer, what would be the starting points for both ends (customer and our application)?
Claims ARE SAML assertions. The ADFS returns a SAML token including assertions (claims) and the signature.
If you already have your identity provider and you want to integrate it with ADFS, you either federate ADFS with the identity provider (so that ADFS allows users to select the authentication source) or vice versa.
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.
I need a good advise and wanted to know whether a solution is feasible or not. Right now one of my customer has a common login application which is based on Forms authentication(ASP.NET) using membership provider. All internal users use their AD credentials to logon and external users use custom username and password. Both are wrapped via Forms authentication. Now the new proposal is to replace this Forms authentication with ADFS. I have gone through various articles over internet and not able to come to a conclusion. Let me list my findings so far with ADFS extension points.
1) It is possible to add a custom attribute to ADFS claims by the approach mentioned in https://blogs.technet.microsoft.com/cloudpfe/2013/12/27/how-to-create-a-custom-attribute-store-for-active-directory-federation-services-3-0/.
2) It is possible to add a second level of authentication( or multifactor authentication) via the approach https://blogs.msdn.microsoft.com/jenfieldmsft/2014/03/24/build-your-own-external-authentication-provider-for-ad-fs-in-windows-server-2012-r2-walk-through-part-1/. Here I understand that after first level authentication done by AD then only our external provider will come into picture.
So I have a general question that is it really possible to achieve what I am looking for with ADFS. Please let me know.
This is based on where the user accounts are stored. If both internal and external users are in AD, you can just redirect to ADFS.
If internal is in AD and external is in an untrusted or other LDAP source, using ADFS 2016 you can link to both these account stores and still offload authentication to ADFS.
If external is in SQL, you can either use a virtual directory in front to project it as an LDAP store (previous option) or use IdentityServer.
If externs is something else, you'd need IdentityServer.
Thanks //Sam (#MrADFS)
Yes - you can add a custom attribute store.
Yes - you can add a custom authenticator.
A better way might be to use thinktecture's IdentityServer 3.0 for the ASP.NET Identity part and then federate IdentityServer and ADFS.
I'm having trouble tying all of this together. Partially due to lack of understanding, and partially because I've not use OpenAM before.
I'm trying to implement Single Sign-on. Here are the players.
OpenAm. https://www.forgerock.com/en-us/products/access-management/
A 3rd party proprietary app that can use it's own username/password database, or authenticate against an SAML or OpenId provider.
Several In-house applications written in either angularjs or .net webforms.
An in-house REST API written in nodejs.
I need to be able to have a user sign-on/register in openam, and then they don't sign-in to any of the other applications. We see this all over the web, so the use-case is pretty normal, but I've never actually implemented it myself before.
See what I'm trying to do using the image below for starters.
Here's what I'm stuggling with:
For SSO purposes, OpenAM seems to store the authenticated user information in a cookie. How does my Proprietary app pick up this cookie and use it if it can only authenticate via openid or saml? It can't use the openam API by going through the /json/* endpoints.
With the in-house apps, I'm assuming I can just pass the cookie along and the appropriate parties can validate the cookie's session info or token and that's that. Is this correct, or am I looking at this wrong?
Can I have the user login to the OpenAm login page, and then use the /oauth2/* endpoints to validate the user's requests? I could see this working better, but am unsure if this is how it's supposed to happen.
Basically, I feel like I've scrambled my brain this last week trying to sort this out. I need some help to get some direction here. As I said above, a good portion of this is new. I've done front-end->rest api->database using a token, but this SSO scenario has given me a real headache.
Any help would be appreciated.
It sounds to me that you miss the "redirection" aspect of SAML SSO. I'll try to explain how it works in a nutshell:
Step 1:
When a user sends a request to one of your in house applications (call it the Service Provider, SP, from here), the SP detects that this is an unauthenticated request and redirects the browser to the OpenAM server (call it the Identity Provider, IdP, from here).
Step 2:
The IdP analyses the redirection request and expects to find a "SAML authnResponse", this is encoded XML metadata added in the redirection request by the SP. It finds out that your SP wants to authenticate a user. The IdP will respond to the request by showing a login page. Here the user can authenticate to the IdP. After the user succesfully authenticated to the IdP, it will redirect him back to the SP adding a "SAML authnResponse" to the request.
Step 3:
The SP will analyse this "SAML authnResponse", which is again just a form of XML metadata. If the validation of the signature is OK,find out which user successfully authenticated, create a session for him and redirect him to the resource he initially tried to access.
Remark 1:
In Step 2, if the user already authenticated to the IdP before, he will have an active session to the IdP. The IdP will not require him to login again but just inmediately redirect him back to the SP with a valid "SAML authnResponse". In this way the user will barely notice all these redirects and it will look like he 'seamlessly' got access to the SP.
Remark 2:
So don't worry to much about cookies, they're used by the IdP to recognize already authenticated user sessions etc. but you should only bother with redirects and analyzing the SAML Responses and Requests. Does this make sense?
Remark 3:
The way how the browser (GET 302 or JS POST) of the user will be redirected depends on your chosen "SAML Profile".
I have a .NET Web API with a bunch of end points/methods that an Angular App calls. I want to now implement the login system against our active directory, and wondering what my options are.
Back in the days, it was simple: windows or forms authentication, and then just some simple configuration in the web.config, and may be a custom provider. But now it seems like there are a lot more options with OWIN, OAuth, token based authentication, etc.
Where do I start? I have a form with username, password, and a login button on the Angular app, and I have the active directory in the backend. What should happen after the user hits the login button? Any direction would help.
Thanks.
Well, it depends on what you actually need.
If you want to authenticate only AD users then you can try authenticate in AD on their behalf and in case of success you return either token or authentication cookie.
But I don't think it is a good idea to make users use their domain password unless you have two factor authentication.
It's better to extend AD schema with additional data for authentication through your service or even to have standalone auth server with associated domain user info. Look how it is done in SQL server (but in reverse direction): you need to define internal user corresponding to domain login. This approach allows you to have users that do not belong to AD, sometimes this can be important for outsourcing some tasks.
Look at IdentityServer
I have an ASP.NET application which uses login cookies already. I need to provide a link in my application upon clicking which the user should be able to access their info in SalesForce.com using SSO. I'm planning to implement this link as an ASP page that constructs a SAML assertion with the corresponding username in SalesForce.com, posts the SAML assertion to SalesForce.com SAML Endpoint URL, receives the SAML response from SalesForce.com and redirects the user to the session URL contained in the response.
Has anyone tried this approach instead of using a dedicated SSO server (such as OpenAM) ? Are there any issues in this approach ?
You won't be able to do that, because it would require you to implement most of SAML IdP (identity provider) piece on your own.
SAML is a complex standard involving multiple interactions between IdP and SP (service provider), it is so much more than just sending an assertion.
To enable SAML you'll need to install IdP (like OpenAM), connect it to your user database and to convert your application to SP.
Wikipedia has more detail on SAML iteractions.