Client Principal and LOGIN-EXPIRATION-TIMESTAMP

This is what I get for making comments about ABL and 4GL .... scratch what I said .

B is the way to go here.

B will result in the ABL knowing that the C-P has expired when performing a SET-CLIENT(), regardless of the auth system.

A means that you need to add code to all your auth system (PAM) callbacks to check expiration. If you can, since you may or not be using ABL authentication systems. So you need to add belts or braces to that, which means more code, which means more points of failure, which I would submit is even more important to avoid in IdM code.

In both cases you do need code to identify expired sessions and clone the C-P in ABL, which leads me to option C, which is to log a bug with TS asking for this kind of behaviour to be built-in (since you're not the first person I've heard ask for/about this).

-- peter

You are nutsto attempt this. My advice is: don't, because it will work

in a decreasing number of casesover time.

(I am trying to be nice... )

Mike J.

validate-seal does check the login-expiration-timestamp, so I'm not

worried about sessions that actually have expired - it was the hassle

of cloning the cp I was trying to avoid.

Thanks for the feedback

Life is never easy. Writing decent software is hard.

The purpose of the expiration mechanism is so that a client-principal that has been validated can't be used forever. Your credit cards and bank cards also have expirations. The user whose identity is encapsulated by the c-p has provided some form of credentials to prove their identity (e.g. user name and password, or something else) and those have been validated as being correct. Therefore we (well really the application) believe the user is who they say they are and therefore are entitled to certain privileges.

When the c-p should expire is highly usage dependent but in most cases does not have to be terribly precise (imho, anyway). For a lot of users, a bit more than a normal workday is enough, maybe 10 or 12 hours. Most of the time a normal user will log off their system just before they leave at the end of the day every working day (or maybe less, like at lunchtime, depending on policy). In such a case, your application would destroy the client prinicipal even though it has not expired. The next day, the user would log in again and a new c-p with a new expiration would be created. In other situations shorter or longer ones would be needed.

Note that when a c-p expires, to create a new one, the user should have to prove their identity again (i.e. they must login again). You can't just save their credentials somewhere and silently reuse them under the covers to create a new c-p -- that would be a huge security problem.

Under normal circumstances, a user would log in to your application and a client principal would be created and validated (note that in 11.1 and later there are 4GL hooks that can be invoked to perform the validation in whatever arbitrary way your 4GL code wants to it, or you can use this mechanism to supplement the validation that is performed by the inbuilt ones -- user table, active directory, ldap, etc.). After the authentication, your application does whatever login processing it wants to do. Then the user uses your application in the normal way for some period. When they are finished, they log out. At that point the client-principal would be destroyed by your application, along with whatever other logout processing your application wants to do.

The timeout mechanism is meant to eventually invalidate the client-principal when things don't go the normal way.

I was looking at this not just from a 4gl app point of view, but also

from a rest-based api point of view.

I don't want to use cookies for session id, so I need to be able to

pass a token or key as part of the url or body.

However, I don't want the url to be reused by someone else a few days

later - as you say, they need to be re-authenticated

But, I also don't want the api/rest user to have to authenticate on

every request

Hence, I was looking at timeouts of x hours or even minutes, so that

if the client doesn't make a request within a certain period of time,

the session times out (good) , but if they are making a request every

minute, the session will not time out and they won't have to

reauthenticate after an arbitrary period of time.

In a nutshell, as long as they are active, I want the session to be valid.

Hence, I was looking at timeouts of x hours or even minutes, so that

if the client doesn't make a request within a certain period of time,

the session times out (good) , but if they are making a request every

minute, the session will not time out and they won't have to

reauthenticate after an arbitrary period of time.

In a nutshell, as long as they are active, I want the session to be valid.

>

This is the pertinent point. You care about the session and a user session's lifespan is NOT the same as the user's credentials are authenticated lifespan (the login-expiration-timestamp). Gus' post is spot-on about the credentials' expirations: that time is a hard stop. You must re-authenticate when the credentials expire.

The session's inactivity timeout is more of a soft limit (as per your requirement), and you should be able to roll that over as often as you choose. But once the credentials expire, the user must re-authenticate.

-- peter

consider it scratched. .. but ... why ... ?

jmls wrote:
consider it scratched. .. but ... why ... ?

It goes to what Gus said and my followup comment: the lifecycle of the valid credentials (C-P) and the lifecycle of the session (incl. the inactivity timeout) are separate things. I was confusing those topics. I should just delete the post (but wanted to first yhave the followup content here)/

-- peter

Call me naive, but how is maintaining the expiration in the DB "dangerous"? What are the odds of the scenario you described happening?Not being argumentative - just curious.

It is dangerous because the CP has no inherent expiration.

However, there might be a compromise here.  I.e., set an expiration for the CP at midnight or whatever so that it will be sure to go away at the end of the day, but maintain a seperate session expiration which one updates with any new activity, but which is set for an hour or whatever.  If that shorter expiration is reached, then terminate the CP and any other artifacts of the session on the basis that the session is idle.

Which said, one has to wonder about the level of security since this allows for a person to leave for lunch with their session logged in and someone else to come by and use their session with the other person's identity.

The CP may not have an inherent expiration but if the underlaying table holding the contents of the CP does and the record is deleted based upon that arbitrary expiration, I don't see the "danger". Julian mentioned the dange being someone getting hold of that record and helping themselves to a non-expiring CP. What are the odds of that happening in this use-case?

Because anyone who can access the table can see if a particular record has expired or not - and therefore concentrate only on the active records.

Yes, I am paranoid. I have also encrypted the sessionid key so it doesn't match the guid in the table.

I subscribe to the view that you should never show anybody anything unless neccessary ...

not very high. All data is encrypted as well.

While I agree that having someone get ahold of the record would be an indication that the security system had some terrible flaws, I am with Julian in thinking that non-expiring CPs is a bomb waiting to go off.