Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Some target applications in an SSO environment may have stronger security requirements, where it is desirable to ensure that the user identity is confirmed again at the beginning of an application session and regularly throughout the use of the application. In effect, SSO is disabled, although the common IDP is used for authentication.

To implement this, the target application (SAML SP) must use the SAML2 options ForceAuthn and OneTimeUse settings in the authentication request (AuthnRequest). This can also be implemented by corresponding agent settings regardless of the agent type (see the following picture).


ForceAuthn ensures that the user is prompted to authenticate again even if they have an existing session which meets all other request requirements. Any existing SSO session is ignored.
OneTimeUse ensures that the newly generated IDP session cannot be used for access to any subsequent SP.

Ubisecure SAML SP for Java and Ubisecure SAML SP for ASP.Net API documentation describes the use of the above settings. Please refer to the relevant product documentation for authnRequest and authnRequestConditions.

For even more advanced use cases, application specific session timing requirements can be satisfied programmatically. Using the LoginEvent of the API, it is possible to check the time and date of the original user authentication, time and date that the SP assertion was issued and time and date after which the IDP application session lifetime ends. The LoginEvent has access to the following UbiloginSAMLAssertion object and AuthnContext methods:

  • getAuthnInstant() - the time and date of the original user authentication
  • getIssueInstant() - the time and date of the assertion issue at the IDP
  • getSessionNotOnOrAfter() - time and date after which the IDP application session lifetime ends

Decisions and behavior based on these values can be coded accordingly to application requirements.

  • No labels