We have multiple websites that share the same customer base but doing different kind of business. We already have a server that acts as a centralized identity service - it manages customers, their businesses and customer's roles in the businesses.
Because of the existence of this centralized identity service, we decide to add single-sign-on to this service - i.e. to make it act as a SSO identity provider.
A customer may have roles in multiple businesses - he could be an admin in business A and a technician in business B. When he logs in, our centralized identity service makes him to pick a business to login.
Question: does SAML response contain fields/attributes to carry this information: "The user has logged into business B as a technician"?
This document answers the question I asked:
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
Related
We have an application which supports a single Identity Provider. However we have multiple customers on it and each of these customers wants to point to their own Identity Providers. It would be a significant amount of rework to allow our application to support many providers. We are looking for a solution (open source or commercial) where we can point our application at a single Identity Provider and (presumably based on email address domain) that Identity Provider can route the requests out to a specific clients Identity Provider. Do such solutions exist?
Yes, it's called Home Realm Discovery.
You federate all these other IDP with your IDP.
When the user logs in they get a choice of which IDP to use to log onto.
Most IDP have rules that allow the IDP to be selected seamlessly.
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.
This is more of a philosophical/architecture question than "code" question.
Let's imagine that we have 2 applications (Service providers) with Single Sign-On. There is obviously data they have to share, mainly the information of the users (username, email, etc). This data is managed by the Identity Provider and "provided" to the service providers when the authentication is successful (the basics, I guess).
Let's also imagine that these 2 applications have their own database itself in which they match each user retrieved from the IDP but each database has their own info (columns) that only belong to their associated application (not to the other!). But (another but), there are some other fields that both have to access (besides username, email, etc). For example, the first application has a list of available companies and the second application needs that information when creating a new user to associate that user with an available company. How should that data be shared? Is that the best/correct way to create an API to provide this type of info between applications? I'm mostly talking about lists of things that are too big to be sent through assertions.
Thanks in advance!
The SAML way is to use NameID as the "primary key" to map a user in the IDP to a user in the application.
e.g. Email could be sent as the NameID for application 1 and UPN could be sent as the NameID for application 2. These would be in the assertions.
Getting info. between applications is not part of an IDP (other than using assertions) so this would have to be done via API.
I'm working on setting up a service provider that supports SAML. I've added two identity providers - one custom one that I built from SimpleSAMLphp and then ssocircle. So I log in to the selected identity provider, and then it returns to my service provider and I inspect the attributes of the SAML Auth object. The identity provider I built returns whatever I want it to (obviously). The ssocircle one only returns e-mail, first, and last names.
So now to map this to the user of the service provider, I have to use some value the identity provider provides. So this led me to wonder how it should be done. Since ssocircle only gives me e-mail as a useful value, do I just use the e-mail to map to the SP user?
Let's pretend for a second that ssocircle doesn't validate e-mail addresses. So now if I create a second account at ssocircle with the same e-mail, I can log in as my coworker who I know has admin privileges.
So my question is, do I handle this? Or is the onus on the admin who set up the identity provider and say "well you shouldn't have used an identity provider that doesn't validate e-mail addresses!" or something of that nature? Or should I only allow identity providers that pass a certain value, like userid or 0.9.2342.19200300.100.1.1? Is there something that identity providers commonly use?
Well, you said it, two different identity providers. They both should be passing not only the email but different entity ids and certificates.
In multi-tenant applications that would mean two different applications, but if you plan to allow multiple IDPs to point to a single app you will need to ensure that same email but different entityID create two different users and or throw an error after the first was created that the second cannot be provision nor access.
Interesting question. These days people think always of auto federation of users by some attribute. In early SAML federation days federating two unrelated users was a manual step in which a user logs in at the IDP and logs in to the SP providing both sets of credentials and then manually federated these two user accounts. The process guarantees that only the user who has access to the accounts at the IDP and SP controls the linkage between the two. It also allows anonymous naming identifiers (SAML persistent NameIDFormat) which protects privacy because even the IDP does not know the user name at the SP and vice versa.
Unfortunately the process was to complicated for users and with the success of OpenID the aspect was getting less and less important.
To answer your question: What you describe happens in the real world -see Office 365 authentication bypass
You need to check that the IDP is authoritative to send a specific attribute and attribute scope in case of two IDPs.
In case of one IDP the attribute must be verified (SSOCircle verifies email address) and it should better be unique (For example SSOCircle userId) to avoid that two users with the same attribute are mapped to a single user at the SP.
If the userid's are not the same (e.g. you use a simple user ID at the IDP and email address format at the SP) you can still add a correlation attribute at the SP (e.g. an attribute named ssocircle-userid) and use that to link the user accounts.
I have a REST API that uses JWT for authenticating clients of 2 types:
- users through a web application
- services
Each client has its own rights (e.g. one can access resource 1 but not resource 2 using the API).
Now a service can have a UI and the problem I'm facing is that I don't really know which rights should the API consider when a request is sent by a service through a user action from the service UI: service rights? User rights? The intersection of both?
For example, let's say the API provides a list of products through ˋGET /products`, that list can be restricted by client's rights:
- user U can list product1, product2.
- service S can list product2, product3.
What products should be listed for user U from the UI of service S?
If I understand what you're asking, you should be thinking about the intersection of users and services. There's no such thing as "service rights" or "user rights" in the absence of the other. Instead, there are rules dictating which users can access which services.
Typically any REST call is processed on the server by first identifying the user and verifying the user can access this service, then performing the actual service if verified.