Identity and Access Management

Prof. dr. ir. André Mariën

There is a problem with IAM

• IAM projects are high-risk projects and at the same time critical improvement projects– High failure rates → management confidence ▼– IT business relationship ▼– Organizations that do not fail?

• Often: expected benefits have not materialized• What are the root causes of the difficulties?

– Lack the right tools?– Inherent complexity?– Incompetent people?

22018-2019 (C) A. Mariën

Business objectives

• Know you users– Manage their identities

• Ensure compliance– Accountability, data protection, duty segregation

• Prevent unauthorized access– Authenticated, Authorized, access control

• Affordable– Fit with business and IT reality

– Maintainable and mostly automated

32018-2019 (C) A. Mariën

Security lingo for objectives

• Ensure confidentiality– Confidentiality ≠ encryption– But access control is key for confidentiality

• Encryption, key management: support for access control

• Ensure accountability– Link between the physical world (people of flesh and blood) with technical world

(userID/password, certificate, token, claim, …): crucial relationship– Manage privileges, but also manage privilege management– Accurate and comprehensive reporting

• Ensure segregation of duties– Identifying duties with segregation constraints

• Dual control required– Submit – approve– Dubble keying

– Identity management must be enterprise wide:• link all logical instances to the actual, physical principal• Example: customer and employee at the same time

• Ensure least-privilege– Only privileges that are needed, but when needed– Organizational agility: acquiring and dropping privileges follows business changes immediately

42018-2019 (C) A. Mariën

Approach from risk management

• Prevent confidentiality breaches

– Privacy/GDPR

– business strategy, partner agreements

– Customer trust in keeping their data protected

• Evidence of transaction responsibility

– Who, what, when ,where

• Prevent fraud

• Limit impact of breaches

2018-2019 (C) A. Mariën 5

Your first decisions may put the whole program at risk

• Classify it as an IT project

– All will go well in the development and implementation phase

– Nothing but trouble near roll-out and production

• Decide on a company wide model, example: RBAC– Role based access control

• Scalability and manageability of the approach

– Proof-of-concept test succeed

– Roll-out and maintenance slowly turn into nightmare

• Pick a product, configure, do some role mining, done

– Great plan

– Try-outs seem to work

– Role mining produced on larger scale are less convincing

– No underpinning (semantics) of roles, so how to maintain?

62018-2019 (C) A. Mariën

Observations

• Identity space– multiple systems for managing identity information exist and are here to stay

• spread across the organization• different vendors• different purposes

– Fundamental to “identity” is it’s uniqueness, but many views coexist

• Business view– business must controlling access, but not all in the same way:

• based on functions, tasks, organizational structure, ...• Force one way: sure to meet resistance

– Business needs drive authorization and access control: the business need leads to authorizations and access granting

• Technology space– N+1 problem:

• Every application, service, package: +1 for account repositories• New & enhanced authorization and access control model(s)

– Ease of integration:• Some systems: immutable, really inert• others come and go, or are replace by new ones with a different vision

72018-2019 (C) A. Mariën

Mickey mouse model

• Divide and conquer: Four domains– Identity management– Business privilege management– Technical authentication and access control– Enterprise Privilege Management: the domain linking it all

together

• Core activities– Entity registration and correlation– Business privilege modeling and

model population– Access control solutions and provisioning– Privilege management and privilege use

8

IT

Identity Business

EPM

core

2018-2019 (C) A. Mariën

Four domains

• The three satellite domains must be able to evolve independently– Keep the center very stable

– Maintain interfaces as much as possible

– Absorb changes in the mapping on the borders (hinges)

• Minimize impact on other domains from– Changes in identity management solutions

– Business unit reorganization, model for privilege management changes

– Technology changes: new solutions, other provisioning, other repositories

9

EPM

interface

Variable

Stable

2018-2019 (C) A. Mariën

Identity management

• Approaches

– Registration authority, with local registration agents

– Correlation extensions in the various solutions

– “Master data management” approach

