[prev in list] [next in list] [prev in thread] [next in thread]
List: wsf-java-dev
Subject: Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.
From: Johann Nallathamby <johann () wso2 ! com>
Date: 2018-01-29 15:54:30
Message-ID: CAE-M9tAvTzmVB1v=XhS=TbYLeFMPhkvgQpmvnvABO=1GR-K-5g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <isharak@wso2.com>
wrote:
>
>
> On Mon, Jan 29, 2018 at 8:40 PM, Hasintha Indrajee <hasintha@wso2.com>
> 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 <isharak@wso2.com>
>> wrote:
>>
>>> HI Hsintha,
>>>
>>> On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee <hasintha@wso2.com>
>>> 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 <isharak@wso2.com>
>>>> 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 <hasintha@wso2.com>
>>>>> 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: isharak@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: isharak@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: isharak@wso2.com, blog: isharaaruna.blogspot.com, mobile:
> +94717996791 <+94%2071%20799%206791>
>
>
>
--
*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware
Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
[Attachment #5 (text/html)]
<div dir="ltr">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.<div><br></div><div>Regards,</div><div>Johann.</div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 29, 2018 at 8:47 PM, \
Ishara Karunarathna <span dir="ltr"><<a href="mailto:isharak@wso2.com" \
target="_blank">isharak@wso2.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div \
class="gmail_quote"><span class="">On Mon, Jan 29, 2018 at 8:40 PM, Hasintha Indrajee \
<span dir="ltr"><<a href="mailto:hasintha@wso2.com" \
target="_blank">hasintha@wso2.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">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. \
<div><br></div><div>The idea is if we can avoid writing cookies we can unify the post \
authentication behaviours (missing mandatory claim handling, authorization, \
etc)</div></div></blockquote><br></span><div>As an improvement we can do \
this.<br></div>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. <div><div class="h5"><div><br></div><div>-Ishara \
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
class="m_-6593735984140753624gmail-HOEnZb"><div \
class="m_-6593735984140753624gmail-h5"><div class="gmail_extra"><br><div \
class="gmail_quote">On Mon, Jan 29, 2018 at 8:26 PM, Ishara Karunarathna <span \
dir="ltr"><<a href="mailto:isharak@wso2.com" \
target="_blank">isharak@wso2.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">HI Hsintha, <br><div \
class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Jan 29, 2018 at 8:19 \
PM, Hasintha Indrajee <span dir="ltr"><<a href="mailto:hasintha@wso2.com" \
target="_blank">hasintha@wso2.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">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 ?</div></blockquote></span><div>Think of a authentication \
steps.<br></div><div>step1 : Federated authenticator<br></div><div>step2 : Local \
authenticator.<br><br></div><div>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.<span class="m_-6593735984140753624gmail-m_6091837983433080254HOEnZb"><font \
color="#888888"><br></font></span></div><span \
class="m_-6593735984140753624gmail-m_6091837983433080254HOEnZb"><font \
color="#888888"><div><br></div><div>-Ishara<br></div></font></span><div><div \
class="m_-6593735984140753624gmail-m_6091837983433080254h5"><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div \
class="m_-6593735984140753624gmail-m_6091837983433080254m_-4006467757291459834HOEnZb"><div \
class="m_-6593735984140753624gmail-m_6091837983433080254m_-4006467757291459834h5"><div \
class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 29, 2018 at 8:15 PM, \
Ishara Karunarathna <span dir="ltr"><<a href="mailto:isharak@wso2.com" \
target="_blank">isharak@wso2.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Hasintha,<br><br></div>Same \
can happen in multi-step authentication where a user successfully login wiht1st \
authenticator and fail in the 2nd case. <br><div class="gmail_extra"><br><div \
class="gmail_quote"><span>On Mon, Jan 29, 2018 at 8:04 PM, Hasintha Indrajee <span \
dir="ltr"><<a href="mailto:hasintha@wso2.com" \
target="_blank">hasintha@wso2.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>This can be seen in two perspectives. \
</div><div><br></div><div>1) The user is authenticated, but authorization fails, \
Hence we should set the cookie for SSO irrespective of authorization decision. \
</div><div><br></div><div>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.</div></div></blockquote></span><div>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.<br><br></div><div>-Ishara <br></div><span><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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)</div><div><br></div><div>WDYT \
?</div><div><br><div><div><br></div><div>[1] <a \
href="https://docs.wso2.com/display/IS530/Configuring+Access+Control+Policy+for+a+Service+Provider" \
target="_blank">https://docs.wso2.com/disp<wbr>lay/IS530/Configuring+Access+C<wbr>ontrol+Policy+for+a+Service+Pr<wbr>ovider</a></div><span \
class="m_-6593735984140753624gmail-m_6091837983433080254m_-4006467757291459834m_3370339333021258491m_4664776205856329836HOEnZb"><font \
color="#888888"><div><br></div><div><br clear="all"><div><br></div>-- <br><div \
class="m_-6593735984140753624gmail-m_6091837983433080254m_-4006467757291459834m_3370339333021258491m_4664776205856329836m_1207588403140380338gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div>Hasintha Indrajee</div><div>WSO2, \
Inc.</div><div>Mobile:<a href="tel:+94%2077%20189%202453" value="+94771892453" \
target="_blank">+94 771892453</a></div><div><br></div></div></div></div></div> \
</div></font></span></div></div></div> </blockquote></span></div><span \
class="m_-6593735984140753624gmail-m_6091837983433080254m_-4006467757291459834m_3370339333021258491HOEnZb"><font \
color="#888888"><br><br clear="all"><br>-- <br><div \
class="m_-6593735984140753624gmail-m_6091837983433080254m_-4006467757291459834m_3370339333021258491m_4664776205856329836gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr"><span></span><a href="http:///" target="_blank"></a><span></span>Ishara \
Karunarathna<br>Technical Lead<br>WSO2 Inc. - lean . enterprise . middleware | <a \
href="http://wso2.com" target="_blank">wso2.com</a><br><br>email: <a \
href="mailto:isharak@wso2.com" target="_blank">isharak@wso2.com</a>, blog: <a \
href="http://isharaaruna.blogspot.com" target="_blank">isharaaruna.blogspot.com</a>, \
mobile: <a href="tel:071%20799%206791" value="+94717996791" \
target="_blank">+94717996791</a><br><br><img \
src="http://c.content.wso2.com/signatures/wso2-signature-general.png"><br></div></div></div></div></div></div></div></div></div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div \
class="m_-6593735984140753624gmail-m_6091837983433080254m_-4006467757291459834m_3370339333021258491gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div>Hasintha Indrajee</div><div>WSO2, \
Inc.</div><div>Mobile:<a href="tel:+94%2077%20189%202453" value="+94771892453" \
target="_blank">+94 771892453</a></div><div><br></div></div></div></div></div> </div>
</div></div></blockquote></div></div></div><div><div \
class="m_-6593735984140753624gmail-m_6091837983433080254h5"><br><br \
clear="all"><br>-- <br><div \
class="m_-6593735984140753624gmail-m_6091837983433080254m_-4006467757291459834gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr"><span></span><a href="http:///" target="_blank"></a><span></span>Ishara \
Karunarathna<br>Technical Lead<br>WSO2 Inc. - lean . enterprise . middleware | <a \
href="http://wso2.com" target="_blank">wso2.com</a><br><br>email: <a \
href="mailto:isharak@wso2.com" target="_blank">isharak@wso2.com</a>, blog: <a \
href="http://isharaaruna.blogspot.com" target="_blank">isharaaruna.blogspot.com</a>, \
mobile: <a href="tel:071%20799%206791" value="+94717996791" \
target="_blank">+94717996791</a><br><br><img \
src="http://c.content.wso2.com/signatures/wso2-signature-general.png"><br></div></div></div></div></div></div></div></div></div></div>
</div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div \
class="m_-6593735984140753624gmail-m_6091837983433080254gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div>Hasintha Indrajee</div><div>WSO2, \
Inc.</div><div>Mobile:<a href="tel:+94%2077%20189%202453" value="+94771892453" \
target="_blank">+94 771892453</a></div><div><br></div></div></div></div></div> </div>
</div></div></blockquote></div></div></div><div><div class="h5"><br><br \
clear="all"><br>-- <br><div class="m_-6593735984140753624gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr"><span></span><a href="http:///" target="_blank"></a><span></span>Ishara \
Karunarathna<br>Technical Lead<br>WSO2 Inc. - lean . enterprise . middleware | <a \
href="http://wso2.com" target="_blank">wso2.com</a><br><br>email: <a \
href="mailto:isharak@wso2.com" target="_blank">isharak@wso2.com</a>, blog: <a \
href="http://isharaaruna.blogspot.com" target="_blank">isharaaruna.blogspot.com</a>, \
mobile: <a href="tel:+94%2071%20799%206791" value="+94717996791" \
target="_blank">+94717996791</a><br><br><img \
src="http://c.content.wso2.com/signatures/wso2-signature-general.png"><br></div></div></div></div></div></div></div></div></div></div>
</div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div \
class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div \
dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div><b><br></b></div><div><b>Johann<font color="#666666"> Dilantha \
Nallathamby</font></b><br></div><div><font color="#999999">Senior Lead Solutions \
Engineer</font></div><div><font color="#999999">WSO2, Inc.</font></div><div><font \
color="#999999">lean.enterprise.middleware</font></div><div \
style="color:rgb(136,136,136)"><br></div><div style="color:rgb(136,136,136)"><span \
style="color:rgb(153,153,153)">Mobile: </span><a value="+94773426635" \
style="color:rgb(153,153,153)"><i>+94 77 7776950</i></a></div><div><span \
style="color:rgb(153,153,153)">LinkedIn: </span><font color="#999999"><span \
style="font-size:12.8px"><i><a href="http://www.linkedin.com/in/johann-nallathamby" \
target="_blank">http://www.linkedin.com/in/johann-nallathamby</a></i></span></font></div><div><span \
style="color:rgb(153,153,153)">Medium: </span><span \
style="color:rgb(153,153,153)"><i><a href="https://medium.com/@johann_nallathamby" \
target="_blank">https://medium.com/@johann_nallathamby</a></i></span><span \
style="color:rgb(153,153,153)"><br></span></div><div><span \
style="color:rgb(153,153,153)">Twitter:</span><span style="color:rgb(153,153,153)"> \
</span><i style="color:rgb(153,153,153)">@dj_nallaa</i></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic