Is this done as part of IS analytics? --Srinath
On Mon, Jun 27, 2016 at 3:53 PM, Gayan Gunawardana <ga...@wso2.com> wrote: > 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: ga...@wso2.com > Mobile: +94 (71) 8020933 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- ============================ Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
