That is exactly what I am describing. I'll have to dig into the jersey handoff in order to understand though I think you are saying that the patterns aren't used to route to any particular filter chain. Not sure I understand that though given the code in the jersey contributor base class - it loops through the patterns creating separate chains. I'm sure it will become obvious when I dig in.
Thanks for the response. On Fri, Jun 20, 2014 at 6:44 PM, Kevin Minder <kevin.min...@hortonworks.com> wrote: > My first thought is that this is tied up in the issue of removing the > filter chain definition from the service contributor. > This has been discussed a number of times including as part of > https://issues.apache.org/jira/browse/KNOX-177 > Note that I no longer really agree with my proposal documented on the > related wiki. > > The need for potentially different authentication schemes for different > URL patterns was one of the original reasons the filter chain construction > was left entirely up to the service contributor. > > All this being said I believe what you are describing here is a way to > control which patterns are for anonymous access so in addition to > > public abstract class JerseyServiceDeploymentContributorBase extends > ServiceDeploymentContributorBase { > protected abstract String[] getPatterns(); > ... > } > > you are considering adding > > public abstract class JerseyServiceDeploymentContributorBase extends > ServiceDeploymentContributorBase { > protected abstract String[] getPatterns(); > *protected abstract String[] getAnonymousPatterns();* > ... > } > > Am I interpreting your email correctly? I sort of get where you are going > but this alone will be insufficient. This is because of the way we hand > off to Jersey. It doesn't matter which chain you come in through as long > as you have declared the correct packages. This assumption would need to > be verified though. > > > On 6/20/14 6:14 PM, larry mccay wrote: > >> All - >> >> As I begin to add the beginnings of the management API to Knox, it occurs >> to me that certain resource URLs will require/allow anonymous access. >> >> For instance, admin/api/v1/version shouldn't require authentication - >> since >> it may be used to determine which contract to use or some other >> non-request >> processing book keeping. >> >> What I have in mind is a scheme wherein a given API service contributor >> will communicate the patternsForAnonymousAccess in addition to packages >> and >> patterns that it does today. The base class jersey contributor can noop >> the >> method for backward compatibility. >> >> As the base class jersey contributor loops through the patterns to add >> filters for, it will check whether each pattern is a member of the >> anonymous access group and if so add an anonymous authentication filter >> instead of the one configured in the topology. The anonymous >> authentication >> provider will simply create a Subject with principal of anonymous and no >> groups. It will then be up to identity assertion role mapping to add any >> groups to the Subject. Something like "everyone" group would make sense >> and >> could then be used in SLA acls for access decisions. >> >> The rest of the API will likely be protected with acls for role of >> "admin". >> The administrator role would need to be added to LDAP groups or also added >> through the identity assertion provider based on specific principal names. >> >> I think that this will allow for an API with up to two authentication >> levels: >> 1. the configured authentication/federation provider for the topology that >> is hosting the API >> 2. anonymous access to a subset of the API >> >> thoughts? >> >> thanks, >> >> --larry >> >> > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity > to which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. >
