Hi, Following is the high level diagram of proposed design,
Claim handling should also be moved to Post Authentication handler, after JIT provisioning handler as we get new claims from the user in JIT. Following diagram shows the internal process logic of JIT handler Currently we do not have a consent page for JIT provisioning flow. With this feature we will be including the consent page as well. Thanks. Regards, Megala On Wed, Apr 11, 2018 at 6:05 PM, Nuwan Dias <nuw...@wso2.com> wrote: > 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 > > -- Megala Uthayakumar Senior Software Engineer Mobile : 0779967122
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