• Principle: Identity as root

– Identity-rooted data modeling

– Specific extensions

• Technical identities, and link with accountable identity

• Third party stub identities , and link with accountable identity

102018-2019 (C) A. Mariën

Business privilege management

• Rooted in business– The privileges of an actor are a consequence of the business context

• Business units have multiple privilege models– Organizational Roles, Organizational structure, Task based– Professional certification or authorizations– Unstructured subsets (for instance workload driven)

• High level differences between– Unit type: HR, finance, sales, IT– Business: bank, insurance, trading

• Primary schemes:– Direct: assign privileges to identities– Chain: example: Role to tasks to privileges

• Approach:– Map business model to a limited subset of concepts

• Example: functions, tasks, organizational units, accreditations

– Map this subset to privileges: pre-authorization step

112018-2019 (C) A. Mariën

Technical authentication and access control

• Account management– Accounts as a consequence of privilege assignments

• Authorization often hidden inside applications– Model per application, no model at all

• Technical privilege modeling– Permissions: abstract specific implementation– Example: Three distinctions to make: user, supervisor, manager; implementations

can vary:• Three classes of userIDs (Uxxx, Sxxx, Mxxx)• userID must be member of the right group• ACL contains userID

• Access control models– OASIS model provides solid base: policy (enforcement, decision, information,

administration) points: PDP, PEP, PIP, PAP– More details later

• Provisioning, SSO, federation, exceptions, credential management

122018-2019 (C) A. Mariën

13

The four-world model

SECURITY

TECHNICAL

CRM

HR

Contact

Marketing

Units

Functions

Accreditations

Contracts

Group Resource

Account

Projects

DelegationHierarchy

2018-2019 (C) A. Mariën

Process: business drives

• Processes and process design matter, a lot

• Move away from “request access”

– Access granting is based on business decisions• No need to ask for an account

• No need to check business reason for a request

– Revert thinking: business decision implies granting access• Not: ask for access as a separate process

• Changes in business imply granting the necessary access

• Task assignment, work unit assignment, … are business events at the basis of privilege changes

– Should lead to privilege changes

– Privilege changes should lead to account requests or removal

– No need to “request” new or delete old privilege

142018-2019 (C) A. Mariën

pilars

Identity

information

Real world

data

Registration

Accounts

Technical

world

Link with

identity

Credentials

Validation

data

ownership

Privileges

Business access

control

IT roles

IT access controls

Access policy

Actor, target

and context

dependent

layers

IAM conceptual design

ABB

IAM solution design

SBB

Access management

access management systems

Access control operation

access control infrastructure

Logg

ing

mo

nit

ori

ng

Generic structure of privilege management and usage

• 2 x 2 levels– Design

• Define the model– Example: RBAC, TBAC, group based, ACL

• Instantiate the model– Define roles, define tasks, define groups, define ACL controls

– Use• Populate the instance

– Assign accounts to roles, to groups, in ACLs

• Use the instance data– Access control decisions based on data

2018-2019 (C) A. Mariën 17

Privileges: two layers

• Two levels at least

– Privileges for primary services

– Privileges for privilege management

• Models for primary services

– Defined by business

– Use standard (RBAC) unless not suitable

• Model for privilege management

– Typically RBAC

2018-2019 (C) A. Mariën 18

Privilege to access control

• Two-step– Model for business level privilege management

– Technical infrastructure for access control

• Business view can be mapped on multiple technical realizations– Ex:

• business model: RO users and RW users

• Implementation:– Users must be member of the right group

– Two roles: RO and RW users; users gets right role

– User accounts with RW have account ending on rw (bad practice)

2018-2019 (C) A. Mariën 19

Cascading IAM

2018-2019 (C) A. Mariën 20

Systemapplication

PAP

PAP

user

Useradmin

Superadmin

App policy (ex.: RuBAC)

Admin policy (ex.: RBAC)

Super admin policy(ex.: 4-eyes, named accounts)

Software certificates

Hardware token

