I think I found the root cause of the issue. Within the DeploymentFactory.collectTopologyProviders we need to check for enabled before inclusion in downstream processing. Will test out tomorrow and submit patch if correct.
--Rick -----Original Message----- From: larry mccay [mailto:lmc...@apache.org] Sent: Friday, December 22, 2017 2:04 PM To: dev@knox.apache.org Subject: Re: Multiple Authentication Providers Interesting.... I think that I have always commented out other providers to switch back and forth. Thinking of that deployment factory code, I can imagine this being entirely true. On Fri, Dec 22, 2017 at 1:58 PM, Rick Kellogg <rmkell...@comcast.net> wrote: > Greetings, > > > > After spending several days attempting to get HBase working with Knox > in a Kerberos secured environment, I discovered a crazy bug I want to > share with you. > > > > I started with the default topology that included the ShiroProvider. > I set the enabled value to false and added my HadoopAuth provider directly > below > it with enabled set to true. This was done so I could easily switch back > to the original if required. > > > > When I finally thought to review the generated deployment artifacts, I > discovered the gateway.xml file did not include any reference to the > ShiroFilter or HadoopAuthFilter. As such my subsequent use of the > identity assertion filter would fail with a missing Subject. > > > > So basically one can only have a single authentication provider listed > in the topology. It does not use the first enabled provider. Next > week, I will research and attempt to suggest some suitable changes or > warnings. > > > > Thanks everyone for their assistance on this matter. Almost completed > my HBase integration with Knox and Kerberos. > > > > Take care, > > Rick > >