TGT Expiring not requiring log-in

[Ben]

Hello,

I am trying to set up a service to require a specific application to log out after x (currently set to 5 as a test) seconds. I see the logs saying its logging out, but when I click around the website, refresh, or make user changes, I'm still logged in and it isn't requiring me to log in.

 I have the following config services. I don't think anything is interfering with the other.

    "proxyPolicy":
    {
      "@class": "org.apereo.cas.services.RegexMatchingRegisteredServiceProxyPolicy",
      "pattern": "^https?://.*"
    },
    "attributeReleasePolicy" : {
      "@class": "org.apereo.cas.services.ReturnAllAttributeReleasePolicy"
    },
    "accessStrategy" : {
      "@class" : "org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy",
      "enabled" : true
    },
    "ticketGrantingTicketExpirationPolicy":
    {
        "@class": "org.apereo.cas.services.DefaultRegisteredServiceTicketGrantingTicketExpirationPolicy",
        "maxTimeToLiveInSeconds":5
    }

Any help would be appreciated.

Looking at https://groups.google.com/a/apereo.org/g/cas-user/c/zvo3KBi46IU/m/fF-prmwDAQAJ, I tried disabling SLO too and that didn't work.

The logs show the following indicating that I'm logged out (but not).

2024-11-04 06:58:37 2024-11-04 11:58:37,840 INFO [org.apereo.inspektr.audit.AuditTrailManager] - <Audit trail record BEGIN
2024-11-04 06:58:37 =============================================================
2024-11-04 06:58:37 WHEN: 2024-11-04T11:58:37.840180900
2024-11-04 06:58:37 WHO: te...@example.com
2024-11-04 06:58:37 WHAT: TGT-1-****************n9NDYZKzU4-localhost
2024-11-04 06:58:37 ACTION: LOGOUT_SUCCESS
2024-11-04 06:58:37 CLIENT_IP: unknown
2024-11-04 06:58:37 SERVER_IP: unknown
2024-11-04 06:58:37 =============================================================
2024-11-04 06:58:37
2024-11-04 06:58:37 >
2024-11-04 06:58:37 2024-11-04 11:58:37,840 DEBUG [org.apereo.cas.ticket.registry.DefaultTicketRegistryCleaner] - <Cleaning up expired ticket [TGT-1-****************n9NDYZKzU4-localhost]>
2024-11-04 06:58:37 2024-11-04 11:58:37,840 DEBUG [org.apereo.cas.ticket.registry.AbstractTicketRegistry] - <Removing children of ticket [TGT-1-****************n9NDYZKzU4-localhost] from the registry.>
2024-11-04 06:58:37 2024-11-04 11:58:37,840 DEBUG [org.apereo.cas.ticket.registry.AbstractMapBasedTicketRegistry] - <Ticket [ST-1-****************QCJKPHUzJY-localhost] could not be found>
2024-11-04 06:58:37 2024-11-04 11:58:37,843 DEBUG [org.apereo.cas.ticket.registry.AbstractTicketRegistry] - <Removing ticket [TGT-1-****************n9NDYZKzU4-localhost] from the registry.>
2024-11-04 06:58:37 2024-11-04 11:58:37,844 INFO [org.apereo.cas.ticket.registry.DefaultTicketRegistryCleaner] - <[2] expired tickets removed.>
2024-11-04 06:59:17 2024-11-04 11:59:17,857 INFO [org.apereo.cas.throttle.AbstractInMemoryThrottledSubmissionHandlerInterceptorAdapter] - <Beginning audit cleanup...>

[Dmitriy Kopylenko]

The client app could be keeping their own local session. 

D. 

--
- Website: https://apereo.github.io/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 visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/1ccf3963-2db1-4036-86d6-ed8ec87f9e38n%40apereo.org.

[Ben]

I thought CAS superseded the client apps session? Is there a way to overwrite the local session?

[Dmitriy Kopylenko]

This could be helpful 

https://apereo.github.io/cas/7.0.x/installation/Logout-Single-Signout.html

D. 

[Ben]

I'm sure I'm misunderstanding it, but in my properties, I added the following to try to resolve the issue:

cas.view.default-redirect-url= ${cas.server.name}/cas

cas.logout.follow-service-redirects=true

cas.slo.asynchronous=true

My application is built in angular 2. Shouldn't it auto log out if the TGC is expired similar to ng-idle?

Ben Chang

[Ben]

Additionally, Ive set the logoutURL to my applications log out and its also not working.

[Ray Bon]

Ben,

Cas session (TGT / TGC) and your application session are independent.

Logout requests are only sent by cas when cas/logout is visited.

Your application (cas client) must be able to receive and process the logout request.

These loggers may help:

