Role-Based Identity Management

Bob Gifford

Novell Strategist

bob.gifford@Novell.com

Role-Based Identity Management
Today’s Agenda

Introduction to RBAC

Benefits of RBAC

Implementing RBAC

Key Challenges & Critical Success Factors

Why Role-Based Identity Management?

Two business drivers for Roles

Manual provisioning is too labor intensive

Increasing number of resources to be provisioned

Granularity of access privileges are higher

High employee mobility

Increasing ad hoc, project-oriented work requiring provisioned resources

Security must be improved

SarbOx, HIPAA require tighter security, better auditability

Manual security admin is not as secure, and is not as easily audited

Customer demands for confidentiality can require customer-level access control

Why Role-Based Identity Management?

Roles allow provisioning to be increasingly automated

Policies are captured and applied automatically by a provisioning policy engine

Compliance to policies is consistently enforced

Increasing complexity of provisioning requirements does not result in commensurate increases in manual effort

Administrative costs are minimized

IT security staff can devote their time to:

Developing appropriate security policies

Auditing compliance

Why Role-Based Identity Management?

More enterprises are starting to implement RBAC

They can't keep up with manual processes

They are facing customer and regulator requirements for better security, confidentiality

The technology to support RBAC is maturing

Early adopters are succeeding, encouraging the mainstream to follow

Source: Crossing the Chasm by Geoffrey A. Moore

Introduction to RBAC

Identity Management
The Big Picture

Identity

Personalization

Identity as a Unifying Principle

Role engineering as the binding agent

Governance as strategic guidance and oversight

Governance

Role Engineering

Account Management

Compliance

Web Services

Provisioning

Work Flow

Security

Access

Control

Role-Based Identity Management
Definition of RBAC

RBAC is the use of data regarding a user’s relationship to the organization to:

Determine resources required and provision them

Control and personalize access to resources

Employees

B2B

Partners

Customers

Your Business

Resource

A system, application, hardware, data, network, facility, or other asset that supports a business function

User

A principal with a unique Identity and relationship to the organization

Traditional Access Provisioning Process

The traditional access control process relies on manually provisioning entitlements one at a time

Entitlement

A right to access, update or consume a resource

Traditional Access Control Process

User requires access to a resource (e.g. application)

Traditional Access Control Process

User requires access to a resource (e.g. application)

Request form is submitted

Traditional Access Control Process

User requires access to a resource (e.g. application)

Request form is submitted

Manager(s) approve request (e.g. resource owner)

Traditional Access Control Process

User requires access to a resource (e.g. application)

Request form is submitted

Manager(s) approve request (e.g. resource owner)

Entitlement (e.g. account) is created manually

Traditional Access Control Process

User requires access to a resource (e.g. application)

Request form is submitted

Manager(s) approve request (e.g. resource owner)

Entitlement (e.g. account) is created manually

User is able to access the resource

An Alternative
Role-Based Access Control (i.e. RBAC)

RBAC is the application of Roles to manage user (e.g. employee) access to the organization’s resources based on the user’s relationship to the organization

User's attributes determine

membership in Roles

An Alternative
Role-Based Access Control (i.e. RBAC)

RBAC is the application of Roles to manage user (e.g. employee) access to the organization’s resources based on the user’s relationship to the organization

Users attributes determine

membership to Roles

Roles specify

Entitlements

An Alternative
Role-Based Access Control (i.e. RBAC)

RBAC is the application of Roles to manage user (e.g. employee) access to the organization’s resources based on the user’s relationship to the organization

Users attributes determine

membership to Roles

Entitlements

grant access to

Resources

Roles specify

Entitlements

An Alternative
Role-Based Access Control (i.e. RBAC)

RBAC is the application of Roles to manage user (e.g. employee) access to the organization’s resources based on the user’s relationship to the organization

A Role is a convenient set of entitlements that maps to and
fulfills a set or sub-set of a user’s access requirements

Note: A user may be a member of more than one role

What Is A Role?

Users

Role

Entitlements

Resources

An Alternative
Rule-Based Access Control

Aka “Policy”-based access control, uses business rules (conditional statements with actions*) to manage access to enterprise resources. Provides dynamic method for determining access to resources.

* Represented as Boolean operations or other scripting language

An Alternative
Rule-Based Access Control

Aka “Policy”-based access control, uses business rules (conditional statements with actions*) to manage access to enterprise resources. Provides dynamic method for determining access to resources.

Users Attributes

trigger Rules

* Represented as Boolean operations or other scripting language

An Alternative
Rule-Based Access Control

