[jira] [Updated] (KNOX-399) Allow Anonymous Access to Select API Patterns

["Kevin Minder (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KNOX-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Minder updated KNOX-399:
------------------------------
    Fix Version/s:     (was: 0.6.0)
                   0.7.0

> Allow Anonymous Access to Select API Patterns
> ---------------------------------------------
>
>                 Key: KNOX-399
>                 URL: https://issues.apache.org/jira/browse/KNOX-399
>             Project: Apache Knox
>          Issue Type: Improvement
>          Components: Server
>            Reporter: Larry McCay
>            Assignee: Larry McCay
>             Fix For: 0.7.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.3.4#6332)