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
Related
I have a need to implement Open ID Connect in an ASP.NET Core 5 web app for authentication at an organization. I cannot test against the identity provider as this org has their own internal one.
I thought Open ID Connect (oidc) was a standard - yet when I look at docs and sample code for the various providers around, they all either have something provided with ASP.NET or I have to install their package.
For example, to use Google, the ASP.NET Core docs say to use services.AddAuthentication().AddGoogle(). For Facebook, it says to use .AddFacebook().
For Auth0, it wants me to install the package Auth0.AspNetCore.Authentication.
Is it not possible to just add OIDC authentication to my app and have it work with any OIDC provider and just change a configuration file to specify the authority URL, Client ID, Client Secret?
I'm confused about why I need these provider-specific calls and packages.
Architecturally, tieing an app to a single form of authentication is entirely wrong, as you suggest. These packages have limited use, perhaps for very simple use cases.
The original OAuth 2.0 spec from RFC6749, from 2012, describes how the OAuth framework is designed, to externalize difficult security from your apps:
The client only implements a code flow
It redirects to an authorization server (AS)
The AS can authenticate users in a myriad of potential ways, including many identity providers
After authentication (and possibly consent) the AS issues tokens to your apps
Tokens enable authorization in your APIs in a myriad of potential ways
Once you've implemented a code flow in your app, your set of users can potentially login in many ways, with zero code changes in the app:
Password sign in (a default option)
Multi-factor authentication (in a dynamic way potentially)
Cloud platform identity providers (for engineering staff)
CRM identity provider (for client focused staff)
SAML identity providet (for users from business partners)
Webauthn, Passkeys and Digital wallets (for some of your customers)
Unless you have a very good reason, stick to OpenID Connect standards based code flows in clients. You can do all of the above using the Microsoft libraries. Auth0 have good libraries also - just make sure you use the standards based ones.
OpenID Connect is an open standard that organisations use to
authenticate users. IdPs use this so that users can sign in to the IdP
From this blog.
And about the OIDC protocol, it allows you to authenticate users, and is designed for users to sign in many websites with only one account, usually it's a social/work account. This is only a protocol and you have to use an implement such as Google/Azure authentication to allow your users to sign in with their specific account.
By the way, since the implements are from different companies, so the configuration in our codes are different and they required different nuget packages like Microsoft.Identity.Web. For example, when using Azure, we need to set such as client id, client secret, tenant id, domain, redirect url... in appsettings.json.
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.
We have an Internet facing Web Application running, and recently our company made some agreements with a 3rd-party company which owns another web site. The idea is to provide access to this external web site to our current customers. Our users will click on an internal link in our solution which will open a new browser window with the third party site. User will not need to authenticate again in the 3rd party company site.
We have agreed to issue SAML2 tokens for our users, with a set of claims used by the 3rd-party site to query an present a personalized view to our users
Something important in our scenario is that users are already authenticated in our web site when they decide to access the 3rd-part web site.
What is the best way to implement all this?
I am thinking on implementing a custom-STS using the WIF SDK to generated those SAML2 tokens and pass then using HTTP POST (cookie) to the 3rd party site. If this is the right approach, then any pointers, tips?
Will ADFS make any difference?
Thanks for any help
Sounds like you'll be playing the role of Identity Provider - responsible for handling the "manual" authentication of the user and generating SAML responses to give the user SSO to the 3rd party website.
Implementing your own IdP is not trivial (there are a handful of specifications to understand), so unless you have your heart set on this as a development project, you may want to consider a COTS like Microsoft ADFS, PortalGuard (for whom I work) or Ping Identity.
Since you asked about ADFS specifically, it has native support for Active Directory as the user repository and has some interesting features with its claims transformation engine (if you get into a complex SP-IdP chaining scenario). Besides SAML it also supports WS-Federation which is important for integration with the other offerings in the Microsoft stack.
If your application is ASP.NET, then connect your application to ADFS.
So to get to your application, the user has to log in.
Then for the link to the 3rd party application use the IDP Initiated scenario (IdpInitiatedSignOnPage Class Overview). This sends a SAML2 token to the 3rd party application. ADFS will handle SSO for you.
To do this, you will have to configure the 3rd party application as a SAML one rather than a WS-Fed one.
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.