Title: 1.5 - How to implement ANSI RBAC
NavPrev: 1.4-why-rbac-is-important.html
NavPrevText: 1.4 - Why is ANSI RBAC Important?
NavUp: 1-intro-rbac.html
NavUpText: 1 - An Introduction to Role-Based Access Control ANSI INCITS 359-2004
NavNext: 1.6-go-for-more.html
NavNextText: 1.6 - Where to go for more info
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.5 - How to implement ANSI RBAC

* Learn using the SPEC
    
* Pick a technology stack you are comfortable with based on current knowledge, SLAs, data storage, and support requirements.

* Design a very simple RBAC data model.  Eight objects are all that is needed.
    * User, Role, Permission, Object, Operation, User-Role, Session, Constraints

* Design a simple RBAC software model. 
    * Top layer called a Manager and contains a stable public API that external apps may call.
        * Three managers, System, Admin, Review are all that is needed.
        * The implementation the manager interface contains must be able to be be swapped out for another complete RBAC system without impacting dependent apps.
        * External applications use RBAC Manager API to map to internal entitlement systems.
    * Middle layer for RBAC system is optional and may be used for processing fine-grained data validations rules
    * Bottom layer for accessing the actual data.
        * Implementation may be swapped for other back ends without impacting Manager.  
        * LDAP, JDBC, Hibernate, JAX-WS, JAX-RS other technologies may be used here to manage the data

* Don't ignore the Audit
    * View before and after images of the data

* Code first as a POC.  Start with the core - RBAC0.  Get it right first.

* Test driven development and automation key contributors to successful outcome.
    * Engage IT teams.
        * Analyze existing IT entitlements.  
        * Use established role mining techniques.  

* Map existing IT entitlements to RBAC system using established role engineering techniques

* Use parent roles as Business Roles and child roles as IT Roles.

* Deploy RBAC system into application environment using established standards.  Use declarative policy enforcement points like JEE security for coarse-grained, Spring for fine-grained.  

* Application teams own mapping between Business and IT roles.

* Model administrative controls on ARBAC.  More on ARBAC coming soon...

<CENTER>
    ![Administrative RBAC](images/ARbac.png)
</CENTER>

* Roll-out (Slow and steady starting out)