[ 
https://issues.apache.org/jira/browse/NIFI-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Moser updated NIFI-3653:
--------------------------------
    Description: 
Rather than using AbstractPolicyBasedAuthorizer to trigger policy management, 
refactor to use a new interface.  New implementations of this interface can 
then create an authorization chain with existing AbstractPolicyBasedAuthorizer 
sub-classes.

----
While investigating alternate implementations of the Authorizer interface, I 
see the AbstractPolicyBasedAuthorizer is meant to be extended.  It's 
authorize() method is final, however, and does not have an abstract 
doAuthorize() method that sub-classes can extend.

In particular, the existing AbstractPolicyBasedAuthorizer authorize() method 
does not take into account the AuthorizationRequest "resourceContext" in its 
authorization decision.  This is especially important when authorizing access 
to events in Provenance, which places attributes in resouceContext of its 
AuthorizationRequest when obtaining an authorization decision.  I would like to 
use attributes to authorize access to Provenance download & view content 
feature.

If I had my own sub-class of AbstractPolicyBasedAuthorizer, with the 
availability of a doAuthorize() method, then I could maintain my own user 
policies for allowing access to flowfile content via Provenance.

  was:
While investigating alternate implementations of the Authorizer interface, I 
see the AbstractPolicyBasedAuthorizer is meant to be extended.  It's 
authorize() method is final, however, and does not have an abstract 
doAuthorize() method that sub-classes can extend.

In particular, the existing AbstractPolicyBasedAuthorizer authorize() method 
does not take into account the AuthorizationRequest "resourceContext" in its 
authorization decision.  This is especially important when authorizing access 
to events in Provenance, which places attributes in resouceContext of its 
AuthorizationRequest when obtaining an authorization decision.  I would like to 
use attributes to authorize access to Provenance download & view content 
feature.

If I had my own sub-class of AbstractPolicyBasedAuthorizer, with the 
availability of a doAuthorize() method, then I could maintain my own user 
policies for allowing access to flowfile content via Provenance.


> Create PolicyBasedAuthorizer interface to allow authorization chain
> -------------------------------------------------------------------
>
>                 Key: NIFI-3653
>                 URL: https://issues.apache.org/jira/browse/NIFI-3653
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core Framework
>            Reporter: Michael Moser
>            Assignee: Matt Gilman
>
> Rather than using AbstractPolicyBasedAuthorizer to trigger policy management, 
> refactor to use a new interface.  New implementations of this interface can 
> then create an authorization chain with existing 
> AbstractPolicyBasedAuthorizer sub-classes.
> ----
> While investigating alternate implementations of the Authorizer interface, I 
> see the AbstractPolicyBasedAuthorizer is meant to be extended.  It's 
> authorize() method is final, however, and does not have an abstract 
> doAuthorize() method that sub-classes can extend.
> In particular, the existing AbstractPolicyBasedAuthorizer authorize() method 
> does not take into account the AuthorizationRequest "resourceContext" in its 
> authorization decision.  This is especially important when authorizing access 
> to events in Provenance, which places attributes in resouceContext of its 
> AuthorizationRequest when obtaining an authorization decision.  I would like 
> to use attributes to authorize access to Provenance download & view content 
> feature.
> If I had my own sub-class of AbstractPolicyBasedAuthorizer, with the 
> availability of a doAuthorize() method, then I could maintain my own user 
> policies for allowing access to flowfile content via Provenance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to