Re: [Architecture] [C5][IS 6.0.0]Admin Forced Password Reset Via Offline for Existing Users

[Ayesha Dissanayaka]

Hi,

The actual requirement of this feature is that, administrators should be
able to enforce a password reset action for users before authenticating to
the system. [1] Explains the similar feature in IS-5.3.0.

Most of the confusions arises by calling this pass-code a OTP. Rather AFAIK
this is an admin generated passcode, not a password that a user can use to
authenticate to the system.
Once an admin initiate this flow for a particular user, then when someone
tries to login to system with accounts current password, he isn't get
authenticated, instead asked to provide the passcode. When user provide the
correct passcode, he will be asked to reset the password. Without resetting
the password he cannot continue to login to the system.

On Thu, Mar 16, 2017 at 9:31 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Why should we allow multiple OTPs for a particular user at a given time ?
> Cannot we keep only one valid OTP for a user at a given time and override
> it at the point of creating a new one ?


+1. Lets keep only one valid OTP.

How do you plan to access the content in this table from the authentication
> flow.
>
> What I wanted to point is, this OTP is another credential for the user. So
> we should store in a "credential store" which is introduced with new user
> core.
>

It's clear this can be use only one time but  what is the scope of this OTP
> ? is this can only be used to login to user-portal or can this OTP use in
> any other purposes ( an example, say login to generate SAML token in a SSO
> story)
>

Actually in this implementation we have not considered this as a password.
Though we used the word OTP it is kind of a code. By using this code the
user can create a new password but can not login to any portal or can not
perform any task of IS. So this is not actually a credential for the user.
+1

In some cases identity admin need to set validity period on OTP so IMO we
> need to support time based validity.
>


> I too have the same concern. What is the idea behind allowing multiple
> OTPs at any point of time? Isn't the usual practice to keep only the latest
> OTP active?
>

+1. Lets add a time based validity period.
Already time based code expiration is there for recovery table entries.

On Thu, Mar 16, 2017 at 10:17 AM, Gayan Gunawardana  wrote:

> Due to some network issue or mail server issue if user doesn't receive
> second OTP in that case user experience is not so good. I do not see a
> problem of having multiple valid OTPs at a given time. What need to be done
> is all should be invalidated if user consume at least one.

In this case user should be given the option to re-recieve a new code. (ex:
Maybe a message to contact an admin to do so, or direct to self served
portal.)

Thanks!
-Ayesha


-- 
*Ayesha Dissanayaka*
Senior Software Engineer,
WSO2, Inc : http://wso2.com

20, Palm grove Avenue, Colombo 3
E-Mail: aye...@wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IoT] Android SDK for developers

[Inosh Perera]

Hi Charitha,

I have already initiated a new thread[1] for this with bit different
architectural approach. So shall we discuss the design in there?
+1

Regards,
Inosh

On Thu, Mar 16, 2017 at 1:52 PM, Charitha Goonetilleke 
wrote:

> Hi All,
>
> I have already initiated a new thread[1] for this with bit different
> architectural approach. So shall we discuss the design in there?
>
> [1] SDK approach for IoT Android Agent
>
> On Thu, Mar 16, 2017 at 10:17 AM, Inosh Perera  wrote:
>
>> Hi Sumedha/Ruwan,
>>
>> Why this has to be special for Android?
>> I don't think we can write a SDK for iOS or windows since they are done
>> by the OS.
>> +1 for having generalisation for other device types such as raspberry pi
>> and arduino.
>>
> +1
>
>>
>> Plus, the more than calling the last segment, communication API, it
>> should be quoted configuration API, as communication protocol, in reality
>> is just a configuration given that said configuration is supported.
>> +1
>>
> +1
>
>>
>> Regards,
>> Inosh
>>
>> On Thu, Mar 16, 2017 at 12:43 PM, Ruwan Yatawara  wrote:
>>
>>> Yes, this should be a generic API. Plus, the more than calling the last
>>> segment, communication API, it should be quoted configuration API, as
>>> communication protocol, in reality is just a configuration given that said
>>> configuration is supported.
>>>
>>> Thanks and Regards,
>>>
>>> Ruwan Yatawara
>>>
>>> Associate Technical Lead,
>>> WSO2 Inc.
>>>
>>> email : ruw...@wso2.com
>>> mobile : +94 77 9110413
>>> blog :  http://ruwansrants.blogspot.com/
>>>
>>> https://500px.com/ruwan_ace
>>> https://medium.com/@ruwanyatawara
>>>
>>> www: :http://wso2.com
>>>
>>>
>>> On Thu, Mar 16, 2017 at 9:07 AM, Sumedha Rubasinghe 
>>> wrote:
>>>
 Why this has to be special for Android? It's the generic API we provide
 from IoT Server. And current API has part of this functionality. Isn't it?

 On Thu, Mar 16, 2017 at 8:59 AM, Inosh Perera  wrote:

> Hi All,
>
> Based on Charitha's suggestion to have an SDK for developers, I would
> suggest we have the following high level APIs made available for 
> developers
> as an Android SDK. This will contain functionalities of the existing
> Android agent and it can be utilized to build agent's faster for different
> types of Android devices such as TVs or wearables.
>
> Enrollment API
> This will provide Oauth based and mutual SSL based authentication
> flows OOB including UIs where the developer simply need to call the needed
> flow and and can get a device enrolled. This flow should also facilitate
> plugging in any new authentication flows, so that if the developer need a
> different authentication mechanism, it can be facilitated.
>
> Device API
> This will simply provide access to different SDKs methods in Android
> so that the developer doesn't need to deal with for example location
> services to get the current location. This may also include sensor data
> querying.
>
> Application API
> This API provides capabilities to handle application management
> related tasks such as app installs, uninstall, updates and get application
> related information on device.
>
> Policy API
> This will provide policy enforcement and policy monitoring related
> APIs. When a policy enforcement request comes from the server, relevant
> policy API must be called to enforce it and the monitoring API provides
> ability to check if the enforced policy is adhered by the device.
>
> Operation API
> This will have APIs necessery to schedule polling the server to get
> operations to be executed and and a default implementation of an operation
> manager which talks to different APIs such as device API, Application API
> or policy API based on the operations received from the server.
>
> Communication API
> This will provide different communication methods such as Http, mqtt
> or listeners for FCM. API should provide mechanism to plugin any user
> needed protocols to communicate with the IoT server. This API will also
> provide means to talk to other applications such as system application or
> App catalog application which are already available.
>
> This is a basic high level API view. Please provide your suggestions.
>
> Regards,
> Inosh
>
>
> --
> Inosh Perera
> Senior Software Engineer, WSO2 Inc.
> Tel: 077813 7285, 0785293686 <078%20529%203686>
>



 --
 /sumedha
 m: +94 773017743 <077%20301%207743>
 b :  bit.ly/sumedha

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>
>>
>> --
>> Inosh Perera
>> Senior Software Engineer, WSO2 Inc.
>> 

