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? Do we really want to allow that? 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? Why not create their user accounts in IS itself instead of federating?
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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
