WHAT’S DELEGATED ADMINISTRATION (DA)?
DA is what happens (or doesn’t!) as the dots are being connected within our security administrative processes. For example, who can add new users. What roles can they be assigned and under what conditions? How do we control access to the administrative services themselves? How do we grant permissions to roles? Who can execute the more privileged actions? How do we keep track of these sensitive operations?
ADMINISTRATIVE ROLE-BASED ACCESS CONTROL (ARBAC)
DA is not a new concept and there are various ways in which to do it. Some are standard, most not. Apache Fortress follows the ARBAC02 model. It includes an entity called organizational unit (OU) to control which pools of users are under the authority of corresponding administrators, conveyed with an ADMIN role. The same thing for permissions using perm OU. There are also controls (range check) over which roles may be targeted when assigning and granting roles to users and permissions. Finally, it has what are called ADMIN permissions to control access over who may call a particular service.
HOW DOES IT WORK
Apache Fortress REST enforces the ARBAC-type controls in its runtime environment. There are other kinds of checks being done, to ensure the runtime is operating in a secure fashion. For example, coarse-grained checks with the Apache Fortress Realm, medium-grained role checks into the service tier.
The caller of the service will pass the identity of the administrator in the HTTP Basic Auth header of the request. After passing authentication and coarse-grained role checks, the service is dispatched to the Apache Fortress Core APIs, where the DA checking is performed. Once properly configured, all of the checks are performed automatically. If Symas OpenLDAP is used as the directory server, an audit trail is persisted using the slapo-accesslog overlay.
For a list of the security controls Apache Fortress REST enforces: README-SECURITY-MODEL
WHAT WAS CHANGED
Before the latest changes using the DA checks was more complicated. In addition to the HTTP Basic Auth creds, callers had to pass the administrator’s session in the payload of the request. This made it harder to use and (worse) less secure.
Now the credential passing has been streamlined. Only the credentials in the HTTP header are needed, which then gets asserted into the runtime for the DA checks.
WHY GO TO THE TROUBLE
There are many reasons to enforce these kinds of controls in the runtime environment.
Auditors needing guarantees that privileged operations are only being performed by the right people.
The ability to delegate authority to customers, so they can manage their own users, roles and permissions, that fall under their control.
Large organizations needing to expand privileges for managing the administrative data to users falling outside of traditional IT boundaries, to the development teams, project managers, team leads, supervisors, etc.
Ability to turn on/off security sensitive services real-time.
Need for a security audit trail showing what security administrative functions were performed by whom.
Fine-grained access control in the service tier.
WHERE TO LEARN MORE
Contact us for a live demo.
Apache Fortress is a trademark of the Apache Software Foundation.