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

Larry McCay updated KNOX-399:
-----------------------------
    Fix Version/s:     (was: 0.7.0)
                   Future

> 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: Future
>
>
> 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)

Reply via email to