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
