On Sat, Jul 15, 2017 at 5:55 AM Darshana Gunawardana <[email protected]> wrote:
> Hi Johann, > > On Fri, Jul 14, 2017 at 5:45 PM Johann Nallathamby <[email protected]> > wrote: > >> Can we change the implementation as follows: >> >> If user is going to login to application Y, which has steps 1 to *m*, >> and user has already logged into Y >> > Should be corrected as application X? > Yes :) > which has steps 1 to *n*, >> > given p <= m , n >> User is already authenticated to step *p* of application Y, if user has >> logged in from any of the optional IdPs in step *p*, within the sequence >> of application X, between steps *p* and n*.* >> > > Anyway I don't think above algorithm is correct because it base on number > of steps. > > 1. The simple way of fixing this is handle LOCAL idp specially. > > Currently the framework calculates to bypass the step p (when loging to > app Y), if user have already logged in at least one of optional IdP in > previous login (app X). > > We have to add extra level of validation if the previously authenticated > IdP picked as the LOCAL IdP where it should check the whether previously > authenticated authenticator (basic authenticator) and current available > authenticator (TOTP) same or not. > > If it's not same, prompt for authentication without bypassing. > +1. This is also a good idea. > > 2. The generic way of fixing this is, consider ACR for each IdP > > Extending the previous solution, (rather having special checks for LOCAL > IdP), check on the authentication level / ACR of the any IdP when it > decide whether user already logged in with that IdP. > I believe this is the generic solution coming with IS 5.5.0. > WDYT? > > Regards, > > >> Can we do something like this for 5.4.0? IMO this will be more practical >> and step up authentication will work seamlessly. >> >> Regards, >> Johann. >> >> On Fri, Jul 14, 2017 at 10:58 AM, Ishara Karunarathna <[email protected]> >> wrote: >> >>> Hi Johan, >>> >>> On Fri, Jul 14, 2017 at 1:56 PM, Johann Nallathamby <[email protected]> >>> wrote: >>> >>>> Hi Asela, >>>> >>>> On Fri, Jul 14, 2017 at 9:34 AM, Asela Pathberiya <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Jul 14, 2017 at 11:31 AM, Harsha Kumara <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> This is regarding the behavior of Authentication flow between >>>>>> multiple service providers. >>>>>> >>>>>> I have created two service providers with following configurations. >>>>>> >>>>>> *SP1* >>>>>> >>>>>> This service provider has two options which allow to users to login >>>>>> either Basic Authentication scheme or Facebook >>>>>> >>>>>> Configuration >>>>>> >>>>>> 1 Authentication Step with MultiOption with Basic Auth and Facebook. >>>>>> >>>>>> >>>>>> *SP2* >>>>>> >>>>>> This service provider has two authentication steps which allow to >>>>>> users to login either Basic Authentication scheme or Facebook and second >>>>>> authentication step with TOTP. >>>>>> >>>>>> Configuration >>>>>> >>>>>> 2 Authentication Steps >>>>>> >>>>>> - 1 Authentication Step with MultiOption with Basic Auth and >>>>>> Facebook. >>>>>> - 2 Authentication Step with TOTP >>>>>> >>>>>> >>>>>> *Behavioral Concern* >>>>>> >>>>>> I have configured two applications with SP1 and SP2 respectively. >>>>>> Then I have logged into the first application with Basic Authentication >>>>>> Scheme which is configured in SP1. >>>>>> >>>>>> But when I going to authentication with my second application which >>>>>> configured with SP2, I have logged into it automatically. >>>>>> >>>>>> Shouldn't it ask for TOTP authentication? Because first application >>>>>> only authenticated with Basic Auth but my second application required >>>>>> Basic >>>>>> Auth + TOTP. >>>>>> >>>>> >>>>> Yes. It should... Session contains the authenticated SP details..... >>>>> Therefore; it can decide based on the SP... If it is not working, it >>>>> seems like a bug.. >>>>> >>>> >>>> I don't think it has ever worked like that because we maintain a list >>>> of IdPs against which we have authenticated so far for any service >>>> provider. We don't consider the step number here. So since basic auth and >>>> TOTP both are for LOCAL IdP, IS considers SP2 also authenticated if we >>>> authenticate with username/password only for SP1. >>>> >>>> We were actually trying this as a logical workaround to have step up >>>> authentication so when the application decided it needs 2nd factor >>>> authentication to send a request using the new service provider ID, but it >>>> seems not possible with current version of IS. >>>> >>> I tested this and got the same behavior. >>> As I remember we have authenticator information as well in the context >>> so we should be able to fix this in future. >>> >>> -Ishara >>> >>>> >>>> Regards, >>>> Johann. >>>> >>>> >>>>> Thanks, >>>>> Asela. >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Harsha >>>>>> >>>>>> -- >>>>>> Harsha Kumara >>>>>> Software Engineer, WSO2 Inc. >>>>>> Mobile: +94775505618 <+94%2077%20550%205618> >>>>>> Blog:harshcreationz.blogspot.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Asela >>>>> >>>>> ATL >>>>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>>>> +358 449 228 979 >>>>> >>>>> http://soasecurity.org/ >>>>> http://xacmlinfo.org/ >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Johann Dilantha Nallathamby* >>>> Senior Lead Solutions Engineer >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+94777776950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Ishara Karunarathna >>> Associate Technical Lead >>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>> >>> email: [email protected], blog: isharaaruna.blogspot.com, mobile: >>> +94717996791 <+94%2071%20799%206791> >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > -- > Regards, > > > *Darshana Gunawardana*Associate Technical Lead > WSO2 Inc.; http://wso2.com > > *E-mail: [email protected] <[email protected]>* > *Mobile: +94718566859*Lean . Enterprise . Middleware > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
