Hi Maduranga,
The 'onSkip' in 'promptIdentifierForStep' looks confusing.
The very fist impression that I got while looking at that call back was
that it denotes what needs to be executed when prompting for the identifier
is skipped.
But, as I understood over the discussions, the intention of that is to
decide whether the identifier has been already handled and to validate if
there is any requirement to prompt for the identifier.
On the other hand, there's no indication of the correlation between the
handler and 'onSkip' callback.
May be something like 'onhandled' or 'onprehandled' would be more
appropriate.
On Wed, Jul 11, 2018 at 11:58 AM, Maduranga Siriwardena <madura...@wso2.com>
wrote:
> 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>
>
Thanks,
Malithi.
--
*Malithi Edirisinghe*
Associate Technical Lead
WSO2 Inc.
Mobile : +94 (0) 718176807
malit...@wso2.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