Aka “Policy”-based access control, uses business rules (conditional statements with actions*) to manage access to enterprise resources. Provides dynamic method for determining access to resources.

* Represented as Boolean operations or other scripting language

Rules manage access to Resources based on User Attributes

Users Attributes

trigger Rules

Role or Rule Based Access Control?

Enterprises will implement an access control solution that is a combination of Roles and Rules

Roles are too static for some situations (i.e. difficult to keep current)

Dynamic business functions

Dynamic industries

Rules complement roles

Rules can modify or restrict role-based entitlements (e.g. only modify sales data in your territory)

Rules can create additional entitlements not based on roles (anyone in “corporate” gets HQ building access)

Not economical to represent all user entitlement requirements in Roles

Role proliferation a serious management and security issue

Data requirements for rules may be difficult to meet

Availability

Reliability

When to Use Roles/Rules?

Use roles/rules until the effort to create and administer them is less than the effort to manually provision

Administrative

Effort

Number of Roles/Rules

0

n

Roles

Management

Provisioning

Total

Minimized cost

When to Use Roles/Rules?

Use roles/rules regardless when:

Enforcing enterprise-wide access control policies via roles will significantly enhance security

Eliminating delays through automated role-based provisioning would result in a significant business benefit

Regulations require role-based controls (e.g. HIPAA)

Cost savings can be captured

Role-Based Identity Management
Includes Roles and Rules

Resources

Users

resource

resource

Finance

Roles Portfolio

Rules Engine

resource

resource

RACF

resource

resource

Facilities

resource

resource

HR

Role-Based Identity Management
Best Practice

Roles and rules-based provisioning process:

Employee’s responsibilities change

Role-Based Identity Management
Best Practice

Roles and rules-based provisioning process:

Employee’s responsibilities change

Employee data is updated in the HRIS

Role-Based Identity Management
Best Practice

Roles and rules-based provisioning process:

Employee’s responsibilities change

Employee data is updated in the HRIS

Employee is automatically assigned to new role(s)

Role-Based Identity Management
Best Practice

Roles and rules-based provisioning process:

Employee’s responsibilities change

Employee data is updated in the HRIS

Employee is automatically assigned to new role(s)

Entitlements (e.g. accounts) are created automatically based on roles as modified by rules

Role-Based Identity Management
Best Practice

Roles and rules-based provisioning process:

Employee’s responsibilities change

Employee data is updated in the HRIS

Employee is automatically assigned to new role(s)

Entitlement (e.g. account) is created automatically based on roles as modified by rules

User is able to access required resources

Implementing RBAC

High-Level Approach

The need for roles is addressed within the broader context of the entire Identity Management environment

Discovery

Requirements Assessment

Design

Maintenance/ Support

Development/

Deployment

Roles

Process Redesign

Technical Infrastructure

Governance

RBAC Implementation Process

Start

Requirements

Assessment

Discovery

Roll-Out
Roles Engineering

Design/Develop Role Definitions

Roll-Out
Roles Engineering

Roll-Out
Roles Engineering

Roll-Out
Roles Engineering

Role Engineering Workstream

Technology Implementation Workstream

Process Redesign Workstream

Governance Workstream

Discovery
Some Key Questions

What is the enterprise’s Vision and Strategy?

Business

Technology

Identity Management

What are the objectives of automating access control?

Security?

Cost Savings and Improved Efficiency?

Improved User Experience?

What ID Management technology is in place?

Is a meta-directory in place?

Is an identity vault in place?

What Resources / Entitlements do Users need improved access to?

Applications, systems, data

Physical assets (e.g., PCs, cell phone, etc)

Services (e.g., web services, …)

Facilities access

Where will RBAC create the highest return on investment?

What Business Units?

What departments?

What groups?

What functions?

Communi-
cations

Governance

Process/

Tools

Repository

Requirements Assessment Approach

Workshops

Identify Candidate Target Groups

Review Directory Requirements

Determine Process and Tool Requirements

Determine Governance Requirements

Determine Communication Requirements

Assess

Prioritize & Schedule Target Groups

Develop Role Repository

Develop Process and Tools

Develop Governance Process

Develop Communications

Define

Conduct Pilot Workshop

Pilot Roles Repository

Pilot Process and Tools

Pilot Governance Process

Pilot Communications

Validate

Refine Workshop Schedule

Refine Repository

Refine Process and Tools

Refine Governance Process

Refine Communications

Refine

Requirements Assessment
Identify Target Groups

Initial Role development should focus on a high priority organization or resource, based on ROI

Organizations

(Users, Departments, Locations BU’s)

