Currently, I'm using spring-security-saml2-sample project(V1.0.1) as an SP, and Shibboleth as an IdP. I've implemented the Web SSO profile and trying to write an ECP client to make ECP profile work. However, I found limited documents about ECP profile in spring security saml(Ref doc Chapter 10.4)..
I found two useful ECP client samples in github:
github.com/spaetow/ShibbolethECPAuthClient
github.com/DARIAH-DE/shib-http-client
After enabling PAOS binding and "ecpEnabled" in SP's metadata generator, I wrote some sample ECP client code refering to the above two project, the main flow is:
Send a Get request to "localhost:8080/spring-security-saml2-sample/saml/login" with PAOS related header.
Get the response(SAML Request) and generate a SAML Envelope.
Use the new generated SAML Envelope to Post to Shibboleth IdP(https://exampleIDP/idp/profile/SAML2/SOAP/ECP), with UserName/Password in Authorization Header(basic authentication).
Shibboleth authenticate and response with SAML Assertion(Also an SAML Envelope).
Send the SAML Assertion(Envelope) to SP: "localhost:8080/spring-security-saml2-sample/saml/SSO" and get response.
I think I've succeeded in the first four steps, Shibboleth can authenticate the user and send the SAML Response. But I've got some problems in the 5th step. And even some examples end in step 4.
I found that, spring security saml gets the 5th request and tries to Authenticate the SAML response just like WebSSO profile does. The logic is in "org.springframework.security.saml.SAMLProcessingFilter". After parse the saml response and get the Authentication, the response will be redirect to a default target URL"/". The logic is in AbstractAuthenticationTargetUrlRequestHandler.handle(req,resp,authn). So, I can only get an 302 HTTP response in the ECP client.
Here are my questions:
I want to get user information in the 5th step, do I have to write another filter instead of "SAMLProcessingFilter" to send the Authentication as response? Or is there any other ways(I think ECP client cannot parse SAML Assertion received in Step 4)?
In this situation, my ECP client likes "Rest client" very much, because I have not record any cookies in my code. So after the 5th step(after login), how can I access the SP again for another resource? Does that mean I have to record the JSessionID cookie in the ECP client?
Is the theory of SAML SSO(WebSSO) like Jasig CAS(Use cookie/session)? If so, in the ECP mode, How can I single sign on two ECP clients(each connect to different SP but SP cpnnect to the same IdP). Or, can I make SSO in a ECP client and a browser?
Thanks in advance!
Related
There are two spring-boot apps.
client
resource-sever
there is dev okta account that is used as auth server
(those 2 apps are standard Spring Boot client -> resource-server, almost out of the box with okta setup for them, should not be problem there)
client - securely sends messages to--> secure-sever (passing the access token in the header as prove that it's authorized to call it and get data back)
(it works as expected)
But I am trying to figure out what's going on between all them, traffic wise
I'm trying to spot that moment when resource-server checks the token it got from the client that got it from the auth server.
Here is a sequence diagram of standard oauth 2.0 flow and that part that I want to debug (arrow)
auth server
And there is a communications between client, resource-sever:
There seems I can not confirm that Resource Server (from the right) does any token validation with the auth-server (okta)..?
Question: is why? From my understanding it is supposed to validate it (somehow).
I was expecting to see a call from resource-server to auth-server (otka) with the token-validation-request (ETF RFC 7662 in October 2015) like this:
How to validate an OAuth 2.0 access token for a resource server?
I was expecting, lets say, tat for every client call, resource server would check if that token the client passes is valid. Yet I do not see any calls from resource service to okta that would use the token in its requests to okta.
This comes down to the difference between JWTs and opaque tokens.
It looks like your application is using JWTs, based on the calls I'm seeing to /keys.
When using JWT authentication the resource server will query the jwks_url (in this case /keys) on startup to retrieve a set of public keys that it can use to validate the JWT-encoded bearer tokens.
Then, when the resource server receives a bearer token in a request from the client it will validate its signature against a public key obtained from the jwks_url endpoint.
This means the resource server doesn't have to query the authorization server on every request.
You can read more about this process in the OAuth 2.0 Resource Server JWT section of the Spring Security reference documentation.
The question that you linked to refers to opaque tokens.
In this setup, the resource server must call the authorization server introspection endpoint to validate the token every time.
You can read more about this process in the OAuth 2.0 Resource Server Opaque Token section of the Spring Security reference documentation.
I need to develop set of microservices (rest APIs) which is to be used by web and mobile client, the microservices are sitting behind API gateway, I've to integrate with SSO (using SAML) for user's authentication, I understand that SAML token to oAuth2 token conversion has to be done so that I can verify auth token at API gateway and handle authorization there itself, but the piece which is not clear to me is that who will take care of conversion of SAML token to oAuth2 token, is it IDP who provide this functionality out of box or do I need to built up something of my own?
One possible solution which I'm thinking of is
User (from web/mobile) sign in via SSO
Gets SAML response from IDP
Send that SAML response to server to generate Auth Token
Server gets request to generate auth token, looks for SAML response and validate it against IDP
If SAML response is valid then generate auth token and send it back to client
On subsequent API request from client the token is passed as header which API gateway validates
The thing is I'm bit reluctant to implement SAML and oAuth thingy myself and looking for some ready made solution but couldn't find any, can someone please suggest of any library solving this problem, thanks in advance.
It feels like your approach is correct - it is the role of the Authorization Server (AS) to deal with SAML login integration for you. Only configuration changes should be needed, though of course you need to use an AS that supports SAML integration.
Your UIs and APIs will not need to know anything about SAML and will just use OAuth tokens. There should be zero code changes needed.
Most companies use an off the shelf AS - eg from a low cost cloud provider. My Federated Logins Blog Post summarises the process of integrating an IDP. The walkthrough uses AWS Cognito as the AS - and the IDP could be a SAML one.
I maintain a microservice that sounds like it could help you - https://github.com/enterprise-oss/osso
Osso handles SAML configuration against a handful of IDP providers, normalizes payloads, and makes user resources available to you in an oauth 2.0 authorization code grant flow.
Osso mainly acts as an authentication server though - we don't currently have a way for your API gateway to verify an access token is (still) valid, but that would be pretty trivial for us to add, we'd be happy to consider it.
I'm looking to implement a plugin using OpenSAML for a 3rd party application that will enable the application to be treated as a SAML Service Provider, so that I can integrate it into AWS SSO.
The following image describes the SAML authentication process when the Service Provider (SP) and Identity Provider (IdP) use HTTP Artifact binding (taken from here):
After the initial authentication, the SP returns the protected resource to the user. My question relates to how subsequent requests for protected resources are processed.
With OIDC, the browser would receive a token and this would be sent to the SP for subsequent requests. The SP can inspect the token and confirm its integrity (assuming it is signed) and validity, without needing to make further calls to the IdP to re-authenticate the end-user.
With SAML, how do I achieve the same effect? How do I not have to make repeated calls to the IdP to check identity?
I suppose I could use a session, but I don't understand how I might ensure that such information is not tampered with within the client (i.e. how does the SP not have to rely on information provided by the client?). Does SAML have some sort of concept of a token that is safe for the user to store (the HTTP Artifact binding explicitly restricts the user from seeing the response from the IdP)?
What happens after the last step is not defined in the spec. You could say it's formally outside of SAML protocol. Even the last protocol-formalized step of SP supplying the resource is essentially a "do it yourself":
Section 3.4.5 (HTTP-Redirect binding):
Upon receiving the SAML response, the SAML requester returns an
arbitrary HTTP response to the user agent
Section 3.5 (HTTP-POST binding):
Upon receiving the SAML response, the SAML requester returns an
arbitrary HTTP response to the user agent
Section 3.6 (HTTP-Artifact binding):
[you can probably guess by now]
Most SPs will drop one or more cookies on the client during that last step. One of those cookies will contain a session ID or a more generic pointer that can be used to locate a session when sent back to SP. Subsequent resource "authorization" requests to SP will proceed by having the SP consult this server-side session. The session will usually hold the (authenticated) security context for this user/client.
For example, Shibboleth (built on top of OpenSAML) does so. The content of the cookie is up to the SP. It's arguable that token-based auth via e.g. local storage is more secure vs a cookie. There are pros/cons to both options and many factors specific to use case/context/technology stack impact the evaluation of risk and associated threat model.
Note: AWS SSO does not support the Artifact binding.
I created my SP using Spring SAML Security. I'm having an issue with Global logout. The logoutRequest is sent to IDP and IDP sends back the logoutResponse. SP validates the message successfully and the logout.jsp is reached without a problem.
The problem I'm having is that the IDP is expecting a “SAML Response” from the SP after successful logout to clear the session. Am I missing something in the configuration?
SP is not supposed to send any additional response once it receives LogoutResponse from IDP. See saml2-profiles, chapter 4.4 for details. It also contains a nice picture which illustrates the message exchanges.
I am trying to implement SAML SSO between two J2ee applications (form-based) deployed on two different instances of WAS, I have configured both WAS instances as service providers using the steps in http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftwbs_enablesamlsso.html
I set the property sso_1.sp.login.error.page to the login page of the Identity provider but when I get redirected to the login page, it displays that no SAML request (AuthRequest) is available, can anyone tell me why the WAS is not issuing the SAML authentication request?
WAS does not send a SAML request in the redirect. This is explained in the paragraph above this section of the DeveloperWorks SAML TAI article. The scenario you're expecting is referred to as the solicited response. WAS only supports what the article terms the unsolicited response. In this latter case, the IDP must understand how to authenticate the user (usually through a browser interaction) without a SAML request.