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? 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. 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. 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
