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 <dar...@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.w...@gmail.com> > Sent: Wednesday, November 4, 2020 12:29:35 PM > To: users@nifi.apache.org <users@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 <dar...@ontrenet.com > <mailto:dar...@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 >
