My application's entry point is a custom URL , how do I tell Spring to redirect to my URL after a successful SAML dance ? I am using IDP initiated flow.
In my app. I have several versions defined depending on a client.
e.g Client abc goes to https:\localhost:8443\abc\admin and client xyz goes to https:\localhost:8443\xyz\admin
thanks
Turns out there is a handler called SAMLRelayStateSuccessHandler which redirects to an endpoint defined in "Default Relay State" configuration item in Okta (application configuration).
So first thing go to Okta and specify a redirect URL in "Default Relay State" property. Then add this property to SAMLProcessingFilter :
samlWebSSOProcessingFilter.setAuthenticationSuccessHandler(new SAMLRelayStateSuccessHandler());
and once Spring-SAML authenticates successfully it'll redirect to your relay URL.
Related
We want an external identity provider within our identityserver where user is redirected to login to this external identity provider (Idp) and complete the authentication there. The external Idp redirects the response back to our identityserver where we want to form the user claims from the response and redirect back to the calling client.
We followed the answer to this stackoverflow question. We implemented our own owin middleware following the the Anders Abel Tutorial and owin middleware's for Google Auth as external Idp.
We also followed the exact implementation of CustomHrd Sample. Everything in the middleware works perfectly, the user gets redirected to the external Idp with the state, we get the response from there back (with the state), we form the claims and on completion we finish the owin middleware pipeline and redirect to /core/callback, but the Identityserver gives the following error:
The URL call flow is available below:
/core/connect/authorize?params
/core/login?signin=3a84a4f3dfe3218b06f3aa2185415e1e
/core/ta (IDP Selector page)
/core/login?signin=3a84a4f3dfe3218b06f3aa2185415e1e (Resume Uri after Idp Selection)
/core/ta/tacall?state=
Redirect to External URL with state
Callback from External Identity provider with state: /core/ta/tacall?state=
Redirect from middleware to redirectUri after forming claims - /core/callback
Error occurs on /core/callback saying "There is an error determining which application you are signing into. Return to the application and try again."
Can you please help us figure out why would this occur?
Note: I also looked into the cookies, we are passing the cookie to /core/callback which contains the SignInMessage.
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
For example, you have TWO different folders on your web site, /folderA and /folderB
You can set the common loginURL for both of these pages in Spring Security.
I use Spring SAML. It aal
Spring Security: Once users try to get /folderA or /folderB, they will be redirected to the "local" LoginURL first (domain.com/auth).
Spring SAML: LoginURL page (domain.com/auth) will redirect the user to the remote SAML SSO provider (for example, myapp.okta.com). The endpoint is specified in metadata.xml.
SAML SSO provider redirects the user to SSO url (configured in OKTA, let's say sso.domain.com/auth/sso).
I want to use the original requested URL (in this case, /folderA or /folder) in the SSO controller (sso.domain.com/auth/sso). I want to make the logic dependent on the requested URL.
So my question is
How to inject these folder URLs into the request to SAML SSO Provider using Spring SAML?
I know how to implement it without Spring SAML. So I am looking how to configure Spring SAML for it.
I think that RELAY_STATE is used for it. But I can’t understand on how to retrieve it at the steps (1) and/or (2)
Relay state is passed as query parameter along with SAMLRequest. Passing relay state depends on the toolkit you use so you would need to check their documentation to see how it can be done. I found this useful thread online http://forum.spring.io/forum/spring-projects/security/saml/125415-spring-saml-integration-authentication-extended-info-relaystate
Also, you can follow this link once session is established via SAML (in that case you can skip passing session token) http://developer.okta.com/use_cases/authentication/session_cookie#initiate-a-saml-sso-with-the-session-token. You can use the single sign on url from Sign on Tab -> View Setup instructions and make a GET request to that passing in the RelayState. That will initiate take you to relay state.
I am creating simple service provider (SP) on java with wso2 saml sso authorization.
I implemented it in this way (please correct me, if I'm wrong):
User inputs some target Url in browser
My SP's servlet sends redirect to WSO2 IDM.
IDM authorizes the user and redirect to my Consumer Url with
SAMLResponse and RelayState parameters.
Now SP must process this request and redirect user to target Url without redirection to IDM again. Otherwise I'll get the infinite loop, so I think that between step 1 and step 2 should be one more step...
What is the proper way to do this?
Typical implementation
1 User tries to access a protected site
2 A filter checks if the user has an authenticated session.
2.1 If not, redirect to IDP/IDM
2.1.1 IDM authenticates user and redirects back to SP with identity proof
2.1.2 SP creates authenticated session
2.1.3 User is redirected to target URL everything start from 2 again.
Here I have a post describing the flow in more detail
Method 1
Browser is directed to Service provider. Service provider checks whether there is any cookie set, If no then it redirects browser to Identity provider and Identity provider(IdP) validates user and redirect a ID to Service Provider(SP). SP takes that ID and set it as session cookie in browser and redirects user to service. Next time, if user asks for service again in same session the SP checks for cookie and redirects directly to service.
Method 2
Browser is directed to Service provider. Service provider redirects to IdP. IdP checks for its cookie and if cookie is not present,IdP authenticates user and set session cookie in browser. Redirects positive response to SP. SP redirects user to service. Next time user asks for the service within the session, Browser is directed to Service provider. Service provider redirects to IdP.IdP checks for its cookie and if it is present,it sends positive response to SP.
I am pretty sure that Guanxi implementation of Shibboleth (SAML2 profile) and almost sure that Shibboleth itself can be simplified to your "method 1".
You better check some of existing SAML2 profile implementations.
I don't believe either of those are valid SAML implementations. Usually in SAML identity information is communicated in a HTTP POST or through SOAP web service (see: http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language#SAML_2.0_bindings). Cookies are not used to 'authenticate' a user.
We have a web application that uses SAML 2.0 XML communicated in a HTTP POST to authenticate the user. Our customer's employees go through the identity provider on their side of the firewall to access our application.