Title: 1.2 - What ANSI RBAC is not
NavPrev: 1.1-rbac-explained.html
NavPrevText: 1.1 - ANSI RBAC Explained
NavUp: 1-intro-rbac.html
NavUpText: 1 - An Introduction to Role-Based Access Control ANSI INCITS 359-2004
NavNext: 1.3-what-rbac-is.html
NavNextText: 1.3 - What ANSI RBAC is
Notice: Licensed to the Apache Software Foundation (ASF) under one
    or more contributor license agreements.  See the NOTICE file
    distributed with this work for additional information
    regarding copyright ownership.  The ASF licenses this file
    to you under the Apache License, Version 2.0 (the
    "License"); you may not use this file except in compliance
    with the License.  You may obtain a copy of the License at
    .
    http://www.apache.org/licenses/LICENSE-2.0
    .
    Unless required by applicable law or agreed to in writing,
    software distributed under the License is distributed on an
    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    KIND, either express or implied.  See the License for the
    specific language governing permissions and limitations
    under the License.

# 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](http://tools.ietf.org/html/rfc4519): 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.