Re: [Architecture] [IoT] Android SDK for developers

[Charitha Goonetilleke]

Hi All,

I have already initiated a new thread[1] for this with bit different
architectural approach. So shall we discuss the design in there?

[1] SDK approach for IoT Android Agent

On Thu, Mar 16, 2017 at 10:17 AM, Inosh Perera  wrote:

> Hi Sumedha/Ruwan,
>
> Why this has to be special for Android?
> I don't think we can write a SDK for iOS or windows since they are done by
> the OS.
> +1 for having generalisation for other device types such as raspberry pi
> and arduino.
>
+1

>
> Plus, the more than calling the last segment, communication API, it should
> be quoted configuration API, as communication protocol, in reality is just
> a configuration given that said configuration is supported.
> +1
>
+1

>
> Regards,
> Inosh
>
> On Thu, Mar 16, 2017 at 12:43 PM, Ruwan Yatawara  wrote:
>
>> Yes, this should be a generic API. Plus, the more than calling the last
>> segment, communication API, it should be quoted configuration API, as
>> communication protocol, in reality is just a configuration given that said
>> configuration is supported.
>>
>> Thanks and Regards,
>>
>> Ruwan Yatawara
>>
>> Associate Technical Lead,
>> WSO2 Inc.
>>
>> email : ruw...@wso2.com
>> mobile : +94 77 9110413
>> blog :  http://ruwansrants.blogspot.com/
>>
>> https://500px.com/ruwan_ace
>> https://medium.com/@ruwanyatawara
>>
>> www: :http://wso2.com
>>
>>
>> On Thu, Mar 16, 2017 at 9:07 AM, Sumedha Rubasinghe 
>> wrote:
>>
>>> Why this has to be special for Android? It's the generic API we provide
>>> from IoT Server. And current API has part of this functionality. Isn't it?
>>>
>>> On Thu, Mar 16, 2017 at 8:59 AM, Inosh Perera  wrote:
>>>
 Hi All,

 Based on Charitha's suggestion to have an SDK for developers, I would
 suggest we have the following high level APIs made available for developers
 as an Android SDK. This will contain functionalities of the existing
 Android agent and it can be utilized to build agent's faster for different
 types of Android devices such as TVs or wearables.

 Enrollment API
 This will provide Oauth based and mutual SSL based authentication flows
 OOB including UIs where the developer simply need to call the needed flow
 and and can get a device enrolled. This flow should also facilitate
 plugging in any new authentication flows, so that if the developer need a
 different authentication mechanism, it can be facilitated.

 Device API
 This will simply provide access to different SDKs methods in Android so
 that the developer doesn't need to deal with for example location services
 to get the current location. This may also include sensor data querying.

 Application API
 This API provides capabilities to handle application management related
 tasks such as app installs, uninstall, updates and get application related
 information on device.

 Policy API
 This will provide policy enforcement and policy monitoring related
 APIs. When a policy enforcement request comes from the server, relevant
 policy API must be called to enforce it and the monitoring API provides
 ability to check if the enforced policy is adhered by the device.

 Operation API
 This will have APIs necessery to schedule polling the server to get
 operations to be executed and and a default implementation of an operation
 manager which talks to different APIs such as device API, Application API
 or policy API based on the operations received from the server.

 Communication API
 This will provide different communication methods such as Http, mqtt or
 listeners for FCM. API should provide mechanism to plugin any user needed
 protocols to communicate with the IoT server. This API will also provide
 means to talk to other applications such as system application or App
 catalog application which are already available.

 This is a basic high level API view. Please provide your suggestions.

 Regards,
 Inosh


 --
 Inosh Perera
 Senior Software Engineer, WSO2 Inc.
 Tel: 077813 7285, 0785293686 <078%20529%203686>

>>>
>>>
>>>
>>> --
>>> /sumedha
>>> m: +94 773017743 <077%20301%207743>
>>> b :  bit.ly/sumedha
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
>
> --
> Inosh Perera
> Senior Software Engineer, WSO2 Inc.
> Tel: 077813 7285, 0785293686
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Charitha Goonetilleke*
Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 77 751 3669 <%2B94777513669>
Twitter:@CharithaWs , fb: charithag

Re: [Architecture] [IoT] Android SDK for developers

[Inosh Perera]

Hi Sumedha/Ruwan,

Why this has to be special for Android?
I don't think we can write a SDK for iOS or windows since they are done by
the OS.
+1 for having generalisation for other device types such as raspberry pi
and arduino.

Plus, the more than calling the last segment, communication API, it should
be quoted configuration API, as communication protocol, in reality is just
a configuration given that said configuration is supported.
+1

Regards,
Inosh

On Thu, Mar 16, 2017 at 12:43 PM, Ruwan Yatawara  wrote:

