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
