On the Essential Question of Identity

For years I’ve been on record proclaiming that identity centralization is good and synchronization is bad.  I reasoned it is better to re-engineer processes to share identities than to distribute and fragment them.

I still believe this to be true.  However I have come to realize that centralization of identities will not happen — during our lifetimes.  The reasons are numerous, obvious, and beyond the scope of this post.

Where does this leave us on the essential question, i.e. how do we maintain identities now they must be distributed across the known universe?

The answer to this question will included within a series of blog posts.  Stay tuned…

RBAC vs ABAC

Frequently debated within info sec circles.  Which one of them is better?

Use the right tool for the job as they say. RBAC, like any access control model, has its weaknesses. Many are well understood, even discussed by the original NIST team who framed the model.

Comments on “A Critique of the ANSI Standard on Role-Based Access Control”

However, there are a number of common fallacies wrt how RBAC works.  For example…

1. RBAC is static. It cannot use contextual information e.g. time, user location, device type.

Constraints are commonly applied during user, role and permission activation in RBAC. For example, placing temporal constraints on a role activation. Indeed INCITS 494 prescribes their use:

5.4 RBAC Policy Enhanced Constraints

Enhanced constraints go beyond the INCITS 359 RBAC Standard by including additional types of constraints. Constraints on roles may be static or dynamic. Static constraints are applied off- line before the role is activated by the user. Dynamic constraints are applied on-line after the role(s) are activated. These enhanced dynamic constraints can introduce attributes into the RBAC environment.
INCITS 494-2012, p. 8

2. RBAC cannot perform dynamic segregation-of-duty.

RBAC supports dynamic SoD constraints. From the spec:

5.3.2 Dynamic Separation of Duty Relations

Dynamic Separation of Duty Relations Static separation of duty relations reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles. Dynamic Separation of duty (DSD) relations, like SSD relations, are intended to limit the permissions that are available to a user. However, DSD relations differ from SSD relations by the context in which these limitations are imposed. SSD relations define and place constraints on a user’s total permission space. This model component defines DSD properties that limit the availability of the permissions over a user’s permission space by placing constraints on the roles that can be activated within or across a user’s sessions.
ANSI INCITS 359-2004, p. 10

3. It relies on custom code within application layers (API, apps, DB…) to implement finer-grained controls.

Presumably what is meant here is that custom code must be written because RBAC controls don’t adequately satisfy security requirements for authorization.

Where are ABAC’s published functional specifications? Where are the standard object (data) and functional (api) model for computing (and storing) its decisions?

Perhaps it is better to use a proven, non-standard ABAC implementation than a custom app widget? If that is what is being said then I agree, but neither are ideal.

ABAC has its place as does RBAC. Knowing when to use one, the other, or both, is important. Understanding the limitations and strengths of each is crucial before adequately addressing the challenges we face as security practitioners.

Apache Fortress Role Engineering Tutorial

Apache Fortress Role Engineering Tutorial

The goals of this tutorial are to

  • Gain understanding of the Role Based Access Control (RBAC) standard
  • Learn the repeatable steps of the Role Engineering Process
  • Learn about using the Apache Fortress RBAC engine

To get started, follow the instructions in the README located on github:

https://github.com/shawnmckinney/role-engineering-sample

More info here: A Practical Guide to Role Engineering.

Apache Fortress SAML Demo

The aim of this tutorial is to connect Apache Directory Fortress with Spring Security SAML and a common Identity Provider – SSO Circle.com. It’s not intended to highlight all of the possible locations in code where security checks may be applied.  For that take a look at The Apache Fortress End-to-End Security Tutorial.


Fortress SAML Demo

Go to https://github.com/shawnmckinney/fortress-saml-demo, complete the steps under the README.

More info here: Fortress-Saml-Demo

Saml-Demo-Block-Diagram-Master

What Are Temporal Constraints?

Defined

Ability to control when an entity activation occurs based on time and date criteria.  Temporal constraints are typically applied during User and Role activation as part of an authentication or authorization check.

