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

Fri Jul 9 20:43:51 UTC 2021

For the record, we discovered the issue.  For these IDPs, we put them behind an AWS application load balancer; previously we used a network load balancer.  

When both hosts were up, I would get the stale request error message.  
If I brought down either host and the ALB removed it, the service would work.  

We enabled stickiness, set it to 5 minutes, turned on both IDPs and it works!

That being said, we will probably switch back to a NLB as on a ALB one must manage a certificate within AWS and on the backend hosts for SSL...and that is a bit of a pain as it crosses multiple business units and has the potential to create a negative situation when a service owner updates the backend cert but forgets that someone else manages AWS and has to update the cert that AWS has associated with the ALB.  

In any case, enabling stickiness on the ALB fixed it.  

Thanks, Jay 

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

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

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>

-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6666 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20210709/292a4c22/attachment.p7s>