Hi All,
This feature will provide capability to admin users to monitor other logged
in users sessions and kill those sessions if necessary. Currently logged in
users sessions persist inside IDN_AUTH_SESSION_STORE table and there is no
mapping to authenticated user. We are planning to introduce new table to
maintain mapping between user and session id.
CREATE TABLE IDN_USER_SESSION_DATA (
SESSION_ID VARCHAR (100) DEFAULT NULL,
USER_NAME VARCHAR(100) DEFAULT NULL,
USER_DOMAIN_NAME VARCHAR(100) DEFAULT NULL,
TENANT_NAME VARCHAR(100) DEFAULT NULL,
FOREIGN KEY (SESSION_ID) REFERENCES
IDN_AUTH_SESSION_STORE(SESSION_ID) ON DELETE CASCADE,
PRIMARY KEY (SESSION_ID, USER_NAME)
);
According to latest implementation of session data persistence, we can
consider particular SESSION ID is active if last record (sorted by time
descending order) for given SESSION ID is "STORE" operation. If there are
two store operations to IDN_AUTH_SESSION_STORE table there is a problem of
duplicating data in IDN_USER_SESSION_DATA. We need to find a way to handle
this situation.
1. Listing active session list for given user
In back-end distinguish sessions will be identified by using SESSION_ID but
in front-end we cannot display SESSION_ID. In front-end unique sessions
will be displayed according to User-Agent.
2. Listing users who have active sessions
Listing users who have at least one active session will be challenging.
Since IDN_AUTH_SESSION_STORE table is HUGE in a production system, and
doing a JOIN operation with it would be costly.
The username in the USER_SESSION_DATA is picked from the authenticated user
attribute available in the session context. This attribute is set after all
processing done in the SequenceHandler hence the authenticated user here
actually subject identifier, rather than a real username.
Hence the username in the USER_SESSION_DATA table can be one of following,
i. A Local User : who use the actual username as the subject identifier
ii. A Local User : who use a claim as the subject identifier
iii. A Federated User : who use federated subject or a claim
Only in first scenario, it can find proper user store domain from the
username. In the third scenario we can store federated IDP name for
USER_DOMAIN_NAME.
Handling\Storing usernames is a common thing we need to decide (in OAuth
IDN_OAUTH2_ACCESS_TOKEN we have the same problem), so we should figure out
a general schema for IDN_USER_SESSION_DATA that can be used for all types
of users.
Thanks,
Gayan
--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/
Email: [email protected]
Mobile: +94 (71) 8020933
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
