*Meeting Notes - 30/5/2019* *Use Case*
The most general form of this use case was identified as follows. A single physical user may have more than one local account in one or more user stores in WSO2 Identity Server. In some use cases the credentials and attributes may be separated into their dedicated stores. We call them credential stores and attribute stores respectively. In other use cases there is no clear separation of credential stores and attribute stores. *Problems* 1. How to reliably link all the local accounts that belong to the same physical user? 2. How do we allow users to make one account as the primary account that is used for login to any service provider, but select the account to present based on either configuration or user input? 3. How do we allow users to make one account as the primary account that is presented to any service provider, but use any linked accounts to login with? 4. In the same scenario as (2) or (3), how do we collect attributes from a configurable set of linked accounts? This is known as account merging. *Proposed Solutions* We discussed and rejected custom user store and custom authenticator because those are layers that don't need to understand the level of information that are needed in this use case. And also if we are to customize the user store layer when multiple user stores are present, each type of user store will have to be customized which is wrong. If we are to customize the authenticator we will have to customize all the authenticators that possibly will be used. The recommendation that came out of the discussion was to implement a PostAuthenticationHandler to do just-in-time linking and switching of account based on config. 1. How to reliably link all the local accounts that belong to the same physical user? Local account linking use case could most probably happen only in cases where two IAM systems were merged together where a single user could have independent accounts in both of these systems. Therefore the most probable way a user wants to link these accounts is by going to the user self-care portal. Once logged into the user self-care portal user may give the credentials of the other account and link the two. This is already supported in IS user portal. Alternatively the linking can also be done just-in-time during login. Just after the user has successfully authenticated to IS, linking can be done, based on a common claim value between 2 or more accounts, that is unique per user and verified. This can be implemented as a PostAuthenticationHandler. 2. How do we allow users to make one account as the primary account that is used for login to any service provider, but select the account to present based on either configuration or user input? Can be implemented as a PostAuthenticationHandler. In the PostAuthenticationHandler, override the account details in the AuthenticationContext, with the selected linked account details. This is because ClaimHandler executes before PostAuthenticationHandlers. This could have been avoided if ClaimHandler is also converted to a PostAuthenticationHandler so that we can order the PostAuthenticationHandlers as needed and place the local account linking handler in between the authentication handler and claim handler. 3. How do we allow users to make one account as the primary account that is presented to any service provider, but use any linked accounts to login with? Either extend the linked accounts table to contain a IS_PRIMARY (CHAR) column that indicates if the particular local account is a primary or not, or maintain a user claim to indicate this. However, linking using a claim will not give optimum performance as we will have to search through all the linked accounts to find the primary account. If these accounts are spread across multiple user stores search performance may become worse. And implement a PostAuthenticationHandler to set the right linked account details in the AuthenticationContext as in (2). 4. In the same scenario as (2) or (3), how do we collect attributes from a configurable set of linked accounts? This is known as account merging. Extend the same PostAuthenticationHandler to do it. Thanks & Regards, Johann. On Fri, Apr 19, 2019 at 6:06 PM Johann Nallathamby <[email protected]> wrote: > > > On Thu, Apr 18, 2019 at 6:51 PM Ruwan Abeykoon <[email protected]> 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. >> > > +1. Will arrange a meeting once I am back next week. > > >> >> Can we do this once the release pressure is over? For the prospect, can >> we say this is in our roadmap. >> > > For the existing customer we can do this as an extension for 5.7.0. > > For the prospect I don't think we can simply say it is in the roadmap and > move on, because it is one of their critical requirements. However, we can > propose an option how we plan to support it, either via extension or WUM. > Probably this will be on IS 5.8.0. > > What I am more keen on deciding is, how we can support this OOTB beyond IS > 5.8.0. > > Regards, > Johann. > > >> >> Cheers, >> Ruwan A >> >> >> On Thu, Apr 18, 2019 at 4:45 PM Johann Nallathamby <[email protected]> >> 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. >>> >>> 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. >>> >>> 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) [email protected] >>> [image: Signature.jpg] >>> >> >> >> -- >> >> *Ruwan Abeykoon* >> *Associate Director/Architect**,* >> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >> *lean.enterprise.middleware.* >> >> > > -- > *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | > WSO2 Inc. > (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected] > [image: Signature.jpg] > -- *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | WSO2 Inc. (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected] [image: Signature.jpg]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
