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)
