You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Darren Govoni <da...@ontrenet.com> on 2020/11/04 16:53:40 UTC
Authorization Framework
Greetings!
We have an internal need to move to a specific PK based authorization for all our nifi processors. Currently, authorizations such as basic auth and kerberos seem to be wired directly inside the processors. My design approach to addressing our need also seeks to factor authorization out of processors where specific authorization handlers can be composed and config/run time and lighten the responsibilities inside processor classes.
Towards this end, my initial design goals for this framework are thus:
1) Allow various kinds of authorization handlers to be written and added to processors without necessarily recoding the processor.
2) Allow for a pipeline effect where one or more authorizers might need to operate at the same time.
3) Do not disrupt existing processors that rely on their internal coding for authorization
4) Use appropriate design patterns to allow for flexible implementations of principals, credentials and other authorization assets.
5) Secure any clear text assets (usernames and passwords) in existing authorizations when moving them inside the framework.
How does the community conduct initial design reviews of such changes? We would be quite a ways from contributing anything back but want to keep in sync with community practices and expectations to make such an offering immediately useful.
Regards,
Darren
Re: Authorization Framework
Posted by Bryan Bende <bb...@gmail.com>.
In the traditional scenario it would work like the following…
1) Processor in NiFi is configured to use some credentials, lets say a key tab
2) Processor runs and attempts authentication to HDFS using the configured key tab
3) If authentication is successful, then HDFS performs authorization, meaning HDFS decides if the nifi principal can perform the given action
Step 3 is really dependent on how HDFS is configured…
It may be based simply on the file permissions, for example if it is a write operation to /tmp then HDFS decides if the NiFi user has write permissions to that directory.
It could also be that HDFS is integration with an authorization framework like Apache Ranger where policies can be defined in Ranger that determine what principals can do in HDFS.
In either case, the point is that the decision of what can be done in HDFS should happen somewhere behind HDFS, not in NiFi.
I can’t really tell how this lines up with what you’d like to do. Where would your authorization system fit into the above steps?
> On Nov 4, 2020, at 4:05 PM, Darren Govoni <da...@ontrenet.com> wrote:
>
> Sure thing Joe. Let me provide a more clear use case.
>
> As I mentioned, our identities are established at the enterprise level. So while I mentioned the existing auth(entication yes) I see in processors now (basic auth, kerberos), probably the general use case there is to authenticate to a remote service and then you're good, our environment separates authentication and authorization and those are managed by different systems entirely at different points in time.
>
> Servers will have identifying certs that are issued and managed automatically and those certs will be used to identify the requesting service's (e.g. NIFI) access to another enterprise layer (e.g. HDFS). In our authorization system, an admin might grant specific privileges to a principal (e.g. NIFI) allowing it to only read or write or access this data set or that data set in another service. This is above and beyond anything the service endpoint itself might expose.
>
> In our environment there is no need to trigger an authentication of the principal (X.509 cert) for that particular server/service as the plumbing for that is "out of band" for nifi processors as best as I can tell. But I'm still learning these things. 🙂
>
> In the spirit of test-driven development, we (our team and company) will have to understand the exact needs before finalizing a viable framework or implementation of PKInit (what our company refers to it), so it's still early, but I want to implement these business needs in a way that makes sense for us, and for the direction Nifi is going, in the event others might find our solution useful. For now, it's mainly exploring/proving pattens and having open discussions. 🙂
>
> Once we get some more concrete workflow decided on our end, I can share it and we can talk about it can best be accommodated.
>
> Darren
>
>
> From: Joe Witt <jo...@gmail.com>
> Sent: Wednesday, November 4, 2020 3:48 PM
> To: users@nifi.apache.org <us...@nifi.apache.org>
> Subject: Re: Authorization Framework
>
> Darren
>
> Its difficult to get to what you have in mind as you keep saying authorization but then giving examples of authentication protocols (kerberos/keytabs, basic auth).
>
> Lets focus though on your later comment about hdfs processors. Take for example put hdfs...it connects to and hdfs cluster to put data. In terms of the actual dataflow we get to authenticate/convey our identity to hdfs and where we want to write data. Hdfs then gets to accept or reiect that. *That* is authorization. Now then, speaking in terms of flow administration in nifi we do have authorization scenarios. Like who can view the processor, start it, stop it, and so on. This kind of authorization in nifi IS something that can be extended/altered to meet some awesome and complex needs.
>
> Lets keep circling closer to your intent here
>
> thanks
>
> On Wed, Nov 4, 2020 at 1:38 PM Darren Govoni <darren@ontrenet.com <ma...@ontrenet.com>> wrote:
> Hi Bryan,
> Thanks for the input. Right now, I'm really exploring how better to accommodate migrating from the use of keytabs to our corporate mandate for pkinit support. Observing that the current authorizations in processors (basic auth, kerberos etc) are tightly wired, it suggested to me an opportunity to move security more into an "aspect" of processors rather than woven into the processor specific code. Of course, there are interactions that take place throughout the behavior of the processor.
>
> This is a fairly common approach to security, noting that for any given behavior, it can be done all the same securely or without security. So I would think it should be possible to abstract the authorizations as needed, and there are a variety of patterns to pull those details out of the components needing them. 🙂
>
> I suppose the difference is more subtle these days, but in my mind Authentication does one thing. Decide if principal (e.g.username) is who they say they are, using the provided credentials (e.g. password). Once this is established the authentication service will return an identifying token, cert etc. That's it. Now, some services will inline this activity along with authorization.
>
> For us, this is already handled and the identity is established as a digitally signed X.509 certificate. Thus, our primary need is to consult our security services which will decide if that principal is allowed to do something - such as use HDFSProcessor, Query Solr, etc.
>
> In looking at the current code in the processors (and I haven't studied them all but will look more closely at HDFS), it didn't seem like a good approach to layer another authorization (PKInit) into that existing code and it will certainly get crowded in processors doing that, which should focus on processing. Just my opinions so far! Subject to change.
>
> Darren
>
> From: Bryan Bende <bbende@gmail.com <ma...@gmail.com>>
> Sent: Wednesday, November 4, 2020 3:22 PM
>
> To: users@nifi.apache.org <ma...@nifi.apache.org> <users@nifi.apache.org <ma...@nifi.apache.org>>
> Subject: Re: Authorization Framework
>
> Darren,
>
> I also thought you were talking about authentication. Processors don’t really perform authorization, they provide credentials to some system which is authentication, the system then decides if they authenticated successfully, and then some systems may also perform authorization to determine if the authenticated identity is allowed to perform the action. The examples you gave of basic auth and kerberos are both authentication mechanisms.
>
> I think it will be very hard to not have this logic embedded in processors since many times it is specific to the client library being used. For example, HDFS processors use the UserGroupInformation class from hadoop-common for kerberos authentication where as Kafka processors use the Kafka client which takes a JAAS config string.
>
> The parts that can be factored out are usually common things like credential holders, such as SSLContextService or KeytabCredentialService, both of which don’t really do anything besides hold values that are then used in different ways by various processors.
>
> If we are missing what you are talking about, let us know.
>
> Thanks,
>
> Bryan
>
>> On Nov 4, 2020, at 2:45 PM, Darren Govoni <darren@ontrenet.com <ma...@ontrenet.com>> wrote:
>>
>> Thanks Joe.
>>
>> Just looking to see where community might be going down the road with respect to processor security so we can keep our efforts aligned.
>>
>> In regards to your question I primarily mean authorization. Our company already has a SSO that establishes identity credentials so these are then used to authorize specific functions and access to certain infrastructure systems when constructing flows.
>>
>> Darren
>>
>> Sent from my Verizon, Samsung Galaxy smartphone
>> Get Outlook for Android <https://aka.ms/ghei36>
>> From: Joe Witt <joe.witt@gmail.com <ma...@gmail.com>>
>> Sent: Wednesday, November 4, 2020 12:29:35 PM
>> To: users@nifi.apache.org <ma...@nifi.apache.org> <users@nifi.apache.org <ma...@nifi.apache.org>>
>> Subject: Re: Authorization Framework
>>
>> Darren
>>
>> You will want this thread on dev list to get traction.
>>
>> Also please clarify if you mean authorization or whether you mean authentication. I read all usages as meaning to discuss authentication.
>>
>> thanks
>>
>> On Wed, Nov 4, 2020 at 9:53 AM Darren Govoni <darren@ontrenet.com <ma...@ontrenet.com>> wrote:
>> Greetings!
>>
>> We have an internal need to move to a specific PK based authorization for all our nifi processors. Currently, authorizations such as basic auth and kerberos seem to be wired directly inside the processors. My design approach to addressing our need also seeks to factor authorization out of processors where specific authorization handlers can be composed and config/run time and lighten the responsibilities inside processor classes.
>>
>> Towards this end, my initial design goals for this framework are thus:
>>
>> 1) Allow various kinds of authorization handlers to be written and added to processors without necessarily recoding the processor.
>> 2) Allow for a pipeline effect where one or more authorizers might need to operate at the same time.
>> 3) Do not disrupt existing processors that rely on their internal coding for authorization
>> 4) Use appropriate design patterns to allow for flexible implementations of principals, credentials and other authorization assets.
>> 5) Secure any clear text assets (usernames and passwords) in existing authorizations when moving them inside the framework.
>>
>> How does the community conduct initial design reviews of such changes? We would be quite a ways from contributing anything back but want to keep in sync with community practices and expectations to make such an offering immediately useful.
>>
>> Regards,
>> Darren
Re: Authorization Framework
Posted by Darren Govoni <da...@ontrenet.com>.
Sure thing Joe. Let me provide a more clear use case.
As I mentioned, our identities are established at the enterprise level. So while I mentioned the existing auth(entication yes) I see in processors now (basic auth, kerberos), probably the general use case there is to authenticate to a remote service and then you're good, our environment separates authentication and authorization and those are managed by different systems entirely at different points in time.
Servers will have identifying certs that are issued and managed automatically and those certs will be used to identify the requesting service's (e.g. NIFI) access to another enterprise layer (e.g. HDFS). In our authorization system, an admin might grant specific privileges to a principal (e.g. NIFI) allowing it to only read or write or access this data set or that data set in another service. This is above and beyond anything the service endpoint itself might expose.
In our environment there is no need to trigger an authentication of the principal (X.509 cert) for that particular server/service as the plumbing for that is "out of band" for nifi processors as best as I can tell. But I'm still learning these things. 🙂
In the spirit of test-driven development, we (our team and company) will have to understand the exact needs before finalizing a viable framework or implementation of PKInit (what our company refers to it), so it's still early, but I want to implement these business needs in a way that makes sense for us, and for the direction Nifi is going, in the event others might find our solution useful. For now, it's mainly exploring/proving pattens and having open discussions. 🙂
Once we get some more concrete workflow decided on our end, I can share it and we can talk about it can best be accommodated.
Darren
________________________________
From: Joe Witt <jo...@gmail.com>
Sent: Wednesday, November 4, 2020 3:48 PM
To: users@nifi.apache.org <us...@nifi.apache.org>
Subject: Re: Authorization Framework
Darren
Its difficult to get to what you have in mind as you keep saying authorization but then giving examples of authentication protocols (kerberos/keytabs, basic auth).
Lets focus though on your later comment about hdfs processors. Take for example put hdfs...it connects to and hdfs cluster to put data. In terms of the actual dataflow we get to authenticate/convey our identity to hdfs and where we want to write data. Hdfs then gets to accept or reiect that. *That* is authorization. Now then, speaking in terms of flow administration in nifi we do have authorization scenarios. Like who can view the processor, start it, stop it, and so on. This kind of authorization in nifi IS something that can be extended/altered to meet some awesome and complex needs.
Lets keep circling closer to your intent here
thanks
On Wed, Nov 4, 2020 at 1:38 PM Darren Govoni <da...@ontrenet.com>> wrote:
Hi Bryan,
Thanks for the input. Right now, I'm really exploring how better to accommodate migrating from the use of keytabs to our corporate mandate for pkinit support. Observing that the current authorizations in processors (basic auth, kerberos etc) are tightly wired, it suggested to me an opportunity to move security more into an "aspect" of processors rather than woven into the processor specific code. Of course, there are interactions that take place throughout the behavior of the processor.
This is a fairly common approach to security, noting that for any given behavior, it can be done all the same securely or without security. So I would think it should be possible to abstract the authorizations as needed, and there are a variety of patterns to pull those details out of the components needing them. 🙂
I suppose the difference is more subtle these days, but in my mind Authentication does one thing. Decide if principal (e.g.username) is who they say they are, using the provided credentials (e.g. password). Once this is established the authentication service will return an identifying token, cert etc. That's it. Now, some services will inline this activity along with authorization.
For us, this is already handled and the identity is established as a digitally signed X.509 certificate. Thus, our primary need is to consult our security services which will decide if that principal is allowed to do something - such as use HDFSProcessor, Query Solr, etc.
In looking at the current code in the processors (and I haven't studied them all but will look more closely at HDFS), it didn't seem like a good approach to layer another authorization (PKInit) into that existing code and it will certainly get crowded in processors doing that, which should focus on processing. Just my opinions so far! Subject to change.
Darren
________________________________
From: Bryan Bende <bb...@gmail.com>>
Sent: Wednesday, November 4, 2020 3:22 PM
To: users@nifi.apache.org<ma...@nifi.apache.org> <us...@nifi.apache.org>>
Subject: Re: Authorization Framework
Darren,
I also thought you were talking about authentication. Processors don’t really perform authorization, they provide credentials to some system which is authentication, the system then decides if they authenticated successfully, and then some systems may also perform authorization to determine if the authenticated identity is allowed to perform the action. The examples you gave of basic auth and kerberos are both authentication mechanisms.
I think it will be very hard to not have this logic embedded in processors since many times it is specific to the client library being used. For example, HDFS processors use the UserGroupInformation class from hadoop-common for kerberos authentication where as Kafka processors use the Kafka client which takes a JAAS config string.
The parts that can be factored out are usually common things like credential holders, such as SSLContextService or KeytabCredentialService, both of which don’t really do anything besides hold values that are then used in different ways by various processors.
If we are missing what you are talking about, let us know.
Thanks,
Bryan
On Nov 4, 2020, at 2:45 PM, Darren Govoni <da...@ontrenet.com>> wrote:
Thanks Joe.
Just looking to see where community might be going down the road with respect to processor security so we can keep our efforts aligned.
In regards to your question I primarily mean authorization. Our company already has a SSO that establishes identity credentials so these are then used to authorize specific functions and access to certain infrastructure systems when constructing flows.
Darren
Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Joe Witt <jo...@gmail.com>>
Sent: Wednesday, November 4, 2020 12:29:35 PM
To: users@nifi.apache.org<ma...@nifi.apache.org> <us...@nifi.apache.org>>
Subject: Re: Authorization Framework
Darren
You will want this thread on dev list to get traction.
Also please clarify if you mean authorization or whether you mean authentication. I read all usages as meaning to discuss authentication.
thanks
On Wed, Nov 4, 2020 at 9:53 AM Darren Govoni <da...@ontrenet.com>> wrote:
Greetings!
We have an internal need to move to a specific PK based authorization for all our nifi processors. Currently, authorizations such as basic auth and kerberos seem to be wired directly inside the processors. My design approach to addressing our need also seeks to factor authorization out of processors where specific authorization handlers can be composed and config/run time and lighten the responsibilities inside processor classes.
Towards this end, my initial design goals for this framework are thus:
1) Allow various kinds of authorization handlers to be written and added to processors without necessarily recoding the processor.
2) Allow for a pipeline effect where one or more authorizers might need to operate at the same time.
3) Do not disrupt existing processors that rely on their internal coding for authorization
4) Use appropriate design patterns to allow for flexible implementations of principals, credentials and other authorization assets.
5) Secure any clear text assets (usernames and passwords) in existing authorizations when moving them inside the framework.
How does the community conduct initial design reviews of such changes? We would be quite a ways from contributing anything back but want to keep in sync with community practices and expectations to make such an offering immediately useful.
Regards,
Darren
Re: Authorization Framework
Posted by Joe Witt <jo...@gmail.com>.
Darren
Its difficult to get to what you have in mind as you keep saying
authorization but then giving examples of authentication protocols
(kerberos/keytabs, basic auth).
Lets focus though on your later comment about hdfs processors. Take for
example put hdfs...it connects to and hdfs cluster to put data. In terms
of the actual dataflow we get to authenticate/convey our identity to hdfs
and where we want to write data. Hdfs then gets to accept or reiect that.
*That* is authorization. Now then, speaking in terms of flow
administration in nifi we do have authorization scenarios. Like who can
view the processor, start it, stop it, and so on. This kind of
authorization in nifi IS something that can be extended/altered to meet
some awesome and complex needs.
Lets keep circling closer to your intent here
thanks
On Wed, Nov 4, 2020 at 1:38 PM Darren Govoni <da...@ontrenet.com> wrote:
> Hi Bryan,
> Thanks for the input. Right now, I'm really exploring how better to
> accommodate migrating from the use of keytabs to our corporate mandate for
> pkinit support. Observing that the current authorizations in processors
> (basic auth, kerberos etc) are tightly wired, it suggested to me an
> opportunity to move security more into an "aspect" of processors rather
> than woven into the processor specific code. Of course, there are
> interactions that take place throughout the behavior of the processor.
>
> This is a fairly common approach to security, noting that for any given
> behavior, it can be done all the same securely or without security. So I
> would think it should be possible to abstract the authorizations as needed,
> and there are a variety of patterns to pull those details out of the
> components needing them. 🙂
>
> I suppose the difference is more subtle these days, but in my mind
> Authentication does one thing. Decide if principal (e.g.username) is who
> they say they are, using the provided credentials (e.g. password). Once
> this is established the authentication service will return an identifying
> token, cert etc. That's it. Now, some services will inline this activity
> along with authorization.
>
> For us, this is already handled and the identity is established as a
> digitally signed X.509 certificate. Thus, our primary need is to consult
> our security services which will decide if that principal is allowed to do
> something - such as use HDFSProcessor, Query Solr, etc.
>
> In looking at the current code in the processors (and I haven't studied
> them all but will look more closely at HDFS), it didn't seem like a good
> approach to layer another authorization (PKInit) into that existing code
> and it will certainly get crowded in processors doing that, which should
> focus on processing. Just my opinions so far! Subject to change.
>
> Darren
>
> ------------------------------
> *From:* Bryan Bende <bb...@gmail.com>
> *Sent:* Wednesday, November 4, 2020 3:22 PM
>
> *To:* users@nifi.apache.org <us...@nifi.apache.org>
> *Subject:* Re: Authorization Framework
>
> Darren,
>
> I also thought you were talking about authentication. Processors don’t
> really perform authorization, they provide credentials to some system which
> is authentication, the system then decides if they authenticated
> successfully, and then some systems may also perform authorization to
> determine if the authenticated identity is allowed to perform the action.
> The examples you gave of basic auth and kerberos are both authentication
> mechanisms.
>
> I think it will be very hard to not have this logic embedded in processors
> since many times it is specific to the client library being used. For
> example, HDFS processors use the UserGroupInformation class from
> hadoop-common for kerberos authentication where as Kafka processors use the
> Kafka client which takes a JAAS config string.
>
> The parts that can be factored out are usually common things like
> credential holders, such as SSLContextService or KeytabCredentialService,
> both of which don’t really do anything besides hold values that are then
> used in different ways by various processors.
>
> If we are missing what you are talking about, let us know.
>
> Thanks,
>
> Bryan
>
> On Nov 4, 2020, at 2:45 PM, Darren Govoni <da...@ontrenet.com> wrote:
>
> Thanks Joe.
>
> Just looking to see where community might be going down the road with
> respect to processor security so we can keep our efforts aligned.
>
> In regards to your question I primarily mean authorization. Our company
> already has a SSO that establishes identity credentials so these are then
> used to authorize specific functions and access to certain infrastructure
> systems when constructing flows.
>
> Darren
>
> Sent from my Verizon, Samsung Galaxy smartphone
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* Joe Witt <jo...@gmail.com>
> *Sent:* Wednesday, November 4, 2020 12:29:35 PM
> *To:* users@nifi.apache.org <us...@nifi.apache.org>
> *Subject:* Re: Authorization Framework
>
> Darren
>
> You will want this thread on dev list to get traction.
>
> Also please clarify if you mean authorization or whether you mean
> authentication. I read all usages as meaning to discuss authentication.
>
> thanks
>
> On Wed, Nov 4, 2020 at 9:53 AM Darren Govoni <da...@ontrenet.com> wrote:
>
> Greetings!
>
> We have an internal need to move to a specific PK based authorization for
> all our nifi processors. Currently, authorizations such as basic auth and
> kerberos seem to be wired directly inside the processors. My design
> approach to addressing our need also seeks to factor authorization out of
> processors where specific authorization handlers can be composed and
> config/run time and lighten the responsibilities inside processor classes.
>
> Towards this end, my initial design goals for this framework are thus:
>
> 1) Allow various kinds of authorization handlers to be written and added
> to processors without necessarily recoding the processor.
> 2) Allow for a pipeline effect where one or more authorizers might need to
> operate at the same time.
> 3) Do not disrupt existing processors that rely on their internal coding
> for authorization
> 4) Use appropriate design patterns to allow for flexible implementations
> of principals, credentials and other authorization assets.
> 5) Secure any clear text assets (usernames and passwords) in existing
> authorizations when moving them inside the framework.
>
> How does the community conduct initial design reviews of such changes? We
> would be quite a ways from contributing anything back but want to keep in
> sync with community practices and expectations to make such an offering
> immediately useful.
>
> Regards,
> Darren
>
>
>
Re: Authorization Framework
Posted by Darren Govoni <da...@ontrenet.com>.
Hi Bryan,
Thanks for the input. Right now, I'm really exploring how better to accommodate migrating from the use of keytabs to our corporate mandate for pkinit support. Observing that the current authorizations in processors (basic auth, kerberos etc) are tightly wired, it suggested to me an opportunity to move security more into an "aspect" of processors rather than woven into the processor specific code. Of course, there are interactions that take place throughout the behavior of the processor.
This is a fairly common approach to security, noting that for any given behavior, it can be done all the same securely or without security. So I would think it should be possible to abstract the authorizations as needed, and there are a variety of patterns to pull those details out of the components needing them. 🙂
I suppose the difference is more subtle these days, but in my mind Authentication does one thing. Decide if principal (e.g.username) is who they say they are, using the provided credentials (e.g. password). Once this is established the authentication service will return an identifying token, cert etc. That's it. Now, some services will inline this activity along with authorization.
For us, this is already handled and the identity is established as a digitally signed X.509 certificate. Thus, our primary need is to consult our security services which will decide if that principal is allowed to do something - such as use HDFSProcessor, Query Solr, etc.
In looking at the current code in the processors (and I haven't studied them all but will look more closely at HDFS), it didn't seem like a good approach to layer another authorization (PKInit) into that existing code and it will certainly get crowded in processors doing that, which should focus on processing. Just my opinions so far! Subject to change.
Darren
________________________________
From: Bryan Bende <bb...@gmail.com>
Sent: Wednesday, November 4, 2020 3:22 PM
To: users@nifi.apache.org <us...@nifi.apache.org>
Subject: Re: Authorization Framework
Darren,
I also thought you were talking about authentication. Processors don’t really perform authorization, they provide credentials to some system which is authentication, the system then decides if they authenticated successfully, and then some systems may also perform authorization to determine if the authenticated identity is allowed to perform the action. The examples you gave of basic auth and kerberos are both authentication mechanisms.
I think it will be very hard to not have this logic embedded in processors since many times it is specific to the client library being used. For example, HDFS processors use the UserGroupInformation class from hadoop-common for kerberos authentication where as Kafka processors use the Kafka client which takes a JAAS config string.
The parts that can be factored out are usually common things like credential holders, such as SSLContextService or KeytabCredentialService, both of which don’t really do anything besides hold values that are then used in different ways by various processors.
If we are missing what you are talking about, let us know.
Thanks,
Bryan
On Nov 4, 2020, at 2:45 PM, Darren Govoni <da...@ontrenet.com>> wrote:
Thanks Joe.
Just looking to see where community might be going down the road with respect to processor security so we can keep our efforts aligned.
In regards to your question I primarily mean authorization. Our company already has a SSO that establishes identity credentials so these are then used to authorize specific functions and access to certain infrastructure systems when constructing flows.
Darren
Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Joe Witt <jo...@gmail.com>>
Sent: Wednesday, November 4, 2020 12:29:35 PM
To: users@nifi.apache.org<ma...@nifi.apache.org> <us...@nifi.apache.org>>
Subject: Re: Authorization Framework
Darren
You will want this thread on dev list to get traction.
Also please clarify if you mean authorization or whether you mean authentication. I read all usages as meaning to discuss authentication.
thanks
On Wed, Nov 4, 2020 at 9:53 AM Darren Govoni <da...@ontrenet.com>> wrote:
Greetings!
We have an internal need to move to a specific PK based authorization for all our nifi processors. Currently, authorizations such as basic auth and kerberos seem to be wired directly inside the processors. My design approach to addressing our need also seeks to factor authorization out of processors where specific authorization handlers can be composed and config/run time and lighten the responsibilities inside processor classes.
Towards this end, my initial design goals for this framework are thus:
1) Allow various kinds of authorization handlers to be written and added to processors without necessarily recoding the processor.
2) Allow for a pipeline effect where one or more authorizers might need to operate at the same time.
3) Do not disrupt existing processors that rely on their internal coding for authorization
4) Use appropriate design patterns to allow for flexible implementations of principals, credentials and other authorization assets.
5) Secure any clear text assets (usernames and passwords) in existing authorizations when moving them inside the framework.
How does the community conduct initial design reviews of such changes? We would be quite a ways from contributing anything back but want to keep in sync with community practices and expectations to make such an offering immediately useful.
Regards,
Darren
Re: Authorization Framework
Posted by Bryan Bende <bb...@gmail.com>.
Darren,
I also thought you were talking about authentication. Processors don’t really perform authorization, they provide credentials to some system which is authentication, the system then decides if they authenticated successfully, and then some systems may also perform authorization to determine if the authenticated identity is allowed to perform the action. The examples you gave of basic auth and kerberos are both authentication mechanisms.
I think it will be very hard to not have this logic embedded in processors since many times it is specific to the client library being used. For example, HDFS processors use the UserGroupInformation class from hadoop-common for kerberos authentication where as Kafka processors use the Kafka client which takes a JAAS config string.
The parts that can be factored out are usually common things like credential holders, such as SSLContextService or KeytabCredentialService, both of which don’t really do anything besides hold values that are then used in different ways by various processors.
If we are missing what you are talking about, let us know.
Thanks,
Bryan
> On Nov 4, 2020, at 2:45 PM, Darren Govoni <da...@ontrenet.com> wrote:
>
> Thanks Joe.
>
> Just looking to see where community might be going down the road with respect to processor security so we can keep our efforts aligned.
>
> In regards to your question I primarily mean authorization. Our company already has a SSO that establishes identity credentials so these are then used to authorize specific functions and access to certain infrastructure systems when constructing flows.
>
> Darren
>
> Sent from my Verizon, Samsung Galaxy smartphone
> Get Outlook for Android <https://aka.ms/ghei36>
> From: Joe Witt <jo...@gmail.com>
> Sent: Wednesday, November 4, 2020 12:29:35 PM
> To: users@nifi.apache.org <us...@nifi.apache.org>
> Subject: Re: Authorization Framework
>
> Darren
>
> You will want this thread on dev list to get traction.
>
> Also please clarify if you mean authorization or whether you mean authentication. I read all usages as meaning to discuss authentication.
>
> thanks
>
> On Wed, Nov 4, 2020 at 9:53 AM Darren Govoni <darren@ontrenet.com <ma...@ontrenet.com>> wrote:
> Greetings!
>
> We have an internal need to move to a specific PK based authorization for all our nifi processors. Currently, authorizations such as basic auth and kerberos seem to be wired directly inside the processors. My design approach to addressing our need also seeks to factor authorization out of processors where specific authorization handlers can be composed and config/run time and lighten the responsibilities inside processor classes.
>
> Towards this end, my initial design goals for this framework are thus:
>
> 1) Allow various kinds of authorization handlers to be written and added to processors without necessarily recoding the processor.
> 2) Allow for a pipeline effect where one or more authorizers might need to operate at the same time.
> 3) Do not disrupt existing processors that rely on their internal coding for authorization
> 4) Use appropriate design patterns to allow for flexible implementations of principals, credentials and other authorization assets.
> 5) Secure any clear text assets (usernames and passwords) in existing authorizations when moving them inside the framework.
>
> How does the community conduct initial design reviews of such changes? We would be quite a ways from contributing anything back but want to keep in sync with community practices and expectations to make such an offering immediately useful.
>
> Regards,
> Darren
>
Re: Authorization Framework
Posted by Darren Govoni <da...@ontrenet.com>.
Thanks Joe.
Just looking to see where community might be going down the road with respect to processor security so we can keep our efforts aligned.
In regards to your question I primarily mean authorization. Our company already has a SSO that establishes identity credentials so these are then used to authorize specific functions and access to certain infrastructure systems when constructing flows.
Darren
Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Joe Witt <jo...@gmail.com>
Sent: Wednesday, November 4, 2020 12:29:35 PM
To: users@nifi.apache.org <us...@nifi.apache.org>
Subject: Re: Authorization Framework
Darren
You will want this thread on dev list to get traction.
Also please clarify if you mean authorization or whether you mean authentication. I read all usages as meaning to discuss authentication.
thanks
On Wed, Nov 4, 2020 at 9:53 AM Darren Govoni <da...@ontrenet.com>> wrote:
Greetings!
We have an internal need to move to a specific PK based authorization for all our nifi processors. Currently, authorizations such as basic auth and kerberos seem to be wired directly inside the processors. My design approach to addressing our need also seeks to factor authorization out of processors where specific authorization handlers can be composed and config/run time and lighten the responsibilities inside processor classes.
Towards this end, my initial design goals for this framework are thus:
1) Allow various kinds of authorization handlers to be written and added to processors without necessarily recoding the processor.
2) Allow for a pipeline effect where one or more authorizers might need to operate at the same time.
3) Do not disrupt existing processors that rely on their internal coding for authorization
4) Use appropriate design patterns to allow for flexible implementations of principals, credentials and other authorization assets.
5) Secure any clear text assets (usernames and passwords) in existing authorizations when moving them inside the framework.
How does the community conduct initial design reviews of such changes? We would be quite a ways from contributing anything back but want to keep in sync with community practices and expectations to make such an offering immediately useful.
Regards,
Darren
Re: Authorization Framework
Posted by Joe Witt <jo...@gmail.com>.
Darren
You will want this thread on dev list to get traction.
Also please clarify if you mean authorization or whether you mean
authentication. I read all usages as meaning to discuss authentication.
thanks
On Wed, Nov 4, 2020 at 9:53 AM Darren Govoni <da...@ontrenet.com> wrote:
> Greetings!
>
> We have an internal need to move to a specific PK based authorization for
> all our nifi processors. Currently, authorizations such as basic auth and
> kerberos seem to be wired directly inside the processors. My design
> approach to addressing our need also seeks to factor authorization out of
> processors where specific authorization handlers can be composed and
> config/run time and lighten the responsibilities inside processor classes.
>
> Towards this end, my initial design goals for this framework are thus:
>
> 1) Allow various kinds of authorization handlers to be written and added
> to processors without necessarily recoding the processor.
> 2) Allow for a pipeline effect where one or more authorizers might need to
> operate at the same time.
> 3) Do not disrupt existing processors that rely on their internal coding
> for authorization
> 4) Use appropriate design patterns to allow for flexible implementations
> of principals, credentials and other authorization assets.
> 5) Secure any clear text assets (usernames and passwords) in existing
> authorizations when moving them inside the framework.
>
> How does the community conduct initial design reviews of such changes? We
> would be quite a ways from contributing anything back but want to keep in
> sync with community practices and expectations to make such an offering
> immediately useful.
>
> Regards,
> Darren
>
>