Re: [Architecture] [architecture ] [IS-5.3.0] Admin forces password reset for user

[Manjula Rathnayake]

Hi all,

It is not clear to me how password reset operation is valid for
read-only user stores. is it a valid use case?

thank you.

On Tue, Oct 4, 2016 at 10:54 AM, Dimuthu Leelarathne 
wrote:

> Hi Johann,
>
> Lets take the read-only case. Our current or future (C5) architecture does
> not support claims coming from two user stores. And that is ok. But ... we
> have this habbit of adding a claim whenever we want to do a new feature, is
> it a good idea to store system claim values in the internal DB? That would
> make things much simpler. Thinking aloud, we can make it generic and enable
> half the stuff to come from internal store, but I think it is a over
> engineering task. IMO, if we can implement such that system claim values
> are coming from internal DB that would be great.
>
> thanks,
> Dimuthu
>
>
> On Mon, Oct 3, 2016 at 10:51 PM, Johann Nallathamby 
> wrote:
>
>>
>>
>> On Mon, Oct 3, 2016 at 1:00 PM, Manjula Rathnayake 
>> wrote:
>>
>>> Hi Ayesha,
>>>
>>> On Fri, Sep 30, 2016 at 3:17 PM, Ayesha Dissanayaka 
>>> wrote:
>>>
 Hi all,

 Based on the discussions with Johann, Darshana, Isura and myself, we
 identified following use cases and design concerns.

 There are three cases of Admin Forced Password Reset action,

- Admin Forced Password Reset Off-line
- Admin knows the password and give it to user offline(ex: via
   phone)
   - Admin Forced Password Reset via OTP
   - OTP is sent to user as a notifications(email/sms). Admin may
   not able see the OTP
   - Admin Forced Password Reset via Recovery Email
   - Email with a link which directs to password recovery portal is
   sent to user

 For each case above, Admin Forced Password Reset action trigger is
 identifies as a claim update.

 When a special claim "http://wso2.org/claims/identi
 ty/adminForcedPasswordReset" is updated, an EventHandler will handle
 the update to this particular claim.

>>> Do we know claims/attritubes used in LDAP schemas for similar purposes?
>>> I assume, we ask the user to map above claim to any LDAP attribute.
>>>
>>
>> We make it a point to use existing attributes wherever possible. I think
>> there is a attribute in AD called "ChangePasswordAtLogon" for this purpose.
>> However we didn't plan to use this attribute to store this value as a claim
>> because its a temporary value for a particular user. Also all LDAPs may not
>> support this attribute. Plus we need to support it when the user store is
>> connected in read-only mode also. However we will reconsider this.
>>
>>> New governance Connector will be implemented and above three cases can
 be enable/disable based on system requirements.

>>> Is there any document, code which discuss about governance connector?
>>>
>>> thank you.
>>>
 Within the EventHandler, a RecoveryScenario is set to identify the
 admin forced password reset activity. And user account will be locked until
 password reset by user.

 At the login, inside Login Authenticator it will look at RecoveryScenario
 along with OTP provided in order to prompt password reset option to the
 user. Once the password is reset by user, account will be unlocked and 
 RecoveryScenario
 entry will be cleaned-up.

 For the MVP1, I am implementing handling *Admin Forced Password Reset*
 trigger with claim update and Handler to send an email with password reset
 link to user.

 Thanks!
 -Ayesha


 On Wed, Sep 28, 2016 at 12:19 PM, Ayesha Dissanayaka 
 wrote:

> Hi Ishara,
>
> Thank you for the input. Having similar discussion with Darshana and
> Isura, I have started extending askPassword implementation with email
> verification flow in order trigger a password reset by capturing "update
> credential" event. Still, we need a mechanism to distinguish admin 
> password
> reset vs. user password reset.
>
> Thanks!
> -Ayesha
>
>
> On Wed, Sep 28, 2016 at 12:06 PM, Ishara Karunarathna <
> isha...@wso2.com> wrote:
>
>> Hi Ayesha,
>>
>> On Tue, Sep 27, 2016 at 11:00 AM, Isura Karunaratne 
>> wrote:
>>
>>> Hi Ayesha,
>>>
>>> We can extend Ask Password feature we developed in IS 5.3.0 to
>>> support this feature. So, we can send a confirmation email rather than 
>>> an
>>> OTP.
>>>
>> There can be different user cases.
>> If we think about a call center scenario then customer will call to
>> support center and asked to reset the password and will communicate that 
>> to
>> the client that time, then use can login and 1st attempt he need to reset
>> the password.
>> Then we can set an additional flag to user attribute that indicate
>> that this password 

