I've a strange problem with with my installation of CAS.
Recently we activated the RememberMe functionality with a 3-Month validity of the ticket on RememberMe.
When the session of my client application expires I got sent back to CAS at
https://urlOfmyCas/login?service=urlOfClient
Even though the CASTGC cookie is there and valid CAS is showing me again the login page.
If I invoke the URL above without service parameter I get redirected to the "Login-Success" page, so CAS knows that I'm logged in.
I would expect CAS to check the cookie log me in and send me back to my client application unless i send the renew parameter.
Did I mess up something in my CAS installation or is this an expected behaviour
Today finally it seems like I found the answer.
CAS is creating a long-term-ticket with validity 3 months (no matter what you specify as expiration timeout in your ticketExpirationPolicies.xml). The value specified in the documentation for rememberMeExpirationPolicy is for the ticketCleaner only. So even if the cookie is still there the cleaner could potentially already have dismissed the TGT in the ticket registry.
If you call /login without service parameter, the system only checks if there is a TGTid in the cookie without checking the ticket registry, so thats why it shows the success-login page, which confused me a bit.
What put me into trouble is that I assumed that the expiration values used in org.jasig.cas.ticket.support.RememberMeDelegatingExpirationPolicy are in SECONDS too (like it is in the default configuration), however this class needs the values as MILLISECONDS.
I should have checked that, but as I tried to set it to 3 months and the ticket has a 3 month validity (so I thought to get what I want), together with the strange behaviour mentioned in the paragraph above... My mistake in the end.
Related
I have used JWT before, but they were API that didn't need logout feature.
I need to implement logout feature for a API of an android app and SPA. When I looked it up I found that there are two ways to do it.
the easiest way is to delete the JWT Token from client side and call it a day.
The logic behind this is that since no session of any kind is maintained in server deleting the token in client side should be enough.
But it still leaves the possibility that, if the token falls in wrong hands they can still use it even after the user is no longer using the token.
Given if the app is well designed and uses HTTPS then chances of this happening is very low and can be minimized by keeping the valid time for the token short. But in my case the tokens are valid for 30 days.
the second option is to maintain a blacklist of tokens in server side
This solves the problem of the token still being usable even after user has logged out and stopped using it.
But it adds a complication of needing to run a cronjob to remove expired token form the blacklist table. Otherwise the table will eventually become ridiculously large.
It also kinda defeats the point of using JWT. Maintaining blacklist is very similar to maintaining session. We have to run an additional db query for every request. And it scales badly, as the no. of users grows the no. of token that needs to be blacklisted will also grow (this will be a bigger problem for API like mine with multiple front end apps and long validity period for the tokens).
Then I got an idea for third way.
Add jwt_secret row in user table that stores randomly generated string. Use it to sign the JWT Token then on every request use user id in the jwt payload to get the user form db(which is not an extra query, we have to do this anyway) and validate the token signature using jwt_secret of the user. When the user logs out we change the jwt_secret which makes all token out there useless.
At first I thought this was a great solution only to realize that in this setup if user logs out of one device or browser he/she gets logged out of all devices.
So is there a another option? Or a way to modify any of above approach to solve the problem. Or am I over thinking this and one of the above option should be used?
For logging out, which as you pointed out is a user initiated action, I don't think you need to do anything extra. If the user somehow did not delete his JWT, then so be it. He wouldn't be getting any extra access over to what he is already entitled.
However, your question seems to hint on the problem of how to know that a JWT is valid. Again, as you pointed out, if a JWT somehow fell into the wrong hands, then there may be no avoiding this. But, with each request you would typically be doing several types of validation against that JWT, e.g.
checking the claims of the JWT, such as the token expiry date
assuming the claims pass, then checking that user's ID against your database table to make sure the account is active, has not been suspended, etc.
My point here is that if you need to keep track on the server side that a logout has happened, you might need to persist this to a database. But, I don't think you would need this.
I'm facing a problem with my CAS server.
A user connects to an app, by using a ST. The app asks for a PGT. Until now, no problem. The user do his stuff in the app, sometimes calling casified-webservice, thus asking CAS for a PT. Sometimes the user doesn't use the webservice during, for example 2 hours (TGT/PGT default expiration time), but still use actively the app. When 3 hours later (for example) the app asks for a PT for the webservice, the PGT is expired, I'm getting PHPCAS_SERVICE_PT_FAILURE error and the user MUST be disconnected to get another valid PGT.
It's a bit awkward having to disconnect the user while the user have been active during all this time.
Is there any solution ? How to "synchronize" use of the app (the user session) and PGT expiration.
CAS 4.3 will allow you to set an expiration policy for PGTs that may be different from the normal TGT expiration policy. Also, when PGT is used the parent TGT is also updated to ensure inactivity does not kill the session.
Scenario:
1) you are implementing a website/webserver that supports SSO (SPNEGO).
2) A client connects to you and provides you a ticket which is valid, so access is granted to the client
Question - At this point, should I implement some mechanism such as a cookie that allows for the client to no longer generate tickets (Storing some value that can be cached client side and used for subsequent calls) ? How long/how many requests can I honor the same spnego token? I tried finding the answer for the second question and could not find an answer.... What is the "MAXLIFE" of a token that you can generate for a SPNEGO token?
The first question/answer clearly depends on your usecase. If you have a website with a browser, a session cookie, e.g. JSESSIONID, is the way to go. If this is some library, it has to support cookies. Thoughly, ticket generation is extremely fast.
Second question: Do not fiddle with the tickets. They cannot be reused and will throw an exception: this is a replay. Pass those tokens to SSPI/GSS-API and throw the context away when the auth is completed. As soon as the server nags you again, create a new context and send a new token.
By default, a ticket is valid for 10 hours in Active Directory but this can be changed by the admin. Use kerbtray.exe on Windows or klist on Unix to see the lifetime of your tickets.
I am integrating against a CAS server. User logs into there, gets forwarded to a script which does the CAS validation, gets the User and logs them in. This all works fine.
Part of the spec for the integration is to ensure we ping the CAS server every 60 seconds, to ensure the user does not get logged out at the 'parent' CAS server, as they are still active.
Is there something built into the CAS setup for this purpose? I've been looking through the CAS documentation and the phpCAS client to no avail. There's a renewAuthentication method but it causes the user to have to login again when called. Perhaps this is just a configuraton issue at the server side though?
There is no way for you to ping the CAS server on behalf of the user as your application should not have access to the token identifying the user's session. The default policies automatically extend the user's single sign on session every time the user requests a new service ticket from the CAS server.
However, if you do have the TGT (which you really, really, really should avoid), you can basically request a service ticket for the user, and that would extend the life of the single sign on session (though if you did this, you would not need to do it every 60 seconds, as that's rather extreme).
While load testing using loadrunner all my virtual users are getting logged off from application after 30 min. Looking in detail came to know that authentication cookie is getting expired even though we have continuous activity performed by users.
Now we are trying to update the cookie explicitly after each action to prevent expiration, but not sure how server identifies that authentication cookie is expired. The cookie has only encrypted text and no explicit title mentioning expiry time.
What information in cookie should be updated in authentication cookie to prevent it from expiring?
Cookie Information:
Cookie:
.ASPXAUTH=66DD4AB74239F00D553BA9640D3AD3F284F47DEC315FD6789AE3FB8D67D2A46A4E89EDB45845C921A7557BD6B39A12EE07188D1009D581AA7AAF6743710653AE44EEF2733CC16082C595D7AE7C73D3E7E3D44BA1BAEEFEB1BF5F98B35C5F8429670FFDD5586E03BB3138C5B78945D82702BDD7C4;
path=/; HttpOnly
Tell us how you are managing session state in your script. Generally if you are cleaning all cookies and instantiating a new session for each iteration you should not run into this. If you are attempting to maintain some sort of singular session state for the entire length of your test I could see how the server would potentially kick you out after your original session technically logged out of the system (as part of a business process).
Also, do you have explicit cookies noted in your script? If so, you may want to consider commenting these statements out as LoadRunner will manage cookies automatically. As part of your burn in consider running a singular virtual user for 30 minutes to an hour to see if you experience this on a single virtual user level. It's a lot easier to fix for a single user and then projecting to load than it is to try and figure out what is happening across dozens or hundreds of users experiencing a similar issue.
From what I can gather the Server keeps track of the expiry time of the cookies, and it's also the server that updates the expiry time, meaning you as the client have no control over this.
I assume the flow is this:
The browser or LoadRunner Script will always send the cookie and the
server then verifies it's expiry time on the server side, redirecting
you to the login page if it has expired.
I've had this happen to me, and solved it by visiting a special page on the server that "updated the client session expiry time". Perhaps you have a similar situation?