There are two ways to store variables against a user during authentication, you can either:
- Update user store attributes against the user in the LDAP/ SQL user store
- Set variables in the Siteminder Session store stored against this connection session (SMSESSION ID) of the user.
There are two ways to store variables against a user:
- At the Authentication API stage the smsession context has not yet been created and is not available. You can set variables for the user but these are done in the userstore, with the methods:
Class UserContext setDnProp(name, value); setProp(name, value);
These are done for instance, when logging on with a custom smartcard implementation, a random challenge may be generated stores in a property of the user directory for that user, and then passed back to the user, and retrieved when the smartcard returns a signature.
However, the value there is stored permanently, it is not a "session variable".
- There is a session store, which can also be accessed from the Custom Auth API and and Custom Az API.
The session store is more generally accessed from the web agent side, but they also work from the Policy Server side, in the Auth API and Az API.
From Auth API: class UserContext getSessionID()
In UserContext getSessionID() only be called once you UserContext.isUserContext() has been established and returns true. It will then return you the sessionId that has been or will be assigned to the user's session, depending on whether the session has been established. Obviously if the authentication fails the user never receives the SMSESSION cookie, so you may want to be careful about storing data prior to the authentication having succeeded.
From Az API: class SessionInfoContext String getSessionId()
Access from the Az is more straightforward, since the session has already been established.
Having obtained the sessionId string, then the following class to get/set the session variables details from the session store.
class SmSessionServer(APIContext context) getSession(...) getVariable(...)