Hi Maduranga, I am not sure if I understood scenario 2 correctly. Are you saying after the user entering the username, based on the already linked federate IdPs for that user account, we will show the login options dynamically?
I was just wondering how all this is going to work with the social sign-up option we implemented recently. Regards, Johann. On Thu, Jul 5, 2018 at 1:55 PM Maduranga Siriwardena <madura...@wso2.com> wrote: > Hi all, > > > > > > > > > > > > > *We had a brainstorming session to identify possible scenarios in > identifier first login. We came up with below 3 scenarios based on the user > experience.Scenario 1Initially user is prompted to enter the username.Based > on the username entered by the user, we decide which type of authenticator > we are going to use and proceed with the selected authenticator. If we > select the basic authenticator, next page would look like below.Scenario > 2Similar to the previous scenario, initially user is prompted to enter the > username. Based on the username entered, we select a set of authenticators > to prompt. One such mechanism would be to use linked user accounts for the > given username. If we select the basic authenticator and the facebook > authenticator from this, page would look like below.Scenario 3In this > scenario, user will have the option to enter the username or select a > authentication option in the first page itself. If the user enter the > username and proceed, it would behave in one of the above scenarios. If the > user selects one of the other multi options, it would behave as normal > multi option login.Authentication flow would behave like below. - First > check if a session is available for the authenticators related to the > identifier first login step.- If the user (browser session) is > authenticated with one or more authenticators, do not prompt anything.- If > the user (browser session) is not authenticated with any authenticator, > prompt for the identifier.- Then user submit the username, decide on what > authenticator(s) should be prompted and prompt the selected > authenticator(s).- When rendering the authenticator page, we will not send > sensitive information via the redirect url. Instead we will be creating a > rest endpoint to fetch the data from the identity server backend, to use > from the authentication endpoint.* > Thanks, > Maduranga > > On Fri, Jun 8, 2018 at 5:03 PM Senthalan Kanagalingam <sentha...@wso2.com> > wrote: > >> Hi all, >> >> I have implemented these proposed commonauth page changes. There are some >> concerns about passing the username to the type 3 page form the type 2 page >> or from the authenticator. We have discussed following ways and found >> limitations in them. >> >> 1. Pass as data in POST request >> - We can't do a POST here as this a direction from the server. >> 2. Pass as a query parameter. >> - The username will be logged somewhere. It will create security >> concerns. >> 3. Set as a temporary cookie >> - If a customer is going to use a different domain to host >> authentication web app, then the domains will differ. >> 4. Provide admin service to get the username using session id by the >> web application. >> - How to protect the access to that service. >> >> Please share if there are any better ways to short this out. We are going >> to stop further implementation on this until figure out a better solution. >> >> thanks, >> Senthalan >> >> On Thu, Jun 7, 2018 at 6:43 PM Senthalan Kanagalingam <sentha...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> I am currently working on implementing Identifier first in >>> authentication flow. This is not an authenticator. This will be like a >>> pre-step which will get the hint(username) from the user and then >>> continue the authentication steps. We can extend this to change the >>> authentication flow based on the username (domain, user-store, tenant). >>> >>> To support this, we will have 3 type of login page which will be decided >>> by a parameter passes to the basic authenticator in the authentication >>> script. >>> >>> 1. The default one. >>> 2. The default one without the password. >>> >>> [image: Screenshot from 2018-06-07 17-32-44.png] >>> 3. Only the password box with signin button. >>> [image: Screenshot from 2018-06-07 17-35-07.png] >>> >>> If the username is provided as a hint(or provided in reqest or found in >>> the cookie), then basicauth will display type 3(or other authenticator >>> decided using the hint). Else type 2 and then type 3. >>> >>> First I have planned to implement the login page changes. Because we are >>> planned to implement getting user input in the authentication flow. So >>> after that, we can implement getting the hint from the user. >>> >>> Please share your thoughts about this implementation. >>> >>> Thanks, >>> Senthalan. >>> -- >>> >>> *Senthalan Kanagalingam* >>> *Software Engineer - WSO2 Inc.* >>> *Mobile : +94 (0) 77 18 77 466* >>> <http://wso2.com/signature> >>> >> >> >> -- >> >> *Senthalan Kanagalingam* >> *Software Engineer - WSO2 Inc.* >> *Mobile : +94 (0) 77 18 77 466* >> <http://wso2.com/signature> >> > > > -- > Maduranga Siriwardena > Senior Software Engineer > WSO2 Inc; http://wso2.com/ > > Email: madura...@wso2.com > Mobile: +94718990591 > Blog: *https://madurangasiriwardena.wordpress.com/ > <https://madurangasiriwardena.wordpress.com/>* > <http://wso2.com/signature> > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *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