<!-- INFO Performing logout operations for [TGT-...]

[number] logout requests were processed

DEBUG ST, principal and URL -->

<Logger name="org.apereo.cas.logout.DefaultLogoutManager" level="info">

<Filters>

<ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="NEUTRAL" />

<RegexFilter regex="Captured logout request.*" onMismatch="DENY" />

</Filters>

</Logger>

<!-- DEBUG Logout request will be sent to but does not print anything when login was through SAML 1.1 -->

<Logger name="org.apereo.cas.logout.DefaultSingleLogoutServiceLogoutUrlBuilder" level="warn" />

<!-- DEBUG preparing, processing and logout with URL and ST -->

<Logger name="org.apereo.cas.logout.slo" level="warn" />

<!-- DEBUG SAML logout payload -->

<Logger name="org.apereo.cas.logout.SamlCompliantLogoutMessageCreator" level="warn" />

Ray

P.S. default-redirect is where cas will redirect when no service is provided at login

[Ben]

But from the https://apereo.github.io/cas/7.0.x/installation/Logout-Single-Signout.html#casslodisabledPropertyConfig page, it appears under the "Service Endpoint for Logout Requests" section, if I set my logoutURL field to my application's log out, it CAS can get the app to logout? Am I misunderstanding this?

Thanks,

[Ray Bon]

Ben,

logoutURL is where cas will send the logout request (BACK_CHANNEL) or redirect (FRONT_CHANNEL). Default is the url used during login.

With back channel logout, cas sends a logout request to logoutURL. Your cas client has to process the request and perform the logout action. Check you cas client's documentation, and perhaps your configuration.

Cas does not end your application's session; it can only suggest to your application to  perform its own logout. 

I suggest removing all of the logout config you have add to cas (except for logoutURL only if it is not the same as the login url). Cas will perform a back channel logout by default. Then see how your application responds to the logout request.

Ray

P.S. I think the shortest time for TGT time to live is 2m, so you may have to wait this long or visit cas/logout

[Ben]

Thanks! 

So the main thing is that I’m trying to use it for a specific application so I created a service to target the specific application (assuming I have the serviceID right). 

When I do the non TGT logout via clicking the links on the application to the back-end, it works fine so my application knows how to handle the request. 

I tried changing the timeout to 125, but that didn't seem to do anything. Also, when you mean cas/logout, do you mean the back end call?

I do see that when the timeout "occurs", it cant seem to find the server and client ips. Is that maybe a cause? When I log in, it has client and server IPs

2024-11-07 09:41:04 =============================================================
2024-11-07 09:41:04 WHEN: 2024-11-07T14:41:04.250032600
2024-11-07 09:41:04 WHO: omitted
2024-11-07 09:41:04 WHAT: omitted
2024-11-07 09:41:04 ACTION: LOGOUT_SUCCESS
2024-11-07 09:41:04 CLIENT_IP: unknown
2024-11-07 09:41:04 SERVER_IP: unknown
2024-11-07 09:41:04 =============================================================

 

Ben

[Ray Bon]

Ben,

cas/logout is an endpoint in cas. It tells cas to destroy its own session and send logout requests to all services associated with the TGT (depending on global and service config). see https://apereo.github.io/cas/7.1.x/protocol/CAS-Protocol-Specification.html

If the service id was not right, cas would tell you.

When a TGT expires, nothing noticeable will happen; no logs, no single logout. Depending on how tickets are stored, a cleaner may remove the TGT (there may be logs, but no single logout).

Cas logout (single logout) only happens when the user initiates it, by visiting cas/logout or logging out of an application that redirects to cas/logout. 

The payload that is sent to the application/service can be seen on the page Dmitriy linked. This payload is what your cas client needs to process (you do not want random logout requests being sent to your app). Once processed, your cas client can trigger a logout in your application.

Cas outbound calls and back channel inbound calls are all https (so be sure your certs are correct).

What cas client are you using?

Ray

[Ben Chang]

I’m using Java CAs. 

Ok, so my application redirects to cas for login and logout. Looking at the SSO page, seems like I don’t need to specify the LogoutURL and LogoutType since the default should work? 

So if I make a service with ticketGrantingTkcletExpirationPolicy and a maxTimeToLiveInSeconds of 125, what’s the purpose of it if it doesn’t force logout or do anything? 

Is there a service to force logout after a certain time? I was under the impression if the tgt ticket expires and is removed, then you would have to relogin. 

Ben

Sent from my iPhone

On Nov 7, 2024, at 1:46 PM, Ray Bon <rb...@uvic.ca> wrote:



[Ben Chang]

Right, and I was using the per service example/code to try to end the sso session. 

