directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <>
Subject Delegated Administration Enhancements to Apache Fortress REST
Date Fri, 08 Mar 2019 17:03:15 GMT
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

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
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.

View raw message