> Yes, this should be a generic API. Plus, the more than calling the last
> segment, communication API, it should be quoted configuration API, as
> communication protocol, in reality is just a configuration given that said
> configuration is supported.
>
> Thanks and Regards,
>
> Ruwan Yatawara
>
> Associate Technical Lead,
> WSO2 Inc.
>
> email : ruw...@wso2.com
> mobile : +94 77 9110413
> blog :  http://ruwansrants.blogspot.com/
>
> https://500px.com/ruwan_ace
> https://medium.com/@ruwanyatawara
>
> www: :http://wso2.com
>
>
> On Thu, Mar 16, 2017 at 9:07 AM, Sumedha Rubasinghe 
> wrote:
>
>> Why this has to be special for Android? It's the generic API we provide
>> from IoT Server. And current API has part of this functionality. Isn't it?
>>
>> On Thu, Mar 16, 2017 at 8:59 AM, Inosh Perera  wrote:
>>
>>> Hi All,
>>>
>>> Based on Charitha's suggestion to have an SDK for developers, I would
>>> suggest we have the following high level APIs made available for developers
>>> as an Android SDK. This will contain functionalities of the existing
>>> Android agent and it can be utilized to build agent's faster for different
>>> types of Android devices such as TVs or wearables.
>>>
>>> Enrollment API
>>> This will provide Oauth based and mutual SSL based authentication flows
>>> OOB including UIs where the developer simply need to call the needed flow
>>> and and can get a device enrolled. This flow should also facilitate
>>> plugging in any new authentication flows, so that if the developer need a
>>> different authentication mechanism, it can be facilitated.
>>>
>>> Device API
>>> This will simply provide access to different SDKs methods in Android so
>>> that the developer doesn't need to deal with for example location services
>>> to get the current location. This may also include sensor data querying.
>>>
>>> Application API
>>> This API provides capabilities to handle application management related
>>> tasks such as app installs, uninstall, updates and get application related
>>> information on device.
>>>
>>> Policy API
>>> This will provide policy enforcement and policy monitoring related APIs.
>>> When a policy enforcement request comes from the server, relevant policy
>>> API must be called to enforce it and the monitoring API provides ability to
>>> check if the enforced policy is adhered by the device.
>>>
>>> Operation API
>>> This will have APIs necessery to schedule polling the server to get
>>> operations to be executed and and a default implementation of an operation
>>> manager which talks to different APIs such as device API, Application API
>>> or policy API based on the operations received from the server.
>>>
>>> Communication API
>>> This will provide different communication methods such as Http, mqtt or
>>> listeners for FCM. API should provide mechanism to plugin any user needed
>>> protocols to communicate with the IoT server. This API will also provide
>>> means to talk to other applications such as system application or App
>>> catalog application which are already available.
>>>
>>> This is a basic high level API view. Please provide your suggestions.
>>>
>>> Regards,
>>> Inosh
>>>
>>>
>>> --
>>> Inosh Perera
>>> Senior Software Engineer, WSO2 Inc.
>>> Tel: 077813 7285, 0785293686 <078%20529%203686>
>>>
>>
>>
>>
>> --
>> /sumedha
>> m: +94 773017743 <077%20301%207743>
>> b :  bit.ly/sumedha
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>


-- 
Inosh Perera
Senior Software Engineer, WSO2 Inc.
Tel: 077813 7285, 0785293686
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0]Admin Forced Password Reset Via Offline for Existing Users

[Gayan Gunawardana]

On Thu, Mar 16, 2017 at 9:31 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi All,
>
> Why should we allow multiple OTPs for a particular user at a given time ?
>> Cannot we keep only one valid OTP for a user at a given time and override
>> it at the point of creating a new one ?
>
>
> +1. Lets keep only one valid OTP.
>
Due to some network issue or mail server issue if user doesn't receive
second OTP in that case user experience is not so good. I do not see a
problem of having multiple valid OTPs at a given time. What need to be done
is all should be invalidated if user consume at least one.
@Johann
WDYT?

>
> How do you plan to access the content in this table from the
>> authentication flow.
>>
>> What I wanted to point is, this OTP is another credential for the user.
>> So we should store in a "credential store" which is introduced with new
>> user core.
>>
>
> It's clear this can be use only one time but  what is the scope of this
>> OTP ? is this can only be used to login to user-portal or can this OTP use
>> in any other purposes ( an example, say login to generate SAML token in a
>> SSO story)
>>
>
> Actually in this implementation we have not considered this as a password.
> Though we used the word OTP it is kind of a code. By using this code the
> user can create a new password but can not login to any portal or can not
> perform any task of IS. So this is not actually a credential for the user.
>
> In some cases identity admin need to set validity period on OTP so IMO we
>> need to support time based validity.
>>
>
>
>> I too have the same concern. What is the idea behind allowing multiple
>> OTPs at any point of time? Isn't the usual practice to keep only the latest
>> OTP active?
>>
>
> +1. Lets add a time based validity period.
>
> Thanks,
>
>
>
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>
> On Wed, Mar 15, 2017 at 10:55 PM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Wednesday, March 15, 2017, Dilan Udara Ariyaratne 
>> wrote:
>>
>>>
>>> On Tue, Mar 14, 2017 at 11:08 AM, Gayan Gunawardana 
>>> wrote:
>>>


 On Tue, Mar 14, 2017 at 10:58 AM, Hasanthi Purnima Dissanayake <
 hasan...@wso2.com> wrote:

> Hi all,
>
> We are in the process of implementing Admin Forced Password Reset via
> Offline for existing users in Admin Portal for the new IS 6.0.0 release.
> The wireframe design for the UI is found at [1].
>
> Admin can select a user and generate a password for the selected user.
> This generated password is an OTP.
>
> This OTP is:
> 1. Not adhere to any password policy.
> 2. There is no validity period
> 3. Once this OTP is used it expires.
> 4. Not considered like a normal password and we are going to store it
> in IDN_RECOVERY_DATA table.
>
 If admin generates two or more OTPs, what is the behavior ?
 All valid or last one valid ?
 Suppose there is two and we consume only first one, in that case does
 it invalidate second one ?

>>>
>>> Why should we allow multiple OTPs for a particular user at a given time
>>> ? Cannot we keep only one valid OTP for a user at a given time and override
>>> it at the point of creating a new one ?
>>>
>>
>> I too have the same concern. What is the idea behind allowing multiple
>> OTPs at any point of time? Isn't the usual practice to keep only the latest
>> OTP active?
>>
>>
>>
>>>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/Wirefr
> ames/admin-portal/v3/3.32%20%20Reset%20password%20with%20off
> line%20OTP%20-%20password%20generated.png
>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>



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


>>>
>>
>> --
>> *A.Farasath Ahamed*
>> Software Engineer | WSO2 Inc.
>> Mobile: +94 777 603 866 <+94%2077%20760%203866>
>> Blog: blog.farazath.com
>> E-Mail: mefaraz...@gmail.com
>>
>>
>> ___
>> 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
>
>


-- 
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/
Email: ga...@wso2.com
Mobile: +94 (71) 8020933
___
Architecture mailing list

Re: [Architecture] [C5][IS 6.0.0] Password History Validation

[Gayan Gunawardana]

Hi Imesh,

On Wed, Mar 15, 2017 at 10:19 AM, Imesh Gunaratne  wrote:

> On Sun, Mar 12, 2017 at 7:44 AM, Gayan Gunawardana  wrote:
>
>>
>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>   USER_UNIQUE_ID   VARCHAR(255) NOT NULL,
>>   SALT_VALUE  VARCHAR(255),
>>   HASHVARCHAR(255) NOT NULL,
>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>   PRIMARY KEY(ID),
>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>> )ENGINE INNODB;
>>
>
> ​Would you mind explaining the purpose of the field SALT_VALUE?
>
In order to compare user given password with stored password salt value is
required.

>
> Thanks
> Imesh
> ​
>
>>
>> Password Hashing algorithm will be a configurable property.
>>
>> [1] [Architecture] Force Password Reset and Password History validation
>>
>> 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
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
> ___
> 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

Re: [Architecture] [C5][IS 6.0.0]Admin Forced Password Reset Via Offline for Existing Users

[Hasanthi Purnima Dissanayake]

Hi All,

Why should we allow multiple OTPs for a particular user at a given time ?
> Cannot we keep only one valid OTP for a user at a given time and override
> it at the point of creating a new one ?


+1. Lets keep only one valid OTP.

How do you plan to access the content in this table from the authentication
> flow.
>
> What I wanted to point is, this OTP is another credential for the user. So
> we should store in a "credential store" which is introduced with new user
> core.
>

It's clear this can be use only one time but  what is the scope of this OTP
> ? is this can only be used to login to user-portal or can this OTP use in
> any other purposes ( an example, say login to generate SAML token in a SSO
> story)
>

Actually in this implementation we have not considered this as a password.
Though we used the word OTP it is kind of a code. By using this code the
user can create a new password but can not login to any portal or can not
perform any task of IS. So this is not actually a credential for the user.

In some cases identity admin need to set validity period on OTP so IMO we
> need to support time based validity.
>


> I too have the same concern. What is the idea behind allowing multiple
> OTPs at any point of time? Isn't the usual practice to keep only the latest
> OTP active?
>

+1. Lets add a time based validity period.

Thanks,




Hasanthi Dissanayake

Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 

On Wed, Mar 15, 2017 at 10:55 PM, Farasath Ahamed 
wrote:

>
>
> On Wednesday, March 15, 2017, Dilan Udara Ariyaratne 
> wrote:
>
>>
>> On Tue, Mar 14, 2017 at 11:08 AM, Gayan Gunawardana 
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 14, 2017 at 10:58 AM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
 Hi all,

 We are in the process of implementing Admin Forced Password Reset via
 Offline for existing users in Admin Portal for the new IS 6.0.0 release.
 The wireframe design for the UI is found at [1].

 Admin can select a user and generate a password for the selected user.
 This generated password is an OTP.

 This OTP is:
 1. Not adhere to any password policy.
 2. There is no validity period
 3. Once this OTP is used it expires.
 4. Not considered like a normal password and we are going to store it
 in IDN_RECOVERY_DATA table.

>>> If admin generates two or more OTPs, what is the behavior ?
>>> All valid or last one valid ?
>>> Suppose there is two and we consume only first one, in that case does it
>>> invalidate second one ?
>>>
>>
>> Why should we allow multiple OTPs for a particular user at a given time ?
>> Cannot we keep only one valid OTP for a user at a given time and override
>> it at the point of creating a new one ?
>>
>
> I too have the same concern. What is the idea behind allowing multiple
> OTPs at any point of time? Isn't the usual practice to keep only the latest
> OTP active?
>
>
>
>>
 [1] https://github.com/wso2-dev-ux/product-is/blob/master/Wirefr
 ames/admin-portal/v3/3.32%20%20Reset%20password%20with%20off
 line%20OTP%20-%20password%20generated.png

 Thanks,

 Hasanthi Dissanayake

 Software Engineer | WSO2

 E: hasan...@wso2.com
 M :0718407133| http://wso2.com 

>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>
> --
> *A.Farasath Ahamed*
> Software Engineer | WSO2 Inc.
> Mobile: +94 777 603 866 <+94%2077%20760%203866>
> Blog: blog.farazath.com
> E-Mail: mefaraz...@gmail.com
>
>
> ___
> 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] [IoT] Android SDK for developers

[Ruwan Yatawara]

Yes, this should be a generic API. Plus, the more than calling the last
segment, communication API, it should be quoted configuration API, as
communication protocol, in reality is just a configuration given that said
configuration is supported.

Thanks and Regards,

Ruwan Yatawara

Associate Technical Lead,
WSO2 Inc.

email : ruw...@wso2.com
mobile : +94 77 9110413
blog :  http://ruwansrants.blogspot.com/

https://500px.com/ruwan_ace
https://medium.com/@ruwanyatawara

www: :http://wso2.com


On Thu, Mar 16, 2017 at 9:07 AM, Sumedha Rubasinghe 
wrote:

> Why this has to be special for Android? It's the generic API we provide
> from IoT Server. And current API has part of this functionality. Isn't it?
>
> On Thu, Mar 16, 2017 at 8:59 AM, Inosh Perera  wrote:
>
>> Hi All,
>>
>> Based on Charitha's suggestion to have an SDK for developers, I would
>> suggest we have the following high level APIs made available for developers
>> as an Android SDK. This will contain functionalities of the existing
>> Android agent and it can be utilized to build agent's faster for different
>> types of Android devices such as TVs or wearables.
>>
>> Enrollment API
>> This will provide Oauth based and mutual SSL based authentication flows
>> OOB including UIs where the developer simply need to call the needed flow
>> and and can get a device enrolled. This flow should also facilitate
>> plugging in any new authentication flows, so that if the developer need a
>> different authentication mechanism, it can be facilitated.
>>
>> Device API
>> This will simply provide access to different SDKs methods in Android so
>> that the developer doesn't need to deal with for example location services
>> to get the current location. This may also include sensor data querying.
>>
>> Application API
>> This API provides capabilities to handle application management related
>> tasks such as app installs, uninstall, updates and get application related
>> information on device.
>>
>> Policy API
>> This will provide policy enforcement and policy monitoring related APIs.
>> When a policy enforcement request comes from the server, relevant policy
>> API must be called to enforce it and the monitoring API provides ability to
>> check if the enforced policy is adhered by the device.
>>
>> Operation API
>> This will have APIs necessery to schedule polling the server to get
>> operations to be executed and and a default implementation of an operation
>> manager which talks to different APIs such as device API, Application API
>> or policy API based on the operations received from the server.
>>
>> Communication API
>> This will provide different communication methods such as Http, mqtt or
>> listeners for FCM. API should provide mechanism to plugin any user needed
>> protocols to communicate with the IoT server. This API will also provide
>> means to talk to other applications such as system application or App
>> catalog application which are already available.
>>
>> This is a basic high level API view. Please provide your suggestions.
>>
>> Regards,
>> Inosh
>>
>>
>> --
>> Inosh Perera
>> Senior Software Engineer, WSO2 Inc.
>> Tel: 077813 7285, 0785293686 <078%20529%203686>
>>
>
>
>
> --
> /sumedha
> m: +94 773017743 <077%20301%207743>
> b :  bit.ly/sumedha
>
> ___
> 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] [IoT] Android SDK for developers

[Sumedha Rubasinghe]

Why this has to be special for Android? It's the generic API we provide
from IoT Server. And current API has part of this functionality. Isn't it?

On Thu, Mar 16, 2017 at 8:59 AM, Inosh Perera  wrote:

> Hi All,
>
> Based on Charitha's suggestion to have an SDK for developers, I would
> suggest we have the following high level APIs made available for developers
> as an Android SDK. This will contain functionalities of the existing
> Android agent and it can be utilized to build agent's faster for different
> types of Android devices such as TVs or wearables.
>
> Enrollment API
> This will provide Oauth based and mutual SSL based authentication flows
> OOB including UIs where the developer simply need to call the needed flow
> and and can get a device enrolled. This flow should also facilitate
> plugging in any new authentication flows, so that if the developer need a
> different authentication mechanism, it can be facilitated.
>
> Device API
> This will simply provide access to different SDKs methods in Android so
> that the developer doesn't need to deal with for example location services
> to get the current location. This may also include sensor data querying.
>
> Application API
> This API provides capabilities to handle application management related
> tasks such as app installs, uninstall, updates and get application related
> information on device.
>
> Policy API
> This will provide policy enforcement and policy monitoring related APIs.
> When a policy enforcement request comes from the server, relevant policy
> API must be called to enforce it and the monitoring API provides ability to
> check if the enforced policy is adhered by the device.
>
> Operation API
> This will have APIs necessery to schedule polling the server to get
> operations to be executed and and a default implementation of an operation
> manager which talks to different APIs such as device API, Application API
> or policy API based on the operations received from the server.
>
> Communication API
> This will provide different communication methods such as Http, mqtt or
> listeners for FCM. API should provide mechanism to plugin any user needed
> protocols to communicate with the IoT server. This API will also provide
> means to talk to other applications such as system application or App
> catalog application which are already available.
>
> This is a basic high level API view. Please provide your suggestions.
>
> Regards,
> Inosh
>
>
> --
> Inosh Perera
> Senior Software Engineer, WSO2 Inc.
> Tel: 077813 7285, 0785293686 <078%20529%203686>
>



-- 
/sumedha
m: +94 773017743
b :  bit.ly/sumedha
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IoT] Android SDK for developers

[Inosh Perera]

Hi All,

Based on Charitha's suggestion to have an SDK for developers, I would
suggest we have the following high level APIs made available for developers
as an Android SDK. This will contain functionalities of the existing
Android agent and it can be utilized to build agent's faster for different
types of Android devices such as TVs or wearables.

Enrollment API
This will provide Oauth based and mutual SSL based authentication flows OOB
including UIs where the developer simply need to call the needed flow and
and can get a device enrolled. This flow should also facilitate plugging in
any new authentication flows, so that if the developer need a different
authentication mechanism, it can be facilitated.

Device API
This will simply provide access to different SDKs methods in Android so
that the developer doesn't need to deal with for example location services
to get the current location. This may also include sensor data querying.

Application API
This API provides capabilities to handle application management related
tasks such as app installs, uninstall, updates and get application related
information on device.

Policy API
This will provide policy enforcement and policy monitoring related APIs.
When a policy enforcement request comes from the server, relevant policy
API must be called to enforce it and the monitoring API provides ability to
check if the enforced policy is adhered by the device.

Operation API
This will have APIs necessery to schedule polling the server to get
operations to be executed and and a default implementation of an operation
manager which talks to different APIs such as device API, Application API
or policy API based on the operations received from the server.

Communication API
This will provide different communication methods such as Http, mqtt or
listeners for FCM. API should provide mechanism to plugin any user needed
protocols to communicate with the IoT server. This API will also provide
means to talk to other applications such as system application or App
catalog application which are already available.

This is a basic high level API view. Please provide your suggestions.

Regards,
Inosh


-- 
Inosh Perera
Senior Software Engineer, WSO2 Inc.
Tel: 077813 7285, 0785293686
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [C5][IS 6.0.0] Add and Update Group UI for IS 6.0.0

[Pushpalanka Jayawardhana]

Hi All,

I am working on implementing 'add group' and 'update group' UIs for IS
6.0.0 as per the wire-frames [1] and [2].

In group addition, user experience will be as, in the 'General' tab user
provides name and description of the role.
User can either conclude the group addition flow here or go to 'Users' tab
to select users who will be in this group.
User can either conclude the flow here or go to 'Roles' tab to select the
roles to be assigned to all the users in the newly added group.

Same goes with the update flow.

Claims will be defined for the group, to keep track of the attributes of
the group, such as group description.
Any thoughts are welcome to improve the flow or design.

[1] -
https://github.com/wso2-dev-ux/product-is/blob/master/Wireframes/admin-portal/v3/4.2%20Add%20group%20-%20general%20info.png
[2] -
https://github.com/wso2-dev-ux/product-is/blob/master/Wireframes/admin-portal/v3/4.8%20Edit%20group%20-%20general%20info.png

