Strange re-auth problem

[spfma...@e.mail.fr]

Hi,

 

I am experiencing something strange on a 6.4.5 instance : when I try to access a service (starting from scratch with a closed browser) I get the login form and the I am granted the right to reach it.

 

In the logfiles, I can clearly see I get TGT after authentication, then a ST for the service.

 

But if I open a second tab on my browser and try to reach the service again, the login form appears again.

 

If I don't reauth, my SSO session is like invalid, I am asked to re-auth all the time, even when I try to reach another service.

 

But with other services, I can start my SSO session, access a firtst service, a second one and the same problem occurs with the third one. Or with the second one, it depends on the services.

 

Of course, none of these services is performing a logout neither I do click on such a link.

 

I'm not able to explain what's happening, so I hope someone here has a clue.

 

I see lines like this one : DEBUG [org.apereo.cas.ticket.expiration.MultiTimeUseOrTimeoutExpirationPolicy] - <Ticket usage count [1] is greater than or equal to [1]. Ticket [xxxxxxxxxxxxx] has expired>

 

Is there a link ?

 

Regards

 

 

---

FreeMail powered by mail.fr

[Ray Bon]

I assume your log in attempts are within seconds of each other and that you have only a single cas server.

Check your service definition to see if it requires a new authentication.

Check what your service is sending to cas, it may be asking for new authentication (use browser developer tools).

Check your TGT and TGC expiration policies to be sure they are still valid for subsequent logins.

By default ST can only be used once. There are logs saying what ST is being processed.

Ray

On Wed, 2022-05-11 at 17:38 +0200, spfma...@e.mail.fr wrote:

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

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/20220511153848.D49ACC0056%40smtp04.mail.de.

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@uvic.ca

I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands, and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day.

[spfma...@e.mail.fr]

Hi Ray,

 

Thanks for your answer.

 

For now, I have a single CAS server.

 

On the old production server I am trying to migrate (don't know exactly which version it is, from around 13 years ago) it's working flawlessly but I don't see anything about specific TGC and TGT configuration.

 

On the new test server, nothing special had been set so default values were used.

 

I just gave a try with those two lines but nothing has changed :

cas.ticket.tgt.primary.time-to-kill-in-seconds=7200
cas.ticket.tgt.primary.max-time-to-live-in-seconds=28800

 

 

I am still not able to clearly understand what all those parameters mean, but here is what the current ticket policies look like (/cas/actuator/ticketExpirationPolicies) :

{
  "org.apereo.cas.ticket.TransientSessionTicket": "{\"@class\":\"org.apereo.cas.ticket.expiration.MultiTimeUseOrTimeoutExpirationPolicy$TransientSessionTicketExpirationPolicy\",\"numberOfUses\":1,\"timeToLive\":300,\"name\":\"TransientSessionTicketExpirationPolicy-798e92e9-c25f-442e-ab4b-0bff4589eac1\"}",
  "org.apereo.cas.ticket.proxy.ProxyTicket": "{\"@class\":\"org.apereo.cas.ticket.expiration.MultiTimeUseOrTimeoutExpirationPolicy$ProxyTicketExpirationPolicy\",\"numberOfUses\":1,\"timeToLive\":10,\"name\":\"ProxyTicketExpirationPolicy-62b1ad7b-0820-4982-aa4e-72d727f98879\"}",
  "org.apereo.cas.ticket.proxy.ProxyGrantingTicket": "{\"@class\":\"org.apereo.cas.ticket.expiration.TicketGrantingTicketExpirationPolicy\",\"timeToLive\":28800,\"timeToIdle\":7200,\"name\":\"TicketGrantingTicketExpirationPolicy-f76fe582-cbdd-4349-b257-c86db4e5083d\"}",
  "org.apereo.cas.ticket.ServiceTicket": "{\"@class\":\"org.apereo.cas.ticket.expiration.MultiTimeUseOrTimeoutExpirationPolicy$ServiceTicketExpirationPolicy\",\"numberOfUses\":1,\"timeToLive\":10,\"name\":\"ServiceTicketExpirationPolicy-3cac0624-d94b-4b70-808f-1d314c0e819c\"}",
  "org.apereo.cas.ticket.TicketGrantingTicket": "{\"@class\":\"org.apereo.cas.ticket.expiration.TicketGrantingTicketExpirationPolicy\",\"timeToLive\":28800,\"timeToIdle\":7200,\"name\":\"TicketGrantingTicketExpirationPolicy-00e0763f-6397-42c9-bcf5-fa35ea203806\"}",
  "org.apereo.cas.ticket.artifact.SamlArtifactTicket": "{\"@class\":\"org.apereo.cas.ticket.query.SamlAttributeQueryTicketExpirationPolicy\",\"timeToLive\":10,\"name\":\"SamlAttributeQueryTicketExpirationPolicy-cbdb5a57-279e-4313-b02d-5f5517f4db34\"}"
}

You pointed something : TGC, I never had a look at policies about it. Should investigate and find how it is configured.

 

I have ported the very complex service configuration we always had, which is :

"@class" : "org.apereo.cas.services.RegexRegisteredService",
"attributeReleasePolicy" : {
"@class" : "org.apereo.cas.services.ReturnAllowedAttributeReleasePolicy",
"allowedAttributes" : [ "java.util.ArrayList", [ "sn", "givenName", "displayName", "mail", "eduPersonPrimaryAffiliation", "departmentNumber" ] ]
},
"serviceId" : "^https?://([A-Za-z0-9_-]+\\.)*OUR\\.DOMAIN.*",
"name" : "ALL",
"description" : "Allows HTTP and HTTP(S) protocols on OUR.DOMAIN",
"evaluationOrder" : "1003",
"allowedToProxy" : "False",
"enabled" : "True",
"ssoEnabled" : "True",
"anonymousAccess" : "False",
"ignoreAttributes" : "False",
"id" : "1003"
}

 

I will now try to debug communication between clients and servers

 

I have captured logs but there is so much informations that I don't want to flood the post if I was not looking at the right place.

 

Regards

[spfma...@e.mail.fr]

After futher investigations, it appears that there was a problem between the legacy webservers providing some services and the new CAS server : they lack the CA certificates required by the latest certificates ! So ST validation never succeded ! With the right configuration adjustments it runs better.

 

But there are still some faulty services, and I am wondering if our URLs could be the problem : because of some lazyness, some services are configured with a CAS url pointing on the root.

So the CAS server will get urls like "/login?service=https%3A%2F%2Fsomething.our.domain" while the prefix in "cas.properties" is set on "/cas".

By some rewriting tweaks, they are translated to "/cas/login?service=https%3A%2F%2Fsomething.our.domain".

 

Could this be one of the culpirts, as the request reaching the CAS server with the "full" URLs seem to be sucessful, but rewritten ones are not always ok.

It seems the legacy CAS is fine with both, maybe the new versions are more strict ?

 

And it seems the SSO session is no more valid when one one this "reauth" condition occurs. Is there some forced logout under some conditions ?

 

Regards

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/20220512071107.E184AC00BF%40smtp04.mail.de.

[Ray Bon]

The ST are validated on a back channel request. Something like /cas/serviceValidate, but will vary with the cas protocol used. Check your rewrite rules (and web server access logs) to see if they handle all cas bound urls.

See https://apereo.github.io/cas/6.4.x/protocol/CAS-Protocol.html

Ray

[Ray Bon]

TGC settings are here under the optional tab https://apereo.github.io/cas/6.4.x/authentication/Configuring-SSO.html#configuration

Ray