Thanks for explanations, the scenarios on when this is needed is now clear.
On Wed, Apr 11, 2018 at 12:30 PM, Johann Nallathamby <joh...@wso2.com> wrote: > 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* > -- Nuwan Dias Software Architect - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