[Architecture] Few thoughts about IoT Analytics Pre Cooked Scenarios

[Srinath Perera]

Hi All,

Wanted to add some thoughts to my earlier blog

https://iwringer.wordpress.com/2015/10/15/thinking-deeply-about-iot-analytics/

Most IoT platform place a CEP engine in the center and a Batch engine (
which Forester called Data Historian), which we have.

However, as we discussed there are things such as Geo Dashboard that we can
provide on top of CEP/ DAS that make the user's life easier. Here I do not
mean to build a UI experience, rather documenting in detail in user guide (
and link from sites) how to do them and implement any gaps.

Following are few things that I thought of.


   1. Geo Dashboard ( this is mostly done I think)
   2. Anomaly Detection ( Seshi's work, most techniques has be tried out)
   3. Predictive Maintenance ( Roshan (intern) has done a full use case
   using a NASA data set which has given very good results, and I believe it
   can be generalized easily)
   4. Spatio-temporal analytics
  - Forecasts - this is what we did for TFL forecasts
  - Adding temporal support for Geo Dashboard so views can be replayed
   5. Out of order processing  ( regardless of what you do, events from
   sensors will come out of order, and you must processed based on event time
   nor arrival time). Miyuru had some a reordering operator already and there
   is an intern project to more complex algorithms)
   6. Ability to redefine streams ( this is a TODO, simple things supported
   via Siddhi language)
   7. Support for current Context ( we can build on Gopinath's paper, but
   will need more work)

I believe users will want to each of above, and we should document
concretely how to do them and fill any gaps.

Please comment. Happy to explain, defend as always

--Srinath




-- 

Srinath Perera, Ph.D.
   http://people.apache.org/~hemapani/
   http://srinathsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [architecture ] [IS-5.3.0] Admin forces password reset for user

[Dimuthu Leelarathne]

Hi Johann,

Lets take the read-only case. Our current or future (C5) architecture does
not support claims coming from two user stores. And that is ok. But ... we
have this habbit of adding a claim whenever we want to do a new feature, is
it a good idea to store system claim values in the internal DB? That would
make things much simpler. Thinking aloud, we can make it generic and enable
half the stuff to come from internal store, but I think it is a over
engineering task. IMO, if we can implement such that system claim values
are coming from internal DB that would be great.

thanks,
Dimuthu


On Mon, Oct 3, 2016 at 10:51 PM, Johann Nallathamby  wrote:

