On Mon, Jul 4, 2016 at 9:31 AM, Selvaratnam Uthaiyashankar <shan...@wso2.com > wrote:
> > > >> >> On Fri, Jul 1, 2016 at 7:32 PM, Selvaratnam Uthaiyashankar < >> shan...@wso2.com> wrote: >> >>> >>> >>> 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, >>>> >>> >>> In all other tables, we keep TENANT_ID, not the TENANT_NAME. Any reason >>> we have TENANT_NAME here and not TENANT_ID? >>> >> >> Reason to use TENANT_NAME instead of TENANT_ID is we retrieve user tenant >> information from SessionContextCacheEntry --> SequenceConfig --> >> AuthenticatedUser there we don't have TENANT_ID information. I will look >> into possibility of using TENANT_ID instead of TENANT_NAME. >> >>> >>> >>> >>>> >>>> FOREIGN KEY (SESSION_ID) REFERENCES >>>> IDN_AUTH_SESSION_STORE(SESSION_ID) ON DELETE CASCADE, >>>> >>>> PRIMARY KEY (SESSION_ID, USER_NAME) >>>> >>> >>> >>> Is it possible for a SESSION_ID to have multiple USER_NAME? if not, >>> above primary key doesn't make sense. >>> >> Yes. It is possible to have multiple USER_NAME for SESSION_ID. >> > > > Can you give an example of a situation where you can have a single > SESSION_ID and different USER_NAME? I thought the session and session_id > are for a particular user. If multiple usernames are possible, if we want > to terminate a session, how to achieve that? > In same browser session for two service providers if authentication steps are different for an example service provider-1 has basic authenticator authenticated with local username 'gayan' and for service provider-2 user authenticated to Facebook federated authenticator with username gayan_em...@gmail.com. Now we have two usernames 'gayan', ' gayan_em...@gmail.com' for same SESSION_ID. If we kill the SESSION of 'gayan' it will kill the session of 'gayan_em...@gmail.com' as well. As an improvement we can group USER_NAMEs associate with particular SESSION_ID. > > > >> >>> >>> >>>> >>>> ); >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> S.Uthaiyashankar >>> VP Engineering >>> WSO2 Inc. >>> http://wso2.com/ - "lean . enterprise . middleware" >>> >>> Phone: +94 714897591 >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> 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 >> >> > > > -- > S.Uthaiyashankar > VP Engineering > WSO2 Inc. > http://wso2.com/ - "lean . enterprise . middleware" > > Phone: +94 714897591 > -- 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
