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 <as...@wso2.com> wrote: > > > On Wed, Sep 18, 2019 at 7:09 AM Ruwan Abeykoon <ruw...@wso2.com> 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 <nip...@wso2.com> 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 : nip...@wso2.com >>> Mobile : +94713031875 >>> Web : http://wso2.com >>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>> >> >> >> -- >> Ruwan Abeykoon | Director/Architect | WSO2 Inc. >> (w) +947435800 | Email: ruw...@wso2.com >> >> > > -- > Thanks & Regards, > Asela > > Mobile : +94 777 625 933 > > http://soasecurity.org/ > http://xacmlinfo.org/ > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Regards, *Darshana Gunawardana*Technical Lead WSO2 Inc.; http://wso2.com *E-mail: darsh...@wso2.com <darsh...@wso2.com>* *Mobile: +94718566859*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