>
>
> On Mon, Oct 3, 2016 at 1:00 PM, Manjula Rathnayake 
> wrote:
>
>> Hi Ayesha,
>>
>> On Fri, Sep 30, 2016 at 3:17 PM, Ayesha Dissanayaka 
>> wrote:
>>
>>> Hi all,
>>>
>>> Based on the discussions with Johann, Darshana, Isura and myself, we
>>> identified following use cases and design concerns.
>>>
>>> There are three cases of Admin Forced Password Reset action,
>>>
>>>- Admin Forced Password Reset Off-line
>>>- Admin knows the password and give it to user offline(ex: via phone)
>>>   - Admin Forced Password Reset via OTP
>>>   - OTP is sent to user as a notifications(email/sms). Admin may
>>>   not able see the OTP
>>>   - Admin Forced Password Reset via Recovery Email
>>>   - Email with a link which directs to password recovery portal is
>>>   sent to user
>>>
>>> For each case above, Admin Forced Password Reset action trigger is
>>> identifies as a claim update.
>>>
>>> When a special claim "http://wso2.org/claims/identi
>>> ty/adminForcedPasswordReset" is updated, an EventHandler will handle
>>> the update to this particular claim.
>>>
>> Do we know claims/attritubes used in LDAP schemas for similar purposes? I
>> assume, we ask the user to map above claim to any LDAP attribute.
>>
>
> We make it a point to use existing attributes wherever possible. I think
> there is a attribute in AD called "ChangePasswordAtLogon" for this purpose.
> However we didn't plan to use this attribute to store this value as a claim
> because its a temporary value for a particular user. Also all LDAPs may not
> support this attribute. Plus we need to support it when the user store is
> connected in read-only mode also. However we will reconsider this.
>
>> New governance Connector will be implemented and above three cases can be
>>> enable/disable based on system requirements.
>>>
>> Is there any document, code which discuss about governance connector?
>>
>> thank you.
>>
>>> Within the EventHandler, a RecoveryScenario is set to identify the admin
>>> forced password reset activity. And user account will be locked until
>>> password reset by user.
>>>
>>> At the login, inside Login Authenticator it will look at RecoveryScenario
>>> along with OTP provided in order to prompt password reset option to the
>>> user. Once the password is reset by user, account will be unlocked and 
>>> RecoveryScenario
>>> entry will be cleaned-up.
>>>
>>> For the MVP1, I am implementing handling *Admin Forced Password Reset*
>>> trigger with claim update and Handler to send an email with password reset
>>> link to user.
>>>
>>> Thanks!
>>> -Ayesha
>>>
>>>
>>> On Wed, Sep 28, 2016 at 12:19 PM, Ayesha Dissanayaka 
>>> wrote:
>>>
 Hi Ishara,

 Thank you for the input. Having similar discussion with Darshana and
 Isura, I have started extending askPassword implementation with email
 verification flow in order trigger a password reset by capturing "update
 credential" event. Still, we need a mechanism to distinguish admin password
 reset vs. user password reset.

 Thanks!
 -Ayesha


 On Wed, Sep 28, 2016 at 12:06 PM, Ishara Karunarathna  wrote:

> Hi Ayesha,
>
> On Tue, Sep 27, 2016 at 11:00 AM, Isura Karunaratne 
> wrote:
>
>> Hi Ayesha,
>>
>> We can extend Ask Password feature we developed in IS 5.3.0 to
>> support this feature. So, we can send a confirmation email rather than an
>> OTP.
>>
> There can be different user cases.
> If we think about a call center scenario then customer will call to
> support center and asked to reset the password and will communicate that 
> to
> the client that time, then use can login and 1st attempt he need to reset
> the password.
> Then we can set an additional flag to user attribute that indicate
> that this password reset by admin.
> And then this can be checked in Password Policy Authenticator.
>
> And secured way to handle this extending Ask password implementation
> and send a email and rest the password. or send a OTP to customer and
> enforce to rest in 1st login.
> I think better to implement the 1st scenario and extent to these cases.
>
> Thanks,
> 

Re: [Architecture] [architecture ] [IS-5.3.0] Admin forces password reset for user

[Johann Nallathamby]

On Mon, Oct 3, 2016 at 1:00 PM, Manjula Rathnayake 
wrote:

> Hi Ayesha,
>
> On Fri, Sep 30, 2016 at 3:17 PM, Ayesha Dissanayaka 
> wrote:
>
>> Hi all,
>>
>> Based on the discussions with Johann, Darshana, Isura and myself, we
>> identified following use cases and design concerns.
>>
>> There are three cases of Admin Forced Password Reset action,
>>
>>- Admin Forced Password Reset Off-line
>>- Admin knows the password and give it to user offline(ex: via phone)
>>   - Admin Forced Password Reset via OTP
>>   - OTP is sent to user as a notifications(email/sms). Admin may not
>>   able see the OTP
>>   - Admin Forced Password Reset via Recovery Email
>>   - Email with a link which directs to password recovery portal is
>>   sent to user
>>
>> For each case above, Admin Forced Password Reset action trigger is
>> identifies as a claim update.
>>
>> When a special claim "http://wso2.org/claims/identi
>> ty/adminForcedPasswordReset" is updated, an EventHandler will handle the
>> update to this particular claim.
>>
> Do we know claims/attritubes used in LDAP schemas for similar purposes? I
> assume, we ask the user to map above claim to any LDAP attribute.
>