Thanks,
-- 
Pushpalanka.
-- 
Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
Mobile: +94779716248
Blog: pushpalankajaya.blogspot.com/ | LinkedIn:
lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] User List UI for IS 6.0.0

[Omindu Rathnaweera]

Hi Nuwandi,

On Tue, Mar 14, 2017 at 10:28 AM, Nuwandi Wickramasinghe 
wrote:

> Hi all,
>
> We are in the process of implementing User List view in the Admin Portal
> for the new IS 6.0.0 release. The wireframe design for the UI is found at
> [1].
>
> Admin can view a list of users and perform actions such as Delete, Edit
> and request to Reset Password. Also admin can select multiple users and
> chose to Delete, Disable or Activate. There will be an option to filter the
> list according to the user attributes.
>

Is there a 'Select All' option in the UI ? If not it's better to give that
option. The 'Select All' functionality should select all the users on the
'current' page.

Also, in multiple user selections, we should not lose previous selections
when navigating to a different page.


>
> I am planning to add an admin profile in profile-mapping.yaml file where
> an admin can define what user attributes to be shown in the list.
>
> According to the wireframe ([1]), we have to give the flexibility to show
> Groups and Roles of the users. ATM we do not have claim definitions for
> Groups and Roles. Therefore we won't be able to handle them with an
> attribute profile. As per the offline chat with Johann we might define
> Claim URIs for Groups and Roles in future since there will be other use
> cases where we need to treat them as user attributes (eg. SAML attribute
> profile). Also loading all the Roles and Groups for each user in the list
> will highly effect the initial loading time. May be we can filter out to
> maximum number (say 3) of records and request all if one wants to see more
> roles/groups.
>
> However for the immediate release (m5) I guess it is ok not to have Roles
> and Groups in the User List view. We did not have that in IS 5.3.0 as well
> so I hope this is not a critical requirement. We will keep the wireframe as
> it is since we are planning to improve things in the future.
>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.19%20User%20Listing.png
>
> thanks
> Nuwandi
> --
>
> Best Regards,
>
> Nuwandi Wickramasinghe
>
> Software Engineer
>
> WSO2 Inc.
>
> Web : http://wso2.com
>
> Mobile : 0719214873
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

Regards,
Omindu.

-- 
Omindu Rathnaweera
Software Engineer, WSO2 Inc.
Mobile: +94 771 197 211
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0]Admin Forced Password Reset Via Offline for Existing Users

[Farasath Ahamed]

On Wednesday, March 15, 2017, Dilan Udara Ariyaratne 
wrote:

>
> On Tue, Mar 14, 2017 at 11:08 AM, Gayan Gunawardana  > wrote:
>
>>
>>
>> On Tue, Mar 14, 2017 at 10:58 AM, Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com >
>> wrote:
>>
>>> Hi all,
>>>
>>> We are in the process of implementing Admin Forced Password Reset via
>>> Offline for existing users in Admin Portal for the new IS 6.0.0 release.
>>> The wireframe design for the UI is found at [1].
>>>
>>> Admin can select a user and generate a password for the selected user.
>>> This generated password is an OTP.
>>>
>>> This OTP is:
>>> 1. Not adhere to any password policy.
>>> 2. There is no validity period
>>> 3. Once this OTP is used it expires.
>>> 4. Not considered like a normal password and we are going to store it in
>>> IDN_RECOVERY_DATA table.
>>>
>> If admin generates two or more OTPs, what is the behavior ?
>> All valid or last one valid ?
>> Suppose there is two and we consume only first one, in that case does it
>> invalidate second one ?
>>
>
> Why should we allow multiple OTPs for a particular user at a given time ?
> Cannot we keep only one valid OTP for a user at a given time and override
> it at the point of creating a new one ?
>

I too have the same concern. What is the idea behind allowing multiple OTPs
at any point of time? Isn't the usual practice to keep only the latest OTP
active?



>
>>> [1] https://github.com/wso2-dev-ux/product-is/blob/master/Wirefr
>>> ames/admin-portal/v3/3.32%20%20Reset%20password%20with%20off
>>> line%20OTP%20-%20password%20generated.png
>>>
>>> Thanks,
>>>
>>> Hasanthi Dissanayake
>>>
>>> Software Engineer | WSO2
>>>
>>> E: hasan...@wso2.com 
>>> M :0718407133| http://wso2.com 
>>>
>>
>>
>>
>> --
>> 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
>>
>>
>

-- 
*A.Farasath Ahamed*
Software Engineer | WSO2 Inc.
Mobile: +94 777 603 866
Blog: blog.farazath.com
E-Mail: mefaraz...@gmail.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0]Admin Forced Password Reset Via Offline for Existing Users

[Sagara Gunathunga]

On Wed, Mar 15, 2017 at 8:37 PM, Darshana Gunawardana 
wrote:

>
> On Tue, Mar 14, 2017 at 10:58 AM Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi all,
>>
>> We are in the process of implementing Admin Forced Password Reset via
>> Offline for existing users in Admin Portal for the new IS 6.0.0 release.
>> The wireframe design for the UI is found at [1].
>>
>> Admin can select a user and generate a password for the selected user.
>> This generated password is an OTP.
>>
>> This OTP is:
>>
>
It's clear this can be use only one time but  what is the scope of this OTP
? is this can only be used to login to user-portal or can this OTP use in
any other purposes ( an example, say login to generate SAML token in a SSO
story)



> 1. Not adhere to any password policy.
>>
>
Thinking in customer POV can we assume above constrain ?


> 2. There is no validity period
>>
>
In some cases identity admin need to set validity period on OTP so IMO we
need to support time based validity.


> 3. Once this OTP is used it expires.
>> 4. Not considered like a normal password and we are going to store it in
>> IDN_RECOVERY_DATA table.
>>
>
> How do you plan to access the content in this table from the
> authentication flow.
>
> What I wanted to point is, this OTP is another credential for the user. So
> we should store in a "credential store" which is introduced with new user
> core.
>

+1 given the fact that we have specially designed credential store we
should use it store any user related credentials.


Thanks !


