25
votes

Scenario:

  1. Browser(User) requests resource from Service Provider (SP).
  2. SP Redirects (with SAML Request) to Identity Provider (IdP).
  3. Since it is first login, User gives the (IdP) his/her valid credentials.
  4. IdP then redirects Browser (with SAML Response which includes SAML token) to the SP page.

I have two questions:

A. In Step 4, does the Browser store or cache the SAML Response and/or SAML token?

B. If yes, what kind of things (attributes? timeouts? protocols?) prevent me from taking that stored SAML token. Then coping it over to another computer (with a new session) and using that token to Login to the same SP?

4

4 Answers

10
votes

The answer is "sort of" re caching. In your scenario, the Response will be sent via POST to the Service Provider from the browser. So the browser can "cache" the POST data that contains the SAML Response. So, just like any other POST event in browsers, if the user were to use the back button enough times after logging into the SP to get back to the POST event, the POST data could be resent to the SP.

There are a few things that help keep the Response from being hijacked -

  1. Use of HTTPS between all parties
  2. SP enforcement of NotBefore & NotOnOrAfter attributes
  3. SP enforcement of one time use criteria (the SP must ensure that Response is not re-used during its validity period. If the message is received outside the validity window, then the SP should discard the message)
5
votes

The IDP usually stores a session cookie on the client browser identifying the SAML session. The theft of this session cookie is probably no more protected then any other session cookie.

Using HTTPS in communication between SP and IDP will provide a great deal of protection from session hijacking.

4
votes

For question A, it probably depends on the browser that you use.

For question B, there are several mechanisms that prevent the SAML response from being reused:

  1. SubjectConfirmationData has attribute NotBefore and NotOnOrAfter that specify the time frame that the SAML assertion is valid. Thus, the SAML assertion cannot be used outside of this time frame.
  2. SubjectConfirmationData has attribute InResponseTo that specifies the SAML request for which the SAML assertion is issued. Thus, the SAML assertion cannot be used for other SAML request.
  3. SP must ensure that the SAML assertion is not replayed by maintaining a set of used SAML assertion.

You can read Section 4.1.4.3 and 4.1.4.5 of SAML Profiles specification.

3
votes

I know this old, but the answer is yes the browser stores the SAML Token as a Cookie. (Typically) You can see it in your Browser's Cookie list, through various traffic/session inspectors like Fiddler, SAML Tracer on FF etc.