We make it a point to use existing attributes wherever possible. I think
there is a attribute in AD called "ChangePasswordAtLogon" for this purpose.
However we didn't plan to use this attribute to store this value as a claim
because its a temporary value for a particular user. Also all LDAPs may not
support this attribute. Plus we need to support it when the user store is
connected in read-only mode also. However we will reconsider this.

> New governance Connector will be implemented and above three cases can be
>> enable/disable based on system requirements.
>>
> Is there any document, code which discuss about governance connector?
>
> thank you.
>
>> Within the EventHandler, a RecoveryScenario is set to identify the admin
>> forced password reset activity. And user account will be locked until
>> password reset by user.
>>
>> At the login, inside Login Authenticator it will look at RecoveryScenario
>> along with OTP provided in order to prompt password reset option to the
>> user. Once the password is reset by user, account will be unlocked and 
>> RecoveryScenario
>> entry will be cleaned-up.
>>
>> For the MVP1, I am implementing handling *Admin Forced Password Reset*
>> trigger with claim update and Handler to send an email with password reset
>> link to user.
>>
>> Thanks!
>> -Ayesha
>>
>>
>> On Wed, Sep 28, 2016 at 12:19 PM, Ayesha Dissanayaka 
>> wrote:
>>
>>> Hi Ishara,
>>>
>>> Thank you for the input. Having similar discussion with Darshana and
>>> Isura, I have started extending askPassword implementation with email
>>> verification flow in order trigger a password reset by capturing "update
>>> credential" event. Still, we need a mechanism to distinguish admin password
>>> reset vs. user password reset.
>>>
>>> Thanks!
>>> -Ayesha
>>>
>>>
>>> On Wed, Sep 28, 2016 at 12:06 PM, Ishara Karunarathna 
>>> wrote:
>>>
 Hi Ayesha,

 On Tue, Sep 27, 2016 at 11:00 AM, Isura Karunaratne 
 wrote:

> Hi Ayesha,
>
> We can extend Ask Password feature we developed in IS 5.3.0 to support
> this feature. So, we can send a confirmation email rather than an OTP.
>
 There can be different user cases.
 If we think about a call center scenario then customer will call to
 support center and asked to reset the password and will communicate that to
 the client that time, then use can login and 1st attempt he need to reset
 the password.
 Then we can set an additional flag to user attribute that indicate that
 this password reset by admin.
 And then this can be checked in Password Policy Authenticator.

 And secured way to handle this extending Ask password implementation
 and send a email and rest the password. or send a OTP to customer and
 enforce to rest in 1st login.
 I think better to implement the 1st scenario and extent to these cases.

 Thanks,
 Ishara

>
> Thanks
> Isura
>
>
> *Isura Dilhara Karunaratne*
> Senior Software Engineer | WSO2
> Email: is...@wso2.com
> Mob : +94 772 254 810
> Blog : http://isurad.blogspot.com/
>
>
>
>
> On Mon, Sep 26, 2016 at 10:03 PM, Ayesha Dissanayaka 
> wrote:
>
>> Hi,
>>
>> I have created public jira IDENTITY-5166
>>  to track this
>> implementation.
>>
>> Thanks!
>> -Ayesha
>>
>>
>>
>> On Mon, Sep 26, 2016 at 5:14 PM, Ayesha Dissanayaka 
>> wrote:
>>
>>> Hi,
>>>
>>> I have started working on [1], which forces password reset for a
>>> user after a administrative password recovery action.

Re: [Architecture] How can we improve our profiles story?

[Sameera Jayasoma]

Hi All,

We can categorize all the files which need to be handled by profiles into
three groups.


*1) OSGi repository *

   - *Location:* repository/components
   - *Description:* Contains all the OSGi bundles, dropins artifacts and
   other required files. This repository is already organized into multiple
   profiles(if any).


*2) Config repository*

   - *Location:* repository/conf
   - *Description: Contains configuration files of the products. We need to
   figure out a way handle profile specific configuration files.*


*3) Artifact repository*

   - *Location*: repository/deployment
   - *Description*: Contains deployment artifacts of the product. We need
   to figure out a way to handle profile specific deployment artifacts.


Shariq from the platform team will work on this.

Thanks,
Sameera.

On Fri, Sep 23, 2016 at 3:18 PM, Nuwan Dias  wrote:

