1.2 - What ANSI RBAC is not

• User Groups (i.e. LDAP groupOfUniqueNames). In RBAC, Roles are many-to-many mappings between User and Permission entities. Furthermore the assignments and grants may be interrogated, added or removed at any time. Roles should fall within a hierarchy which facilitate control over assets, encourages reuse and reduces the number of entitlements that have to be maintained.

  RFC 4519 LDAP: Schema for User Applications June 2006

      ( 2.5.6.17 NAME 'groupOfUniqueNames'
         SUP top
         STRUCTURAL
         MUST ( uniqueMember $
               cn )
         MAY ( businessCategory $
               seeAlso $
               owner $
               ou $
               o $
               description ) )
  

  groupOfUniqueNames is not RBAC

• Resource connections (i.e. LDAP connection). Allowing your LDAP or DB system to calculate entitlements based on user group assignments violates the concept of least privilege. RBAC compliant systems add a role activation step to signon that provides control over what a user can do at a point in time within a particular application.

• User-to-Entitlement Access Control List. Bypassing roles and mapping entitlements directly to users will undermine the ability to control and determine who has access to what resources. It also makes it difficult to figure out what access needs to be granted or revoked and when.

• Outdated or obsolete. Contrary to what is often told, the RBAC model is still a viable means in which to manage security within the enterprise. Employ finer-grained attribute-based or dynamic access controls as needed but ANSI RBAC is still the foundation for sound enterprise IT security strategies.