HI Hsintha,

On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee <[email protected]>
wrote:

> Multi-step authentication is a different case I think, We don't set
> cookies in an intermediate state. What if we use "remember me" ? So the
> cookie will be there even if we close the browswer. isn't it ?
>
Think of a authentication steps.
step1 : Federated authenticator
step2 : Local authenticator.

Then in the step 1 federated authenticator will create a session where 2nd
authentication files. So in the 2nd time also user will automatically
redirect to the federated authenticator and authenticated then fails in 2nd
case.

-Ishara

>
> On Mon, Jan 29, 2018 at 8:15 PM, Ishara Karunarathna <[email protected]>
> wrote:
>
>> Hi Hasintha,
>>
>> Same can happen in multi-step authentication where a user successfully
>> login wiht1st authenticator and fail in the 2nd case.
>>
>> On Mon, Jan 29, 2018 at 8:04 PM, Hasintha Indrajee <[email protected]>
>> wrote:
>>
>>> We have the feature of enabling authorization for service provider [1].
>>> Imagine a scenario where we login to an SP for the very first time and
>>> authorization fails due to some violation of authorization policies. Even
>>> if authorization fails we do set commonAuthId cookie in the response which
>>> means the user has a valid SSO session from that point onwards.
>>>
>>> This can be seen in two perspectives.
>>>
>>> 1) The user is authenticated, but authorization fails, Hence we should
>>> set the cookie for SSO irrespective of authorization decision.
>>>
>>> 2) But this may lead to an inconsistant state. Suppose this is the only
>>> application the user is allowed to login. But due to some policy violation,
>>> the first login fails. In a case of a shared computer this leads to a
>>> deadlock where the user neither can't properly login nor proper logout. We
>>> can use the workaround of calling commonAuthLogout=true. But this will not
>>> do a proper logout. (logging out external idps). Hence in a shared computer
>>> the user has no option.
>>>
>> I think in this case user should close the browser, then he won't get
>> this issue. this is valid for the multi step authentication as well.
>>
>> -Ishara
>>
>>>
>>> Hence I think we can avoid setting cookie until a user successfully
>>> accesses at least a single application upon successful authentication and
>>> authorization. So simply even if the user is authenticated for the very
>>> first time, we will not set the cookie unless the user is authorized to
>>> access that particular application. (This only applies to the very first
>>> app the user is trying to login)
>>>
>>> WDYT ?
>>>
>>>
>>> [1] https://docs.wso2.com/display/IS530/Configuring+Access+C
>>> ontrol+Policy+for+a+Service+Provider
>>>
>>>
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>
>>>
>>
>>
>> --
>> Ishara Karunarathna
>> Technical Lead
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> email: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
>> +94717996791 <071%20799%206791>
>>
>>
>>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


-- 
Ishara Karunarathna
Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to