Another Stale Request Post

Fri Nov 18 15:54:17 UTC 2022

Thanks, Nate. Any info is helpful.

So I'm thinking of testing the samesite filter but I have a question (not
necessarily for you Nate, just anyone who can/will answer). The code to be
included in web.xml, which is on
https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/1183416353/IdP+SameSite+Filter+Implementation,
already exists in our web.xml; so we're set there. However, the code on
that page that should be in global-system.xml is not there on our system.
This is probably a dumb question, but where in global-system.xml should it
be included? I'm thinking between <import
resource="classpath:/net/shibboleth/idp/conf/global-system.xml" /> and
</beans>?

And then it's just a matter of setting the following in idp.properties,
correct?

idp.cookie.sameSite = None
idp.cookie.sameSiteCondition = shibboleth.Conditions.TRUE

Thanks,
Jason

On Fri, Nov 11, 2022 at 3:40 PM Nate Klingenstein <ndk at sudonym.me> wrote:

> Jason,
>
> SameSite issues would be general to the flows writ large, but if this is
> the only SP that uses the CAS or Duo flows and they involve different user
> routing, it could manifest as something that would affect only a single SP.
>
> Assuming the flows are right -- and I don't know these flows well, which
> is why I didn't respond -- it's a cookie issue or a stickiness/server side
> state issue.  The former is more likely and SameSite can be the culprit.  I
> would definitely start the investigation there.
>
> Good luck,
> Nate
>
> On Fri, Nov 11, 2022 at 1:25 PM Jason Rotunno via users <
> users at shibboleth.net> wrote:
>
>> I should have added that I looked at posts by others who have had similar
>> issues and for them it seems to have been SameSite. I'll need to read up on
>> that but based on the little I know so far, I wouldn't think it would
>> affect only a single SP, would it?
>>
>> Jason
>>
>>
>> On Fri, Nov 11, 2022 at 11:39 AM Jason Rotunno <jrotunno at swarthmore.edu>
>> wrote:
>>
>>> So we have a service provider that uses CAS to authenticate against our
>>> Shib 4 instance. Apparently, it stopped working sometime over the summer
>>> but the users only just now got around to reporting it to us:
>>>
>>>    1. Users browse to the SP, click the login link, and are redirected
>>>    to our IdP.
>>>    2. They perform password authentication, are redirected to Duo, and
>>>    authenticate via a push
>>>    3. They're then redirected back to Shib. At this point the stale
>>>    request error appears.
>>>
>>> The logs show what I'm sure many of us have seen before:
>>>
>>> 2022-11-11 10:54:10,956 - ERROR
>>> [net.shibboleth.idp.authn.ExternalAuthenticationException:91] -
>>> [104.16.99.52] -
>>> net.shibboleth.idp.authn.ExternalAuthenticationException: Error
>>> retrieving flow conversation
>>> at
>>> net.shibboleth.idp.authn.ExternalAuthentication.getProfileRequestContext(ExternalAuthentication.java:227)
>>> Caused by:
>>> org.springframework.webflow.execution.repository.NoSuchFlowExecutionException:
>>> No flow execution could be found with key 'e2s2' -- 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 '2' -- perhaps this conversation has
>>> ended?
>>> at
>>> org.springframework.webflow.conversation.impl.ConversationContainer.getConversation(ConversationContainer.java:126)
>>>
>>>
>>> I turned up logging for spring and noticed this:
>>>
>>> 2022-11-11 11:02:22,342 - DEBUG
>>> [org.springframework.web.servlet.DispatcherServlet:119] - [104.16.99.52] - *GET
>>> "/idp/profile/Authn/Duo/2FA/duo-callback?state=<something>&code=<other>",
>>> parameters={masked}*
>>> 2022-11-11 11:02:22,342 - DEBUG
>>> [org.springframework.webflow.mvc.servlet.FlowHandlerMapping:114] -
>>> [104.16.99.52] - *No flow mapping found for request with URI
>>> '/idp/profile/Authn/Duo/2FA/duo-callback'*
>>> 2022-11-11 11:02:22,342 - DEBUG
>>> [org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping:522]
>>> - [104.16.99.52] - Mapped to
>>> net.shibboleth.idp.plugin.authn.duo.impl.DuoOIDCAuthnController#authorizationCallback(HttpServletRequest,
>>> HttpServletResponse)
>>> 2022-11-11 11:02:22,342 - DEBUG
>>> [org.springframework.webflow.execution.repository.impl.DefaultFlowExecutionRepository:106]
>>> - [104.16.99.52] - Getting flow execution with key 'e5s3'
>>> 2022-11-11 11:02:22,342 - ERROR
>>> [net.shibboleth.idp.authn.ExternalAuthenticationException:91] -
>>> [104.16.99.52] -
>>> 2022-11-11 11:02:22,342 - DEBUG
>>> [org.springframework.web.servlet.DispatcherServlet:1349] - [104.16.99.52] -
>>> Using resolved error view: ModelAndView [view="error";
>>> model={exception=net.shibboleth.idp.authn.ExternalAuthenticationException:
>>> Error retrieving flow conversation,
>>> request=org.apache.catalina.connector.RequestFacade at 1328262b,
>>> encoder=class net.shibboleth.utilities.java.support.codec.HTMLEncoder,
>>> springContext=Root WebApplicationContext, started on Wed Oct 26 14:18:57
>>> EDT 2022, response=org.apache.catalina.connector.ResponseFacade at 35a01e83
>>> }]
>>> 2022-11-11 11:02:22,342 - DEBUG
>>> [org.springframework.web.servlet.DispatcherServlet:1131] - [104.16.99.52] -
>>> Completed 200 OK
>>>
>>>
>>> This happens during every login attempt, in Firefox and Chrome, and on
>>> Windows and Linux. I'm at a loss so I'm hoping someone can provide some
>>> help.
>>>
>>> Thanks,
>>> Jason
>>>
>>> --
>>>
>>> Jason Rotunno
>>> System & Security Administrator
>>> Swarthmore College
>>> 500 College Ave
>>> Swarthmore, PA 19081
>>> 610.328.8505
>>>
>>> *VERIFY before you click!!*
>>>   - Attackers make their emails look like they come from someone they don't.
>>>   - Attackers make links look like they go to websites they don't.
>>>   - Attackers disguise malware as receipts, invoices, faxes, etc.
>>>
>>> Forward suspicious emails to phishing at swarthmore.edu.
>>>
>>>
>>
>> --
>>
>> Jason Rotunno
>> System & Security Administrator
>> Swarthmore College
>> 500 College Ave
>> Swarthmore, PA 19081
>> 610.328.8505
>>
>> *VERIFY before you click!!*
>>   - Attackers make their emails look like they come from someone they don't.
>>   - Attackers make links look like they go to websites they don't.
>>   - Attackers disguise malware as receipts, invoices, faxes, etc.
>>
>> Forward suspicious emails to phishing at swarthmore.edu.
>>
>> --
>> For Consortium Member technical support, see
>> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>

-- 

Jason Rotunno
System & Security Administrator
Swarthmore College
500 College Ave
Swarthmore, PA 19081
610.328.8505

*VERIFY before you click!!*
  - Attackers make their emails look like they come from someone they don't.
  - Attackers make links look like they go to websites they don't.
  - Attackers disguise malware as receipts, invoices, faxes, etc.

Forward suspicious emails to phishing at swarthmore.edu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20221118/59e93936/attachment.htm>