>
>
> On Fri, Sep 23, 2016 at 2:38 PM, Srinath Perera  wrote:
>
>> I think this happen with ESB NIO transport and Servelt transport for
>> webapps. ( Nuwan, is there other examples?).
>>
>
> In the regsitry.xml, we configure the indexers and handlers. These again
> are only required in certain profiles. There are also some configs in the
> api-manager.xml which only makes sense to enable in certain profiles.
>
>>
>> On Fri, Sep 23, 2016 at 9:42 AM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> Current issue is that all bundles and artifacts (conf files, webapps)
>>> are common to the server which are shared among all the profiles. We don't
>>> have a way to delete and modify them when starting up a profile.
>>>
>>> One other option is we could pack everything (profile specific
>>> artifacts) in the base distribution and provide a build script (ant) which
>>> create profile specific runtime a.
>>>
>>> We will check for the other alternatives along with this PoC and see.
>>>
>>> On Thu, Sep 22, 2016 at 12:27 PM, Afkham Azeez  wrote:
>>>
 We proposed an idea to build a pack based on a profile. That will
 contain only the essential stuff. So rather than starting up a runtime and
 then loading a profile, you build a pack that contains the bare
 minimum stuff required. Perhaps we can have a descriptor which describes
 what non-OSGi stuff are required for a profile and we can combine that with
 the OSGi bundles.info to figure out exactly what is needed. Can
 someone in the kernel team do a quick PoC?

 On Thu, Sep 22, 2016 at 11:26 AM, Srinath Perera 
 wrote:

> Smaeera, are these things we can fix?
>
> --Srinath
>
> On Thu, Sep 22, 2016 at 11:23 AM, Nuwan Dias  wrote:
>
>> Hi,
>>
>> This is to raise some concerns over the current server profiles.
>> Although we are able to control the bundles which are loaded to the 
>> runtime
>> based on the -Dprofile parameter, we still lack the ability of removing
>> files and modifying configuration files when the server starts on a
>> profile. And this is forcing us to start unnecessary bundles at startup.
>> Let me explain...
>>
>> API Manager has both webapps and a gateway in its distribution. The
>> synapse bundles are only required in the Gateway profiles. However since
>> the axis2.xml file of API Manager defines the http transport senders and
>> receivers based on the Synapse passthrough senders and receivers, the 
>> axis2
>> engine will try to load the synapse classes on startup. Ideally if we 
>> were
>> able to modify the axis2.xml on the Publisher, Store and Key Manager
>> profiles and replace the passthrough senders and receivers with our
>> standard http senders and receivers, we could avoid loading the synapse
>> bundles on the Publisher, Store and Key Manager.
>>
>> The same problem occurs for registry indexers and handlers. Since the
>> registry indexers and handlers are configured on the registry.xml, even
>> though these are only required in the publisher and store profiles, these
>> bundles will be activated and running even on the Gateway, Key Manager 
>> and
>> Traffic Manager. So unless we modify the registry.xml on those nodes
>> manually, we can't stop those bundles from running.
>>
>> Another problem we're facing is the inability to remove webapps.
>> Since all webapps in the repository/deployment/server/webapps and
>> repository/deployment/server/jaggeryapps are deployed into the
>> runtime, unless we remove these webapps manually there is no other way to
>> stop them from being deployed in unrelated profiles.
>>
>> I heard there is a discussion to bind a profile to a container. Which
>> would solve these problems. However it still won't help the 
>> "non-container"
>> deployments. Are there ways to overcome the above mentioned limitations 
>> and
>> enhance the 

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Ishara Karunarathna]

Hi All,

There is a OpenID RISC (Risk and Incident Sharing and Coordination) WG [1]
they also talking about Share information about important security events.
They also looking for Pub sub model for Oauth token revocation, OIDC
session revocation etc[2].

I think If there is a broker capable of supporting our requirement no wrong
if we try this.

Thanks,
Ishara

[1] http://openid.net/wg/risc/
[2]
http://lists.openid.net/pipermail/openid-specs-risc/Week-of-Mon-20151102/61.html

On Mon, Oct 3, 2016 at 12:17 PM, Dimuthu Leelarathne 
wrote:

