Overall I think we need not to worry at this stage what happens from one step to another. Authorization will happen at the end of the authentication flow (as Pulasthi explained)... and SP should not be aware of what steps got executed in the authentication flow - it will simply define access control rule for that particular SP...
Thanks & regards, -Prabath On Wed, Oct 19, 2016 at 4:32 AM, Pulasthi Mahawithana <[email protected]> wrote: > Hi All, > > >> Do we execute the authorization handler for each request...? even the >> user is authenticated...? >> > > Yes we do, that way we'll ensure that different policies will be evaluated > per service provider even in the same IdP session. We also don't maintain > an 'authorized' state for the user because it can change per SP. Even > within the same SP the state may change on factors like time of day. > > On Wed, Oct 19, 2016 at 10:18 AM, Godwin Shrimal <[email protected]> wrote: >> >> As per my previous example, if authorization fails after first step >>> (Basic authentication) we should not go for the next step and perform Fido >>> authentication. right ? >> >> >>> I am not quiet sure about the scope we are going to cover with this >>> implement, Looks there are valid user cases as above. >> >> I think these are two use cases. >> >> 1. Authenticate the user with given authentication mechanism, once user >>> is authenticated we check the users authorization. >> >> 2. Depend on users different authentication levels and associated >>> authorization we change the users authentication flow. >> >> >>> So in this implementation we are addressing 1st and later I think we can >>> implement the option 2. >> >> > Yes, for now we'll be addressing the case 1 only. The requirement > mentioned by Eranga also falls to the option 2 here. > > On Wed, Oct 19, 2016 at 1:47 PM, Asela Pathberiya <[email protected]> wrote: > >> >> >> On Wed, Oct 19, 2016 at 12:57 PM, Ishara Karunarathna <[email protected]> >> wrote: >> >>> Hi Farasath, >>> >>> On Wed, Oct 19, 2016 at 12:39 PM, Farasath Ahamed <[email protected]> >>> wrote: >>> >>>> We also need to consider how we are going to handle the 'NotApplicable' >>>> and 'Indeterminate' responses by the XACML engine. Especially the >>>> Indeterminate response that might be due to some missing attributes etc. >>>> >>>> AFAIK the decisions of multiple evaluated policies are currently >>>> evaluated based on the combining algorithm (like Deny overrides, First >>>> applicable) defined globally. >>>> Shouldn't we also allow this algorithm to be decided at SP level? >>>> >>> This is a good point. Policy combining algorithm is a global >>> configuration that effect to all the available policies. >>> since we are having different policy categories in the future we may >>> need to set different policy combining algorithms to >>> different policy categories. >>> Until we implement we may have to live with that. >>> >> WDYT ? >>> >> >> Yes. In SP level; we can define a policy set which contains multiple >> policies & policy combining algo for that policy set... But; Yes. there >> is a global policy combining algo which will effect for all the SP policy >> set. But; we can just filter out the requests for given SP by defining a >> some specific value in target of the SP policy set (may be SP name). >> Therefore; we can avoid the effect from other SP policy set & global >> policy algo (as there is only one policy set to combine) Also; Say; we >> need to enforce some rule for all the SPs. We can have a separate policy >> set which will effect for all the SPs where global policy algo would be >> useful.. >> >> Thanks, >> Asela. >> >> >>> >>> >>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Farasath Ahamed >>>> Software Engineer, WSO2 Inc.; http://wso2.com >>>> Mobile: +94777603866 >>>> Blog: blog.farazath.com >>>> Twitter: @farazath619 <https://twitter.com/farazath619> >>>> <http://wso2.com/signature> >>>> >>>> >>>> >>>> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana < >>>> [email protected]> wrote: >>>> >>>>> Hi All, >>>>> >>>>> As per the current implementation of the Identity Server's >>>>> authentication framework, it does not provide any OOTB authorization >>>>> mechanism for the service providers. We are going to provide this >>>>> capability to Identity server so that the users can be authorized to >>>>> service providers using rules based on user attributes, userstore, time of >>>>> the day, etc. >>>>> >>>>> Following is the proposed sequence for the implementation. >>>>> >>>>> >>>>> [image: Inline image 1] >>>>> >>>>> >>>>> The existing authentication flow is kept as is until the >>>>> authentication steps are completed and authentication result decided. At >>>>> the AuthenticationRequestHandler (after authentication) if the >>>>> authentication is success, we will be calling an AuthorizationHandler with >>>>> the authentication context. AuthenticationHandler is responsible for >>>>> evaluating the configured policies and responding back whether the user is >>>>> authorized or not. If the authorization is not required or handled by the >>>>> SP itself, we'll be providing the capability of bypassing the >>>>> authorization >>>>> step per service provider . >>>>> >>>>> The default implementation of the AuthorizationHandler will be using >>>>> the IS's XACML engine for authorization. It will send a XACML request to >>>>> the PDP and the request will be evaluated against the policies published >>>>> to >>>>> the PDP. Admins can write XACML policies and publish them to allow/deny >>>>> the >>>>> users logging into SPs based on those policies. >>>>> >>>>> Also, to retrieve the basic authentication context values (such as SP >>>>> Name, authenticated user's username/userstore/tenant) we will provide a >>>>> default PIP. In case any complex or derived attributes are needed we can >>>>> retrieve them by writing a custom PIP and use them in the policies. >>>>> >>>>> Please share your thoughts and suggestions. >>>>> >>>>> -- >>>>> *Pulasthi Mahawithana* >>>>> Senior Software Engineer >>>>> WSO2 Inc., http://wso2.com/ >>>>> Mobile: +94-71-5179022 >>>>> Blog: http://blog.pulasthi.org >>>>> >>>>> <https://wso2.com/signature> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >> >> >> -- >> Thanks & Regards, >> Asela >> >> ATL >> Mobile : +94 777 625 933 >> +358 449 228 979 >> >> http://soasecurity.org/ >> http://xacmlinfo.org/ >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Pulasthi Mahawithana* > Senior Software Engineer > WSO2 Inc., http://wso2.com/ > Mobile: +94-71-5179022 > Blog: http://blog.pulasthi.org > > <https://wso2.com/signature> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://facilelogin.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