Resources

(Applications, Platforms,

Fixed Assets, Services)

Requirements Assessment
Roll-out Across the Enterprise

Starting with the high priority target group, Roles can then be defined across the enterprise for other Users

Organizations

(Users, Departments, Locations BU’s)

Resources

(Applications, Platforms,

Fixed Assets, Services)

Requirements Assessment
Roll-out Across Resources

Roles can later be expanded upon to address additional resources

Organizations

(Users, Departments, Locations BU’s)

Resources

(Applications, Platforms,

Fixed Assets, Services)

Requirements Assessment
Defining Target Groups

To manage complexity, only define roles for 2 to 3 levels of the organizational hierarchy at a time

Begin at a level in the organization with a large number of heavy IT users, and add one or two levels up

Higher levels in the organization often will not have enough employees to best leverage roles

Lower levels in the organization will not have enough resources to justify unique roles

Manager

Supervisor

Supervisor

Supervisor

Worker

Worker

Worker

Requirements Assessment
Prioritizing Target Groups

Prioritization of organizational and resource scope is based upon criteria demonstrating ROI

Organizational Prioritization

Number of users

User turn-over

User loaded costs

Business impact of lack of access

Resource Prioritization

Frequency of user account adds, changes, deletes

Business criticality of application security

Administrative burden of current provisioning process

Describe Any Sub-Groups

Identify Key Functions

Identify Key Tasks of Each Function

Identify Key Attributes of Each Function

Identify the Enterprise Resources Needed to Fulfill the Assigned Responsibilities or Job Functions

Identify Systems and Assets Used

Identify Access Rights Required

Identify Commonality

Eliminate Redundancies

Associate Common Attributes & Access Rights (based on responsibilities or job-tasks) to Groupings or Sub-Groupings

Map Overlap of Common Access Requirements

Identify Separation of Duties Constraints (conflicts with Additive nature of Roles)

Describe

Target

Group

Identify

Required

Resources

Group

Access

Requirements

Define Roles

1

3

4

2

Design/Develop Roles
Roles Definition

The process of defining the Roles and entitlements of a Role-Based Identity Management solution

Resource Entitlement Overview

Role: Core Employee

Included entitlements

Excluded entitlements

Role: Core Manager

Included entitlements

Excluded entitlements

Role: Core Banking

Included entitlements

Excluded entitlements

Role: Branch

Included entitlements

Excluded entitlements

Role: Loans Call Center

Included entitlements

Excluded entitlements

Role: Member Svcs Call Center

Included entitlements

Excluded entitlements

Role: Call Center Lead

Included entitlements

Excluded entitlements

Role Definition Summary

Included entitlements

Excluded entitlements

Role Definition Summary

Included entitlements

Excluded entitlements

Manual

Exceptions

Sample Technical Architecture

Workflow and

Provisioning

Engine

SAP HR

Roles are assigned to jobs, positions and org structures

Role and
Attribute
Sources

Discretionary roles and some non-HR attributes are administered via the Provisioning Engine

Direct Web

Interface

Web Services

Interface

Identity

Vault

Policy

Repository

Loopback

Drivers

Service

Dir Drivers

Identity
Management
System

HR based roles and attributes are synchronized to the Identity Vault

Rules based authorizations are realized by driver processes

Policy data may reside either in the Identity Vault or a separate data store

Some policies are hard coded into the drivers. More dynamic policies are read from the repository by the drivers.

SAP CUA

RACF/ACF2

Active Dir

Linux/UNIX

LDAP
Authentication
Directory

Drivers translate authorizations into the representation appropriate to each service directory

Service

Directories

SQL

Automatic Access Provisioned based on

Basic Role

Assign rights in Auth-Tree

Assign rights in Notes

Assign rights in RACF

Automatic Access Provisioned based on

Customer Team Role

Assign rights in Auth-Tree

Assign rights in Notes

Assign rights in RACF

Assign rights in Imaging

J

N

R

e

RACF Driver

eDir-eDir Driver

JDBC Driver

Lotus Notes Driver

A

P

C

T

Custom Driver

Delimiter Text Driver

AD Driver

People soft Driver

Basic

Roles

Customer

Team Role

Sample Technical Architecture

Key Challenges & Critical Success Factors

Implementation
Key Challenges

Understanding relationships

Managing complexity & risk

Managing scope and expectations

Ensuring adequate governance

Encouraging adoption

Implementation
Barriers

Inadequate definition of strategy, goals and boundaries (e.g. number of roles, when roles or rules, etc.)

Lack of role definition and management processes

