[jira] [Created] (KNOX-397) Knox Management API
Larry McCay created KNOX-397: Summary: Knox Management API Key: KNOX-397 URL: https://issues.apache.org/jira/browse/KNOX-397 Project: Apache Knox Issue Type: Bug Components: Server Reporter: Larry McCay Assignee: Larry McCay Fix For: 0.5.0 This is an umbrella jira for all Knox management APIs. Subtasks will track specific API implementations. -- This message was sent by Atlassian JIRA (v6.2#6252)
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
[jira] [Created] (KNOX-399) Allow Anonymous Access to Select API Patterns
Larry McCay created KNOX-399: Summary: Allow Anonymous Access to Select API Patterns Key: KNOX-399 URL: https://issues.apache.org/jira/browse/KNOX-399 Project: Apache Knox Issue Type: Sub-task Components: Server Reporter: Larry McCay Assignee: Larry McCay Fix For: 0.5.0 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 -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Anonymous API Patterns
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.
