Hi Asela et al, As the ACR is is a concept comes with OIDC which defines only front channel mechanisms, the current IS natively supports only for front channel mechanisms...
And I think we need to stick to that behavior considering that, we need the user to be aware such elevation of authentication level and prompt for required consents etc. Do you see any other perspective? Thanks, On Wed, Sep 18, 2019 at 1:39 PM Asela Pathberiya <[email protected]> wrote: > > > On Wed, Sep 18, 2019 at 7:09 AM Ruwan Abeykoon <[email protected]> wrote: > >> Hi Nipun, >> This is supported OOTB [1] >> >> [1] https://docs.wso2.com/display/IS570/Working+with+ACR+and+AMR >> > > Does this support with back channel authentication + token granting ? > > Thanks > Asela. > > >> >> Cheers, >> Ruwan A >> >> On Wed, Sep 18, 2019 at 12:44 AM Nipun Thathsara <[email protected]> wrote: >> >>> Hello Everyone, >>> >>> *Use case :* >>> An Oauth application supports accessing both high value and low value >>> resources. Say these resources are protected with two types of scopes as >>> highValueScope and lowValueScope respectively. User can obtain an access >>> token for the lowValueScope with just basic authentication and continue >>> accessing low value resources (Balance between security and the user >>> experience). Whenever the user decides to access a higher value resource >>> (or maybe perform a high value transaction), they indeed need to obtain >>> another access token with the highValueScope. As the name implies, this >>> scope requires a step-up authentication (OTP maybe). Thereafter, the user >>> is free to access either resource. >>> >>> *Practical scenario :* >>> Banking system requesting higher levels of authentication upon >>> performing a transaction worth over 1 million. >>> >>> *Catering this with a custom grant : * >>> First token would be obtained by providing the user credentials (code >>> grant). Once the step-up authentication (SMS OTP here) is triggered, this >>> would be handled by a custom grant which accepts a Bearer token (previously >>> obtained) and issues/validates sms otp for the user. Upon a successful >>> verification only, the second access token will be issued to the >>> application. >>> >>> *Suggestion :* >>> Believe that this is a common use case and the WSO2 Identity Server >>> should be addressing this OOTB rather than going for customizations. Which >>> will enable users to easily adopt any kind of authenticator we support as >>> their step-up option and make the process seamless as much as possible. >>> >>> Appreciate your thoughts. >>> >>> Cheers, >>> -- >>> >>> *Nipun Thathsara* >>> Software Engineer | WSO2 >>> >>> Email : [email protected] >>> Mobile : +94713031875 >>> Web : http://wso2.com >>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>> >> >> >> -- >> Ruwan Abeykoon | Director/Architect | WSO2 Inc. >> (w) +947435800 | Email: [email protected] >> >> > > -- > Thanks & Regards, > Asela > > Mobile : +94 777 625 933 > > http://soasecurity.org/ > http://xacmlinfo.org/ > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Regards, *Darshana Gunawardana*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
