Please make sure we do not do the work twice. If what this do is something IS analytics can use later, then OK. But if one is redundant at the end, that is a waste.
--Srinath --Srinath On Tue, Jun 28, 2016 at 10:40 AM, Mohanadarshan Vivekanandalingam < [email protected]> wrote: > > > On Tue, Jun 28, 2016 at 10:23 AM, Mohanadarshan Vivekanandalingam < > [email protected]> wrote: > >> Hi Srinath, >> >> Above mentioned scenarios are not handled in the initial version of >> session related analytics (and not in our future list as well).. The >> scenarios that we are covering are mentioned in [1].. We are looking at >> overall session analytics and not focusing on user specific sessions or >> session specific user. >> >> But, as per Gayan's description it seems they are looking to do some >> operations rather than just monitoring those sessions.. But anyway, we can >> incorporate these session analytics for next version it it make sense.. >> >> [1] Analytics IS - Session Analytics View >> >> Thanks, >> Mohan >> >> >> On Tue, Jun 28, 2016 at 8:26 AM, Srinath Perera <[email protected]> wrote: >> >>> Is this done as part of IS analytics? >>> >>> --Srinath >>> >>> On Mon, Jun 27, 2016 at 3:53 PM, Gayan Gunawardana <[email protected]> >>> 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: [email protected] >>>> Mobile: +94 (71) 8020933 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://people.apache.org/~hemapani/ >>> http://srinathsview.blogspot.com/ >>> >> >> >> >> -- >> *V. Mohanadarshan* >> *Associate Tech Lead,* >> *Data Technologies Team,* >> *WSO2, Inc. http://wso2.com <http://wso2.com> * >> *lean.enterprise.middleware.* >> >> email: [email protected] >> phone:(+94) 771117673 >> > > > > -- > *V. Mohanadarshan* > *Associate Tech Lead,* > *Data Technologies Team,* > *WSO2, Inc. http://wso2.com <http://wso2.com> * > *lean.enterprise.middleware.* > > email: [email protected] > phone:(+94) 771117673 > -- ============================ Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