It seems to work by my logs (where it has a logout_success log albeit with unknown client_ip and server_ip), but it isn’t forcing the user to sign back in even after clicking other endpoints. I only set it to 5 (and 125) like the example in the tab to see if it worked, but it isn’t. That’s been the crux of my issue. I’m sure I’m missing  or misunderstanding something but I’m not sure what. 

I’m running the environment locally so I have my serviceID to be “localhost” so that should be correct. I’m able to sign in and sign out, just not force out after the time expires/logout_sucess log . 

Ben

Sent from my iPhone

On Nov 7, 2024, at 3:13 PM, Ray Bon <rb...@uvic.ca> wrote:



Ben,

TGT expiration policies are for life of cas session (how long does SSO last). see under per service tab https://apereo.github.io/cas/7.1.x/ticketing/Configuring-Ticket-Expiration-Policy-TGT.html

java cas client defaults should be fine.

Cas does not manage application sessions (one cas can support multiple applications). Cas is only about authentication (and a few other related items). Set your application session to the length you want. Think about the user experience if someone was in the middle of a task and some other system logged them out.

Ray

[Ray Bon]

Ben,

By default cas sends a back channel logout request to your application. This has to be on https. If you are using localhost (cas and your app running locally), then you must be using a self signed cert. see https://apereo.github.io/cas/7.1.x/installation/Troubleshooting-Guide.html#ssl--certificates

Both cas and your app need to know about the certificate (you can add it to the java trust store). Though cas must be validating service tickets (there will be an audit log)???

There is no logout when the TGT expires.

see https://apereo.github.io/cas/7.1.x/protocol/CAS-Protocol.html#webflow-diagram

Ray

[Ray Bon]

Ben,

TGT expiration policies are for life of cas session (how long does SSO last). see under per service tab https://apereo.github.io/cas/7.1.x/ticketing/Configuring-Ticket-Expiration-Policy-TGT.html

java cas client defaults should be fine.

Cas does not manage application sessions (one cas can support multiple applications). Cas is only about authentication (and a few other related items). Set your application session to the length you want. Think about the user experience if someone was in the middle of a task and some other system logged them out.

Ray

On Thu, 2024-11-07 at 14:48 -0500, Ben Chang wrote:

[Ben]

(Not sure why the order of messages got mixed up).

There isnt any certification errors or anything and I am able to log in and log out via the application. I'm just trying to force a specific application to log out once the maxTimeToLive is met. From the per service tab you mentioned earlier, once the TGT expires, shouldn't the user be unable to change settings and unable access authenticated pages since the TGT is expired/removed? My logs show that it gets removed (via the logout_success log), but nothing happens on my applications ends. 

That is the crux of what I'm trying to figure out. It seems like from our conversation, the logoutURL is the default and doesn't need to be in the service file so that if I copy the 'per service' example into my service file, it should logout after the specified time, but isnt. From looking at that flow chart, would I instead need to set the Service Ticket instead to force a log out? I've tried all the expiration policies to essentially the same result.

My service file is the following:

{

    "@class": "org.apereo.cas.services.CasRegisteredService",

    "serviceId": "(^https.*)",

    "name": "Test",

    "id": 1,

    "description": "Test Logout for application.",

    "evaluationOrder": 1,

    "proxyPolicy":

    {

      "@class": "org.apereo.cas.services.RegexMatchingRegisteredServiceProxyPolicy",

      "pattern": "^https?://.*"

    },

    "attributeReleasePolicy" : {

      "@class": "org.apereo.cas.services.ReturnAllAttributeReleasePolicy"

    },

    "accessStrategy" : {

      "@class" : "org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy",

      "enabled" : true

    },

    "ticketGrantingTicketExpirationPolicy":

    {

        "@class": "org.apereo.cas.services.DefaultRegisteredServiceTicketGrantingTicketExpirationPolicy",

        "maxTimeToLiveInSeconds":125

    },

    "proxyGrantingTicketExpirationPolicy": {

      "@class": "org.apereo.cas.services.DefaultRegisteredServiceProxyGrantingTicketExpirationPolicy",

      "maxTimeToLiveInSeconds": 10

     },

    "serviceTicketExpirationPolicy": {

      "@class": "org.apereo.cas.services.DefaultRegisteredServiceServiceTicketExpirationPolicy",

      "numberOfUses": 1,

      "timeToLive": 15

    },

    "proxyTicketExpirationPolicy": {

     "@class": "org.apereo.cas.services.DefaultRegisteredServiceProxyTicketExpirationPolicy",

     "numberOfUses": 1,

     "timeToLive": 10

    }

  }

Thanks

Ben

[Ray Bon]

Ben,

You are misunderstanding the nature of sessions. Cas session, TGT, is completely separate from your application session. The end of one of these sessions has no effect on the other. 

