Hi all,
*We have started on working with the implementation of the Identifier first
login. At the moment we are working on the scenario 1 and 2 above. Below
shows the flow of the authentication flow.Scenario 1Page 1Page 2Scenario
2Page 1Page 2Authentication script for the identifier first login would
look like below.*
*var username;*
*function onInitialRequest(context) {*
* promptUsername ();*
*}*
*function promptUsername () {*
* promptIdentifier(1, {*
* onSuccess: function(context, data) {*
* if (context.request.params.username) {*
* username = context.request.params.username[0];*
* }*
* promptBasic(username);*
* },*
* onSkip: function(context, data) {*
* executeStep(1);*
* },*
* onFail: function(context, data) {*
* Log.info('================================= fail prompt');*
* }*
* });*
*}*
*function promptBasic(username) {*
* executeStep(1, {*
* authenticatorParams: {*
* "local": {*
* "BasicAuthenticator": {*
* "username": username*
* }*
* }*
* }*
* }, {*
* onSuccess: function(context) {*
* Log.info("================================= success basic auth");*
* }, onChangeUser: function(context) {*
* promptUsername ();*
* }, onFail: function(context) {*
* promptBasic(username);*
* }*
* });*
*}*
*We have implemented a function to prompt for username.
promptIdentifier(promptStep, handlers, callbacks) - promptStep: Step number
that this prompt is used for- Handlers: Handlers to call before and after
the prompt. This is a optional parameter. Handlers should return a boolean
value. For pre handler, if true is returned, it will skip prompting for
username and directly go to onSkip callback. If pre handler is not added we
add a default pre handler to check whether a session exist for any of the
authenticators in the step. Default pre handler would look like below.*
*function(step, context) {*
* return checkSession(step, context);*
*}*
*At the moment we have not completed the post handler implementation.*
* - Callbacks: Callbacks to proceed after the prompt.- onSuccess: After
successfully prompting for username, thiscallback will be executed.-
onSkip: If the prompting for username is skipped, this callback will be
executed.- onFail: If the prompting for username is failed, this callback
will be executed.For executeStep function, we have added a new callback,
onChangeUser which will be invoked when “Not <username>? Login as a
different user” link is clicked.*
On Thu, Jul 5, 2018 at 1:55 PM Maduranga Siriwardena <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
>> 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: [email protected]
> Mobile: +94718990591
> Blog: *https://madurangasiriwardena.wordpress.com/
> <https://madurangasiriwardena.wordpress.com/>*
> <http://wso2.com/signature>
>
--
Maduranga Siriwardena
Senior Software Engineer
WSO2 Inc; http://wso2.com/
Email: [email protected]
Mobile: +94718990591
Blog: *https://madurangasiriwardena.wordpress.com/
<https://madurangasiriwardena.wordpress.com/>*
<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
