You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by larry mccay <lm...@apache.org> on 2014/06/21 00:14:13 UTC
Anonymous API Patterns
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
Re: Anonymous API Patterns
Posted by larry mccay <la...@gmail.com>.
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 <ke...@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.
>
Re: Anonymous API Patterns
Posted by Kevin Minder <ke...@hortonworks.com>.
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 <ke...@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.
Re: Anonymous API Patterns
Posted by larry mccay <la...@gmail.com>.
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 <ke...@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.
>
Re: Anonymous API Patterns
Posted by Kevin Minder <ke...@hortonworks.com>.
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.