Failing to server parallel flows in SAML2

[Miguel Martínez De Espronceda Cámara]

Dear all,

I am reaching out regarding the use of CAS 6.6.8 for serving SAML2 requests. Currently, we are in the process of migrating our Google integration from the deprecated Google-native integration to standard SAML2 endpoints. To provide some context, the deprecated module was designed to directly reply within the /cas/login endpoint without performing a redirect. This approach deviates from the regular protocol integration, which follows the bridge pattern as described in the following documentation: https://apereo.github.io/cas/6.6.x/protocol/Protocol-Overview.html#the-bridge.

During our migration, we have encountered what appears to be a general bug in the SAML2 endpoints. We have observed that this endpoint saves the SAMLauthn (SAML authentication) in the user session prior to redirection to the login. Upon user login, the user is redirected to the SAML Callback endpoint, which retrieves the SAMLauthn request from the session and generates the SAMLresponse/assertion.

While this process works smoothly when the user completes the flow sequentially, we have encountered an issue when the user opens another SSO-integrated application in a separate browser tab before logging in. In this scenario, the controller overrides the SAMLauthn from the first tab with the SAMLauthn from the second tab. Consequently, when the user logs in on one of the tabs, it works correctly in the second tab but results in an error in the first tab.

I wanted to inquire if anyone else has experienced this issue and, if so, how you resolved or worked around it. Any insights or suggestions would be greatly appreciated.

Thank you for your attention.

Best regards,
Miguel

Este mensaje puede contener información confidencial. Si usted no es el destinatario o lo ha recibido por error, por favor, bórrelo de sus sistemas y comuníquelo a la mayor brevedad al remitente. Los datos personales incluidos en los correos electrónicos que intercambie con el personal de la Universidad de Navarra podrán ser almacenados en la libreta de direcciones de su interlocutor y/o en los servidores de la Universidad durante el tiempo fijado en su política interna de conservación de información. La Universidad de Navarra gestiona dichos datos con fines meramente operativos, para permitir el contacto por email entre sus trabajadores/colaboradores y terceros. Puede consultar la Política de Privacidad de la Universidad de Navarra en la dirección: https://www.unav.edu/aviso-legal

 

This email message may contain confidential information. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments.  The personal information included in email messages exchanged with employees of the University of Navarra may be stored in the database of your interlocutor and/or the servers of the University for the time-period stipulated by its internal information storage policy. The University stores such data for purely administrative purposes, to facilitate e-mail contact between its employees and third parties. The University of Navarra Privacy Policy may be accessed at https://www.unav.edu/aviso-legal      

 

Antes de imprimir este mensaje o sus documentos anexos, asegúrese de que es necesario. Proteger el medio ambiente está en nuestras manos.
Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment.

[Ray Bon]

Miguel,

This sounds like what Jérôme talked about in this thread https://groups.google.com/a/apereo.org/g/cas-user/c/fNZ82V32sio/m/RKhi5VQCAQAJ?utm_medium=email&utm_source=footer

Ray

On Fri, 2023-06-09 at 05:03 -0700, Miguel Martínez De Espronceda Cámara wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

[Miguel Martínez De Espronceda Cámara]

Thank you, Ray. Best regards

[Miguel Martínez De Espronceda Cámara]

Dear Ray, Jerôme, 

I have asked colleagues in other universities and they reproduce the same problem. We are interested in collaborate and propose an improvement to the web flow. I have checked the code and as I see it I will need to change a few core classes. At a minimum, I think that the solution will be to store the SAMLrequest in a separate TST, which will be handled in the AbstractSamlIdPProfileHandlerController. It could construct the redirect URL including the ticket in a parameter  to the callback url named sessionIdInRequestAttribute. 

An example of the redirect to login will be the following (URL encoded): 

https://example.org/cas/login?service=https%3A%2F%2Fexample.org%2Fcas%2Fidp%2Fprofile%2FSAML2%2FCallback%3FentityId%3D{{SP_ENTITY_ID}}%26sessionIdInRequestAttribute%3D{{SESSIONID}}

Once authenticated, the regular login flow will redirect the client to the callback:

https://example.org/cas/idp/profile/SAML2/Callback?entityId=<SP_ENTITY_ID>&sessionIdInRequestAttribute=<SESSIONID>&ticket=<SERVICE_TICKET>

It seems that the code right now will process the request seamlessly from this point.

The the SSOSamlIdPProfileCallbackHandlerController will load the session from this parameter, accorfing to the implementation of the DistributedJEESessionStore. It is not possible for the standard JEESessionStore, so this should only be applied in case of cas.authn.saml-idp.core.session-storage-type=TICKET_REGISTRY.

I do not know much about the implicatins in the other SAML profiles but seems coherent.

To do that, an approach is to modify the DistributedJEESessionStore and the AbstractSamlIdPProfileHandlerController. Minimum of changes will be:

- implement the renewSession method of the sessionStore or define a new method. Really I do not now if it should be a different method as the renew meaing lets undefined if the previous session is destroyed. I think of it as duplicateSession.

- call this method at the begining of request processing (autoConfigureCookiePath).

- optionally, do not send the session cookie to the client.

- destroy the TST once used (probably this is already done, I have to check)

What do you think? Is this the correct path to go?

Best regards,

Miguel

PD: I wrote in the other thread but it wasn't published. 

[Miguel Martínez De Espronceda Cámara]

Good morning!

I'd like to gather some opinions on the following implementation idea. I'm planning to create a facade for the SessionStore called StackableSessionStore. The purpose of this facade is to handle the storage of the TST (Ticket Storage Token) in a new session object that won't be transmitted via cookies. However, it should still be able to retrieve the TST when needed.

To kickstart the process, my plan is to introduce a new puppeteer scenario. I believe the best location for it would be in ci/tests/puppeteer/scenarios/saml2-idp-login-concurrent. Here's the outline of my plan:

1. Reproduce the scenario in the test.
2. Rebuild the SessionStore component, ensuring it stores a new session backed by the TicketRegistry. This involves copying the data from the previous session and preventing the cookie from being returned to the client.
3. Retrieve the TST as a parameter.
4. Test the new scenario thoroughly.

I would greatly appreciate any opinions or feedback on this approach.

Thank you in advance!

Miguel

[Miguel Martínez De Espronceda Cámara]

Bear all,

I implemented two approaches:

1. Passing the SAML artifacts in the URL
2. Creating a new TST for each SAML request and passing it as parameter (do not store artifacts in the session).

Although both of them work in our setup, I do not like them completely. Misagh commented about approach 1, that it is not a good way to go in general, as the length of SAML request and artifects could not be fully compatible with in all kind of browsers. In the case of approach 2, the flow will still be lost and the error still happen in the case that the user waits too much to load the session as the TST will have been removed from the Ticket Store.

https://github.com/apereo/cas/pull/5703

Best regards