knox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From larry mccay <larry.mc...@gmail.com>
Subject Re: Anonymous API Patterns
Date Fri, 20 Jun 2014 22:59:31 GMT
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.minder@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message