> Hi Sanjeewa,
>
> On Mon, Oct 3, 2016 at 10:33 AM, Sanjeewa Malalgoda 
> wrote:
>
>>
>>
>> On Mon, Oct 3, 2016 at 9:33 AM, Dimuthu Leelarathne 
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 Hi,
 Before we need to take any decision about moving to pub/sub approach we
 need to consider some of the facts.

 As of now token revoke responses carrying revoke token as transport
 header and at gateway cache clear handler will remove revoked token from
 cache. Then it will replicate to other nodes through clustering.

 If we are planning to have pub/sub solution then either oauth2
 implementation or cache clear handler at gateway should push this event to
 topic.
 Both cases we need to maintain message broker in gateway or key manager
 while all gateway workers subscribe to topic available there.
 Then we need to think about how high availability works for this
 broker(since we have multiple gateways and key managers in most of the
 deployments). IMHO it will add more complexity to deployment.

 My main point is even if we use pub/sub in order to achieve HA we need
 multiple broker instances. Then those need to synchup with each other and
 we need some sort of group communication for that(again clustering comes to
 picture).

 May be we can evaluate some solution like kafka for this. We are
 evaluating it for traffic manager update retrieving process(through kafka
 event publisher in CEP and extension to subscribe topics to fetch updates).
 It will not be a first class support but through extensions we may be able
 to do that. Even with that we need to maintain zoo-keeper cluster when we
 have multiple brokers(again this make deployment bit complicate).

>>>
>>> What if we add this as an deployment option? We can ship it as a
>>> component that is switched on with configs.
>>>
>> I'm sorry if i didn't make it clear in my first reply. What i wanted to
>> tell is even if we remove hazlecast based clustering we still need
>> something like zookeeper which does cluster coordination for traffic
>> managers.  So we cannot completely eliminate clustering from deployment.
>>
>
> Clustering traffic managers are ok. The problem is clustering gateways.
> Clustering gateways hinders our ability to scale to large numbers. Since
> the gateway t-manager ration is 10 to 1, it is ok to cluster t-managers.
>
> thanks,
> Dimuthu
>
>
>> Thanks,
>> sanjeewa.
>>
>>>
>>>

 If need we can wait 15 minutes for cache timeout rather adding this
 kind of feature if users do not like to use gateway clustering.

 And clustering is required to replicate validation information cache
 across gateway nodes. Otherwise when LB not routing requests without
 session awareness gateways may do same key validation call again and again.
 In this case usually cluster communication is cheaper than another key
 validation call. So if we remove clustering completely then we need to
 think about this as well.

>>>
>>> I think the best here is switching on IP hashing at LB.
>>>
>>> Cos think of a case where we have to support a large TPS. Having this
>>> would be so easy. For large TPS (say .. X TPS range) they wouldn't even
>>> mind having a their own broker in HA.
>>>
>>> thanks,
>>> Dimuthu
>>>
>>>
>>>

 Thanks,
 sanjeewa.



 On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne <
 dimut...@wso2.com> wrote:

