RBAC, Workflow

1
RBAC, Workflow Self-Service

• Dave Nesbitt, Oxford Computer Group

2
BYA ILM Phase 2

• Provisioning
• From HR for Employees
• From Admin Interface for non-Standards
• Admin Interface
• Extension of White Pages
• Allows single point of administration
• No Workflow, Roles, Delegated Admin or
  Self-Service (yet)

3
BYA ILM Stage 2 (Employees)
White Pages
ADAM
Admin Interface
Access Control
Auto Group
MIIS
4
Problems

• No self-service/delegated admin
• Relies on HR data being accurate and useful
• Still some duplication of effort
• Large administrative burden on the helpdesk
• Costs of misusing skilled staff for mundane tasks

5
Problems

• No Workflow
• Manual or paper-based JML processes
• No automatic escalation or delegation
• Traceability or audit accountability for
  approvals is more difficult
• Simple workflow could be coded into MIIS
  extensions or use ADAM

6
Problems

• No RBAC
• Crude provisioning
• Manual assignment of users to roles/groups
• Accrual of rights
• No separation of duty (or manually enforced)
• No enterprise-wide view of roles and rights
• Cant be managed through MIIS extensions alone
  not scaleable or manageable

7
Self-Service/Delegated Admin

• Stop using skilled administrators to do mundane
  tasks
• Get the users themselves or delegated others to
  start processes
• Get users or delegated others to take ownership
  of certain data
• Relies on
• A simple to use interface
• A simple to configure interface
• Translation of technical language into business
  language (especially permissions/roles)
• Security built into the interface
• Well-defined processes in support of policy
  (remember this from yesterday?)
• Workflow steps

8
Workflow

• Enabling processes with technology
• For example
• User requests additional application rights
• Request automatically forwarded to approver
• Once approved, request automatically fulfilled
• Escalation, delegation, notification etc
• Approvals and changes all tracked and made
  available for auditing

9
RBAC
10
What Are Roles?

• Organizational roles what we do at work
• IT roles what we are permitted to do on a
  particular system or application
• Collections of privileges
• Users (or groups of users) are assigned to roles
  and inherit these privileges

Permission
Permission
Permission
John Smith (person)
administrator (role)
11
Role-based Access Control

• Standard access control is per user
• RBAC means managing access based on a users role
• In AD, group membership is analogous to role
  membership

12
Access Control with Group Membership
Group access rights?
Yes
Token
13
Why Roles?

• Easier to administer as opposed to individually
  assigning each person all the privileges they
  might need
• Reduce security risks by seeing who has access
  to what
• In theory

14
Application Roles

• What we have just described are (what we term)
  Application Roles
• These can be formally defined, or could just be
  expressed through group membership or even just
  attributes
• They can be a pre-existing set of privileges
  within an application
• SQL server roles
• AD roles (domain admin)
• Some applications are naturally very
  role-orientated
• SAP Siebel
• Pushing us the right way
• Active Directory
• Best practices conceptually push us the right way
• A group acts very much like a role in a
  well-designed system

15
Application Roles Continued

• People will probably have more than one
  application role
• They may have no direct relation to a persons
  job title

Permission
AD Group 1
Permission
AD Group 2
SAP Role 1
John Smith Sales Assistant
SAP Role 2
16
Problems

• Many application roles in many systems
  management nightmare
• People tend to accrue rights (and roles) over
  time roles are added but not taken away
• No-one really understands what application roles
  a particular HR-defined job needs
• Application roles tend to be assigned either
  gradually as required, or in a lump based on the
  roles assigned to a similar person
• Application roles might only be needed
  temporarily, for a particular job or project
• Fundamentally there is no enterprise-wide
  formal policy for role management

17
Enterprise Roles

• In the IdM world, we like to normalize identity
  data
• MIIS 2003 uses a metadirectory
• One person object for each real world user
  identity
• Mapping between these and corresponding objects
  in managed systems (ditto for groups, printers
  etc.)
• A reduced set of attributes that can map to all
  the attributes we care about in managed systems
• In an analogous way, we (Oxford) like to
  normalize roles
• Use objects to represent roles
• One enterprise role object for each real world
  role (HR Manager, Receptionist, Business Manager)
• Mapping between these and corresponding
  representations of roles in our managed
  applications

18
Oxford Pragmatic Role Solution
Enterprise Role
Application Roles
Permission
cnsales assistants
AD Group 1
Permission
ousales
AD Group 2
Jack Black
SAP Role 1
Sales Assistant
John Smith
SAP Role 2
19
RBAC

