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 <isha...@wso2.com> wrote: > > > On Mon, Jan 29, 2018 at 8:40 PM, Hasintha Indrajee <hasin...@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 <isha...@wso2.com> >> wrote: >> >>> HI Hsintha, >>> >>> On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee <hasin...@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 <isha...@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 <hasin...@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: 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 <+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*
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
