Support for delegated administration has been part of the Core API since the 
beginning.  How it works, a session is created on behalf of an administrator, 
that session is pushed into the runtime context, and subsequent API calls are 
made on behalf of that administrator.

The kinds of checks are two-fold:

1. All API invocations calls checkAccess on an admin perm, e.g. 
AdminMgr.addUser.  This means at least one admin role activated for that admin 
has to have been granted that particular permission.

2. Some APIs do org checks.  For example, assignUser(Role) will verify that the 
admin has an admin role that has a userOU that corresponds with the user being 
added.  There are similar type of checks for grantPermission, the admin has 
role with permOU corresponding with permission being granted.

***

How this works with Apache Fortress REST is rather problematic.  The admin 
session is passed in the body of the request.  It is tricky for the caller to 
pass this admin session in the request.  Worse, the admin session isn’t secure. 
 The caller could manipulate the admin session, adding roles that weren’t 
activated, or even passing a session that was manufactured by the client and 
not in any way validated by fortress.

This is a problem that touches into a larger concern, how do you pass a session 
object into a server securely.  It usually means one of three approaches:

1. Create a new secure token format.  One that has been cryptographically 
signed. 
2. Pass a session ID instead of a session.  This would require Apache Fortress 
REST to be stateful.
3. Use a standard token format, i.e. HTTP Basic Auth, SAML, Oauth, etc.

I really, really, don’t want to do 1 or 2.  The last thing the world needs is 
another token format, especially a non-standard one.  And a stateful RESTful 
server is not moving in the right direction either.

That leaves #3.  Apache Fortress REST already supports HTTP basic auth.  
Typically this is a service account, i.e. a single user account on behalf of 
all calls.  In addition to authN and a role check, performed by the Apache 
Fortress Realm, there is another role check, performed in the service layer, by 
the Apache CXF runtime.

The approach I am aiming toward, is to run the delegated admin checks on behalf 
of the user that is passed in the HTTP basic auth header.  Most of the work to 
achieve this has already been done.

What this means is now when a caller invokes an Apache Fortress REST service, 
in addition to the three checks already mentioned, performed why they realm and 
CXF, there will be the two additional checks mentioned at the beginning of this 
post.

For the first release I will make the binding of ARBAC to the caller of the 
REST service optional, via a property, but think it should be a mandatory 
setting going forward.  (Secure by default).

I’ve already verified that this approach will work, with minimal impact to 
existing code, again just connecting the dots.  My next step is to create a 
ticket and check the code.  There will be changes to Rest and Core to support 
this.

Stay tuned.

—Shawn

Reply via email to