>
>
>>
>> [1] https://github.com/wso2-dev-ux/product-is/blob/master/
>> Wireframes/admin-portal/v3/3.32%20%20Reset%20password%
>> 20with%20offline%20OTP%20-%20password%20generated.png
>>
>> Thanks,
>>
>> Hasanthi Dissanayake
>>
>> Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
> --
> Regards,
>
>
> *Darshana Gunawardana*Associate Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com *
> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
> Middleware
>



-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] User List UI for IS 6.0.0

[Dilan Udara Ariyaratne]

On Tue, Mar 14, 2017 at 10:28 AM, Nuwandi Wickramasinghe 
wrote:

> Hi all,
>
> We are in the process of implementing User List view in the Admin Portal
> for the new IS 6.0.0 release. The wireframe design for the UI is found at
> [1].
>
> Admin can view a list of users and perform actions such as Delete, Edit
> and request to Reset Password. Also admin can select multiple users and
> chose to Delete, Disable or Activate. There will be an option to filter the
> list according to the user attributes.
>
> I am planning to add an admin profile in profile-mapping.yaml file where
> an admin can define what user attributes to be shown in the list.
>
> According to the wireframe ([1]), we have to give the flexibility to show
> Groups and Roles of the users. ATM we do not have claim definitions for
> Groups and Roles. Therefore we won't be able to handle them with an
> attribute profile. As per the offline chat with Johann we might define
> Claim URIs for Groups and Roles in future since there will be other use
> cases where we need to treat them as user attributes (eg. SAML attribute
> profile). Also loading all the Roles and Groups for each user in the list
> will highly effect the initial loading time. May be we can filter out to
> maximum number (say 3) of records and request all if one wants to see more
> roles/groups.
>

For a list view, we can always limit what we are showing per row to the
most essential. It's not required to fetch and show all the data, for ex:
in here, we can omit showing roles / groups and focus on other primary data
suitable for an overview of the user. And from the list view, when someone
wants to get into a more detailed look of a user, we can always direct him
for that using a link to a separate, detailed page view of a user.

>
> However for the immediate release (m5) I guess it is ok not to have Roles
> and Groups in the User List view. We did not have that in IS 5.3.0 as well
> so I hope this is not a critical requirement. We will keep the wireframe as
> it is since we are planning to improve things in the future.
>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.19%20User%20Listing.png
>
> thanks
> Nuwandi
> --
>
> Best Regards,
>
> Nuwandi Wickramasinghe
>
> Software Engineer
>
> WSO2 Inc.
>
> Web : http://wso2.com
>
> Mobile : 0719214873
>
> ___
> 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] [C5][IS 6.0.0]Admin Forced Password Reset Via Offline for Existing Users

[Darshana Gunawardana]

On Tue, Mar 14, 2017 at 10:58 AM Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi all,
>
> We are in the process of implementing Admin Forced Password Reset via
> Offline for existing users in Admin Portal for the new IS 6.0.0 release.
> The wireframe design for the UI is found at [1].
>
> Admin can select a user and generate a password for the selected user.
> This generated password is an OTP.
>
> This OTP is:
> 1. Not adhere to any password policy.
> 2. There is no validity period
> 3. Once this OTP is used it expires.
> 4. Not considered like a normal password and we are going to store it in
> IDN_RECOVERY_DATA table.
>

How do you plan to access the content in this table from the authentication
flow.

What I wanted to point is, this OTP is another credential for the user. So
we should store in a "credential store" which is introduced with new user
core.


>
> [1]
> https://github.com/wso2-dev-ux/product-is/blob/master/Wireframes/admin-portal/v3/3.32%20%20Reset%20password%20with%20offline%20OTP%20-%20password%20generated.png
>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>
-- 
Regards,


*Darshana Gunawardana*Associate Technical Lead
WSO2 Inc.; http://wso2.com

*E-mail: darsh...@wso2.com *
*Mobile: +94718566859*Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0]Admin Forced Password Reset Via Offline for Existing Users

[Dilan Udara Ariyaratne]

On Tue, Mar 14, 2017 at 11:08 AM, Gayan Gunawardana  wrote:

>
>
> On Tue, Mar 14, 2017 at 10:58 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi all,
>>
>> We are in the process of implementing Admin Forced Password Reset via
>> Offline for existing users in Admin Portal for the new IS 6.0.0 release.
>> The wireframe design for the UI is found at [1].
>>
>> Admin can select a user and generate a password for the selected user.
>> This generated password is an OTP.
>>
>> This OTP is:
>> 1. Not adhere to any password policy.
>> 2. There is no validity period
>> 3. Once this OTP is used it expires.
>> 4. Not considered like a normal password and we are going to store it in
>> IDN_RECOVERY_DATA table.
>>
> If admin generates two or more OTPs, what is the behavior ?
> All valid or last one valid ?
> Suppose there is two and we consume only first one, in that case does it
> invalidate second one ?
>

Why should we allow multiple OTPs for a particular user at a given time ?
Cannot we keep only one valid OTP for a user at a given time and override
it at the point of creating a new one ?

>
>> [1] https://github.com/wso2-dev-ux/product-is/blob/master/Wirefr
>> ames/admin-portal/v3/3.32%20%20Reset%20password%20with%
>> 20offline%20OTP%20-%20password%20generated.png
>>
>> Thanks,
>>
>> Hasanthi Dissanayake
>>
>> Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>
>
>
> --
> 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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Password History Validation

[Dilan Udara Ariyaratne]

On Mon, Mar 13, 2017 at 5:00 PM, Omindu Rathnaweera  wrote:

> Hi,
>
> On Sun, Mar 12, 2017 at 7:59 AM, Ruwan Abeykoon  wrote:
>
>> Hi All,
>> Can the hash algorithm change over the time?
>> If so we need to record the hash algorithm used to do hashing along with
>> the particular password history record. We need to use the particular
>> algorithm to do the comparison, not the system configured one.
>>
>
> In addition to the hashing algo, we should store the key length and the
> iteration count. We have given the option to configure these properties for
> the credential stores and we should do the same for password history
> management. Since we are storing the current password in the history table,
> the hashing mechanism should be similar to that of the credential stores.
>

Will the hashing mechanism (i.e. algorithm, key length, iteration count) be
same for all hashing algorithms ?
In that case, How do we handle such a scenario in storing hashing mechanism
related data in database ? When hashing mechanisms differ from one another,
we will definitely not be able to have a fixed column structure in the
table.