What Are They For?

Can be used to limit when a User may log onto or activate a particular Role within a security domain.  Follows the principle of least privilege as it ensures access rights are only granted when appropriate.

How Do They Work?

There may be policies to control what dates, times, and days of week a User may access a particular area of the system and in what Role.  Can also be used to enforce a lockout period when the User is inactive or otherwise away for an extended period of time.

Apache Fortress Temporal Constraints

Fortress allows constraints to be applied onto both User and Role entities.  There are rules that fire during an activation event (any policy enforcement API call):

  1. Can the entity be active on this Date?
  2. Is the entity within a lockout period?
  3. Has the entity exceeded a particular inactive period?
  4. Can the entity be used at this time?
  5. Can the entity be used on this day?
  6. Are there mutual exclusion constraints that prevent activating this entity?  (Roles Only)

These temporal constraint rules are pluggable and may be added, overridden or removed.

What are Password Policies?

Defined

A set of rules surrounding the content, quality and lifecycle of a password.

What Are They For?

Helps to safeguard the integrity of password values within a particular security domain.  With moves toward Multi-Factor Authentication (MFA) and other biometric authentication measures one can make the argument that the password’s days are numbered.  Nevertheless they remain in use widely today and will continue for the foreseeable future.

How Do They Work?

Define a set of rules to be enforced during a password lifecycle event.  An example of a lifecycle event is authentication, password change and password expiration.  There are a few standards that govern how systems should behave in this area.

IETF Password Policies

Apache Fortress adheres to IETF Password Policy Draft.  While this draft was never formally adopted it has traction within the various directory implementations and remains the de facto standard today.

Password Policy Enforcement

Password enforcement options include:

  1. A configurable limit on failed authentication attempts.
  2. A counter to track the number of failed authentication attempts.
  3. A time frame in which the limit of consecutive failed authentication attempts must happen before action is taken.
  4. The action to be taken when the limit is reached. The action will either be nothing, or the account will be locked.
  5. An amount of time the account is locked (if it is to be locked) This can be indefinite.
  6. Password expiration.
  7. Expiration warning
  8. Grace authentications
  9. Password history
  10. Password minimum age
  11. Password minimum length
  12. Password Change after Reset
  13. Safe Modification of Password
  14. Password Policy for LDAP Directories

What is Delegated Administration?

Defined

The ability to control access on the security system itself.  This control is exercised inside the policy administration programs.

In addition to what functions may be executed, we must control which entities to operate on.  A common use case is to allow User X the ability to reset and unlock passwords only for Users within Organization Y.  Another is the administrator may only assign a specific subset of Roles to Users who reside inside their Organization.  Additionally we must also be able to limit an Administrator to a specific subset of Roles in which to Grant to a subset of Permissions.  Indeed every API that changes state inside the back-end security repository must be governed via a well understood delegated administration policy.


Administrative Role-Based Access Control (ARBAC)

Apache Fortress has implemented ARBAC02. [link to paper].  This is a formal model for Delegated Administration and builds on the ANSI RBAC specification.  The control is marshaled into three interfaces:

  1. Delegated Admin Manager – Provides CRUD for related entities like Administrative Roles and Permissions.
  2. Delegated Review Manager – Interrogation of Delegated Admin policy objects.
  3. Delegated Access Manager – Enforcement of Delegated Administration Policies.

1 & 2 are for management of the Delegated Admin policies themselves.  3 is for enforcement of Delegated Admin policies at runtime.


Delegated Admin Policy Enforcement

There are two types of controls:

  1. Ensure that the caller has the permission to call the security administrative method (e.g. addUser, addRole, addPermission,…)
  2. Ensure the caller is entitled to perform the function for a given organization (e.g. which Users and Permissions to grant access rights).

With Fortress, the Delegated Administration control is baked into its APIs.  The enforcement occurs during API invocation which means it can’t be circumvented by poorly implemented administrative programs.

In addition to control, every API invocation leaves an audit trail so you may determine what policies changed, by whom, when and where.