Also please check [1] for some details... The derived UUID makes things easy - but it has some challenges too...
Thanks & regards, -Prabath [1]: https://docs.google.com/document/d/14r2HDeqCqVuTMLqIw-EZmclvsx0uY047gsDZic3uHVs/edit On Tue, Dec 6, 2016 at 8:36 PM, Ishara Karunarathna <[email protected]> wrote: > Hi Nuwan, > > On Wed, Dec 7, 2016 at 9:58 AM, Nuwan Dias <[email protected]> wrote: > >> >> On Wed, Dec 7, 2016 at 7:12 AM, Thanuja Jayasinghe <[email protected]> >> wrote: >> >>> Hi All, >>> >>> In the IS 6.0.0 Identity Store design we facilitate to have multiple >>> user domains, each contains one or more identity/credential store >>> connectors. Also, same identity/credential store connector may reside in >>> two different domains. So there is a requirement to identify a user >>> uniquely throughout the system. >>> >> >> I'm finding it hard to understand what is a domain and what is a >> connector :). Are there mails explaining exactly what these are? Sorry if >> I've missed them. >> > You can find it in the following thread [1] > -Ishara > > [1] "User-Core Domain Implementatin" > >> >>> *Approach One* >>> >>> Calculate unique user id as a combination of domain id and connector >>> wise user mappings. Use a signing mechanism to ensure the integrity of the >>> id. >>> >>> Ex: {domain-id}.{connector-id : connector-user-id}*.{digest-value} => >>> 12.{c1:[email protected]}{c2:78451244}.W4sU2s >>> >>> Pros: >>> >>> - Can verify the user without a database call by recalculating the >>> digest value of the id. >>> - Can identify the domain and connector wise mapping without a >>> database call if server received the id. >>> >>> Cons: >>> >>> - If a connector added or removed from the domain, then the unique >>> id will be a different one. So need to have a constraint there. >>> - In a scenario where we have multiple connectors, during a user >>> claim update, some connectors may be added to the id. Since when we >>> create >>> a user we may not add attributes to all the connectors. >>> - Having a valid unique user id does not guarantee that user still >>> exists in the system. >>> - Unique id may be lengthy. >>> >>> >>> *Approach Two* >>> >>> Calculate unique user id as a combination of domain id and a random UUID. >>> >>> Ex: {domain-id}.{random-uuid} => 12.A1j88KlmSKAl74 >>> >>> Pros: >>> >>> - Can identify the domain without a database call. >>> - Can add or remove connectors without changing the unique user id. >>> - User claim update does not affect the unique user id value. >>> - Fairly small id compared to the approach one. >>> >>> >>> Cons: >>> >>> - Need a database call to get the connector mappings. >>> >>> >>> It feels like approach two is more suitable for the identity store. WDYT? >>> >>> Thanks, >>> Thanuja >>> >>> -- >>> *Thanuja Lakmal* >>> Senior Software Engineer >>> WSO2 Inc. http://wso2.com/ >>> *lean.enterprise.middleware* >>> Mobile: +94715979891 +94758009992 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 <+94%2077%20777%205729> >> > > > > -- > Ishara Karunarathna > Associate Technical Lead > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > email: [email protected], blog: isharaaruna.blogspot.com, mobile: > +94717996791 <071%20799%206791> > > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://facilelogin.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
