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.
