On Tue, Jun 28, 2016 at 11:24 AM, Srinath Perera <[email protected]> wrote:
> 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. > I don't think we can straight away use above implementation.. It seems, above implementation is totally dealt with Identity tables and doing manipulation with those data.. @Gayan, can we have a chat on this and see whether we can reuse any of these work for Identity Session related analytics ? Thanks, Mohan > > --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/ > -- *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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
