On Fri, Apr 19, 2019 at 1:30 AM Asela Pathberiya <as...@wso2.com> wrote:
> > > On Fri, Apr 19, 2019 at 5:21 AM Ruwan Abeykoon <ruw...@wso2.com> wrote: > >> Hi Johann, >> +1 for implementing the use-case. >> We need to have a white-board session to capture all the possible cases, >> and modules to be touched. >> >> Can we do this once the release pressure is over? For the prospect, can >> we say this is in our roadmap. >> >> Cheers, >> Ruwan A >> >> >> On Thu, Apr 18, 2019 at 4:45 PM Johann Nallathamby <joh...@wso2.com> >> wrote: >> >>> IAM Team, >>> >>> I know we just have a facility to store and manage linked local >>> accounts. However we don't use it anywhere. There have been many customers >>> and/or leads in the past who have requested for this capability for >>> different kinds of requirements and mostly we've provided extensions but >>> never thought about making it part of the product. Do we have any plans on >>> improving this aspect? >>> >>> Currently I am working with one customer and one prospect who have the >>> following 2 requirements respectively: >>> >>> 1. A user must authenticate with username/password in secondary user >>> store and fetch attributes from primary user store and return back to the >>> service provider. >>> >> In fact the requirement is even broader than this. There can be more than 2 user stores, the primary is the attribute store, and all secondaries are credential stores. User could login via any credential store and retrieve attributes from primary store. >>> 2. A user can have multiple accounts in the local user store. Same user >>> also has a federated identity. The user should be able to link the >>> federated identity to both the local identifiers. When logging in the user >>> will choose, federated login and then on IS choose which local identity to >>> login as. >>> >> > +1 > > It looks like aggregating user attributes from multiple local user > stores. I remember that simple implementation was done for it long time > back [1] > > [1] > http://soasecurity.org/2015/03/03/configure-attribute-sources-with-wso2-identity-server/ > > Thanks for this link Asela. This is one approach I also was thinking about. The interesting thing I learnt from this implementation is that, the claim map that we return from getUserClaimValues() method is passed to the post interceptor of that method, which means we can modify it inside doPostGetUserClaimValues() method as well, without extending the UserStoreManager itself. Another approach I was thinking is to simply have a post processing handler in authentication framework, after the authentication is complete, before claims are handled, to switch the user based on local account linking. I prefer this approach because it give clear separation of concerns - each layer is getting to know only what it is supposed to know. We can discuss these options further and see. Regards, Johann. > > Thanks, > Asela. > >> >>> What is our strategy on local account linking? If needed we can have an >>> offline discussion on this. >>> >>> Thanks & Regards, >>> Johann. >>> >>> -- >>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect >>> | WSO2 Inc. >>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >>> [image: Signature.jpg] >>> >> >> >> -- >> >> *Ruwan Abeykoon* >> *Associate Director/Architect**,* >> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >> *lean.enterprise.middleware.* >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Thanks & Regards, > Asela > > Mobile : +94 777 625 933 > > http://soasecurity.org/ > http://xacmlinfo.org/ > -- *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | WSO2 Inc. (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com [image: Signature.jpg]
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
