knox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From larry mccay <>
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 <>

> 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
> 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
> --
> 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.

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