> Hi,
>
> If we publish OAuth key revocation to a topic (we can do so using by
> writing an extension to WSO2IS), we can remove clustering in the APIM
> gateway. Are there better ways for achieving the same? Can we prioratise
> this for next APIM release?
>
> thanks,
> Dimuthu
>
> --
> Dimuthu Leelarathne
> Director, Solutions Architecture
>
> WSO2, Inc. (http://wso2.com)
> email: dimut...@wso2.com
> Mobile: +94773661935
> Blog: http://muthulee.blogspot.com
>
> Lean . Enterprise . Middleware
>



 --

 *Sanjeewa Malalgoda*
 WSO2 Inc.
 Mobile : +94713068779

 blog
 :http://sanjeewamalalgoda.blogspot.com/
 

Re: [Architecture] [architecture ] [IS-5.3.0] Admin forces password reset for user

[Manjula Rathnayake]

Hi Ayesha,

On Fri, Sep 30, 2016 at 3:17 PM, Ayesha Dissanayaka  wrote:

> Hi all,
>
> Based on the discussions with Johann, Darshana, Isura and myself, we
> identified following use cases and design concerns.
>
> There are three cases of Admin Forced Password Reset action,
>
>- Admin Forced Password Reset Off-line
>- Admin knows the password and give it to user offline(ex: via phone)
>   - Admin Forced Password Reset via OTP
>   - OTP is sent to user as a notifications(email/sms). Admin may not
>   able see the OTP
>   - Admin Forced Password Reset via Recovery Email
>   - Email with a link which directs to password recovery portal is
>   sent to user
>
> For each case above, Admin Forced Password Reset action trigger is
> identifies as a claim update.
>
> When a special claim "http://wso2.org/claims/identity/
> adminForcedPasswordReset" is updated, an EventHandler will handle the
> update to this particular claim.
>
Do we know claims/attritubes used in LDAP schemas for similar purposes? I
assume, we ask the user to map above claim to any LDAP attribute.

> New governance Connector will be implemented and above three cases can be
> enable/disable based on system requirements.
>
Is there any document, code which discuss about governance connector?

thank you.

> Within the EventHandler, a RecoveryScenario is set to identify the admin
> forced password reset activity. And user account will be locked until
> password reset by user.
>
> At the login, inside Login Authenticator it will look at RecoveryScenario
> along with OTP provided in order to prompt password reset option to the
> user. Once the password is reset by user, account will be unlocked and 
> RecoveryScenario
> entry will be cleaned-up.
>
> For the MVP1, I am implementing handling *Admin Forced Password Reset*
> trigger with claim update and Handler to send an email with password reset
> link to user.
>
> Thanks!
> -Ayesha
>
>
> On Wed, Sep 28, 2016 at 12:19 PM, Ayesha Dissanayaka 
> wrote:
>
>> Hi Ishara,
>>
>> Thank you for the input. Having similar discussion with Darshana and
>> Isura, I have started extending askPassword implementation with email
>> verification flow in order trigger a password reset by capturing "update
>> credential" event. Still, we need a mechanism to distinguish admin password
>> reset vs. user password reset.
>>
>> Thanks!
>> -Ayesha
>>
>>
>> On Wed, Sep 28, 2016 at 12:06 PM, Ishara Karunarathna 
>> wrote:
>>
>>> Hi Ayesha,
>>>
>>> On Tue, Sep 27, 2016 at 11:00 AM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Ayesha,

 We can extend Ask Password feature we developed in IS 5.3.0 to support
 this feature. So, we can send a confirmation email rather than an OTP.

>>> There can be different user cases.
>>> If we think about a call center scenario then customer will call to
>>> support center and asked to reset the password and will communicate that to
>>> the client that time, then use can login and 1st attempt he need to reset
>>> the password.
>>> Then we can set an additional flag to user attribute that indicate that
>>> this password reset by admin.
>>> And then this can be checked in Password Policy Authenticator.
>>>
>>> And secured way to handle this extending Ask password implementation and
>>> send a email and rest the password. or send a OTP to customer and enforce
>>> to rest in 1st login.
>>> I think better to implement the 1st scenario and extent to these cases.
>>>
>>> Thanks,
>>> Ishara
>>>

 Thanks
 Isura


 *Isura Dilhara Karunaratne*
 Senior Software Engineer | WSO2
 Email: is...@wso2.com
 Mob : +94 772 254 810
 Blog : http://isurad.blogspot.com/




 On Mon, Sep 26, 2016 at 10:03 PM, Ayesha Dissanayaka 
 wrote:

> Hi,
>
> I have created public jira IDENTITY-5166
>  to track this
> implementation.
>
> Thanks!
> -Ayesha
>
>
>
> On Mon, Sep 26, 2016 at 5:14 PM, Ayesha Dissanayaka 
> wrote:
>
>> Hi,
>>
>> I have started working on [1], which forces password reset for a user
>> after a administrative password recovery action.
>>
>> Based on the off-line discussion with Darshana, this flow can be as
>> follows.
>>
>>1. User, '*Bob*' forgets password and request administrative
>>person for a password reset action
>>2. Admin person reset the password and provide a new password to
>>*Bob* off-line
>>3. This can be performed using management console
>>4. When *Bob* tries to log-in with newly provided password, login
>>page should prompt password reset UI to *Bob*
>>5. And without changing the password Bob cannot login to the
>>system
>>6. There should be a way to distinguish *user password 

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Dimuthu Leelarathne]

Hi Sanjeewa,

