After having some discussions about the current behavior, we decided below
changes.
- For executeStep function, we have renamed the the new callback
onChangeUser to onUserAbort which will be invoked when “Not <username>?
Login as a different user” link is clicked.
- We have added new authenticatorParams object with key "common" which
are intended for all the authenticators.
We still couldn't finalize a proper name for handlers and what is the name
of the callback invoked when the prompt is skipped.
Below is the new modified script.
var username;
function onInitialRequest(context) {
promptUsername ();
}
function promptUsername () {
promptIdentifierForStep(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('================================= onFail prompt');
}
});
}
function promptBasic(username) {
executeStep(1, {
authenticatorParams: {
"common": {
"username": username,"inputType":"identifierFirst"
}
}
}, {
onSuccess: function(context) {
Log.info("================================= onSuccess basic
auth");
}, onUserAbort: function(context) {
Log.info("================================= onUserAbort basic
auth");
promptUsername ();
}, onFail: function(context) {
promptBasic(username);
}
});
}
On Tue, Jul 10, 2018 at 9:48 AM Maduranga Siriwardena <madura...@wso2.com>
wrote:
> 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 <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>
>>
>
>
> --
> 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>
>
--
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
