3

I'm using the Spring Security SAML extension for my SP. After a user is authenticated from the IDP, the SP uses some sort of method to allow subsequent calls to not have to be reauthenticated with the IDP. How is this done in the Spring Security SAML extension?

A related question: Authenticating mobile users against SAML IDP

In the accepted answer from the above related question, the SP should create a token and pass it back to the client for future requests. I'm not seeing anything like this when watching the flow in Chrome's Network Tool. What should I be looking for?

Update 1: I'm coming to the conclusion that Spring SAML doesn't pass anything back to a browser in the form of a token. It must be keeping track of the user on the server side. Can I get confirmation on this? Is it possible to generate a token to pass back to the client in the case of a REST call?

Community
  • 1
  • 1
AndyB
  • 1,896
  • 2
  • 22
  • 32

2 Answers2

7

Spring SAML is relaying on Spring Security for handling of user's authentication state. By default user state is stored in SecurityContext and Authentication objects which are put into user's HTTP Session (identified by secure cookie typically JSESSIONID which is passed to the browser). You'll be able to find all details related to this in the Spring Security documentation.

In case your user is calling REST APIs from browser where she authenticated, and the API is deployed together with the Spring Security application, the call will be providing same cookies as you would get for normal server calls and they will be authenticated using the same mechanism without need for any tokens.

In case you want to perform calls to a 3rd party REST API where you have not established a session or authenticated using other means, one way to secure such scenario is e.g. issue and use OAuth 2.0 Bearer tokens.

Vladimír Schäfer
  • 15,375
  • 2
  • 51
  • 71
0

After the user is authenticated from the IDP, the IDP sends back a SAML assertion to the SP. The Spring Security SAML extension validates this assertion.
If the validation is successful, Spring Security establishes a user session, which is generally persisted through the cookie mechanism.

In the case of a REST service, your suggestion is basically what is done on OAuth-enabled REST services. The client sends an authorization token with each request.

sk_
  • 2,105
  • 17
  • 31
  • After the validation of the assertion is completed, I see too cookies being set: JSESSIONID and iPlanetDirectoryPro. The first is a common cookie and I could see that being used if the Spring SAML is handling everything via the server side session. The iPlanetDirectoryPro is being set from the IDP (OpenAM) so it's not Spring SAML exclusive. Assuming I'm correct in what I stated above in Update 1, ultimately what I'm trying to figure out is if there's a way to make Spring SAML provide a token for REST calls so that each request doesn't have to go back to the IDP. – AndyB Apr 21 '15 at 13:06