Lack of central coordination and support

Lack of cross-functional involvement e.g., HR, security, IT Admin (computing & networking admin), business users, systems & application Dev

Lack of Executive Management involvement

Poor data quality

Translating definitions (roles) into productions/solutions

Implementation
Critical Success Factors

Establish a Vision

Understand how RBAC supports the enterprise’s Strategy (business and IT architecture)

Phase the implementation

Gain support from owners of and access to Authoritative Sources

Ensure appropriate education, planning and support

Execute a Communication Plan

Organizational Coordination

Develop approaches to maintain the system

Questions & Next Steps

General Disclaimer

This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. Novell, Inc., makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.

No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.

Applications that use Roles / role initiatives

NIKU

A+

SMART Office

EDEN

NIMROD

CSS/SMART

Job Familes

Workstyles

Profiling Technology - exact

Applications that use Roles / role initiatives

NIKU

A+

SMART Office

EDEN

NIMROD

CSS/SMART

Job Familes

Workstyles

Profiling Technology - exact

A time length note would be helpful here.

Chris Bidleman thinks there are some industry studies that show average time for this process is 1 - 2 weeks.

A time length note would be helpful here.

Chris Bidleman thinks there are some industry studies that show average time for this process is 1 - 2 weeks.

A time length note would be helpful here.

Chris Bidleman thinks there are some industry studies that show average time for this process is 1 - 2 weeks.

A time length note would be helpful here.

Chris Bidleman thinks there are some industry studies that show average time for this process is 1 - 2 weeks.

A time length note would be helpful here.

Chris Bidleman thinks there are some industry studies that show average time for this process is 1 - 2 weeks.

Applications that use Roles / role initiatives

NIKU

A+

SMART Office

EDEN

NIMROD

CSS/SMART

Job Familes

Workstyles

Profiling Technology - exact

Applications that use Roles / role initiatives

NIKU

A+

SMART Office

EDEN

NIMROD

CSS/SMART

Job Familes

Workstyles

Profiling Technology - exact

Applications that use Roles / role initiatives

NIKU

A+

SMART Office

EDEN

NIMROD

CSS/SMART

Job Familes

Workstyles

Profiling Technology - exact

Applications that use Roles / role initiatives

NIKU

A+

SMART Office

EDEN

NIMROD

CSS/SMART

Job Familes

Workstyles

Profiling Technology - exact

Rules can be static (early binding) or Dynamic (late binding, using a Boolean expression), or both

Applications that use Roles / role initiatives

NIKU

A+

SMART Office

EDEN

NIMROD

CSS/SMART

Job Familes

Workstyles

Profiling Technology - exact

Applications that use Roles / role initiatives

NIKU

A+

SMART Office

EDEN

NIMROD

CSS/SMART

Job Familes

Workstyles

Profiling Technology - exact

Applications that use Roles / role initiatives

NIKU

A+

SMART Office

EDEN

NIMROD

CSS/SMART

Job Familes

Workstyles

Profiling Technology - exact

So, what you in effect now have is a layer between the Users and the Resources – Roles & Rules. It is this layer where entitlements are managed

Also, you users will receive entitlements by more than one Role, based on their job functions at the time.

In contrast to slide 17, time will be reduced from days to minutes

Implementing RBAC - Nicely defined. Be nice if there was a corresponding case study with time frames similar to what was in the previous deck

In contrast to slide 17, time will be reduced from days to minutes

Implementing RBAC - Nicely defined. Be nice if there was a corresponding case study with time frames similar to what was in the previous deck

In contrast to slide 17, time will be reduced from days to minutes

Implementing RBAC - Nicely defined. Be nice if there was a corresponding case study with time frames similar to what was in the previous deck

In contrast to slide 17, time will be reduced from days to minutes

Implementing RBAC - Nicely defined. Be nice if there was a corresponding case study with time frames similar to what was in the previous deck

In contrast to slide 17, time will be reduced from days to minutes

Implementing RBAC - Nicely defined. Be nice if there was a corresponding case study with time frames similar to what was in the previous deck

Our approach begins with a Discovery Workshop, an opportunity to develop consensus regarding a direction for RBAC in a short period of time

Communication Plan – due to the abstract nature of the benefits/project

This means that no work is lost with either the Novell Nsure UDDI corporate or testing solution.

Enterprises that build their UDDI solutions with Novell Nsure UDDI Server, are not only leveraging the deep experience Novell Identity Management foundation brings to the standard, they are securing their own future by building on an open standard implementation that will grow and scale with their corporate needs.

2003-12-08T12:43:39