On Mon, Feb 13, 2017 at 11:22 AM, Thanuja Jayasinghe <[email protected]> wrote:
> Hi Johann / Isura, > > On Tue, Feb 7, 2017 at 10:00 PM, Johann Nallathamby <[email protected]> > wrote: > >> >> >> On Wed, Feb 8, 2017 at 9:25 AM, Isura Karunaratne <[email protected]> wrote: >> >>> Hi Johann, >>> >>> >>> On Wed, Feb 8, 2017 at 9:19 AM, Johann Nallathamby <[email protected]> >>> wrote: >>> >>>> For IS 6.0.0 M3 we decided to implement and manage user lifecycle >>>> states. For IS 6.0.0 M2 we are implementing SCIM 2.0. I propose that we >>>> extend SCIM 2.0 metadata and include the user lifecycle state as a user's >>>> metadata. >>>> >>>> Also regarding where we need to store this metadata, I think it needs >>>> to be stored in a column in the UM_USER table. This means we don't have to >>>> go to the identity store to fetch user's state for most of the operations >>>> we will be performing on the user. >>>> >>>> Should we store state and lifecycleId in UM_USER table or IDM_USER >>> table ? >>> >> >> Sorry it should be IDM_USER. This will be irrespective of underlying >> identity store type. >> >> > IDM_USER table comes with the default UniqueUserIdResolver implementation. > When we connect to an existing user store( basically when we have deferent > UniqueUserIdResolver implementation), we can't garauntee that this table > will be included in the schema. > > Since life cycle status is mandotery, it should not depend on the IDM_USER > table to store values? > Keeping lifecycle state in IDM_USER means now we treat lifecycle state as a first class user metadata in our identity-mgt implementation. And also in future we will treat all the SCIM 2.0 metadata also as first class in identity-mgt implementation. This is purely for performance reasons. So we should not be thinking as if lifecycle depends on identity-mgt. Even without lifecycle-mgt that table must be populated now with initial lifecycle state "CREATED". However we may not be able to transition between states without lifecycle-mgt feature. > > >> >>> Thanks >>> Isura >>> >>> >>> >>>> On a different note I think we also need to merge the SCIM2.0 metadata >>>> table with UM_USER table so that all SCIM 2.0 metadata is supported by our >>>> identity-mgt implementation. This will greatly improve performance and >>>> avoid multiple lookups in database. Similarly we must use UM_GROUP to store >>>> group metadata of SCIM 2.0. >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Johann Dilantha Nallathamby* >>>> Technical Lead & Product Lead of WSO2 Identity Server >>>> Governance Technologies Team >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+94777776950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>> >>> >> >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Technical Lead & Product Lead of WSO2 Identity Server >> Governance Technologies Team >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > Thanks, > Thanuja > -- > *Thanuja Lakmal* > Senior Software Engineer > WSO2 Inc. http://wso2.com/ > *lean.enterprise.middleware* > Mobile: +94715979891 +94758009992 > -- Thanks & Regards, *Johann Dilantha Nallathamby* Technical Lead & Product Lead of WSO2 Identity Server Governance Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
