Hi Nuwan, On Wed, Apr 11, 2018 at 5:43 PM, Nuwan Dias <nuw...@wso2.com> wrote:
> Provisioning users with a known/proper password would make it possible for > them to login/authenticate directly against IS without being authenticated > against the federated IDP right? > Yes. The requirement is to allow these users have a password in IS that will be governed by the password policies in IS, and allow them to login to applications using IS login. > Do we really want to allow that? > Yes, that is the requirement. > If internal admins want to manage their accounts internally, or if we want > users to login/authenticate to IS directly, why would they authenticate > against a federated IDP in the first place? > There are two use cases that need to have this capability. 1. Social sign-up - In some websites social signup (not login) is used as a means of making the signup process easier, by providing the mandatory user attributes, but at the end of it a password must be provisioned. After this signup process the user will mostly login using IS. But in some scenario social login will also continue to be there, so if the user uses social login, we will automatically link that to the already provisioned account. 2. Migrating users from a external IdP - The use case is where a company has done an acquisition or merger, or simply has the need to centralize the identity management, therefore wants to migrate all the identities from an external IdP to IS, and eventually once all identities are migrated may be disconnect the IdP even. Regards, Johann. > Why not create their user accounts in IS itself instead of federating? > This won't work for the social signup use case. Even for the external IdP migration use case, if it has to be done it has to be a manual bulk import process. This is sometimes difficult to do because, 1. We cannot get password from the external IdPs 2. Even to do it as a bulk admin initiated forced password reset, with the recent performance numbers we are seeing it is almost impossible to do it. Therefore the better option is to do it on the fly when each user wants to login to the application. Regards, Johann. > On Wed, Apr 11, 2018 at 9:51 AM, Menaka Jayawardena <men...@wso2.com> > wrote: > >> Hi, >> >> In WSO2 Identity Server, users can be provisioned to the internal User >> store when the users are signing up with social accounts. But in this case, >> the users should always use the social login option to login to the >> application and the identity admins could not manage them as internal users. >> >> The main idea of this feature is to provision the users with password so >> that a proper user account will be created in the identity server so that >> they can use the user name and password to login and the identity admins >> can manage the users as internal users. >> >> As per the Flash PC[1], we need to consider following aspects when >> implementing this feature. >> >> *1. Configuring password provisioning in the IDP level.* >> A new option can be provided in the Just-In-Time Provision section to >> enable/ disable provisioing with password. >> >> *2. Prompting a page to get the user claims and password* >> When a user is using social sign up, in the sign up flow, new page will >> be shown with the claims. The claims that are retrieved from the social >> signup response will be automatically populated. Users need to fill any >> mandatory claims that are missing in the request as well as they need to >> provide a valid password. >> >> >> *3. How multiple social accounts can be associated*This applies when we >> support multiple social signup options (Facebook, Google, Twitter etc). >> When a user has already signed up with one social account, after some >> time, he/she again tries to signup using a different account. >> As different social accounts use differnt ids for users, there shoul be a >> mechanism to map the values to the existing user. >> >> As a solution for this we can allow users to add their other social >> account details in the user profile. So, when the user is trying to sign up >> using another account he/she will be logged into the existing account. >> >> *4. What are the user claims that we should retrieve from the social >> account and do we allow users to edit those claims.* >> As we show the claims that are retrieved from the signup request, have to >> decide whether we allow users to modify those details. As per the >> discussion [1] we only allow to edit the exact claims that can be edited in >> the user profile. >> >> I have written the use cases that will be involved in this use case and >> attached herewith. >> https://docs.google.com/document/d/1rNnQj_KMJO5ZLJQE_2F9Ezk_ >> WqC-IAq2vmaJ5bk5j4k/edit?usp=sharing >> >> Any ideas suggestions are highly appreciated. >> >> [1] Updated invitation: IS Flash PC @ Mon Apr 9, 2018 1:45pm - 2:30pm >> (IST) (Rapid Response Group) >> >> Thanks and Regards, >> Menaka >> -- >> *Menaka Jayawardena* >> Software Engineer >> WSO2 Inc. >> >> Phone : +94 71 350 5470 >> LinkedIn : https://lk.linkedin.com/in/menakajayawardena >> Blog : https://menakamadushanka.wordpress.com/ >> >> > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > -- *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile: *+94 77 7776950* LinkedIn: *http://www.linkedin.com/in/johann-nallathamby <http://www.linkedin.com/in/johann-nallathamby>* Medium: *https://medium.com/@johann_nallathamby <https://medium.com/@johann_nallathamby>* Twitter: *@dj_nallaa*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
