knox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From larry mccay <>
Subject Anonymous API Patterns
Date Fri, 20 Jun 2014 22:14:13 GMT
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
1. the configured authentication/federation provider for the topology that
is hosting the API
2. anonymous access to a subset of the API




  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message