>
> Regards,
> Omindu.
>
>
>>
>> Cheers,
>> Ruwan
>>
>>
>> On Sun, Mar 12, 2017 at 7:44 AM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are in the process of implementing password history validation
>>> feature for IS 6.0.0. Architecture of this feature was previously discussed
>>> in [1] by Isura for IS 5.3.0. We plan to follow same architecture with
>>> minor changes.
>>>
>>> Previously history validation has been done by checking only last 'n'
>>> number of attempts. Ex. you cannot use a password which is inside last 5
>>> attempts. This time we additionally validate time factor as well Ex. you
>>> cannot use a password, if there is a similar password with created date
>>> inside last 7days.
>>>
>>> Table structure will be changed as below since we have unique user ID in
>>> C5.
>>>
>>> *Previous *
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>   USER_NAME   VARCHAR(255) NOT NULL,
>>>   USER_DOMAIN VARCHAR(127) NOT NULL,
>>>   TENANT_ID   INTEGER DEFAULT -1,
>>>   SALT_VALUE  VARCHAR(255),
>>>   HASHVARCHAR(255) NOT NULL,
>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>   PRIMARY KEY(ID),
>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>> )ENGINE INNODB;
>>>
>>>
>>> *New *
>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>   USER_UNIQUE_ID   VARCHAR(255) NOT NULL,
>>>   SALT_VALUE  VARCHAR(255),
>>>   HASHVARCHAR(255) NOT NULL,
>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>   PRIMARY KEY(ID),
>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>> )ENGINE INNODB;
>>>
>>> Password Hashing algorithm will be a configurable property.
>>>
>>> [1] [Architecture] Force Password Reset and Password History validation
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>>
>> *Ruwan Abeykoon*
>> *Associate Director/Architect**,*
>> *WSO2, Inc. http://wso2.com  *
>> *lean.enterprise.middleware.*
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Omindu Rathnaweera
> Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>
> ___
> 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] [APIM 3.0.0][C5] Permission model : Visibility and subscription availability

[Shani Ranasinghe]

On Wed, Mar 15, 2017 at 11:29 AM, Lakmal Warusawithana 
wrote:

>
>
> On Wed, Mar 15, 2017 at 10:47 AM, Pubudu Gunatilaka 
> wrote:
>
>> Hi,
>>
>> Based on the recent queries we got, users try to bring the tenancy model
>> for managing APIs. For an example there can be two developers who create
>> APIs for two departments such as marketing and engineering. Basic idea is
>> that those APIs are only visible for particular group in store which we can
>> achieve. On the other hand same thing is expected in publisher side as well.
>>
>
> I think we can achieve what you mention easy with permission model what
> described in this thread.
>

 but Lakmal, lets say we have a scenario where API development can be given
to multiple departments. so , lets say engineering, finance and marketing
develops API's. This aforementioned permission model applies to the
permissions among that group, and if you need to share the API with other
groups right? So what if I am in engineering (lets say in a bank, I am
creating an API to get account details. I do not need to expose API
implementation specific details to anyone outside of my department), I do
not want to expose my API details in the publisher to other departments but
want them to be able to consume the API for their applications? this sort
of requirement can we fulfill using this permission model?

>
>
>
>> Only concern I see here is whether we support this kind of a separation
>> in APIM 3.0.
>>
>> Thank you!
>>
>>
>> On Wed, Mar 15, 2017 at 9:54 AM Roshan Wijesena  wrote:
>>
>>>
>>> On Wed, Mar 15, 2017 at 12:48 AM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
>>> How can we support this by only sticking to the new permission model? We
>>> need to make the API visible in the store side but hide it on the publisher
>>> side(other publisher users).
>>>
>>>
>>> As I understood, your requirement is to hide an API from other
>>> developers in publisher but in the store that should be visible to everyone
>>> is it? In that case, if other publishers log into the store they still can
>>> see other APIs no?
>>>
>>>
>>> --
>>> Roshan Wijesena.
>>> Senior Software Engineer-WSO2 Inc.
>>> Mobile: *+94719154640 <+94%2071%20915%204640>*
>>> Email: ros...@wso2.com
>>> *WSO2, Inc. :** wso2.com *
>>> lean.enterprise.middleware.
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Lakmal Warusawithana
> Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692 <+94%2071%20428%209692>
> Blogs : https://medium.com/@lakwarus/
> http://lakmalsview.blogspot.com/
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks and Regards
*,Shani Ranasinghe*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 77 2273555 <+94%2077%20227%203555>
Blog: http://waysandmeans.blogspot.com/
linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM 3.0.0][C5] Permission model : Visibility and subscription availability

[Lakmal Warusawithana]

On Wed, Mar 15, 2017 at 10:47 AM, Pubudu Gunatilaka 
wrote:

> Hi,
>
> Based on the recent queries we got, users try to bring the tenancy model
> for managing APIs. For an example there can be two developers who create
> APIs for two departments such as marketing and enginnering. Basic idea is
> that those APIs are only visible for particular group in store which we can
> achieve. On the other hand same thing is expected in publisher side as well.
>

I think we can achieve what you mention easy with permission model what
described in this thread.



>
> Only concern I see here is whether we support this kind of a separation in
> APIM 3.0.
>
> Thank you!
>
>
> On Wed, Mar 15, 2017 at 9:54 AM Roshan Wijesena  wrote:
>
>>
>> On Wed, Mar 15, 2017 at 12:48 AM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>> How can we support this by only sticking to the new permission model? We
>> need to make the API visible in the store side but hide it on the publisher
>> side(other publisher users).
>>
>>
>> As I understood, your requirement is to hide an API from other developers
>> in publisher but in the store that should be visible to everyone is it? In
>> that case, if other publishers log into the store they still can see other
>> APIs no?
>>
>>
>> --
>> Roshan Wijesena.
>> Senior Software Engineer-WSO2 Inc.
>> Mobile: *+94719154640 <+94%2071%20915%204640>*
>> Email: ros...@wso2.com
>> *WSO2, Inc. :** wso2.com *
>> lean.enterprise.middleware.
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blogs : https://medium.com/@lakwarus/
http://lakmalsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture