After reading a few articles on SAML, including "SAML for dummies," and the SAML wiki article, I'm still entirely unclear as to how SAML actually solves the SSO problem. Suppose I take something like a Google account as an example. My understanding is that if I go to GMail and SAML is implemented, I will be redirected to an IDP, which, let's say, is Google's sign-in authority. My browser then goes there with a redirect, and I'm asked to log in. After providing the correct login info, I return to GMail with a token and SAML response encrypted with Google Sign-in's private key, which is then authenticated using GMail's public key, thus verifying that I am, in fact, who I say I am.
What's confusing to me, is that this seems to solve the problem of signing in the first time, or into a single application, but I don't understand what happens when I now go to Google Drive. Even if my browser saves the SAML token/response as a cookie, I would have to sign in again after the token expires, which, I read, is something like 2 minutes later. Moreover, even within the same application, requests to separate resources or endpoints seem like they would time-out in the same fashion.
The only hint I have is that, according to the wiki article, step 1 has the target resource at the SP check for "a valid security context." However, if GMail and Drive are separate applications which aren't communicating with each other, how would Drive know that I already have a valid security context?
Questions:
After the initial authentication, what information needs to be sent with future requests to the same or different application/endpoint? For example, perhaps the SAML assertion saved and resent with every request.
How is this information secured/verified?
What timeouts are associated with SAML's SSO, and how are the timeouts enforced on both the SP and IDP sides?
What you are missing is that the Idp (Google's sign in page in your example) sets a session cookie on the first login. When you access Google drive as the second application, it has indeed no knowledge of the gmail session. Google drive does a redirect to the idp to get an authentication.
Now, the idp has an active session thanks to the cookie on the idp domain. That makes it possible for the idp to reply to google drive with a new assertion, generated from the persisted session information.
You're right that each assertion is normally only valid for a few minutes, but that isn't a problem as the idp can create a new assertion for each application.
For timeouts: The Idp can set a SessionNotOnOrAfter condition in the assertion to tell the SP that it must terminate the session at a given time.
Related
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
I'm having hard time understanding SSO. Anywhere I read there are those high-level explanations of how the site that authenticates the user "passes the token" to the site that was originally accessed or that it knows that the user has already been authenticated if you access it later on. But I am still interested in the details of how those things are being accomplished.
Let's assume there are two sites, A and B, and a site X that is responsible for the authentication that A and B use.
Here are some questions that I can't find answers for:
if I access A and are then redirected to X to input my credentials, I get authenticated and then how exactly does X let A know that I am who I am? I know there is a token involved - how is this token passed exactly? Is it passes in a query string/body/header of a request that redirects me back to site A?
What happens after the A is notified that I have been authenticated? Does it issue me a cookie? Or am I holding this token somehow? How do A know with every subsequent request that I am who I am?
if I got successfully authenticated accessing site A and then try to access site B, I get redirected to site X - how does the site X know that I have already been authenticated? I guess I don't pass any cookies, do I? Did I get a cookie from X when authenticating there?
The reason it's confusing has to do with ambiguity of term "SSO". Your questions are good but the answers would depend on how SSO is implemented, there's not a one size fits all solution. We'll answer your questions with SAML as the protocol, it's often used to implement SSO between web apps:
A = service provider, X = identity provider. These are "roles" a service (or an application) might play in SAML. The identity provider sends a SAML response to the service provider after the identity provider authenticates the user. A so-called binding is a set of rules in SAML spec that determines how the response is formatted and transmitted from identity provider to the service provider. In Web Browser SSO profile of SAML, the HTTP-POST binding mandates that the response is sent via, well, POST over HTTPS. The response contains an assertion, sometimes referred to as a SAML "token". The assertion is a container for statements (aka claims) made by the SAML authority (your X) with respect to authenticated entity. For example, if the identity provider authenticates user "bee", the assertion sent to the service provider may contain bee's first name, last name, user id and so on.
Typically you'll get a cookie. The service provider A will create a "local" (to A) session and drop a cookie with session ID (or whatever session pointer) to associate the user agent with the session. On subsequent requests to A, A knows you on the basis of the cookie which maps to a session in A. The session holds the authenticated context established, say, the user id of user "bee" that came from the SAML response in step 1.
Also via cookies (usually). When you're authenticated with the identity provider X, it issues its own cookie. You have one cookie for X, one for A, one for B, ...
We say "usually" because the state management (how does A or X know it's you) is not part of the SAML spec. If an identity provider comes up with an exotic state management scheme, say, fingerprinting your browser and relying on that fingerprint as your authenticated context/session id, that's still okay with SAML from a protocol perspective. Only step 1 is formally described in the protocol, steps 2 and 3 are up to the implementation. In practice, cookies have a very short list of alternatives and most apps use cookies.
Take a look at SAML Technical Overview, it does a good job of addressing the essence of this Q&A.
Let's say we have a service provider app called A hosted on tomcat, a user clicks a link to the SP A. SP A sees no token is provided so it redirects the user to the IdP for authentication (with a SAML Authn request provided by some means). The IdP then redirects the user to some common login page where credentials are provided, assuming that these credentials are correct the IdP creates a SAML response with a token and some assertions about the subject, and sends it back to SP A. SP A sees this and allows the user access into the application. Great!
I have a few questions though
How is the authorisation request/response sent, I understand there is a redirect binding and a POST binding where the SAMLResponse and request are encoded either as a query param, or sent as an XHTML form in case of a POST binding. But I'm not sure which is used where?
A service provider is the thing providing a service, so Office 365 or Sales force for example. Is each one a separate service provider? I ask as I watched a video where the guy said the service provider was the thing that hosted these services, so I'm not sure of the correct answer here?
How is the token stored on the client side? So for example I am now authenticated against SP A, the user then tries to use SP B from the same machine/browser window, how does SP B and the IdP know that the user has already authenticated and therefore doesn't need to re-authenticate. I.e. the SSO aspect of it.
Does SP B need to be hosted on the same tomcat instance for this to work?
I dedicated significant time to get SSO working for me. The most helpful document was this specification
The answers below are based on this experience:
Redirect or Post binding is used depending on a respective HTTP request header. The Post binding is recommended since it does not imply restrictions on data volume transferred.
A Service Provider in this context is anything that clients request. There may be many of them, participating in the same SSO scheme.
The service providers must be SSO-aware, which includes handling of the authentication response data. Usually you don't have to implement the protocol - there are ready-made frameworks that your SP can utilize.
Service Providers may reside on different servers.
From my own experience:
You choose your own SAMLBinding (redirect or post) depending on what your idp and sp supports. This binding type will be used both for the 1st step (SP -> Idp) and 2nd step (IdP -> SP). If you have some running environment, open your browser devtools and look at network tab to see what happens. It's just a way to send data from browser to SP/IdP.
Both Office 365 and Salesforce.com are cloud services, right? Let's take Office 365. it means that beyond "end-user" services (like Word, Excel) there is some technical SSO service which are common to the platform. It can be viewed as lower (or technical) service layers, I think that what you speaker meant.
The SAML token is stored by you SP application inside your browser, either hidden inside web page, cookie or web storage. It depends on how your SP is implemented.
SAML response can be validate by each SP based on shared private key, so it will decrypt the token using this key and be able to grant user without the help of IdP redirection.
Tomcat have some extension to support SAML. But SAML is designed to work without being on the same instance, as the opposite as basic JSESSIONID cookies.
So you have several instances, of course.
So I'm struggling a bit with the basics of the flow of SAML. Here's the scenario I find confusing.
I have a java web application. The user is logged in. I know they want to order cookies from a 3rd party because they've clicked on the "I want chocolate chip cookies" link. I also know that "Mrs. Pillsbury Cookies Co." is a "Service Provider" because she sent me her meta-data and I've registered her with my Gluu Server (IdP). I've also sent her my IdP meta-data so we've done the whole hand-shaking thing.
My question is...how do I now send the SAMLResponse to Mrs. Pillsbury? She's given me a SOAP endpoint that is waiting for a SAMLResponse. How do I tell my Java application to get some XML from my gluu server as a SAMLReponse that I can then pass to the Pillsbury SOAP endpoint? That's the part where I'm stuck...I don't know how to get a response to forward. I can see in the metadata that there are lots of SSO endpoints
<SingleSignOnService Binding="urn:mace:shibboleth:2.0:profiles:AuthnRequest" Location="https://idp.myjavaapp.com/idp/profile/SAML2/Unsolicited/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.myjavaapp.com/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://idp.myjavaapp.com/idp/profile/SAML2/POST-SimpleSign/SSO
Am I supposed to hit one of those SSO endpoints and it'll generate a response that I can then forward on to Pillsbury? Can one of you SAML experts out there get me straigtened out? Thanks in advance.
There are a few ways SAML Requests/Responses can be generated.
IdP initiated:
This is a SAML Response generated w/o a SAML request. This requires the user to login/be logged into the idP and the idP will generate a SAML Response based off the SP setup in the idp.
SP initiated:
This is usually an HTTP Redirect but can be a POST as well. This is a SAML Request Redirect/POST that gets sent to the idP based of some link or button on the SP's website.
As I understand it you have the following relationship:
Your App
\
3rd Party ordering
/
IdP Server
Your app needs to make a request to the 3rd party, but also need it to authenticate against the IdP. Yes?
Normally the process works such that the 3rd party requests the token itself. Your app shouldn't have the token intended for the 3rd party -- it should only have the token for its own app.
Usually you send whatever your app-specific request is to the 3rd party first. When they receive that bit of information they hold onto it and then make a SP-Initiated authentication request to your IdP. They will attach a bit of information as part of the auth request called relay state. This bit of information is used to reconstitute the session after the IdP responds.
Once the IdP receives the request it does whatever it needs to do to authenticate the user, and sends the token back to the 3rd party. As part of that response they also send the relay state. The 3rd party then verifies the token and sets the session as necessary, then reads the relay state and sets whatever internal state is necessary to continue the order.
You're on the right track. As the previous answers have explained, it can be done one of two ways: the SP site (Pillsbury) sends you an authentication request, or you can direct your IDP/Gluu server to send an SAML message to the SP without them prompting: "unsolicited".
In the case of the first "SP-Initiated", you just create a link to the SP site for the user's browser to follow. The user's browser hits the SP site, the SP site realizes that it needs to authenticate the user: so it creates a SAML Authentication Request to your IDP endpoint, directing the user's browser there. Then your IDP server will respond according to the metadata/relationship that you've set up with the SP site. Just as one of the other answers explained, this Authentication Request can include a RelayState parameter which will be sent back to the SP to tell them where to send the user after the SAML message had been consumed & validated. I haven't used Gluu but I believe the SP would use the second endpoint you showed in your question to do this.
In the case of the second "IDP-initiated", you need to direct the user's browser to one of the Gluu server endpoints to generate a SAML assertion, which will be POST'd back to the SP site without the SP site's prompting. This one is less used because every time the user is directed to the SP site from your site, they will be forced through the AuthN process among other reasons. I believe this is the first listed endpoint that you showed in your question.
Here's a really good explanation of IDP-initiated from Shibboleth, that should help clear this up for you: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO
Best of luck!
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.