[cas-user] CAS Management 6.5.2
Hi All, I'm trying to set up a fresh 6.5.2 install and am having trouble getting the cas-management to work. I can login OK if I go to https:///cas/login. But if I try to go to https:///cas-management I get redirected to https://localhost:8443/cas-management/ Theoretically, this should be controlled by the "mgmt.server-name" property in management.properties but changing it doesn't seem to have any affect. In the /etc/cas/config/management.properties I have the following configured: cas.server.name=https:// cas.server.prefix=https:///cas mgmt.admin-roles[0]=ROLE_ADMIN mgmt.user-properties-file=file:/etc/cas/config/users.properties # Update this URL to point at server running this management app mgmt.server-name=https:// server.context-path=/cas-management server.port=443 logging.config=file:/etc/cas/config/log4j2-management.xml Would anyone have any clue what's going on? Thanks a lot, Trev -- - 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+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/744d1b02-a0df-4105-b1c0-a051c9379c50n%40apereo.org.
[cas-user] Apereo Stack-Hack: You & Your Project!
Hello Apereo Community, Apereo's diverse portfolio includes innovative edtech solutions, supporting multiple academic and administrative initiatives, and developed by talented and committed communities. Many campuses have already adopted one or more of our tools to enable teaching and learning and support institutional infrastructure. Let's show the world what the Apereo community can really deliver. Let's build "The Apereo Stack." a complete reference implementation of every Apereo project integrated to showcase both the technologies and communities available with Apereo. The ultimate goal is to create a "complete edtech software stack" including every Apereo project, a model campuses can realize through Apereo software and with Apereo communities. Day two of Open Apereo--the Stack-Hack--is an open invitation and an open forum for Apereo projects and communities to self-organize and develop a complete edtech solution for colleges and universities. The day will run as a hackathon, providing a unique opportunity for Apereo people and projects to collaborate and co-create. Please join us on June 15th online. Registration for Open Apereo & the Stack-Hack is now open. See you soon, Patrick -- | | ||| || | | ||| | || | | || | | | | | | Patrick Masson Interim General Manager Apereo Foundation 9450 SW Gemini Dr PMB 98572 Beaverton, OR 97008-7105 Mobile: +1 (970) 4-MASSON Website: www.apereo.org -- - 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+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/5caf40bac8d0f16a317f52274212a4d6682e1785.camel%40apereo.org.
Re: [cas-user] Strange re-auth problem
TGC settings are here under the optional tab
https://apereo.github.io/cas/6.4.x/authentication/Configuring-SSO.html#configuration
Ray
On Thu, 2022-05-12 at 09:11 +0200, spfma.t...@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.
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
Le 11-May-2022 18:03:12 +0200, r...@uvic.ca a écrit:
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.t...@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.
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
Re: [cas-user] Strange re-auth problem
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
On Thu, 2022-05-12 at 16:46 +0200, spfma.t...@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.
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
Le 12-May-2022 09:11:14 +0200, spfma.t...@e.mail.fr a écrit:
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
[cas-user] TGT problem with mfa-trusted
Hello, I have a problem with the MFA Gauth and the trusted device. We are currently in 6.5.4 (I also tested in 6.3.7 and 6.5.3), the mfa-gauth works fine, but when I activate the trusted device (stored in mysql or mongodb database) we have a strange behavior: -at the first connection on a clean browser, we go through the mfa and the trusted device registration (bypass because we set the parameter to assign the device-name automatically), once this is done we have no problem, the TGT ticket is well created, the mfatrusted too, and on the cookies side, we have everything (JSESSIONID, MFATRUSTED, TGC) -if we disconnect from CAS on this same browser, the TGC and JSESSIONID cookies are destroyed, as well as the TGT on the CAS side (normal), but the MFATRUSTED remains (expected behavior, so far so good) -if we connect again, it is there that it spoils, we do not need to put the MFA (normal because the MFATRUSTED cookie is always present), on the other hand once the connection carried out, we do not manage any more to have the TGC cookie (of the TGT which is created well on the CAS side) and thus the SSO does not function any more, the cause seems to come from the MFATRUSTED, as long as this one is present, impossible to re-obtain the TGC cookie. On the logs side during the connection, here is the Warn that we can observe: WARN [org.apereo.cas.gauth.web.flow.GoogleAuthenticatorValidateSelectedRegistrationAction] - if we activate the debug mode of the webflow logs, this is what we get: ERROR, text = 'Unable to accept this authentication request. The selected device or given credentials is invalid.' Have you ever seen this malfunctioning? I haven't found any info about this problem on the CAS google group or in the doc, the mfa and trusted device work in itself, but it's really the TGC cookie and thus the SSO that is the problem, behavior that doesn't happen outside of MFA Trusted. the last version where I can confirm that we did not have this problem is 6.0.5.1 (our old production version recently updated). here are the configuration parameters in cas.properties: cas.tgc.crypto.encryption.key=(replaced) cas.tgc.crypto.signing.key=(replaced) cas.webflow.crypto.signing.key=(replaced) cas.webflow.crypto.encryption.key=(replaced) cas.authn.mfa.trusted.core.device-registration-enabled=true cas.authn.mfa.trusted.core.auto-assign-device-name=true cas.authn.mfa.trusted.crypto.encryption.key=(replaced) cas.authn.mfa.trusted.crypto.signing.key=(replaced) cas.authn.mfa.trusted.device-fingerprint.cookie.crypto.encryption.key=(replaced) cas.authn.mfa.trusted.device-fingerprint.cookie.crypto.signing.key=(replaced) cas.authn.mfa.gauth.core.issuer= cas.authn.mfa.gauth.core.label= cas.authn.mfa.gauth.crypto.encryption.key=(replaced) cas.authn.mfa.gauth.crypto.signing.key=(replaced) cas.ticket.st.time-to-kill-in-seconds=30 cas.ticket.tgt.primary.max-time-to-live-in-seconds=86400 cas.ticket.tgt.primary.time-to-kill-in-seconds=21600 cas.ticket.registry.hazelcast.cluster.core.instance-name= cas.ticket.registry.hazelcast.cluster.network.members= cas.ticket.registry.hazelcast.cluster.network.port-auto-increment=true cas.ticket.registry.hazelcast.cluster.core.timeout=60 cas.ticket.registry.hazelcast.crypto.signing.key=(replaced) cas.ticket.registry.hazelcast.crypto.encryption.key=(replaced) cas.ticket.registry.hazelcast.crypto.enabled=true cas.ticket.registry.hazelcast.core.enable-compression=true Thanks in advance -- - 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+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/c667e692-0637-4366-a87a-62d4635f12b3n%40apereo.org.
Re: [cas-user] Strange re-auth problem
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
Le 12-May-2022 09:11:14 +0200, spfma.t...@e.mail.fr a crit:
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
Le 11-May-2022 18:03:12 +0200, r...@uvic.ca a crit:
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
Re: [cas-user] Strange re-auth problem
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
Le 11-May-2022 18:03:12 +0200, r...@uvic.ca a crit:
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.t...@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.
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
