*Meeting Notes - 30/5/2019* During the meeting for [1], we also identified some federated account linking improvements that are currently not supported in WSO2 IS.
A single physical user may have a set of linked local accounts in WSO2 Identity Server. The same physical user may have one or more federated identities also. *Problems* 1. How to reliably link all the federated identities to the set of linked local accounts? 2. How do we allow users to login with any one of the federated accounts and get mapped to the primary local account or one of the other local accounts based on either configuration or user input and login to service provider? 3. Cannot link multiple federated accounts in the same IdP to a single local account. This could be a valid requirement. *Solutions* 1. How to reliably link all the federated identities to the set of linked local accounts? We do have just-in-time provisioning and linking in the same request. However, we don't have just-in-time linking to an existing user account. The reason being that we don't have just-in-time verification of ownership of the link identifier. For example, if the linking is done based on email address on both sides, the email address coming from the IdP must be verified. If we can't be sure if its verified, then it can result in an account takeover. Therefore we haven't allowed this capability out-of-the-box. However, in a particular deployment if we can make sure that the ownership of the link identifier is independently verified on both sides, then we can implement an extension and do the federated account linking. In order to implement the just-in-time link identifier verification, we can extend the federated account linking handler, find if a user exists with the link identifier, and set the "http://wso2.org/claims/verifyEmail"; claim of that user to 'true'. This will initiate the email address verification flow for that particular user and send out a verification email to the user's given email address. Once the user logs into his email account and confirms the account, user will be directed to IS's portal, and a web service will be invoked to link the identified user to the federated account used to login. In this flow we may have to track the federated account identifier throughout the flow. This can be passed as a property to the notification handler and added as a URL parameter in the email confirmation link. Another problem which was discussed is that we can't directly link a federated account to multiple local accounts. Alternatively we can link the federated account to a single primary local account and link all the other local accounts to the primary account via local account linking. 2. How do we allow users to login with any one of the federated accounts and get mapped to the primary local account or one of the other local accounts based on either configuration or user input and login to service provider? Linking federated account identifier to the primary local account and logging in, is support today. What is not supported is allowing to pick a linked local account to the primary local account based on configuration or user input for a particular service provider. This can be implemented using a PostAuthenticationHandler. [1] "[IAM] What is our Strategy on Local Account Linking?" in [email protected] 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]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
