Hi all,

As discussed in the design review, I implemented a function that can be
used to get information regarding current active sessions for a particular
user.

This function can be used in the conditional authentication script to get a
JSON object with that session information. I used the "*analytics/search*"
REST endpoint in IS-analytics and retrieved the records available in the "
*ORG_WSO2_IS_ANALYTICS_STREAM_ACTIVESESSIONS*" table.

However, I'm having a problem terminating the session creation request when
session limit is exceeded. To get the existing session information for the
user, information such as username, user tenant domain etc. is required.
Executing the basic authenticator is the proper way to collect that
information from the user AFAIK. But when the basic authentication step is
finished with success, a new session is created regardless of the results
of other steps. Below is the conditional authentication script I used.

function(context) {

executeStep({
id: '1',
on: {
success: function (context) {

var sessionLimit = 3;
             var result = getUserActiveSessions(context,sessionLimit);
             var jsonResult = JSON.parse(result);
             var withinAllowedSessionLimit = jsonResult.state;
             Log.info(JSON.stringify(jsonResult))
             Log.info("WITHIN SESSION LIMIT :"+ withinAllowedSessionLimit);
if (withinAllowedSessionLimit){
executeStep({id: '2'});
}
             else{
Log.info("Session Limit Exceeded");
                 return false;
             }
}
}
});
}


Newly created *getUserActiveSessions()* function returns a JSON Object with
an array of session objects and a state which indicates whether the user
has exceeded the session limit. We can use that information to decide the
authentication flow and display metadata about existing sessions in the
User Interface in later phases of the project. Below image shows the logs
that generated when the above script is executed.


​
IMO the best way to handle this situation is by creating new authentication
step similar to the basic authenticator. When that step is called, a new
session should not be created.

 Please give your comments and thoughts regarding this.

Regards,
Dimuth Menikgama.


On Tue, Apr 3, 2018 at 5:02 PM, Dimuth Menikgama <dim...@wso2.com> wrote:

> [Update]
>
> Hi all,
>
> During the design review for this project. Following things were
> discussed.
>
>    - Problems with existing design
>
>
>    1.  Operational issues - Performance may degrade with the number of
>    users
>    2.  Bounded to schema - Extensions should not depend on databases
>
>
>    - Make this feature an Extension.
>    - To avoid the above mentioned design issues, use IS-Analytics to
>    retrieve data about sessions. (For the POC )
>    - Use existing session information in IS-Analytics if possible. Create
>    a new stream with required session information.
>    - Use Siddhi to publish and retrieve the basic session information and
>    meta data.
>    - This approach allow users to write/ modify their own ways of session
>    management logic with Siddhi.
>    - This session information will then moved inside the identity server
>    and this feature can be used without analytics components.
>
> please add anything I have missed.
>
> Regards,
> Dimuth Menikgama
>
>
> On Mon, Apr 2, 2018 at 5:31 PM, Vihanga Liyanage <viha...@wso2.com> wrote:
>
>> Hi Ruwan,
>>
>> I share the same concern as Dimuthu, losing data in older sessions. I
>> understand that you have a way to identify the oldest session. If we can
>> get some information about that session, at least a device ID, we can pop
>> up a confirmation box as follows.
>>
>> "Your session limit has reached. We have to close "xxx" session in order
>> to create a new one. Please confirm."
>>
>> If the user said "OK", we close the session and create a new one. No new
>> UI will be required. This is of cause if we can get information about the
>> oldest session.
>>
>> If we can't do that as well, then I think the best way to go forward is
>> moving all of this to the next phase. Just MHO.
>>
>> Thanks,
>> Vihanga.
>>
>> On Mon, Apr 2, 2018 at 3:27 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
>>
>>> Hi Dimuthu,
>>> +1 on the second phase.
>>>
>>> But I am worried about the "Unlikely case" ..
>>> The problem is that the user is not able to login, which means he can
>>> not use any services, except "call the admin". Usually you can not reach
>>> admin in time when this kind of thing happens. I consider this as "Denial
>>> of Service", which causes loss of productivity in critical situations.
>>>
>>> Cheers,
>>> Ruwan
>>>
>>>
>>> On Mon, Apr 2, 2018 at 9:36 AM, Dimuthu Leelarathne <dimut...@wso2.com>
>>> wrote:
>>>
>>>> Hi Ruwan,
>>>>
>>>> He has to close the session by closing the browser or logging out from
>>>> other device.
>>>>
>>>> Let's take the unlikely case of user loosing the device or not having
>>>> the other browser (eg. left the extra machine at home etc ...), then we
>>>> have the phase-2 of this project where he can chose to kill the session
>>>> while the authentication is happening for the current session. Or else he
>>>> can call the admin and ask him to kill a session.
>>>>
>>>> thanks,
>>>> Dimuthu
>>>>
>>>>
>>>> On Mon, Apr 2, 2018 at 2:14 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
>>>>
>>>>> Hi Dimuthu,
>>>>> The problem would be that the user will not be able to login at all on
>>>>> a new device, if we choose to stop creation of sessions. Then there is no
>>>>> way to terminate any old sessions, as the user is not authenticated.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Ruwan
>>>>>
>>>>> On Mon, Apr 2, 2018 at 8:18 AM, Dimuthu Leelarathne <dimut...@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I am in favor of not allowing the user to proceed with the current
>>>>>> session. That is because old sessions could have unsaved data. There is 
>>>>>> no
>>>>>> harm in stopping the creation of new session.
>>>>>>
>>>>>> thanks,
>>>>>> Dimuthu
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 2, 2018 at 12:09 PM, Ruwan Abeykoon <ruw...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Dimuth/Vihanga,
>>>>>>> I think we need to get the minimal solution implemented and
>>>>>>> demonstrated first. The minimal product would,
>>>>>>>
>>>>>>> 1. Close the oldest session, when the session count exceeds maximum
>>>>>>> allowed count. No need to provide a UI to the user.
>>>>>>> 2. Log the above case in separate identifiable log in IS side.
>>>>>>>
>>>>>>> The reason is, identifying the multiple sessions and allowing this
>>>>>>> to be handled is a major feature itself, and there are number of 
>>>>>>> technical
>>>>>>> hurdles to overcome.
>>>>>>>
>>>>>>> At a later phase, we can add the feedback UI for the user, allow him
>>>>>>> to select which sessions to close, etc. This is again a major feature.
>>>>>>> Because the UI needs to display a lot of information about the session
>>>>>>> (Device, IP, Time, Browser, etc), which we do not capture as of now.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ruwan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 2, 2018 at 5:53 AM, Vihanga Liyanage <viha...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Dimuth,
>>>>>>>>
>>>>>>>> I'm not sure I understand your approach. In the first phase of the
>>>>>>>> project, if a user request for a new session, you will just close the
>>>>>>>> existing session and create a new one, without letting the user know. 
>>>>>>>> Is
>>>>>>>> that correct?
>>>>>>>>
>>>>>>>> On Mon, Apr 2, 2018 at 10:41 AM, Dimuth Menikgama <dim...@wso2.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Vihanga,
>>>>>>>>>
>>>>>>>>> AFAIU you are suggesting an improvement to first solution
>>>>>>>>> suggested. Instead of closing the existing session at once, you are
>>>>>>>>> suggesting to notify the user and get the approval before closing.
>>>>>>>>>
>>>>>>>>> This can be added to second phase of this project. In the second
>>>>>>>>> phase, we hope to add functionality to prompt the user with active 
>>>>>>>>> session
>>>>>>>>> information (meta data such as device, session start time etc ) and 
>>>>>>>>> let
>>>>>>>>> user to select what session to close.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Dimuth Menikgama
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Apr 2, 2018 at 10:02 AM, Dimuth Menikgama <dim...@wso2.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> Hi Denuwanthi,
>>>>>>>>>>
>>>>>>>>>> Currently we have decided to implement this as a conditional
>>>>>>>>>> authentication function. Admin user can use this function to get the 
>>>>>>>>>> number
>>>>>>>>>> of active sessions and can create a condition with the limit he 
>>>>>>>>>> wants. If
>>>>>>>>>> the admin user does not use this function, no conditions will be 
>>>>>>>>>> tested
>>>>>>>>>> based on session count. So the user can create unlimited number of 
>>>>>>>>>> sessions
>>>>>>>>>> without any problem.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Dimuth Menikgama.
>>>>>>>>>>
>>>>>>>>>> On Sat, Mar 31, 2018 at 3:24 PM, Vihanga Liyanage <
>>>>>>>>>> viha...@wso2.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Dimuth,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>    -
>>>>>>>>>>>>>
>>>>>>>>>>>>>    What is the best way to handle new session request when
>>>>>>>>>>>>>    maximum allowed session limit is 1?
>>>>>>>>>>>>>    -
>>>>>>>>>>>>>
>>>>>>>>>>>>>       If there is a session, close that session and create a
>>>>>>>>>>>>>       new session.
>>>>>>>>>>>>>       -
>>>>>>>>>>>>>
>>>>>>>>>>>>>       Notify the user about the existing session and ask to
>>>>>>>>>>>>>       end that manually if he want to create a new session.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> IMHO, I think both of these proposed methods are not suitable.
>>>>>>>>>>> Instead what if we notify the user about the limitation on active 
>>>>>>>>>>> sessions
>>>>>>>>>>> and ask for the consent to close the existing session from our end? 
>>>>>>>>>>> Closing
>>>>>>>>>>> the session manually by the user could be a hassle for him 
>>>>>>>>>>> especially if it
>>>>>>>>>>> was another device. We can just invalidate the session from our end 
>>>>>>>>>>> without
>>>>>>>>>>> much effort. WDYT?
>>>>>>>>>>>
>>>>>>>>>>> ​Thanks,
>>>>>>>>>>> Vihanga.​
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Vihanga Liyanage
>>>>>>>>>>>
>>>>>>>>>>> Software Engineer | WS*O₂* Inc.
>>>>>>>>>>>
>>>>>>>>>>> M : +*94710124103 <071%20012%204103>* | http://wso2.com
>>>>>>>>>>>
>>>>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> *Dimuth Menikgama*
>>>>>>>>>>
>>>>>>>>>> *Software Engineer*
>>>>>>>>>> *WSO2*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Mobile :      + 94 702337977
>>>>>>>>>> <%2B%2094%2011%202145345%20%C2%A0Ext.%205737>*
>>>>>>>>>>
>>>>>>>>>> * <%2B%2094%2011%202145300>*
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> *Dimuth Menikgama*
>>>>>>>>>
>>>>>>>>> *Software Engineer*
>>>>>>>>> *WSO2*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Mobile :      + 94 702337977
>>>>>>>>> <%2B%2094%2011%202145345%20%C2%A0Ext.%205737>*
>>>>>>>>>
>>>>>>>>> * <%2B%2094%2011%202145300>*
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Vihanga Liyanage
>>>>>>>>
>>>>>>>> Software Engineer | WS*O₂* Inc.
>>>>>>>>
>>>>>>>> M : +*94710124103 <071%20012%204103>* | http://wso2.com
>>>>>>>>
>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Architecture mailing list
>>>>>>>> Architecture@wso2.org
>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dimuthu Leelarathne
>>>>>> Director, Rapid Response Team
>>>>>>
>>>>>> WSO2, Inc. (http://wso2.com)
>>>>>> email: dimut...@wso2.com
>>>>>> Mobile: +94773661935 <+94%2077%20366%201935>
>>>>>> Blog: http://muthulee.blogspot.com
>>>>>>
>>>>>> Lean . Enterprise . Middleware
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Ruwan Abeykoon*
>>>>> *Associate Director/Architect**,*
>>>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>>>>> *lean.enterprise.middleware.*
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Dimuthu Leelarathne
>>>> Director, Rapid Response Team
>>>>
>>>> WSO2, Inc. (http://wso2.com)
>>>> email: dimut...@wso2.com
>>>> Mobile: +94773661935 <+94%2077%20366%201935>
>>>> Blog: http://muthulee.blogspot.com
>>>>
>>>> Lean . Enterprise . Middleware
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Ruwan Abeykoon*
>>> *Associate Director/Architect**,*
>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>>> *lean.enterprise.middleware.*
>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> Vihanga Liyanage
>>
>> Software Engineer | WS*O₂* Inc.
>>
>> M : +*94710124103* | http://wso2.com
>>
>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>
>
>
>
> --
>
> *Dimuth Menikgama*
>
> *Software Engineer*
> *WSO2*
>
>
> *Mobile :      + 94 702337977
> <%2B%2094%2011%202145345%20%C2%A0Ext.%205737>*
>
> * <%2B%2094%2011%202145300>*
>



-- 

*Dimuth Menikgama*

*Software Engineer*
*WSO2*


*Mobile :      + 94 702337977 <%2B%2094%2011%202145345%20%C2%A0Ext.%205737>*

* <%2B%2094%2011%202145300>*
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to