• Role Based Access Control
• Formal definition by NIST
• Rich feature set
• Inheritance
• Separation of duties
• Received wisdom
• It is very difficult to do
• You may have more roles than employee
• You can take a pragmatic approach
• Stick to a reduced feature set
• Make a start (this is very MIIS)

20
Role-Based Provisioning with MIIS

• When provisioning using MIIS, our goal is to
  automatically put users into the right
  Application Roles
• Could be a native role (SAP etc)
• Could be an AD group
• Could just be some attributes
• Fine-grained authorization
• But how?
• Manually using an interface
• Automatically being driven by data from another
  source such as HR
• Pragmatically a combination of both

21
Role-based Provisioning - mvextension

• Look away non-MIIS techies!
• To do the role-based provisioning in MIIS, our
  mvextension needs to understand the rules
• We could just write code like this

If csentry(jobTitle).value Sales Assistant
Then mventry(role).values.Add(ADRole1,
ADRole2, SAPRole1, SAPRole2) ElseIf
csentry(jobTitle).value Sales Manager
Then mventry(role).values.Add(ADRole1,
ADRole3, SAPRole1, SAPRole3) Etc Etc

• Not scaleable too many roles
• Not manageable redevelop/compile/test every
  time something changes

22
Roles as Objects?

• To avoid the problems in the previous slide, we
  need to think of roles as either
• Something we can instantiate into our
  provisioning code or (more simply)
• Something that exists somewhere that we can
  lookup
• MIIS Metaverse
• ADAM
• AD
• SQL
• XML
• Whatever this thing is, it needs to pass to our
  provisioning code all the fine-grained
  authorization data we need group memberships
  and attribute values

23
Role-Based Provisioning
ADAM
Admin creates new user
Role1, Role2
MIIS
HR
Import Employee
Consumer Systems
Export Users
Group1
Which application roles does this user need?
cngroup1 cngroup2
24
Manual Role Assignment
ADAM
User Admin
Administrator adds user to an Enterprise role
User object is imported to MIIS
Role1, Role2
MIIS
HR
Import Employee
Consumer Systems
Export Users
Group1
MIIS reads the users role info and makes
provisioning decisions
cngroup1 cngroup2
25
Automatic Role Assignment
User object exported to ADAM and put into an OU
that has an Enterprise role(s) associated with
it, or put into ADAM groups with an Enterprise
role associated
ADAM
Role1, Role2
MIIS
HR
Import Employee
Consumer Systems
Export Users
Group1
MIIS reads the users role info and makes
provisioning decisions
cngroup1 cngroup2
26
Or SQL?

• ADAM is not the only place
• There is an argument for keeping roles in an
  RDBMS
• Multi-dimensional relationships
• Mutually exclusive roles
• Omada stores roles within SQL
• ADAM can be a good place to make a practical start

27
The Omada Approach
Workflow Authorization
SQL
User Admin Self-Service
Role assignment management
MIIS
HR
Import Employees
Consumer Systems
Export Users
28
Application Role Discovery with MIIS
Create analogs of these roles as appRole objects
in ADAM/SQL
ADAM
Import appRoles to MIIS join to groups/roles
MIIS
HR
Import Role Objects
Flow changes in role/group memberships out as
attribute flow
Consumer Systems
Import Group Objects
29
Role Mining

• So, now we know our application roles
• But how do we know which roles apply to which
  users?
• How do we group them into Enterprise roles?
• Products such as Eurekify
• Or make a pragmatic start using MIIS

30
Role Mining with MIIS

• Import users from HR and target systems,
  including their current roles
• Join them up
• Export them to a SQL 2005 instance
• Analyse the data to see the most common
  relationships between HR jobTitle and
  permissions/roles
• Where there is a significant correlation, make
  that a de-facto role for that job title
• Where there isnt, do it manually.
• Come back in 6 months and check again.

31
Role Mining with MIIS
ADAM
MIIS
HR
Project users
Consumer Systems
Join Users
32
Role Mining with MIIS
33
Role Mining with MIIS
34
BYA
35
BYA ILM Stage 2 (Employees)
Admin Interface
OMADA
ADAM
White Pages
Delegated Admin/Self-Service
Workflow
RBAC
Access Control
Audit
MIIS
Auto Group
36
Demo
37
Event Sponsors