5

I'm building SAML 2.0 based authentication to a web application. The authentication is done against an WSO2 Identity Server (WSO2-IS). I have managed to get the actual authentication working using HTTP redirects. However now I'm having issues trying to "refresh" the authentication information from the Identity Server.

The problem is that the assertions the WSO2-IS is returning have only a lifetime of 5 minutes. So based on this, I should get a new assertion from the WSO2-IS every 5 minutes. However I have found no other way to do this against the WSO2-IS than doing yet another round of redirects. Redirecting the user somewhere else every five minutes is not very user friendly.

SAML 2.0 specifies an AuthnQuery request, which is supposed to be done using SOAP over HTTP. If I've understood correctly, the AuthnQuery would be exactly what I need to re-request assertion information for the user, but to me it seems that the WSO2-IS does not support this request.

So, the question is, how would I be able to refresh (or re-request) the assertion information from the WSO2 Identity Server without having to redirect the user away from the page they are currently accessing?

Community
  • 1
  • 1
Pauli Kaila
  • 53
  • 1
  • 3

2 Answers2

1

The answer is to be found in the SAML proile speciefication under Web browser SSO profile -> Usage and Message Processing Rules.

The bearer element described above MUST contain a element that contains a Recipient attribute containing the service provider's assertion consumer service URL and a NotOnOrAfter attribute that limits the window during which the assertion can be delivered

NotOnOrAfter is the time at which the message has to have been delivered.

What you should consider is the attribute SessionNotOnOrAfter in AuthnStatement if it is present.

If an used to establish a security context for the principal contains a SessionNotOnOrAfter attribute, the security context SHOULD be discarded once this time is reached, unless the service provider reestablishes the principal's identity by repeating the use of this profile.

SAML profile spec

Stefan Rasmusson
  • 5,445
  • 3
  • 21
  • 48
0

Im not sure you can use that anyway. This is from the SAML spec

The message element is used to make the query “What assertions containing authentication statements are available for this subject?” A successful will contain one or more assertions containing authentication statements.

The message MUST NOT be used as a request for a new authentication using credentials provided in the request. is a request for statements about authentication acts that have occurred in a previous interaction between the indicated subject and the authentication authority.

You are talking about the NotOnOrAfter contraint on the assertion, right? As I understand it this just for when you can't trust that message anymore. I you read it before that time is up you can consider the user as authenticated. This is typicaly to prevent replay attaks.

Stefan Rasmusson
  • 5,445
  • 3
  • 21
  • 48
  • Yes, I'm talking about the NotOnOrAfter constraint. Based on the spec it defines the validity of the assertion. The way I understood it was that you cannot trust the user to be properly authenticated after that and a re-authentication was needed. I have not found anywhere any information that would state otherwise. However if the condition is there only to prevent replay attacks and I can myself decide for how long I trust the authentication information, then there is no issue. – Pauli Kaila Feb 08 '13 at 08:03
  • When I think about it, I think the issueInstant is for replay. This was interesting. – Stefan Rasmusson Feb 08 '13 at 11:13
  • Now I'm a bit confused. I thought that the way you described the assertion condition to be there just in order to prevent replay attacks made sense. I just could not find supporting documentation in the specifications, but neither could I find anything that would be against that idea. Are you now having second thoughts? – Pauli Kaila Feb 08 '13 at 11:49
  • Yes I am. i don't think NotOnOrAfter if for replay prevention. But I still don't think you need to refresh the assertion when NotOnOrAfter is up. But i have no documentation supporting this. I will try to find some. – Stefan Rasmusson Feb 08 '13 at 12:11
  • Found some on this on google apps SSO pages. NOT_ON_OR_AFTER - A timestamp identifying the date and time after which the SAML response is deemed invalid. It indicates this is actually for the validity of the message not the user session. Not empirical proof but its something – Stefan Rasmusson Feb 08 '13 at 13:57