I am trying to configure BIME Analytics as a service provider (SP) to use Google for Work as a SAML Identity Provider (IdP).
Following the instructions at https://support.google.com/a/answer/6087519?hl=en I am able to perform SP initiated authentication. This means if I visit https://.bime.io/portal and click the SAML login button, I am redirected to a Google login page and after entering my Google for Work credentials am able to access my BIME portal page.
Unfortunately, I cannot get IdP initiated authentication to work. That is, from Gmail for example, if I open the app launcher and click on the icon for my BIME SAML app, it will take me into BIME without any authentication issues, but then I get a BIME dashboard not found error.
BIME support was able to identify that this is because I was not sending a RelayState parameter value which they require. When I start in BIME, I'm on their webpage and there is a hidden RelayState value that is sent to Google to let it know where to send me after I log in. However, when I start in Google, that value is not set. BIME support was able to configure the connection in Okta because Okta has a "Default RelayState" field that they could hardcode a value into.
For Google SAML apps, how do I specify a default RelayState value to enable IdP initiated authentication into a SAML app?
Yesterday I took a look at the IdP SAML setup page in G Suite and noticed there is an optional "Start URL" field.
I also noticed in the help documentation to configure pre-integrated SAML applications that the "Start URL" field was frequently used.
Since the configurable parts of an IdP response are:
SAMLResponse With Assertion (including "Assertion Consumer Service URL" and "Entity ID" fields in G Suite config page)
RelayState parameter
I had to guess that the "Start URL" is likely the field to hold the RelayState parameter. Considering RelayState is an optional--but important and commonly used--part of the SAML integration this makes a lot of sense. It also explains why the field is optional, and directly below the ACS and Entity ID fields.
This Oracle blog post references the Start URL field and suggests one of its uses is to contain the unsolicited RelayState value:
Optionally enter a Start URL for Google IdP Initiated SSO operations,
where the user will click on the SAML Application partner at Google to
be redirected to the Application at OAM: this would be the protected
application URL, or unsolicited Relay State.
So while I can't test myself at the moment, I think it's safe to say this "Start URL" field is what you're looking for to set your RelayState value.
The relaystate URL you are looking for is
https://www.google.com/a/[DOMAIN]/ServiceLogin?continue=https://mail.google.com
More info here
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?
When initiating a SAML authentication request (from the Service Provider), is there any way to give the Identity Provider the username/email address to set as a default on login screen? I'd like that username to be added in the IdP's username box.
Using SAML 2.0 with OneLogin
I understand this can be done with the information within the AuthnRequest, but I cannot see any way of being able to modify that data.
is there any way to give the Identity Provider the username/email address to set as a default on login screen?
As far as I know, there is no standard way to indicate required attributes as part of a SAML authentication request sent by the SP. If you know this capability exists in the SAML specification, please share a link.
And even so, if hypothetically there was a way to ask for attributes in the authentication requests, that would only suggest to the IdP to consider sending and releasing those attributes back to the app; not that the attribute should be used in the login process/forms. That feature, is entirely implementation specific and depends on your choice of the SAML2 identity provider.
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.
I am trying to understand implementation of SSO system for service provider. Here are my questions.
User logs into System A. System A does authentication and displays a link to the user on page. When User clicks the link, System A redirects user to System B where System B is a 3rd party vendor. Who is IdP here and who is SP?
Is there any server to server communication in a flow initiated from IdP to SP? Is it required in all scenarios?
can you explain the data flow step by step in case of IdP initiated flow to SP?
Any material on this same or simple explanation will help.
In answer to your questions and assuming SSO via Security Markup Language (SAML):
System A is the Identity Provider (IdP) and System B is the Service Provider (SP).
There is no server-to-server communication. Information is passed via the client browser using HTTP bindings, for example HTTP POST.
Step by step IdP-initiated workflow (taken from OASIS SAML V2.0 Technical Overview):
If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML message. The message is then placed within an HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource (not shown).
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
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.