Hardware token + fingerprint

Automation

• Process: Three steps– Legitimate request for access?

• Implied by business decision.• Derive situation from business

data– Authorize access

• Principle-based authorization, not case-based.

• Modeling exercise: define privileges and mapping onto business attributes

– Enable access

• (Provisioning)• Update access control

repositories to allow access.• Update account repositories• Update access control component

database (PIP, PDP implementation)

• Business privilege assignment– Based on principles

• “All employees are authorized to access email”

• “Only personnel in HR has access to personnel records”

• “Only managers have access to evaluation reports”

– Based on business information sources• “is an employee”• “works in HR”• “is a manager”• “is a certified accountant”

• Automatic:– No approval delays for automated

privilege assignment– Privilege removal: as soon as business

context changes

• Responsibility:– Direct impact on operational rights– Change throttling/buffering

212018-2019 (C) A. Mariën

Additional complexity

• Constraints– Incompatible privileges cannot be combined– Important objective for business– Issues: where to check? When to check? Override?

• Contexts (mobile workforce, different commercial contexts)– Privileges assigned in context require context verification (acting for, from, …)

• Delegation (illness, holiday)– Delegation as normal business practice

• Not exceptional• Not via credential passing

• Transitions (function change, role change, in/out)– Transitions as normal business practice

• Start working, move to different unit, move to different function

– Change takes time• coexistence of two situations• Controlled move

• Parameterization– Opaque parameters for specific business information transfer to access control components– Context information

222018-2019 (C) A. Mariën

Access control

• Parameters for access control– Requesting entity

• Privileges

• Account

– Resource, target

• Target

• Action

• Parameters– Owner, restrictions

– Request

• Context: time, channel, location

• Actual access control: how? XACML model

232018-2019 (C) A. Mariën

XACML Data Flow Model

PEP

context

handler

8. request

context

PIP

4. attribute

query

9. response

context

1. policy

6. attribute

environment

resource

subjects

5b. envrionment

attributes

PAP

obligations

service11. obligations

PDP

access

requester2. access request

7. resource

3. request10. response

5c. resource

attributes

5a. subject

attributes

242018-2019 (C) A. Mariën

OASIS XACML based view

• Differentiation: location of the Access Control Enforcement Point (PEP), Decision Point (PDP), Administration Point (PAP) and Information Point (PIP):

– Provisioning Model (PAP[, PIP]):• privileges are translated into realm permissions and provisioned towards

the different realm masters.

• PDP, PEP: in the applications

– Privilege Information Retrieval Model (PAP,PIP):• PDP, PEP: in the applications

• But: PIP consulted to take decision

– Centralized Privilege Control (PAP,PDP[,PIP]):• PEP: in the applications

• PDP is externalized

• possibly PIP consulted to take decision

252018-2019 (C) A. Mariën

DAC & MAC (wikipedia)

• Discretionary Access Control (DAC)– the data owner determines who can access specific

resources– Example, a system administrator may create a

hierarchy of files to be accessed based on certain permissions.

• Mandatory Access Control (MAC)– users do not have much freedom to determine who

has access to their files.– Example, security clearance of users and classification

of data (as confidential, secret or top secret) are used as security labels to define the level of trust.

2018-2019 (C) A. Mariën 26

Some access control models

• Role-Based Access Control (RBAC)– RBAC allows access based on the job title. RBAC largely eliminates

discretion when providing access to objects. For example, a human resources specialist should not have permissions to create network accounts; this should be a role reserved for network administrators.

• Attribute-based Access Control (ABAC)– An access control paradigm whereby access rights are granted to users

through the use of policies which evaluate attributes (user attributes, resource attributes and environment conditions)

• Rule-Based Access Control (RuBAC)– RuBAC method is largely context based. Example of this would be only

allowing students to use the labs during a certain time of day.

• Tasked-based Access Control (ABAC)– An access control paradigm whereby access rights are granted to users

based on their assigned tasks

2018-2019 (C) A. Mariën 27