Thoughts on how to support multiple session durations with SAML2

This topic has 5 replies, 2 voices, and was last updated 4 years, 11 months ago by Scott Heger.

  • Author
  • #18234

    I’m soliciting ideas for how best to configure/implement OpenAM to meet these requirements.

    Imagine I have two SPs that rely on OpenAM to authenticate users as the IdP. SAML2 is a requirement.

    Application A:
    * Wants users to authenticate every 4 hours

    Application B:
    * Requires users only authenticate every 30 days

    We have implemented our own login site (UI). Behind the scenes it makes REST calls to OpenAM to authenticate users. Upon successful authentication it sets the iPlanetDirectoryPro cookie in the user’s browser. So, this custom login site needs to be part of the solution.

    What’s the best way to configure OpenAM to meet these requirements? Both SPs have a 30 min app session, so they will be making auth-requests back to OpenAM as frequently as every 30 minutes, per user.

    Authentication is always SP initiated.

    I feel like a persistent cookie could be useful for the Application B authentication flow. It would be valid for 30 days.

    But, I want to ensure the following scenario doesn’t happen?….

    A user comes in on Monday, visit Application B, is redirected to our login with our login site and authenticates -setting a persistent cookie. Then tomorrow, the same user visits Application B again, but this time isn’t prompted to authenticate because of the persistent cookie. Immediately following this ‘persistent-cookie authentication’, the user then visits Application A. How do I ensure the user is still prompted for their credentials during this auth flow? We need to ensure that the presence of the iPlanetDirectoryPro cookie doesn’t automatically log in the user for Application A.

    All ideas and comments are welcome. Hopefully we can achieve our goals without writing any code (expect for maybe our custom login site).


     Scott Heger

    I haven’t validated this with a POC, but you could try to achieve this as follows:

    In the realm where you have your SAML entities defined, create two authentication chains that include the Adaptive Risk module. Configure the Adaptive Risk module to use the “Time since Last login Check” option. Set the values appropriately for the two application session requirements. In the chain for Application B also include the persistent cookie module and PAP. Then set up two different IDP entities, one for Application A and one for Application B. Put them both in the same realm and CoT for SSO purposes. Configure each one to require authentication via the appropriate chain for each app.

    In this case if someone has a 30 day persistent cookie from Application B’s IDP, it won’t be used for the IDP for Application A since it requires a different chain. Also the Adaptive Risk module in each chain will check to see the last login time and you can fail and force re-authentication if the time exceeds your values.

    One potential issue with this approach is that I think the time interval that is set in the “Time since Last login Check” option is in terms of days vs hours that you need. In any event with some creative use of authentication chains and multiple IDPs you should be able to come up with something.

    Hopefully that points you in a direction that can help.


    Thanks, we’ll look into that. One issue we’re having with this setup is that our single-logout process doesn’t seem to work across 2 IdPs. Somewhat surprisingly, it seems logging out of one SP causes OpenAM to send logout requests to both SPs -even though they are using different IdPs.


    So we have the authentication part working beautifully. We are using two IdPs in a single circle of trust. But they are configured to use different auth chains and have different minimum auth levels. The IdP that uses the persistent cookie has a lower required auth level than the one that requires full authentication(username/password). So the persistent cookie module has an auth level of 0 (and is sufficient). The LDAP auth module, next in the chain, has an auth level of 5 but marked as optional. In the normal auth chain the LDAP module is marked as required and also has an auth level of 5. If a session is created with an auth level of 5, the user can log into any SP. But if a user only authenticates with the persistent cookie, only the auth chain for app B will allow the user to proceed.

    That’s all great but now we have logout issues. If I have logged into both app A and B, then when I attempt an SP initiated single logout, the logout request that OpenAM eventually sends to the other SP fails because the logout request comes from an IdP that the other app doesn’t recognize (different IdP entity name/issuer than what the SP imported from the other IdP metadata)

    Is there a way to fix this? I’d settle for just having the SP and OpenAM sessions ended while the other SPs live on until their app sessions end. But I can’t figure out how to configure this with OpenAM. If an SP sends a logout request, then OpenAM attempts to send a logout requests to all SPs -even if they’re in a different circle of trust or we’re authenticated by a different IdP and auth chain.

    Thoughts? I feel like we’re really close to solving this but I’m not seeing many options to control the logout process.


    I think we found a solution to our logout problems. Instead of using 2 IdPs, we stuck with a single IdP in our circle of trust. We then configured 2 Authentication Contexts. Each auth context specified the auth-chain to use and the minimum auth-level that it would accept. As mentioned above, the LDAP module has sets the highest auth level (compared to the Persistent Cookie module). Finally, we configured the extended-metadata of each SP to use a specific authentication context when authenticating.

    This way, when an SP initiates single sign on, it will call our single IdP and then authenticate through the appropriate auth chain. The other SP will use the SAME IdP, but this time invoke a different auth-chain through the different auth-context.

    And finally, when SLO is initiated, it just works because all SPs were authenticated by the same IdP (in the same COT).

     Scott Heger

    Very cool. Glad you got it figured out and also shared your solution with the community.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?