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 Mon, 23 Jun 2014 13:58:21 GMT
I see.

Yes, we certainly have to ensure that - I think that it would be difficult
to do that without access to server side config.
Perhaps we could add another check inside anonymous filter to make sure
that the request does indeed match a configured anonymous pattern.


On Mon, Jun 23, 2014 at 9:46 AM, Kevin Minder <kevin.minder@hortonworks.com>
wrote:

> No the patterns are used to select a filter chain.  However they are not
> used to by Jersey in any way. This is OK as long as we can ensure that a
> call intended for a secured resources doesn't cannot malicously be routed
> through an anonymous pattern/chain.
>
>
> On 6/20/14 6:59 PM, larry mccay wrote:
>
>> 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.
>>>
>>>
>
> --
> 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