Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Johann Nallathamby]

I also like the idea of writing the authenticated session cookie at the end
of the authentication sequence; even if it's a multi step authentication.
This will simply solve a lot of inconsistency issues we have I feel. Not
saying we can't solve it in any other way, but they might be bit more
complex.

Regards,
Johann.

On Mon, Jan 29, 2018 at 8:47 PM, Ishara Karunarathna 
wrote:

>
>
> On Mon, Jan 29, 2018 at 8:40 PM, Hasintha Indrajee 
> wrote:
>
>> So that's because we don't have a proper way of reverting it back. Hence
>> isn't it better to not to write cookies until a proper access of an
>> application takes place for this scenario ?. In multi step scenario it's
>> true that there is an idp session, but still the user is not properly
>> logged in since one of the steps failed. Hence next time the next step will
>> be prompted which means he doesn't have a valid session.
>>
>> The idea is if we can avoid writing cookies we can unify the post
>> authentication behaviours (missing mandatory claim handling, authorization,
>> etc)
>>
>
> As an improvement we can do this.
> But shared computer scenario is a rare use case. Even if you use a shared
> computer it's not a good practice to keep the browser session or use
> remember me option.
>
> -Ishara
>
>>
>> On Mon, Jan 29, 2018 at 8:26 PM, Ishara Karunarathna 
>> wrote:
>>
>>> HI Hsintha,
>>>
>>> On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee 
>>> 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 
 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 
> 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: isha...@wso2.com,   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 . 

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Hasintha Indrajee]

So that's because we don't have a proper way of reverting it back. Hence
isn't it better to not to write cookies until a proper access of an
application takes place for this scenario ?. In multi step scenario it's
true that there is an idp session, but still the user is not properly
logged in since one of the steps failed. Hence next time the next step will
be prompted which means he doesn't have a valid session.

The idea is if we can avoid writing cookies we can unify the post
authentication behaviours (missing mandatory claim handling, authorization,
etc)

On Mon, Jan 29, 2018 at 8:26 PM, Ishara Karunarathna 
wrote:

> HI Hsintha,
>
> On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee 
> 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 
>> 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 
>>> 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: isha...@wso2.com,   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: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <071%20799%206791>
>
>
>


-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Hasintha Indrajee]

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 ?

On Mon, Jan 29, 2018 at 8:15 PM, Ishara Karunarathna 
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 
> 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+
>> Control+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: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <071%20799%206791>
>
>
>


-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Ishara Karunarathna]

On Mon, Jan 29, 2018 at 8:40 PM, Hasintha Indrajee 
wrote:

> So that's because we don't have a proper way of reverting it back. Hence
> isn't it better to not to write cookies until a proper access of an
> application takes place for this scenario ?. In multi step scenario it's
> true that there is an idp session, but still the user is not properly
> logged in since one of the steps failed. Hence next time the next step will
> be prompted which means he doesn't have a valid session.
>
> The idea is if we can avoid writing cookies we can unify the post
> authentication behaviours (missing mandatory claim handling, authorization,
> etc)
>

As an improvement we can do this.
But shared computer scenario is a rare use case. Even if you use a shared
computer it's not a good practice to keep the browser session or use
remember me option.

-Ishara

>
> On Mon, Jan 29, 2018 at 8:26 PM, Ishara Karunarathna 
> wrote:
>
>> HI Hsintha,
>>
>> On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee 
>> 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 
>>> 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 
 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: isha...@wso2.com,   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: isha...@wso2.com,   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: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Ishara Karunarathna]

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 
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+Control+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: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Ishara Karunarathna]

HI Hsintha,

On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee 
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 
> 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 
>> 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: isha...@wso2.com,   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: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Hasintha Indrajee]

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.

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+Control+Policy+for+a+Service+Provider



-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev