Our SAAS system is currently using standard Microsoft.AspNet.Identity.Owin libraries to authenticate users via Bearer tokens, as well social logins such as Facebook/Google/Twitter/etc.
Some of our users are asking for us to start allowing of authentication via ADFS.
I'm trying to understand how this can be done. Unfortunately, all of the blogs appear to dive right into the details without providing a good overview as to what's involved. Furthermore, most blogs talk about trusting a specific Active Directory, while we need to trust a whole number of possible customers' active directories - and do it dynamically. IE: customer registers for an account using custom username/password, then provides our SAAS application with some information about their AD. Afterwards, our SAAS application should trust authentication for users in that AD (just the auth part)
Can anyone provide information on what's involved?
TIA
Agree with #vibronet's points.
Another approach would be to add STS support to your SaaS application. This could be either WS-Fed or SAML. You have tagged the question with Azure so AAD could be an option.
You could then federate with any number of other STS's (like ADFS). Note as stated that each ADFS has to agree to add your metadata.
Another approach would be to use IDaaS (e.g. Auth0, Okta). These would do the Identity heavy lifting for you and would essentially provide the STS capability.
The question has 2 parts,
how to work with an ADFS instance and
how to deal with an arbitrary number of ADFS instances from different
owners.
The answer to 1) is to use the WS-Federation middleware, which can be added alongside the middlewares you are already using. However the initialization of that middleware requires knowledge of the location of the metadata document of the ADFS you want to target; furthermore, the ADFS administrator must provision your app explicitly or no tokens will be issued. Hence, the flow you are suggesting (temporary username/password and subsequent details exchange) might be tricky - but not impossible.
About 2) there isn't a way of wiring up an arbitrary number of different ADFS instances unless you modify the middleware setting pretty heavily. The actual answer is that the standard practice for dealing with that scenario is to rely on one intermediary ADFS (or equivalent) that can broker trust toward all others, while your app only needs to trust the intermediary ADFS.
Related
Could you help me determine which authentication protocol I should use for the following use case? I am new to this area of development and am a little bamboozled with all the technical information out there - so a 'for dummies' answer would be greatly appreciated.
I have an online learning website that hosts courses in English Language. A requirement has arisen that we should integrate with 3rd party Enterprise Systems (because we sell the courses to Enterprises).
The primary requirement is to allow 3rd party systems to redirect their users to my site and have them access it with there 3rd party system credentials (I believe this is called Single Sign-on?). The 3rd Party systems are obviously remote systems and I am focusing more on capability than 1 specific customer / integration.
So, what I am trying to understand, is what capability should I offer to allow this to happen? I am trying to develop a generic 'developer toolkit' so that I don't have to be bogged down in lots of individual integrations as and when they arise.
I have read that there are lots of protocols / things in this space (SAML, OAuth, OAuth2, OpenID, Shibboleth, etc) - so I wondered where I should focus my attention and research? Which is the most common among Enterprise systems (CRMs, etc)?
Also, as a sub-question. Is OAuth deprecated or sneered upon now that OAuth 2.0 is released?
Any help is truly appreciated!
Thanks all.
SAML 2.0 is the most popular protocol for Single Sign On when it comes to Enterprise systems. Most if not all enterprises are able to provide SAML based SSO for third party websites.
Ideally, if correctly implemented the enterprise would need to configure their system to send your website SAML assertions (Identity information in the form of XML) and you would the information in the assertion to log the user in.
The Enterprise would be called the Identity Provider (IDP) in this case and your website would be called the Service Provider (SP)
There are a number of open source libraries available that allow implementing SAML (Spring etc.), alternatively your existing servers may have the capability as well.
Once you have the base implementation done, you can then choose to do two things:
If the user does not exist in your DB, create a new record and allow the user access.
The enterprise that you are integrating with must supply a list of users before hand and then you can allow only the users that are present in the DB.
Although the second option has a lot of overhead and not used very often.
---------------------------- Answer to Comments-------------------------
It depends on the way you would setup the interaction.. There are two ways to setup SAML SSO:
SP initiated SSO: This means that the users always access your site and then is redirected to the IDP for authentication. The SAML token is sent back to your site post authentication.
IDP initiated SSO: This works in a way that the IDP generates a SAML token and directly posts it to the SAML endpoint of your website.
If you are using option#1 and users are already logged in step C would not be needed since the user is already logged in and the token can be directly generated.
For option#2 only the steps D and E would be needed. I would however urge you to strongly to not omit the SP Initiated SSO implementation since some IDPs do not support IDP initiated SSO.
Hope this helps
Avi
I am working on an internal authentication system for users of a set of of RESTful web applications. Our intention is that a user should be able to sign-on once via a web form and have appropriate access to all these RESTful applications in our domain, which may be distributed in a private cloud across many servers. (I understand already that having a single authenticated session is not aligned with a pure RESTful approach, but this is a usability requirement.)
The applications themselves will be written in a variety of programming languages so a language-neutral approach is required. It was suggested to me that we might use OpenID or OAuth or a similar framework to handle the authentication but my understanding is that these are intended for third-party services and not the first-party services that would share data on our internal system. In this case, we might have a central provider service with all the other applications treated as third parties (or relying parties).
Questions:
Are OpenID/OAuth suitable for authentication among first-party services?
If so, how would one be advised to set up authentication for this use case?
Wouldn't a user have to grant individual permission to each first-party server that they wanted to use, just as they would need to grant individual permission to any third-party server? I think this would violate the requirement of having a single sign-on for accessing all the first-party services.
Are there good examples of sites supporting this first-party use case?
What would be a good alternative framework for this first-party use case?
You do not need OAuth for SSO services.
The primary use/advantage of OAuth is, as you know already, granting access to a 3rd party app to access/use your resource in a controlled manner.
Rather than having an authentication/authorization server that you would need for OAuth, why not use a single log in service across all your APIs. An OAuth access token is totally different from what you need.
As far as I understand, what you can have is something like OAuth in a way that your server vends out tokens to the app. (I'm assuming that it's a totally internal system, so tokens cannot be misused).
So basically what I'm proposing is:
When an app tries to access the first API it's redirected to a web-form.
The user enters credentials and is taken to the DB for verification. Let there be a service that generates a token for the user/app
Next API access request would be made with that token - the token uniquely identifies the app
Depending on the level of security you need you can sign some text using HMAC and send it as token, or if its totally internal just generate a unique identifier for the app/user and send it to other API
On receiving the token, each service first calls the main server with the token and internally fetches the corresponding customer/user ID and performs the required function.
In short separate the login + token generation + token verification into a different module. All APIs should use this module for login/token verification.
What I have proposed here works like OAuth but all security aspects have been stripped down since you want to use it in a private cloud.
Oauth supports multiple different kinds of flows. You can use the client crendentials flow from Oauth 2.0 to avoid asking the user to grant permission for every app (this is intended for the cases where you control both the server and the app or where you want to preauthorize certain apps). This post does a good job explaining everything: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/
I'm working on a WCF project that will be our new service layer.
These services will be called by 2 separate clients, the first of which is a WPF application and the other is an ASP.Net web application. The WPF client will be run by internal users and will authenticate with the service via domain authentication and run under the context of that user. The other will be used by external users and needs to authenticate using some separate mechanism then impersonate a "WebUser" account on our domain.
I'm reading a bit about Windows Identity Foundation and it sounds like this might be a good fit. Am I right in thinking I could have 2 token services, one for domain authentication and one for something like ASP.Net membership authentication (Or some similar equivalent) and have each client get it's token from the relevant STS and pass that along to the WCF service?
I'm assuming there is an STS I can use out of the box for domain authentication, but will I have to implement the second one myself to authenticate web users? I can't find a lot of information on this.
Am I thinking along the right lines or should I just be creating duel endpoints for each service each with a different authentication mechanism? Or should I be doing something completely different?
Thanks
The big advantage of using Claims-Based authentication / WIF is that both the task of authenticating the user AND the administration of the user's properties are moved way from the applications to the STS/Identity provider.
You are developing a service layer but the true benefits of using WIF will be for the applications written on top of your layer. The WPF application will no longer need to connect to the AD and fetch the user's groups to figure out what they are allowed to do. The groups will already be visible as claims in the token the user/WIF provides.
The web application (is it just one web application or more?) will no longer need the ASP.Net Membership database with accompanying user administration. This functionality gets moved to the STS.
There is a cost. (There always is, somehow...) Claims-Based authentication has a rather steep learning curve. It takes a while for the quarter to drop for all people involved.
So the answer to your question depends on what kind of users the web application(s?) built upon your service layer have and how many. And how much they wish to know about them. Can you perhaps trust Google / Facebook / Windows Live for authentication? Are the users already in an existing database within your domain? How much work will it take to maintain the user directories? Do your marketing people wish to send them emails regularly? Et cetera.
This is probably not just for the service layer's developers to decide, but something to discuss with people in the rest of your organisation.
If the benefits are not particularly big, the alternative is to simply keep these responsibilities at the web application's server. Each web application will have a good old ASP.Net membership database, it'll authenticate the user all by itself. When asking queries from the service layer, it'll present its web server certificate plus specify the user's name and type.
If the benefits are big enough, you can in principle use ADFS 2.0 for everything. It can also store external users nowadays and it's free if you already have Active Directory. Or the ThinkTecture 2.0 server that Ross recommends. It's easier to customize and perhaps your systems administrators and security folks will not be too enthusiastic about opening the firewall to the ADFS server.
Microsoft has some good reads on WIF, in particular an Overview of Claims-Based Architecture.
You should take a look at identity server as it can indeed handle this scenario.
The person who leads the project above has a great pluralsight video on this exact scenario! You need to sign up to watch it, but they offer a free trial.
Basically you get a token from the identity provider (windows ADFS for the internal client, and what ever you decide for the external users). You will give this token to the federated gateway (identity server probably, but it could be Azure ACS). This will return an authentication token that you can then use with your service.
I have a need to implement a STS-IP server for our web applications and services. The server will need to issue SAML tokens for the following scenarios:
Business partner submits their SAML token which is converted to a SAML token with the claims required for our applications. This token is used to access our Web Applications and Services.
Our public facing applications need to have a user sign in (via forms authentication) and then access our web applications and services with a SAML token.
Our clients (without a STS trust) needs to authenticate with our STS-IP server, get a SAML token, and use that token to access our WCF services.
In all 3 scenarios, we need to have custom claims on the SAML token that our applications and services use. The thought is once we identify the user, we would look up their authorization in our back-end systems and attach claims.
In these scenarios, you can assume the back-end authentication store is a custom implementation with authentication stored in Active Directory and authorization stored in a database.
So my thought has been, we need to create a custom STS-IP server using something like Windows Identity Framework. But I have also been reading that you should not do this because it can take some time.
Can I use an off-the-shelf STS-IP server? Everything I've seen is a mapping between one system to another (SAML to SAML or AD to SAML).
Why will it "take a long time" to build a production ready STS-IP ? I built one using WIF very easily, but I guess I don't understand the risks in doing this.
In terms of "It will take a long time", the documentation showing how to do this is very poor. See here: http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/257d93be-165e-45a6-a277-fc7ed2286e7d/
Anyhow, you'll simply need to look over the code samples that Microsoft provides: Google for Identity Developer Training Kit. That should help you get started.
Why are you not considering using ADFS? If the backing store for authentication is AD, then ADFS is probably a good candidate to evaluate.
Before writing you own STS, you may want to check out this blog and closely review the features that you may need in the STS. Just because you can build one yourself, doesn't always mean you should.
extending adfs to multiple identity and attribute stores
They "why not" is relatively simple: Why take weeks to build something that will probably only handle a single use-case when you can put in off-the-shelf STS in a day that will cover all sorts of things your company may come up with? Building it yourself will also require you to become an expert in SAML (which is probably not the best us of your company's time).
Check out --
http://www.pingidentity.com/our-solutions/pingfederate.cfm
Good luck -- Ian
Agree with #eugenio - why not use ADFS?
ADFS can only authenticate against AD as discussed but it can derive authorisation attributes from AD / LDAP / SQL server
The nuts and bolts for an STS are available in VS 2010 plus the identity tool kits. A simple STS can be quickly prototyped.
There are some examples available. StarterSTS is already mentioned plus SelfSTS.
The hard part is getting the security right especially if this will be part of a production system. As per "Steve on Security" Build your own Directory Federation Service:
It may sound like I think it’ll be a
synch to develop this system and have
it work securely, but in reality there
is a lot that will need to go into it
to protect the network, the employees,
and the data this could possibly
interact with. It is tough to develop
applications securely. It is far
harder to develop secure applications
whose sole responsibility is security
related.
That's the reason that all the samples on the Internet have disclaimers in bold:
Do not use in a Production environment
What's the difference between SAML and federated login with OAuth? Which solution makes more sense, if a company wants to use a third-party webapp, and but also wants single sign-on and be the authentication authority?
They solve different problems.
SAML is a set of standards that have been defined to share information about who a user is, what his set of attributes are, and give you a way to grant/deny access to something or even request authentication.
OAuth is more about delegating access to something. You are basically allowing someone to "act" as you. Its most commonly used to grant access api's that can do something on your behalf.
They are two completely different things.
Some examples that might help out.
OAuth think of an twitter. Lets say you are using Google Buzz and Twitter, and you want to write an app to be able to keep the two synchronised. You basically can establish trust between your app and twitter. First time you go to link the app to twitter, you do the classic prompt to log into twitter, and then that confirmation box pops up and asks "Would you like to grant access to «your app name»?" once you click "yes", the trust has been established, and now your app can act as you on Twitter. It can read your posts, as well as make new ones.
SAML - For SAML think of some type of "agreement" between two unrelated membership systems. In our case we can use US Airways and Hertz. There is no shared set of credentials that can take you from one site to another, but lets say Hertz wants to offer a "deal" to US Airways. (Granted I know this is an extreme example, but bear with me). After buying a flight, they will offer a free rental car to its Chairman members. US Airways and Hertz would setup some form of trust, and some way to identify the user. In our case our "federated id" would be the email address, and it would be a one way set of trust Hertz trusts that US Airways identity provider will deliver a token that is accurate and in a secure manner. After booking the flight US Airways identity provider would generate a token and populate how they have authenticated the user, as well as "attributes" about the person in our case the most important attribute would be his status level in US Airways. Once the token has been populated it passes it via some type of reference, or encoded in a url and once we get to Hertz, it looks at the token, validates it and now can allow for the free rental car.
The problem with this SAML example is it's only one specialized use case out of many. SAML is a standard and there are almost too many ways that you can implement it.
Alternatively, if you dont care about authorization, you could almost argue that asserting authentication via SAML and OpenID.
Have a look at this simple explanation summarized here:
Many people are confused about the differences between SAML, OpenID
and OAuth, but it’s actually very simple. Although there is some
overlap, here is a very simple way of distinguishing between the
three.
OpenID – single sign-on for consumers
SAML – single sign-on for enterprise users
OAuth – API authorization between applications
For folks comfortable with OO design patterns, I think there's a nice corollary to wrapper patterns. Think of Facade, Decorator and Proxy patterns. Fundamentally these are all the same, they're just wrappers... The difference is the intention of each pattern.
Similarly, SAML, OAuth and OpenID all facilitate different intentions via a common underlying mechanism, which is redirection to a service provider/identity authority for some private interaction, followed by redirection to the originating third party app.
Looking around on the net you will find overlap between the protocols' capabilities. Authentication via OAuth is perfectly reasonable. SSO over OAuth may not make a lot of sense though as SAML and OpenID are specifically geared towards federated identity.
To the question itself, in a corporate context SAML sounds more appropriate than OAuth for SSO. I'd bet if you look at the third party apps you'd like to integrate with your corporate identities, you'll find they're already designed to integrate with SAML/LDAP/Radius etc. IMO OAuth is more appropriate for Internet interaction between applications or perhaps applications comprising a Service Oriented Architecture in a large corporate environment.
Authorization rules may be specified in a corporate environment in other ways too. LDAP is a common tool for this. Organizing users into groups and associating application privileges against group membership is a widespread approach. Just so happens LDAP can be used for authentication too. Active Directory is a great example, though I prefer OpenLDAP.
Found Good article here
SAML (Security Assertion Markup Language) is set of standards to achieve Single Sign On (SSO), Federation and Identity Management.
Example : A user (principal) authenticates with a flight booking website, AirFlyer (identity provider) which has SSO configured via SAML with a shuttle booking website,Shuttler (service provider). Once authenticated to Flyer, the user can book shuttles on Shuttler without requiring authentication
OAuth (Open Authorization) is a standard for authorization of resources. It does not deal with authentication.
Example : A photo sharing mobile app (OAuth consumer) that allows users import photos from their Instagram account (OAuth provider) which sends a temporary access token or key to the photo sharing app that expires after some hours.
They handle a subtle use case
SAML - Sharing credential (e.g., SSO) of a user to various service providers (e.g., web or web service)
OAuth - A User delegating an App to access a resource on behalf of his/her
SAML has a variety of "profiles" to choose from allow other users to "log in" to your site. SAML-P or SAML Passive is very common and fairly simple to set up. WS-Trust is similar and it too allows for federation among websites.
OAuth is designed for authorization. You can read more here:
What's the difference between OpenID and OAuth?
SAML is for authentication - mainly used in Single Sign On scenario. OAuth is for authorization of resource representations.
JSON Web Token (JWT) is an alternative for SAML XML Tokens. JWT can be used with OAuth
A good reference is SAML vs. OAuth: Which One Should I Use?
The terms federation really means connection identities across systems. It's related to SSO but they aren't quite the same. I Found this blog post really helpful in terms of what federation really means.