On Mon, Oct 3, 2016 at 10:33 AM, Sanjeewa Malalgoda 
wrote:

>
>
> On Mon, Oct 3, 2016 at 9:33 AM, Dimuthu Leelarathne 
> wrote:
>
>>
>>
>> On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> Hi,
>>> Before we need to take any decision about moving to pub/sub approach we
>>> need to consider some of the facts.
>>>
>>> As of now token revoke responses carrying revoke token as transport
>>> header and at gateway cache clear handler will remove revoked token from
>>> cache. Then it will replicate to other nodes through clustering.
>>>
>>> If we are planning to have pub/sub solution then either oauth2
>>> implementation or cache clear handler at gateway should push this event to
>>> topic.
>>> Both cases we need to maintain message broker in gateway or key manager
>>> while all gateway workers subscribe to topic available there.
>>> Then we need to think about how high availability works for this
>>> broker(since we have multiple gateways and key managers in most of the
>>> deployments). IMHO it will add more complexity to deployment.
>>>
>>> My main point is even if we use pub/sub in order to achieve HA we need
>>> multiple broker instances. Then those need to synchup with each other and
>>> we need some sort of group communication for that(again clustering comes to
>>> picture).
>>>
>>> May be we can evaluate some solution like kafka for this. We are
>>> evaluating it for traffic manager update retrieving process(through kafka
>>> event publisher in CEP and extension to subscribe topics to fetch updates).
>>> It will not be a first class support but through extensions we may be able
>>> to do that. Even with that we need to maintain zoo-keeper cluster when we
>>> have multiple brokers(again this make deployment bit complicate).
>>>
>>
>> What if we add this as an deployment option? We can ship it as a
>> component that is switched on with configs.
>>
> I'm sorry if i didn't make it clear in my first reply. What i wanted to
> tell is even if we remove hazlecast based clustering we still need
> something like zookeeper which does cluster coordination for traffic
> managers.  So we cannot completely eliminate clustering from deployment.
>

Clustering traffic managers are ok. The problem is clustering gateways.
Clustering gateways hinders our ability to scale to large numbers. Since
the gateway t-manager ration is 10 to 1, it is ok to cluster t-managers.

thanks,
Dimuthu


> Thanks,
> sanjeewa.
>
>>
>>
>>>
>>> If need we can wait 15 minutes for cache timeout rather adding this kind
>>> of feature if users do not like to use gateway clustering.
>>>
>>> And clustering is required to replicate validation information cache
>>> across gateway nodes. Otherwise when LB not routing requests without
>>> session awareness gateways may do same key validation call again and again.
>>> In this case usually cluster communication is cheaper than another key
>>> validation call. So if we remove clustering completely then we need to
>>> think about this as well.
>>>
>>
>> I think the best here is switching on IP hashing at LB.
>>
>> Cos think of a case where we have to support a large TPS. Having this
>> would be so easy. For large TPS (say .. X TPS range) they wouldn't even
>> mind having a their own broker in HA.
>>
>> thanks,
>> Dimuthu
>>
>>
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>>
>>> On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne >> > wrote:
>>>
 Hi,

 If we publish OAuth key revocation to a topic (we can do so using by
 writing an extension to WSO2IS), we can remove clustering in the APIM
 gateway. Are there better ways for achieving the same? Can we prioratise
 this for next APIM release?

 thanks,
 Dimuthu

 --
 Dimuthu Leelarathne
 Director, Solutions Architecture

 WSO2, Inc. (http://wso2.com)
 email: dimut...@wso2.com
 Mobile: +94773661935
 Blog: http://muthulee.blogspot.com

 Lean . Enterprise . Middleware

>>>
>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>>
>>
>> --
>> Dimuthu Leelarathne
>> Director, Solutions Architecture
>>
>> WSO2, Inc. (http://wso2.com)
>> email: dimut...@wso2.com
>> Mobile: +94773661935
>> Blog: http://muthulee.blogspot.com
>>
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>


-- 
Dimuthu Leelarathne
Director, Solutions Architecture

WSO2, Inc. (http://wso2.com)
email: dimut...@wso2.com
Mobile: +94773661935
Blog: http://muthulee.blogspot.com

Lean . Enterprise . Middleware