Hi All,
The notes from the review we had on the "password rotation policy" progress
are as follows.
Participants: DimuthuL, RuwanA, Darshana, Pamoda, Senthalan
1. Consider the following when finding *unique* password change events
1. Tenant ID
2. Username
3. Domain
2. Use an event table to store the password change events since *restarting
a server clears the unique window*
3. Use *"days" as the unit* for the following time measures in the
template
1. Password Expiry Check Interval
2. Password Expiry Time
Thanks!
Regards,
NadunD
On Tue, Jan 23, 2018 at 6:12 PM, Johann Nallathamby <[email protected]> wrote:
> According to the discussion we had with Jayanga in the solution
> architecture team's bootcamp meeting, this is something we are considering
> in the WUM roadmap, to make connectors first class citizens of WUM.
>
> *@Jayanga/Kishanthan*: your thoughts.
>
> Regards,
> Johann.
>
> On Tue, Jan 23, 2018 at 11:38 AM, Ruwan Abeykoon <[email protected]> wrote:
>
>> Hi All,
>> I agree with Johann,
>> i.e.
>> a) to publish as connector for current version of the product.
>> b) to include this in next viable release in product itself.
>>
>> On a different but related note,
>> IMO connectors are really features, technically. Hence we need to look a
>> way to be publish htme as features.
>> Currently we add connectors to dropins. But this is not correct in terms
>> of OSGI or the user experience perspective. I would think, "dropins" are
>> for those components developed by users, not by WSO2.
>>
>> But there are problems in our WUM model when we do feature installation.
>> We need to work on this too.
>>
>> Cheers,
>> Ruwan
>>
>> On Tue, Jan 23, 2018 at 11:21 AM, Johann Nallathamby <[email protected]>
>> wrote:
>>
>>>
>>>
>>> On Tue, Jan 23, 2018 at 11:06 AM, Nadun De Silva <[email protected]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have been working on *publishing events to IS Analytics* for the
>>>> notification system for the expired passwords.
>>>>
>>>> In the existing implementation to publish events to IS Analytics, a
>>>> stream and a publisher for each event type had been bundled together with
>>>> IS. (The artifacts are installed by the p2-feature at product-is build
>>>> time)
>>>>
>>>> The publishing works as follows.
>>>>
>>>> 1. AbstractEventListeners in IS injects events into the stream.
>>>> 2. The publisher connected to the stream publishes to IS Analytics.
>>>>
>>>> If I am *to follow the same implementation* of publishing for the
>>>> password changed event, We would *need to add the relevant xml files
>>>> to the server*.
>>>>
>>>> There are several approaches that we can employ, that I could come up
>>>> with.
>>>>
>>>> - Publish the connector as a p2-feature. (However, AFAIK, all the
>>>> IS connectors are published as jar files and therefore this may not be
>>>> suitable.)
>>>>
>>>> +1 to publish as connector for current version of the product. New
>>> config additions also can be added in connectors.
>>>
>>>>
>>>> -
>>>> - Bundle this along with the next release of IS.
>>>>
>>>> Must do this. At this point it will get published as p2 feature.
>>>
>>>>
>>>> - Let the user copy the files (This IMO is not very user-friendly.)
>>>>
>>>> Even if you publish as a connector we need to manually copy files.
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>>> What are your ideas on these approaches? Is there a better alternative?
>>>>
>>>> Any comments or suggestions are welcome.
>>>>
>>>> Thank you!
>>>>
>>>> Regards,
>>>> Nadun De Silva
>>>>
>>>> On Fri, Jan 19, 2018 at 2:21 PM, Nadun De Silva <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> *@Johann* Thank you for the information. I was able to extend the
>>>>> handler and listen to password change events.
>>>>>
>>>>> Now I am working on publishing data to IS Analytics using the
>>>>> EventStreamService.
>>>>>
>>>>> I will keep the thread updated.
>>>>>
>>>>> Thank you!
>>>>>
>>>>> Regards,
>>>>> NadunD
>>>>>
>>>>> On Wed, Jan 17, 2018 at 2:14 PM, Johann Nallathamby <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 17, 2018 at 12:43 PM, Nadun De Silva <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Johann,
>>>>>>>
>>>>>>> On Tue, Jan 16, 2018 at 9:30 PM, Johann Nallathamby <[email protected]
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi Nadun,
>>>>>>>>
>>>>>>>> On Tue, Jan 16, 2018 at 11:16 AM, Nadun De Silva <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> At the moment the authenticator only has the *"password
>>>>>>>>> expiration time period"* in the password expiration policy.
>>>>>>>>>
>>>>>>>>> So I can start off by altering the authenticator to publish the
>>>>>>>>> following to analytics
>>>>>>>>>
>>>>>>>>> - The password expiration time period config change
>>>>>>>>> - The password changed event
>>>>>>>>>
>>>>>>>>> Also, the high-level architecture would be as follows.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any comments or improvements are highly appreciated.
>>>>>>>>>
>>>>>>>>
>>>>>>>> There is a problem in this architecture. You are only considering
>>>>>>>> the password change events sent from the password rotation policy
>>>>>>>> authenticator. There are other channels also. E.g. SCIM2 and Admin
>>>>>>>> Console.
>>>>>>>> So you need to publish the same event from there as well. This
>>>>>>>> should be pretty easy to do in IS with the handler architecture we
>>>>>>>> have. We should be already getting a password update event to the
>>>>>>>> system
>>>>>>>> whenever user password is updated via any one of the above channels.
>>>>>>>> Therefore all you need to do is write a handler (or reuse an existing
>>>>>>>> handler appropriately) and create the siddhi streams and publish.
>>>>>>>>
>>>>>>>> My diagram was a bit incorrect. Sorry about the confusion I caused.
>>>>>>>
>>>>>>> This is not a class diagram and simply *shows how the events are
>>>>>>> published*. The updated correct high level diagram which uses a
>>>>>>> listener is shown below.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My current approach after more research is to extend the
>>>>>>> *UserOperationEventListener* [1]
>>>>>>> <https://github.com/wso2/carbon-kernel/blob/release-4.4.20/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/listener/UserOperationEventListener.java>
>>>>>>> and
>>>>>>> listen to the following events.
>>>>>>>
>>>>>>
>>>>>> From IS 5.3.0 onwards we don't use *UserOperationEventListener* anymore.
>>>>>> We have one single *UserOperationEventListener* that publishes
>>>>>> events for the operations you have mentioned below. And there are
>>>>>> IdentityHandlers which listen to to those event and do stuff. You need to
>>>>>> write a IdentityHandler. For example [1].
>>>>>>
>>>>>> [1] https://github.com/wso2-extensions/identity-event-handler-no
>>>>>> tification/blob/master/components/event-handler-notification
>>>>>> /org.wso2.carbon.identity.event.handler.notification/src/mai
>>>>>> n/java/org/wso2/carbon/identity/event/handler/notification/N
>>>>>> otificationHandler.java
>>>>>>
>>>>>> Regards,
>>>>>> Johann.
>>>>>>
>>>>>>>
>>>>>>> 1. User Add [2]
>>>>>>>
>>>>>>> <https://github.com/wso2/carbon-kernel/blob/release-4.4.20/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/listener/UserOperationEventListener.java#L90>
>>>>>>> 2. User Credentials Update [3]
>>>>>>>
>>>>>>> <https://github.com/wso2/carbon-kernel/blob/release-4.4.20/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/listener/UserOperationEventListener.java#L119>
>>>>>>> 3. User Credentials Update By Admin [4]
>>>>>>>
>>>>>>> <https://github.com/wso2/carbon-kernel/blob/release-4.4.20/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/listener/UserOperationEventListener.java#L144>
>>>>>>>
>>>>>>> This will handle the publishing of the password change events to
>>>>>>> siddhi.
>>>>>>>
>>>>>>>
>>>>>>>> With that can we remove this Password Expiration Policy
>>>>>>>> authenticator from the design? Is there any other requirement for this?
>>>>>>>> Looking at the "inheritance" relationship worries me :)
>>>>>>>>
>>>>>>>
>>>>>>> With the current approach the *authenticator* will only be used to
>>>>>>> force the user to reset the expired password in the *authentication
>>>>>>> flow*.
>>>>>>>
>>>>>>> The "authenticator" and the "listener to publish the relevant
>>>>>>> events" will be separately implemented and *bundled them together
>>>>>>> in one connector*. (Including a C-App containing the IS-Analytics
>>>>>>> artifacts)
>>>>>>>
>>>>>>> I hope this solves the concerns pointed out before.
>>>>>>>
>>>>>>> Please correct me if I am wrong and any comments or improvments are
>>>>>>> highly appreciated.
>>>>>>>
>>>>>>> Thank you!
>>>>>>>
>>>>>>> [1] https://github.com/wso2/carbon-kernel/blob/release-4.4.2
>>>>>>> 0/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carb
>>>>>>> on/user/core/listener/UserOperationEventListener.java
>>>>>>> [2] https://github.com/wso2/carbon-kernel/blob/release-4.4.2
>>>>>>> 0/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carb
>>>>>>> on/user/core/listener/UserOperationEventListener.java#L90
>>>>>>> [3] https://github.com/wso2/carbon-kernel/blob/release-4.4.2
>>>>>>> 0/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carb
>>>>>>> on/user/core/listener/UserOperationEventListener.java#L119
>>>>>>> [4] https://github.com/wso2/carbon-kernel/blob/release-4.4.2
>>>>>>> 0/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carb
>>>>>>> on/user/core/listener/UserOperationEventListener.java#L144
>>>>>>>
>>>>>>> Regards,
>>>>>>> NadunD
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Johann.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thank you!
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> NadunD
>>>>>>>>>
>>>>>>>>> On Tue, Jan 16, 2018 at 6:39 AM, Ruwan Abeykoon <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Dimuthu,
>>>>>>>>>> I would suggest storing the expiration policy in IS side. How and
>>>>>>>>>> where this can be stored yet to be discussed. For the time being, we
>>>>>>>>>> can
>>>>>>>>>> play around registry for quick start( but registry will go away soon)
>>>>>>>>>> IS needs to emit an event towards analytics upon any change in
>>>>>>>>>> the policy. This change will then be stored in analytics side too,
>>>>>>>>>> and used
>>>>>>>>>> as parameters on Siddhi (preferable) or Spark queries.
>>>>>>>>>>
>>>>>>>>>> This will decouple the policy from the code. Hence "Identity
>>>>>>>>>> Admin" is given chance implement most of things that can bed imagine.
>>>>>>>>>>
>>>>>>>>>> We provide default policy + default query. But "Identity Admin"
>>>>>>>>>> can modify them without code change and change will be immediately
>>>>>>>>>> live.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ruwan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Jan 16, 2018 at 3:03 AM, Dimuthu Leelarathne <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Nadun,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jan 15, 2018 at 9:01 PM, Nadun De Silva <[email protected]
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I have started working on a Password Rotation Policy
>>>>>>>>>>>> Authenticator for the Identity Server.
>>>>>>>>>>>>
>>>>>>>>>>>> Currently, there is an authenticator [1] which can be used to
>>>>>>>>>>>> force the user to change the password.
>>>>>>>>>>>>
>>>>>>>>>>>> However, it does not support the following requirements on its
>>>>>>>>>>>> own.
>>>>>>>>>>>>
>>>>>>>>>>>> - Force the user to change the password to a *previously
>>>>>>>>>>>> unused password*
>>>>>>>>>>>> - *Notify the user* when the password had expired
>>>>>>>>>>>>
>>>>>>>>>>>> According to my research, I found out that the *user can be
>>>>>>>>>>>> forced to change the password to a previously unused password
>>>>>>>>>>>> using the
>>>>>>>>>>>> Password History Validation Policy* [2] and the authenticator
>>>>>>>>>>>> [1]. However, the authenticator does not show a proper message to
>>>>>>>>>>>> the user.
>>>>>>>>>>>> I am planning to fix this.
>>>>>>>>>>>>
>>>>>>>>>>>> I have also started working on the *password expiry
>>>>>>>>>>>> notifications*. The planned approach that will be used is as
>>>>>>>>>>>> follows,
>>>>>>>>>>>>
>>>>>>>>>>>> - Emit the password change event to analytics
>>>>>>>>>>>> - Use an analytic query to identify the user's whose
>>>>>>>>>>>> passwords had expired
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Where do we hope to maintain the password expiration policy? It
>>>>>>>>>>> is at the identity server side. Can analytics query can invoke a
>>>>>>>>>>> REST API
>>>>>>>>>>> on identity server side to retrieve it?
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>> Dimuthu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This approach was selected as this will have a minimal load on
>>>>>>>>>>>> the identity server instance as well as it will also open up the
>>>>>>>>>>>> path to do
>>>>>>>>>>>> further analytics to identify anomalous user behaviors.
>>>>>>>>>>>>
>>>>>>>>>>>> Any suggestions or improvements are highly appreciated.
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://store.wso2.com/store/assets/isconnector/details/
>>>>>>>>>>>> 502efeb1-cc59-4b62-a197-8c612797933c
>>>>>>>>>>>> [2] https://docs.wso2.com/display/IS530/Password+History+Val
>>>>>>>>>>>> idation
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you!
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> NadunD
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> *Nadun De Silva*
>>>>>>>>>>>> Software Engineer | WSO2
>>>>>>>>>>>>
>>>>>>>>>>>> Email: [email protected]
>>>>>>>>>>>> Mobile: +94778222607 <077%20822%202607>
>>>>>>>>>>>> Web: http://wso2.com
>>>>>>>>>>>>
>>>>>>>>>>>> <http://wso2.com/signature>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Dimuthu Leelarathne
>>>>>>>>>>> Director, Solutions Architecture
>>>>>>>>>>>
>>>>>>>>>>> WSO2, Inc. (http://wso2.com)
>>>>>>>>>>> email: [email protected]
>>>>>>>>>>> Mobile: +94773661935 <+94%2077%20366%201935>
>>>>>>>>>>> Blog: http://muthulee.blogspot.com
>>>>>>>>>>>
>>>>>>>>>>> Lean . Enterprise . Middleware
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> *Ruwan Abeykoon*
>>>>>>>>>> *Associate Director/Architect**,*
>>>>>>>>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>>>>>>>>>> *lean.enterprise.middleware.*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Nadun De Silva*
>>>>>>>>> Software Engineer | WSO2
>>>>>>>>>
>>>>>>>>> Email: [email protected]
>>>>>>>>> Mobile: +94778222607 <+94%2077%20822%202607>
>>>>>>>>> Web: http://wso2.com
>>>>>>>>>
>>>>>>>>> <http://wso2.com/signature>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Architecture mailing list
>>>>>>>>> [email protected]
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Johann Dilantha Nallathamby*
>>>>>>>> Senior Lead Solutions Engineer
>>>>>>>> WSO2, Inc.
>>>>>>>> lean.enterprise.middleware
>>>>>>>>
>>>>>>>> Mobile: *+94 77 7776950*
>>>>>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>>>>>>>> <http://www.linkedin.com/in/johann-nallathamby>*
>>>>>>>> Medium: *https://medium.com/@johann_nallathamby
>>>>>>>> <https://medium.com/@johann_nallathamby>*
>>>>>>>> Twitter: *@dj_nallaa*
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Architecture mailing list
>>>>>>>> [email protected]
>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Nadun De Silva*
>>>>>>> Software Engineer | WSO2
>>>>>>>
>>>>>>> Email: [email protected]
>>>>>>> Mobile: +94778222607 <+94%2077%20822%202607>
>>>>>>> Web: http://wso2.com
>>>>>>>
>>>>>>> <http://wso2.com/signature>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Johann Dilantha Nallathamby*
>>>>>> Senior Lead Solutions Engineer
>>>>>> WSO2, Inc.
>>>>>> lean.enterprise.middleware
>>>>>>
>>>>>> Mobile: *+94 77 7776950*
>>>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>>>>>> <http://www.linkedin.com/in/johann-nallathamby>*
>>>>>> Medium: *https://medium.com/@johann_nallathamby
>>>>>> <https://medium.com/@johann_nallathamby>*
>>>>>> Twitter: *@dj_nallaa*
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Nadun De Silva*
>>>>> Software Engineer | WSO2
>>>>>
>>>>> Email: [email protected]
>>>>> Mobile: +94778222607 <+94%2077%20822%202607>
>>>>> Web: http://wso2.com
>>>>>
>>>>> <http://wso2.com/signature>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Nadun De Silva*
>>>> Software Engineer | WSO2
>>>>
>>>> Email: [email protected]
>>>> Mobile: +94778222607 <+94%2077%20822%202607>
>>>> Web: http://wso2.com
>>>>
>>>> <http://wso2.com/signature>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile: *+94 77 7776950*
>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>>> <http://www.linkedin.com/in/johann-nallathamby>*
>>> Medium: *https://medium.com/@johann_nallathamby
>>> <https://medium.com/@johann_nallathamby>*
>>> Twitter: *@dj_nallaa*
>>>
>>
>>
>>
>> --
>>
>> *Ruwan Abeykoon*
>> *Associate Director/Architect**,*
>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>> *lean.enterprise.middleware.*
>>
>>
>
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile: *+94 77 7776950*
> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
> <http://www.linkedin.com/in/johann-nallathamby>*
> Medium: *https://medium.com/@johann_nallathamby
> <https://medium.com/@johann_nallathamby>*
> Twitter: *@dj_nallaa*
>
--
*Nadun De Silva*
Software Engineer | WSO2
Email: [email protected]
Mobile: +94778222607
Web: http://wso2.com
<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
