Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Dimuth Menikgama]

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  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  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  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 
>>> 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 ...), 

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Dimuth Menikgama]

[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  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  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 
>> 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  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 
 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 
> 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 
>> 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 

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Vihanga Liyanage]

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  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 
> 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  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 
>>> 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 
 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 
> 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 
>> 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 
>>> 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
 

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Ruwan Abeykoon]

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 
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  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 
>> 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  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 
 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 
> 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 
>> 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 
>>> 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 

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Dimuthu Leelarathne]

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  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 
> 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  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 
>>> 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 
 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 
> 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 
>> 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: 

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Ruwan Abeykoon]

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 
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  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 
>> 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 
>>> 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 
 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 
> 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] 
>>
>
>
>
> --
>
> *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>* | 

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Dimuthu Leelarathne]

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  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  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 
>> 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 
>>> 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 
 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] 
>



 --

 *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] 
>>
>> ___
>> 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: 

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Ruwan Abeykoon]

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  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  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 
>> 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 
>>> 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* | http://wso2.com

 [image: 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* | http://wso2.com
>
> [image: 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

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Vihanga Liyanage]

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  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  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 
>> 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* | http://wso2.com
>>>
>>> [image: 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* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Dimuth Menikgama]

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  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 
> 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* | http://wso2.com
>>
>> [image: 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

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Dimuth Menikgama]

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  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* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>



-- 

*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

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Vihanga Liyanage]

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* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [RRT] Limiting the Concurrent active session count for users in WSO2 Identity Server

[Denuwanthi De Silva]

Hi Dimuth,

If the admins do not specify this configuration what are the default values
that would be taken upon?

Thanks,

On Tue, Mar 27, 2018 at 10:30 AM, Dimuth Menikgama  wrote:

> Hi all,
>
> I started working on this new project for *limiting the concurrent active
> session count for users in WSO2 Identity Server*. This project aims to
> add a configuration so that *tenant admin, user store admin *or *identity
> admin* can enforce the maximum sessions for each user belong to a
> particular *tenant, user store *or* user role*. If a user tries to exceed
> the maximum session limit, the user will be notified with active session
> count and will be asked to log out from existing active session manually in
> order to create a new session.
>
> I was able to come up with user stories[1] for this feature and an initial
> user story review for this was held on 21st March with Dimuthu, Pulasthim,
> Menaka, and Myself.
>
> Conditional Authentication capabilities of Identity server will be used
> for the implementing this feature. I hope to create a function to identify
> the number of active sessions for a particular user.
>
> Following problems were selected to discuss further,
>
>
>-
>
>A mechanism for identifying maximum session count is needed when more
>than one session limiting policy is applied. As an example let user Bob
>belongs to tenant T and user store S. If maximum session count for users in
>T is M and maximum session count for users in S is N, we need a mechanism
>to identify the maximum allowed session count (Need to decide whether to
>use M or N). For that, following things were suggested
>-
>
>   Defining a precedence list.
>   -
>
>   Taking the minimum limit of all policies as the maximum allowed
>   session count. (Minimum of M and N )
>
>
>
>-
>
>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.
>
>
> Any comments or suggestions are highly appreciated.
>
> [1] https://docs.google.com/document/d/1MwTSI79G7TvgMwIhWpW3tAZ8JRR9V
> TzqwfvjlOOAke0/edit?usp=sharing
> 
>
> Regards,
>
> Dimuth Menikgama.
>
>
> --
>
> *Dimuth Menikgama*
>
> *Software Engineer*
> *WSO2*
>
>
> *Mobile :  + 94 702337977
> <%2B%2094%2011%202145345%20%C2%A0Ext.%205737>*
>
> * <%2B%2094%2011%202145300>*
>



-- 
Denuwanthi De Silva
Senior Software Engineer;
WSO2 Inc.; http://wso2.com,
Email: denuwan...@wso2.com
Blog: https://denuwanthi.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture