So, when management tells us our website needs to "support SSO through SAML 2.0", with no additional details, what are they thinking?
What will our customers expect?
Note - The is not an open website, where everyone can join. To log in you need to be a configured user in the system. The customer's admins need to create an account in our system for each user.
So we aren't going to let just anyone who has an account with an IdP in to our website. We'll have to have some mechanism for mapping a SAML identity to our users.
How would our customers expect that to work?
Based on hints in your question, I am going to presume that you will be acting as a service provider.
To be what I would call a "good" service provider, I would expect the following:
You sign your AuthnRequests.
You provide a metadata endpoint that is kept up to date with your SP metadata to include current public keys for encrypting attributes (if necessary) to be sent to you as well as validating your AuthnRequest signatures.
You support dynamic consumption of my identity provider's metadata endpoint to keep your side of the connection up to date, especially with concern to my signing certificate.
You expose management of my identity provider configuration inside of your service provider mechanism to my IdP administrators through a web or API interface.
You either support a mechanism to automatically manage my users (like via SCIM or Graph or something else), or you support Just-In-Time provisioning based on an incoming assertion.
You allow me to decide my SAML Name ID format, and that format is per-tenant. As an example, I may want to use email address as the identifier, while another IdP may want to use sAMAccountName. e.g., john.doe#domain.com vs. johndoe.
You support Service-Provider-Initiated SSO. That means that the user shows up to partner1.yourdomain.com and get redirected for authentication to that partner's IdP, and that going to the location partner2.yourdomain.com would redirect to a different IdP.
As a service provider, you should make using your service easy and secure. By shifting to SAML, it allows you to get out of the business of password and user management because you get to put that back on the identity provider. It allows your users to not have to type in a password (or more, if you're doing MFA) to use your service, removing friction caused by security. It allows you to put the onus of authenticating the user back on the organization that owns the identity.
Your customers would expect that if they have an application that uses the SAML 2.0 client-side stack then when the application sends an AuthnRequest, they will see a login page on your site and once authenticated, the application will receive a set of assertions (claims) from your IDP via an AuthnResponse.
One of these assertions is NameID. This is the "primary key" between their system and yours. Normally this is UPN or email.
This mapping is outside of the SAML spec. There needs to be some kind of "on-boarding" for the customers.
Related
I’ve done a few OpenID integrations, so I understand the problem I’m about to describe is something OpenID and OAuth can solve, but I’m new to SAML and trying to wrap my head around one particular use case:
So, say user visits Site1, which asks the user to confirm which one of the other sites he or she belongs to (Site2, Site3 etc.)
Site1 cannot authenticate user and relies on Site2 or Site3 to do authentication, so it presents user a list of sites to authenticate against.
User chooses either Site2 or Site3, performs authentication there and is redirected back to Site1. Site1 acknowledges the user and it now knows where the user is from.
Question: Is this a valid problem for SAML to solve?
There are two problems in your question:
Service provider (Site1) needs to redirect the user to the identity provider (Site2, Site3, ...) that "owns" the user identity (can authenticate them)
Authentication at the identity provider and propagation of this fact back to the service provider
SAML can solve both of these but read on for caveats:
One of the profiles in SAML is an Identity Provider Discovery profile. Its definition from the spec (section 4.3):
...a profile by which a service provider can
discover which identity providers a principal is using with the Web
Browser SSO profile. In deployments having more than one identity
provider, service providers need a means to discover which identity
provider(s) a principal uses. The discovery profile relies on a cookie
that is written in a domain that is common between identity providers
and service providers in a deployment. The domain that the deployment
predetermines is known as the common domain in this profile, and the
cookie containing the list of identity providers is known as the
common domain cookie.
As you can see, this profile relies on a common domain cookie that is issued by a discovery service hosted on a common (shared) domain:
When a service provider needs to discover which identity providers a
principal uses, it invokes an exchange designed to present the common
domain cookie to the service provider after it is read by an HTTP
server in the common domain.
The common domain (and associated cookie) requirements were an early take and some developers didn't think it was an elegant approach that met everyone's needs. This lead to the profile being revised and later issued as a separate specification called Identity Provider Discovery Service Protocol and Profile. From this spec:
This specification defines a browser-based protocol by which a
centralized discovery service can provide a requesting service
provider with the unique identifier of an identity provider that can
authenticate a principal. The profile for discovery defined in section
4.3 of [SAML2Prof] is similar, but has different deployment properties, such as the requirement for a shared domain. Instead, this
profile relies on a normative, redirect-based wire protocol that
allows for independent implementation and deployment of the service
provider and discovery service components, a model that has proven
useful in some large-scale deployments in which managing common domain
membership may be impractical
The mention of large-scale deployments is important. The first attempt (cookie-based profile) was simple but messy; the improved spec does everything the "SAML way"...and greatly increases the complexity of the implementation. It's only worth it if your collection of identity providers is sizable, like all universities in your country for example.
There are many non-SAML options for solving the identity provider discovery problem. The simplest option is "ask the user" by employing a UX-friendly technique for the user to select their identity provider. This blog does a good job of summarizing these options. For a real-world, complex solution to this problem take a look at Swiss universities' implementation.
This is a common scenario where SAML is a good fit. Take a look at SAML Technical Overview for more details.
Note: oAuth does not authenticate the user, it authenticates the client app. OpenID Connect is based on oAuth and it can authenticate the user via the id token. The id token and the associated exchange was heavily influenced by SAML
IDP's handle this via Home Realm Discovery.
If an IDP is configured with Sites 1, 2 and 3 then when the application redirects to the IDP, there will be an HRD screen asking the user to pick one of the three.
The user selects one, authenticates and is redirected through the IDP back to the application.
It's not a protocol feature - more of an IDP feature - since it does this irrespective of the protocol.
What I know so far is, to make any application SSO enabled, there must be an Identity provider taking part in the SSO game. So there is direct dependency on IDP as the SP need to "know" who the IDP is. Can SP have a common saml communication mechanism which can work with any IDP that my customer is using ? Or I need to build different saml communicator based on the customer supported IDP ?
Reason: One of our company customer is using Okta for its employees and want us to make our application Okta enabled so that its employees need not to remember credentials on our site anymore. That's fine. Now, if any other customer comes with some other IDP (PingOne for example), do we need to work again to make it that xyz IDP enabled ? or our existing implementation will work same way by just adding that IDPs url ? Let me know if I am missing any big picture or key concept here.
P.S. Our application is on .NET platform.
Unfortunately you will need to create a new association if a user want to use a new IDP.
There is a good reason for this. You need to be say that you trust the IDP. The IDP is the one that vouches that the user is who they say they are. So you have to ensure that you trust it to authenticate users for you system.
What you could do is to allow for the customer to define its the IDP to be used, provided that the IDP is only allowed to authenticate that customers users.
If you want to do this I would recommend using some third party software.
I am reading about SAML2.0 based federation as it is supposed to apply for SSO in the current setting:
In application A a user has credentials email/password1
In application B, the same user has credentials username/password2
If the user logs in at A, he/she should also be logged in at B
SAML v2.0 seems to be a good choice in this situation:
central identity provider (IdP), maybe A or B or a third party C.
A and B would be service providers (SP)
if user tries to access A, A would request SAML assertions from the IdP containing email
if user tries to access B, B would request SAML assertions from the IdP containing username
But if the user is authenticated in A, how should he/she be logged in B (for which username)?
Documents about SAML (e.g. here: https://www.oasis-open.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft-06.pdf) pretend that SAML allows SSO without requiring to synchronize or migrate identities between all players.
However, I don't see, how all this should work without maintaining and merging all credentials of the same subject in the central IdP which in fact is a kind of synchronization.
If you have the impression that I am quite confused about SAML v2.0 capibilities, you are right ;-)
As a service provider, SAML doesn't allow you to do away with a user store usually. This is because it's a method by which you externalize authentication only. Most service providers have a 1-to-1 relationship of users in their store, to users at their identity providers. However, it may not need to be this way, as you can do a one-to-many federation as well. I'll expand shortly.
In the one-to-one, you will generally use either a "just in time" provisioning method, or an out of band user synchronization method. The just in time is usually done via attributes provided in the assertion, and is done by the SP when it realizes that the user that has been presented in the assertion doesn't exist the application's user store. The out of band method is some other process, a directory synchronization, etc. A user gets add to the IdP's store, and some process adds that user to the SP store, via flat file, XML, etc.
Having said that, depending on the type of service provider, you could do a one-to-many, and count solely on the attributes provided to support the needs of the application. Let's say you run a printing operation. You could agree on having the IdP send a cost center along with other attributes for the user (name, number, email, etc.). Then all the data is stored just on that print job, with the Cost Center sent back during billing. I will say, I've only seen a couple of instances of one-to-many federations in my career.
I don't think your example is quite right - meaning you didn't ask it quite right, but then again, you're not familiar enough, maybe.
Let's presume the following:
Service Provider X needs username
Service Provider Y needs email
Identity Provider A can provide all of these from their user store
The user shows up at SPX. SPX says "based on the url you went to (idpa.serviceproviderx.com), I know you need to be sent over to IdPA." and redirects the user to IdPA. IdPA authenticates the user, looks at its "attribute contract" to determine that it's supposed to send username to SPX, and redirects the user with that attribute as its "subject" in the assertion. SPX consumes that assertion, and can map the user back to where they are supposed to go.
Now, the user is browsing through their portal, and clicks a link that starts an SSO to SPY. The user is already authenticated to IdPA, so IdPA checks it's contract and sees it's supposed to use email with SPY. It creates an assertion for SPY with email as the subject, and redirects the user to SPY for consumption of the assertion and connection to the application.
Now, in both those instances, the IdP has to determine what to send to complete the contract with the SP - and it always will. This is based on a "contract" - some form of agreement between the IdP and SP that has to be supported by administrators of both systems.
Ok, I think the main missunderstanding here is how authentication works in SAML. I SAML the IDP authenticates the user. This means, you have no crederial store at the SP.
SSO in SAML happends at the IDP. If the user has already signed in once at the IDP the user is just sent back to the SP without authenticating.
I am creating a service provider which talks to third party IDP for authentication. But I have a concern that I have a set of dedicated machines(Desktop,tab) which are highly trusted, so is their a way in SAML that when a request is sent from such machines user is directly authenticated without the need to type username and password.
you want that user that tries to access a resource from his desktop (which is trusted) will be automatically authenticated? if this is the case, it seems that you need to identify the user using the active directory or something.
if this is the case, search a bit about Kerberos, or ADFS - it might serve your needs.
I am working on a project that needs to be integrating SAML2.0. I was thrown into this project suddenly, i need to make it work.
Here is the background: We have created the files and wanted Client Company to integrate using SAML2 to get to our web site. We have sent them the meta datafile.
Now the client company had sent their metadata file. I dont know how and what to do with that file. Any help will be appreciated.
ASP.NET, Framework 4.0
The metadata file basically provides you information of your client. Such as entityID, credential, and so on. If it is an IdP then it also contain couple URLs so that you know where to send different request, e.g. login request, attribute query request. You need to give this metadata to your SAML component so that it know which client it should talk to.
Another main purpose is to establish a trust relationship between SP and IdP.
It's kind of old question but I would like to add some additional information and resources for .NET.
SAML Metadata is used to exchange configuration information between Service Provider and Identity Provider and vice versa. The information can include:
Binging location
Organization name
Contact Person
Single Sign On Url
Single Logout Url
The Metadata can be signed and encrypted so that the information is sent securely. The other side may need the corresponding public key to validate and decrypt it and then can be used to understand and establish the connection with the SP or IdP.
You can see some more info at the following blog posts:
http://samlcomponent.net/constructing-saml-metadata-xml-for-single-sign-on-idp/
http://samlcomponent.net/how-to-create-saml-metadata-xml-for-service-provider/
Security Assertion Markup Language (SAML) is a standard for logging users into applications based on their sessions in another context. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password:
1.No need to type in credentials
2.No need to remember and renew passwords
3.No weak passwords
It is easy to manage all applications in one tree using SAML SSO login.
How actually SAML works:
The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.
The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.
The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.
The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
The identity of the user is established and the user is provided with app access.
Take a look at the metadata SAML 2.0 specification to check what elements must be read by your implementation.
If you are looking for a SAML2 .Net Tookit, take a look to this thread of stackoverflow
Also take a look on SAML open source implementations to learn how others resolved this problem before:
SimpleSAMLphp (PHP implementation Idp/SP). (Metadata parser)
Shibboleth IdP (Java) (opensaml2) / SP (C)
spring-security-saml: SP (Java) (metadata files)
Jboss (Java)
Metadata is nothing but the xml file containing all the information required by your SAML implementation to talk with host. you can extract information from this meta to get the desired information required. Like public/private keys.
I hope you are also using certificate to talk with host on secure manner.
This key is required for handshaking with unknown host system.