If you want your application session to be limited to 2m or 2h, set that in your application.

If you want the user to reauthenticate at the end of your application's session, your application should send renew=true parameter in the login request (see cas protocol link).

Those steps will simplify your cas configuration (i.e., just use all cas defaults).

Certificate errors are handled by the jvm; they fail silently.

Do you have ST validation success messages in the cas audit log?

Ray

[Ben Chang]

So from my reading of tgts and the flow diagram you posted earlier, don’t tgts grant service tickets (with help of the session cookie) which are only valid during the maxtimetolive? If the tgt is no longer valid, wouldn’t the key change and therefore the session end since you can’t request resources anymore? I’m trying to understand the purpose of TGTs since I thought they essentially provided the keys to a session. 

If I configure a service for single logout, shouldn’t it logout once the tgt expires since the cas server sends a logout message to all the applications?

Sorry for all the questions, I’m new to CAS and trying to grasp it. The documentation is appearing to not be as straightforward as expected. 

Thanks

Ben 

Sent from my iPhone

[Ben]

Additionally, looking at the documentation, it sounds like SLO would be able to log out of the application session as well as its own session when TGT expires. This may be going in a loop, but why doesn't the service I posted work if SSO is configured? Is it maybe because my serviceId is wrong or my SLO configured wrong?

[Ray Bon]

Ben,

When the TGT expires, nothing happens.

A service ticket (ST) is relatively short lived (default is 10s). It is sent to the service, which then verifies (validates) it with the cas server. The validation is through a back channel call, not through the browser.

Your application will only contact cas once, to authenticate the user. After that, session management is entirely within the control of your application.

Ticket granting cookie (TGC) is the cas session cookie. It has nothing to do with your application. It is only sent to the cas server; that is, only when an application wants a user to authenticate or logout (single logout).

To initiate SLO, a user must visit cas/logout. The user can choose to visit that link, but usually the user clicks logout in an application and the application redirects the user to cas/logout. It is important to understand that the redirect to cas/logout should be user initiated; never some automated process in your application.

If this is your first go round with cas, and you only have one application, then ignore SLO, it does not apply.

Ray

On Mon, 2024-11-11 at 06:23 -0800, Ben wrote:

Additionally, looking at the documentation, it sounds like SLO would be able to log out of the application session as well as its own session when TGT expires. This may be going in a loop, but why doesn't the service I posted work if SSO is configured? Is it maybe because my serviceId is wrong or my SLO configured wrong?

On Sunday, November 10, 2024 at 11:29:48 PM UTC-5 Ben Chang wrote:

So from my reading of tgts and the flow diagram you posted earlier, don’t tgts grant service tickets (with help of the session cookie) which are only valid during the maxtimetolive? If the tgt is no longer valid, wouldn’t the key change and therefore the session end since you can’t request resources anymore? I’m trying to understand the purpose of TGTs since I thought they essentially provided the keys to a session. 

If I configure a service for single logout, shouldn’t it logout once the tgt expires since the cas server sends a logout message to all the applications?

Sorry for all the questions, I’m new to CAS and trying to grasp it. The documentation is appearing to not be as straightforward as expected. 

Thanks

Ben 

Sent from my iPhone

On Nov 8, 2024, at 1:36 PM, Ray Bon <rb...@uvic.ca> wrote:



Ben,

You are misunderstanding the nature of sessions. Cas session, TGT, is completely separate from your application session. The end of one of these sessions has no effect on the other. 

If you want your application session to be limited to 2m or 2h, set that in your application.

If you want the user to reauthenticate at the end of your application's session, your application should send renew=true parameter in the login request (see cas protocol link).

Those steps will simplify your cas configuration (i.e., just use all cas defaults).

Certificate errors are handled by the jvm; they fail silently.

Do you have ST validation success messages in the cas audit log?

Ray

On Fri, 2024-11-08 at 07:28 -0800, Ben wrote:

(Not sure why the order of messages got mixed up).

There isnt any certification errors or anything and I am able to log in and log out via the application. I'm just trying to force a specific application to log out once the maxTimeToLive is met. From the per service tab you mentioned earlier, once the TGT expires, shouldn't the user be unable to change settings and unable access authenticated pages since the TGT is expired/removed? My logs show that it gets removed (via the logout_success log), but nothing happens on my applications ends. 

That is the crux of what I'm trying to figure out. It seems like from our conversation, the logoutURL is the default and doesn't need to be in the service file so that if I copy the 'per service' example into my service file, itshould logout after the specified time, but isnt. From looking at that flow chart, would I instead need to set the Service Ticket instead to force a log out? I've tried all the expiration policies to essentially the same result.