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.min...@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.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.
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity
to which it is
