SPs work and then they don't - Web Login Service - Stale Request

Fri Jul 9 17:46:20 UTC 2021

Jay,

That implies to me that the authentication plug-in is broken.  It should absolutely be able to do that, and the fact that time-bounding it triggers it indicates that the plug-in is doing something horribly wrong.  It's best to bring it up with the maintainers of the code; it's not really a Shibboleth problem.  It's a plug-in problem.

Thanks for taking the time to clarify,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

-----Original message-----
From: Jason B. Rappaport
Sent: Friday, July 9 2021, 5:38 pm
To: Shib Users
Subject: RE: SPs work and then they don't - Web Login Service - Stale Request

Thanks Nate for the information.

By it stops working, I mean that when I try to log into the same SP or another SP I never see CAS, but rather I see the stale request.

When I start up the IDP:
1) I got to a test SP
2) I am redirected to the IDP
3) I am redirected to CAS
4) I authenticate
5) I am redirected back to the IDP
6) I am redirected back to the SP and I am logged in
7) Then I wait a few minutes
8) I try my other SP
9) I am redirected to the IDP and I immediately see the stale request

If I reverse which SP I started with the same thing happens.

If I remove step 7 from above, I can log into the second SP.

Thanks, Jay

________________________________
Jason Rappaport (he/him)
Identity and Access Management Analyst
Office of Information Technology
Email:  jasonrap at princeton.edu <mailto:jasonrap at princeton.edu> 
Office:  609-258-8464

-----Original Message-----
From: users <users-bounces at shibboleth.net <mailto:users-bounces at shibboleth.net>> On Behalf Of Nate Klingenstein
Sent: Friday, July 9, 2021 1:32 PM
To: Shib Users <users at shibboleth.net <mailto:users at shibboleth.net>>; users at shibboleth.net <mailto:users at shibboleth.net>
Subject: RE: SPs work and then they don't - Web Login Service - Stale Request

Jason,

I'm not sure I completely understand what you mean by "it stops working", but basically, you're losing track of the user's container session during authentication.  Closing the browser and then re-opening it causes a replay of a stale step in the login flow that the browser helpfully cached, leading to the error you're encountering.  Try just randomly going to https://samltest.id/idp/profile/SAML2/Redirect/SSO?execution=e1s1 <https://samltest.id/idp/profile/SAML2/Redirect/SSO?execution=e1s1> and you'll see the exact same phenomenon.

We would need more details on what you mean by failure, and it may very well be issues with the plug-in.  It could have some munged flow use that is leading to this.  But from the IdP's perspective, you're just attempting to resume a flow that has already expired.  Stale request means stale request.

Take care,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id <https://www.signet.id>

-----Original message-----
From: Jason B. Rappaport
Sent: Friday, July 9 2021, 5:24 pm
To: users at shibboleth.net <mailto:users at shibboleth.net>
Subject: SPs work and then they don't - Web Login Service - Stale Request

Good afternoon.  I am working on configuring two Shibboleth IDP 4.1.2 hosts behind a AWS ALB, their configuration is controlled via an Azure DevOps pipeline.  We are using the Shib-cas-authn plugin to defer authentication to CAS.

When I restart the IDPs, authentication (CAS) and attribute resolution (Shibboleth IDP) works great.  A few minutes later, in the same web browser it stops working.  If I close the web browser and open it back up again, it also fails immediately.

Here is a snippet of the logs when it worked and then 9 seconds later when it failed:

2021-07-09 10:26:16,461 - 10.21.0.37 - INFO [Shibboleth-Audit.SSO:283] - 10.21.0.37|2021-07-09T14:26:09.896165100Z|2021-07-09T14:26:16.461130700Z|testaccount|https://testservice/saml/metadata|_bbc….|password|2021-07-09T14:24:37.583Z|universityid,eduPersonPrimaryAffiliation,eduPersonPrincipalName,eduPersonScopedAffiliation,eduPersonAffiliation,surname|A…..|transient|true|true|AES128-GCM|Redirect|POST||Success||1fe670e15... <https://testservice/saml/metadata|_bbc….|password|2021-07-09T14:24:37.583Z|universityid,eduPersonPrimaryAffiliation,eduPersonPrincipalName,eduPersonScopedAffiliation,eduPersonAffiliation,surname|A…..|transient|true|true|AES128-GCM|Redirect|POST||Success||1fe670e15...> (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0|10.21.0.37
2021-07-09 10:26:25,025 - 10.21.0.37 - ERROR [org.springframework.webflow.execution.repository.NoSuchFlowExecutionException:91] -
org.springframework.webflow.execution.repository.NoSuchFlowExecutionException: No flow execution could be found with key 'e1s1' -- perhaps this executing flow has ended or expired? This could happen if your users are relying on browser history (typically via the back button) that references ended flows.
at org.springframework.webflow.execution.repository.support.AbstractFlowExecutionRepository.getConversation(AbstractFlowExecutionRepository.java:172)
Caused by: org.springframework.webflow.conversation.NoSuchConversationException: No conversation could be found with id '1' -- perhaps this conversation has ended?
at org.springframework.webflow.conversation.impl.ConversationContainer.getConversation(ConversationContainer.java:126)

Within the UI I get a Web Login Service – Stale Request.

When it stops working, both SPs no longer work.

Any suggestions?

Thanks, Jay

________________________________

Jason Rappaport (he/him)

Identity and Access Management Analyst

Office of Information Technology

Email:  jasonrap at princeton.edu <mailto:jasonrap at princeton.edu> <mailto:jasonrap at princeton.edu <mailto:jasonrap at princeton.edu>>

Office:  609-258-8464

--

For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg <https://wiki.shibboleth.net/confluence/x/coFAAg>

To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>

-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg <https://wiki.shibboleth.net/confluence/x/coFAAg>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg <https://wiki.shibboleth.net/confluence/x/coFAAg>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>