Generic Processes for Identity & Access

This GenericIAM.org document is published under a Creative Commons 2.0 Germany Attribution Licence
GenericIAM
Generic Processes for Identity & Access
Dr. Horst Walther, 2019-05-23, for the public, Version 0.163
2019-05-23
www.GenericIAM.org
1
2006 to 2018 - How far we got
Public draft and Report of the achievements of the standardisation
initiative GenericIAM.org.

Serious Warning
Stop me – before it is too late.
www.GenericIAM.org
2
 Acute PowerPoint poisoning is a widespread but widely unknown
civilization disease.
 It occurs particularly in the case of ambitious executives and their leaders.
 It can be easily healed by therapy from fresh air, sun, absolute peace and a
glass of wine.
2019-05-23

Agenda
• Driving modelling principles
How to define a common ground among the diversity of models?
• Essential modelling
How to separate essential business activities from implementation artefacts?
• Finding the interacting objects
How to derive a simple static role model?
• The broader context
How do Identity & Access objects relate to the embedding organisation?
• ESSAM – The essential simple static access model
How are the objects of the ESSAM defined?
• Time to introduce some physics
What is still missing to deal with the cruel, dirty world?
• Generic Processes of Identity & Access
Which processes need to be in place to maintain the model?
www.GenericIAM.org
32019-05-23

Driving modelling principles
• Follow a top-down approach
• Employ essential Modelling
• Define the model’s scope & context
• Find the essential interacting objects
• Define processes of object maintenance
• Determine actors
• Add physical objects
• Add physical processes
• Separate static from dynamic behaviour
2019-05-23
www.GenericIAM.org
4

Top down approach
Why did we abandon the initial bottom-up approach?
2019-05-23
www.GenericIAM.org
5

Top-down Modelling approach
The lessons learnt form our trials
• Trying to collect the broad experience of existing implementations
Modelling bottom-up seemed to us to be the natural approach.
• Collecting, anonymizing, harmonizing and normalizing implemented
models to derive generic models out of customer specific fragments.
• It only did not work. Although volunteers had invested a huge amount of
work, they failed to come-up with an accepted truly generic model.
• In fact it turned out, that especially the most experienced practitioners
faced difficulties in getting to the next layer of abstraction.
• Rigorous, principle-driven top-down modelling is a more promising
approach.
• Start by deriving the basic processes from the interaction of corporations’
fundamental objects.
2019-05-23
www.GenericIAM.org
6

Process modelling
Bottom-up or top-down - or what?
• Top-Down
• The promising approach
• Allows for generic modelling
• Starts with the interacting objects
• Interactions result in business processes
• Which fan out at implementation level
• Bottom-up
• Causes high effort to be invested
• Tends to stay environment specific
• May ignore vital business requirements
• Leads to an IT view on the business
• Can be used for quality assurance (QA)
• Is not recommended for modelling
7
 Go for Generic Top-Down Modelling
custom processes
adapted & extended
generic processes
elementary
activities
objects
subjects
2019-05-23
www.GenericIAM.orgwww.GenericIAM.org

Essential modelling
How to separate essential business activities from
implementation artefacts?
2019-05-23
www.GenericIAM.org
8

• The Essential Systems Modelling
Methodology was defined and
applied by Stephen M. McMenamin
in 1984.
• It was published in a book called
Essential Systems Analysis
(McMenamin, S. & Palmer, J.,
Essential Systems Analysis, Yourdon
Press Prentice Hall, Englewood Cliffs,
NJ, 1984)
Modelling fundamentals
Follow the essential systems modelling (esm) principles
2019-05-23 9
www.GenericIAM.org

Essential Modelling
In a four-step Process to the target implementation model
• McMenamin and Palmer 1984 recommend following a four-step
specification process with the analysis of the source model :
1. Analysis of the current system; creating a model of the current implementation
of the system.
2. Analysis of the fundamental concepts of this Implementation: creating a model
of the essence of the current system. It will be abstracted from all
implementation specific properties (perfect technology).
3. Deriving the requirements to the new system: creating a model of the essence
of the target system. This model describes the requirements and is not
affected by any implementation considerations.
4. Designing the target system: creating a model of the implementation model of
the target system.
2019-05-23
www.GenericIAM.org
10

The modelling cycle
Modelling the essence removes implementation artefacts
2019-05-23
www.GenericIAM.org
11
essential
target model
physical
current model
essential
current model
physical
target model
The enterprise
Modelling cycle
[abstraction]
essential
layer
physical
layer
today future
[time]
classic
systems analysis
technological
development
“forbidden"
transition
enterprise strategy
abstraction
projection
Enterprise models
Evolution
architecture
implementation
• objects
• roles
• processes
Note: The direct
transition is a short-cut
to hell

• McMenamin & Palmers propose an event-oriented approach to process
modelling.
• To identify the "essential (elementary or atomic) processes" & their
relationships to the events that drive the business.
• Essential Processes are triggered by external or by time events.
• There are 2 types of essential processes …
• Fundamental essential processes deliver an external result.
• Administrative essential processes store a result internally for a fundamental
essential process.
• Essential Processes are time decoupled
• They communicate asynchronously via essential stores.
Caveat: It turned out, that especially the most experienced practitioners face
difficulties in getting from implementation to some layer of abstraction.
Essential Modelling
Steve McMenamin & John Palmers essential processes
2019-05-23 12
www.GenericIAM.org

Essential modelling characteristics
Avoid technical „folklore“ through the concept of perfect technology
• McMenamin & Palmer propose an event-oriented approach to process modelling.
• Essential systems can be detected by the following gedankenexperiment …
• "If we had perfect implementation technology (e.g., a computer with infinite speed,
unlimited memory, transparent interface, no failures, and no cost), which of the
requirements would still need to be stated?"
• Every requirement that is still necessary in spite perfect technology is an essential
requirement.
• To remove legacy implementation artefacts, only the essence is modelled.
• In the inner system neither errors nor processing- or waiting times occur.
• Here there is no need for audit, translation und transport processes.
• The system context however – the real world - is considered as imperfect.
• Both are separated by a physical ring of audit, translation und transport processes.
2019-05-23
www.GenericIAM.org
13

Essential system 1st – physical ring 2nd
Start with the stable essential core - followed by volatile physical ring
• Essential processes represent the
business‘ intended behaviour.
• They can be identified assuming
“perfect technology”
• They need not to care for
transport, translation or
audit activities.
• They are implementation
independent.
• They form a durable core of
the business.
• They only change if business changes.
• Physical processes are introduced to
deal with the imperfect outside world.
• Here transport, translation &
audit processes are
introduced.
• Physical processes are
implementation
dependent.
• They are more volatile
and subject to
frequent change.
• When re-implemented the
physical ring will be
different while the
essential core may stay
unchanged.
14
physical ring
physical ring
essential
core
142019-05-23

• Document the current situation
• Build a model of the actual implementation of the
current system.
• This is the physical system like it is implemented in
reality - the current physical system.
Essential Modelling fundamentals
To the target implementation model in a 4-step Process
• Include new requirements into the essential
model
• Build the new essential model by adding new
requirements.
• This model represents all functional requirements.
• Ideally it is still free of any design- and
implementation consideration.
• The result is the new essential system.
• Extract the fundamental concepts of the
current physical model
• Deriving of the essence out of the current system.
• All implementation specific artefacts are removed in
this step.
• Using "perfect technology" as the guiding principle.
• The result is the current essential system.
• Design the new physical model
• Build the implementation model of the new system.
• The result is the new physical system.
 Essential modelling removes implementation artefacts leaving the functional essence.
2019-05-23 15
www.GenericIAM.org
1 2
3 4

• In the essential model the essential business requirements are documented
stating what has to be implemented - without defining how it will be done.
• This separation from implementation artifacts enables us to implement the
same unchanged essential system using different target technologies.
• Even when using identical technology maintaining the essential model may turn
out to be very helpful.
• When significant changes are applied to the essential (=functional) model the
optimal new physical model may be implemented by a considerably different
design than the current physical model.
Representing requirements
The essential model represents the functional requirements.
2019-05-23 16
www.GenericIAM.org

The assumption of perfect technology leads to the following model characteristics:
• Inside the system there are neither errors nor processing or waiting times.
• No audit-, translation- or transport processes are necessary.
• But the environment of the system is considered as imperfect - as is.
• Along the systems boundary a ring of audit-, translation- and transport
processes connects to this real world - the physical ring.
The purpose of finding the essence
Avoid technical folklore by assuming perfect technology
2019-05-23 17
www.GenericIAM.org

1. Essential Processes may be triggered by an external or a time event.
2. Fundamental essential processes yield an externally useful result.
3. Administrative essential Processes store their results in essential stores to be used
by a fundamental essential process.
4. Essential Processes are time decoupled, they communicate via essential stores.
5. Essential processes may be expanded to form nested essential models themselves.
6. Essential models may be collapsed to serve as essential processes on a higher level.
7. At the lowest level the essential processes represent elementary activities.
8. Elementary activities may be triggered by state transitions of the fundamental
business objects.
9. Elementary activities typically bundle all actions, which are done by one processor
without a necessary interruption.
Composing the essential system
Nine rules of thumb to ease essential modeling
2019-05-23 18
www.GenericIAM.org

Finding the interacting objects
How to derive a simple static role model?
2019-05-23
www.GenericIAM.org
19

The interacting objects of Access Management
Access is about digital identities accessing information objects
In the beginning there were …
1. The information object,
2. The digital identity
3. A relationship representing the access
202019-05-23
Digital
Identity
Information
Object
www.GenericIAM.org
„The digital identity accesses the information object“

Access, information objects & digital identities represent own process groups
212023-May-19
identity
Information
object
Identity
Management
Information
Management
Access
management
• Identity Management deals with the lifecycle
of the digital identity
• The information Management deals with the
lifecycle of the information object.
• This will become our context boundary for the
modelling focus.
• Leaving Access Management dealing with the
access.
www.GenericIAM.org

The authorisation ties digital identities to information objects
Derived objects …
• The authorisation represents the relationship between the digital
identity and the information object
• It expresses:
„The digital identity is authorised to access the information
object“.
222019-05-23
Digital
Identity
Information
Object
www.GenericIAM.org
Authorisation

The authorisation has to be qualified by action type: The operation
• Access to information objects is usually
qualified by an access type.
• This access type is usually expressed as
operations.
• E.g. fundamental operations of object
maintenance are: Create, Read, Update &
Delete – often abbreviated as CRUD.
232019-05-23
Digital
Identity
Information
Object
www.GenericIAM.org
Authorisation
operation

permission
The NIST calls this operation on objects „permission“
242019-05-23
Digital
Identity
Information
Object
www.GenericIAM.org
Authorisation
operation
• The NIST groups operations on objects
as ”permissions.
• Hence a digital identity is authorised by
granting it certain permissions.

permission
The role is the central structuring object of authorisation
The role is a bundle of permissions …
• It represents a compound business necessity
• A role is composed of business functions to be
performed in a certain business context.
• To fulfil its mission each business function
needs certain permissions.
• So a role refers to a bundle of permissions
• Hence roles may be interpreted and enforced
at runtime.
• Or they may be split apart transformed und
transported (provisioned) to target systems.
• In the latter case the policy enforcement is left
to the target system.
252019-05-23
Digital
Identity
Information
Object
www.GenericIAM.org
Authorisation
operation
Role

permission
A business role conveys more access determining dimensions beyond function
262019-05-23
Digital
Identity
Information
Object
www.GenericIAM.org
Authorisation
operation
Business
Role
Functional
role
Constraint
The role is a bundle of permissions …
• As a role is composed of business functions to
be performed in a certain business context.
• By design roles are defined purely functional
• In a division of labour based organization,
however, the corporate function is restricted
to a certain sphere of responsibility.
• Hence the roles representing the business are
made up of a functional roles and constraints
applied to them.
• For role modelling purposes constraints as well
as functional roles need to reference further
context objects.

The broader context
How do Identity & Access objects relate to the embedding
organisation?
www.GenericIAM.org
27
Governance functions
Core functions
Support functions
The enterprise value chain
2019-05-23

The broader context
Why are digital identities held by an organisation?
• When an identity enters the corporate ecosystem
there is a reason to do so.
• There is an interaction of the person, represented
by the digital identity, and the organisation.
• This interaction usually leads to an agreement.
• The agreement may be formal (employment
contract) or informal (product offer via phone),
documented or not documented.
• According to data privacy laws only in case of
vetted interests the there is sufficient reason
justifying the storage of identity information.
• Some form of documented agreement can
therefore be assumed.
2019-05-23
www.GenericIAM.org
28
Digital
Identity
Agreement
Organisation
signs

The broader context
Where are roles anchored in the organisation?
• When organising a corporation alongside its
planned business processes, tasks are defined to
perform the elementary activities.
• Being elementary these activities represent a single
session, usually conducted by a single person or
system as represented by the digital identity.
• These planned repeating corporate tasks are
bundled into roles, classifying the digital identity.
• Hence roles contain all skills and necessary
authorisations to perform this tasks.
• To assign a task to a digital identity (a person or a
system) an agreement has to be closed first.
• This agreement may be valid for a limited in time
• All this happens in the realm of Identity
Management Relationship Management.
2019-05-23
www.GenericIAM.org
29
Digital
Identity
Agreement Role
Organisation
signs
refers to
defines

The broader context
How Agreements influence the Access Management
• The agreement determines the authorisations
necessary to perform the tasks.
• Agreement means a role for the digital identity to
play within the organisation.
• Authorisations are handled in Access Management.
• Hence for Managing Access only the authorisation
part of a role is necessary.
• Some processes with impact on Access Management
are handled within Identity Management. e.g. …
• Assigning a deputy during planned temporary absence.
• Temporary leave, e.g. maternity leave or Mandatory
Time Away (MTA).
• They unfold their effects in Access Management
2019-05-23
www.GenericIAM.org
30
Digital
Identity
Agreement Role
Organisation
signs
refers to
defines
Authorisation
determines

Access Management
Identity Management
The broader context
How Agreements influence the Access Management
• The agreement determines the authorisations
necessary to perform the tasks.
• Agreement means a role for the digital identity to
play within the organisation.
• Authorisations are handled in Access Management.
• Hence for Managing Access only the authorisation
part of a role is necessary.
• Some processes with impact on Access Management
are handled within Identity Management. e.g. …
• Assigning a deputy during planned temporary absence.
• Temporary leave, e.g. maternity leave or Mandatory
Time Away (MTA).
• They unfold their effects in Access Management
2019-05-23
www.GenericIAM.org
31
Digital
Identity
Agreement Role
Organisation
signs
refers to
defines
Authorisation
determines

How to find roles
Processes, Roles & Rules express the Organisation
Top-down Modelling
• Start with the business processes
• Business processes express the
organisation’s dynamic behaviour.
• They consist of elementary functions: one
person at a time in one location
• Functions are performed by roles.
• Roles may be augmented by rules to
reflect the influence of non-functional
parameters.
• They need appropriate access to
information objects.
• Processes and Roles need to be modelled
jointly .
• Roles are populated by functions taken
from a functional enterprise model.
Function
#3
Process
Role
#1
Role
#2
Resource
#1
Resource
#2
Resource
#3
Resource
#4
create
read
update
delete
approve
reject
create
read
update
delete
Signoff
escalate
Policies
Rules
2016-02-17
www.GenericIAM.org
32
Enterprise
Model
Function
#1
Function
#2
2019-05-23

Types of Enterprise Models
Enterprises can be modelled as Functional or Object Oriented Taxonomies
• Functional Taxonomy
• Focuses on functions within
organizations
• Functions are associated to
business processes
• Requires organizational
maturity in describing
processes and functions
• Is in line with traditional
business organisation
• Easier to uncover & to
communicate
• Only delivers functions
• Object Oriented Taxonomy
• Focuses on the interacting
objects of organizations
• Objects have their „methods“
to operate on them
• Objects introduce an additional
structuring layer.
• OO Models are more powerful
& more demanding
• They cause more initial effort
• They are less common
33
2016-02-17
www.GenericIAM.org
 Both Models can be mapped towards each others however
2019-05-23

The Functional Enterprise Model
A functional hierarchy from value chain down to elementary functions
• In a static business a person’s tasks can be expressed in roles.
• Roles are to be populated by business functions from an enterprise model.
• Most often they are functional enterprise models or taxonomies
• Structured hierarchically
• Named canonically
• Augmented by aliases.
• Canonical naming (Ontology) is required
• For methodological rigour
• To easily spot commonalities,
• Aliases map the canonical names to folkloric designations from BAU.
• Functional taxonomies are useful because regulations are often expressed as
functions.
• E.g. requiring Segregation of Duties (SoD).
• Even more helpful would be the use of an object oriented enterprise model.
Governance functions
Core functions
Support functions
The enterprise value chain
www.GenericIAM.org
2019-05-23 34

What is a Taxonomy?
• Taxonomy is derived from Greek
ταξινοµία = taxinomia, from taxis =
order and nomos = law.
• It refers to either a hierarchical
classification of things, or the
principles underlying the
classification.
• Almost anything, animate objects,
inanimate objects, places, and events,
may be classified according to some
taxonomic scheme.
• Taxonomy is systematic classification
• Taxonomies provide a guiding
structure to information and content
2019-05-23
www.GenericIAM.org
35

Examples of Taxonomies
Most commonly known examples are found in Biology
• Classification of organisms (life) into a
hierarchy of groupings
• Runs from the general to the specific
• Reflects evolutionary and usually
morphological relationships.
• Historically an enormous effort has been
devoted to agree on a common and
widely accepted taxonomy.
• Dispute is continuously ongoing
• Several currently uncategorized
candidates for a more fine grained
classification are on the waiting list.
• Frequent re-classifications of species is
common.
2019-05-23
www.GenericIAM.org
36

A corporate Functional Taxonomy
A functional hierarchy from value chain down to elementary functions
category
domain
sub-domain
capability
function
www.GenericIAM.org
• The functional enterprise model …
• aka functional taxonomy
• aka domain model
• Elementary functions need to be known for …
• Automation
• Access control
• They …
• can be grouped to business capabilities,
• which can be grouped to business sub-domains
• which can be grouped to domains,
• which can be grouped to categories
• which comprise the corporation
• Different notations and levels can be applied
• Internally the models need to be consistent
2019-05-23 37

Functional Taxonomy
A near real world banking example
Category Domain
Sub-
Domain
Capability
G Governance Functions
G.1 Corporate Controlling
G.1.1 Corporate Development
G.1.1.1 Strategy Development
G.1.1.2 Project Portfolio Management
G.1.1.3 Project Management
G.1.1.4 Mergers & Acquisitions
G.1.1.5 Regional Development
G.1.1.6 Outsourcing Management
G.1.2 Corporate Communication
G.1.2.1 Internal Communication
G.1.2.2 External Communication
G.1.3 Regulatory Reporting
G.1.3.1 Supervisory Regulatory Reporting
G.1.3.2 External Reporting
G.1.3.3 Country Reporting
G.1.4 Internal Audit
G.1.4.1 Audits
G.1.4.2 Internal Control System
G.1.5 Legal Functions
G.1.5.1 Compliance
G.1.5.2 Data Protection
G.1.5.3 Corporate Law
G.1.5.4 Legal Advice
G.2 Risk Management
G.2.1 Risk Classification
G.2.1.1 Parameter Models
G.2.1.2 Rating & Scoring
G.2.1.3 Portfolio Analysis
G.2.2 Risk Control
G.2.2.1 Loan & Risk Strategies
G.2.2.2 Risk Quantification
G.2.2.3 Risk taking Capacity
G.2.2.4 Reinsurance
G.3 Workforce & Organisation
G.3.1 Human Resources
G.3.1.1 Human Resources Development
G.3.1.2 Human Resources Management
G.3.1.3 Staff Planning
G.3.1.4 Staff Resource Planning
G.3.1.5 Human Resources Controlling
G.3.1.6 Human Resources Support
G.3.1.7 Tariff Planning
G.3.2 Organisation
G.3.2.1 Guidelines & Processes
G.3.2.2 Process Management
G.3.2.3 Organisational Structure
G.3.2.4 Policy Documents
G.4 Corporate Finance
G.4.1 Treasury
G.4.1.1 Asset Liability Management
G.4.1.2 Liquidity Management
G.4.1.3 Financial Trading
G.4.1.4 Money Market
G.4.1.5 Securitisation
G.4.2 Controlling
G.4.2.1 Financial Controlling
G.4.2.2 Equity Controlling
G.4.2.3 Internal Controlling
Category Domain
Sub-
Domain
Capability
C Core Functions
C.1 Product Management & Marketing
C.1.1 Product Management
C.1.1.1 Product Development
C.1.1.2 Product Pricing
C.1.1.3 Product Portfolio Management
C.1.1.4 Pricing
C.1.1.5 Commission Policy
C.1.2 Marketing
C.1.2.1 Market Research
C.1.2.2 Customer Segmentation
C.1.2.3 Market Cultivation
C.1.2.4 Product & Performance Communication
C.1.2.5 Brand Management
C.2 CRM & Sales
C.2.1 CRM & Campaign Management
C.2.1.1 Customer Self-Service
C.2.1.2 Campaign Management
C.2.1.3 Analytical CRM
C.2.2 Sales Support
C.2.2.1 Dealer Recruitment
C.2.2.2 Marketing Control
C.2.3 Advisory Services & Sales
C.2.3.1 Customer Recruitment
C.2.3.2 Sales Approach
C.2.3.3 Customer Service Outbound
C.2.3.4 Financing Decision
C.2.3.5 Point of Sales
C.2.3.6 Remarketing
C.3 Contract Life Cycle
C.3.1 Enquiry & Application Processing
C.3.1.1 Business Initiations
C.3.1.2 Transaction Processing
C.3.1.3 Process Decisions
C.3.1.4 Fraud Prevention
C.3.1.5 Framework Agreements
C.3.1.6 Central Underwriting
C.3.2 Contract Management
C.3.2.1 Contract Preparation
C.3.2.2 Contract Portfolio Management
C.3.2.3 Fraud Management
C.3.2.4 Dunning
C.3.3 Customer Service
C.3.3.1 Query Management
C.3.3.2 Contract Information
C.3.3.3 Customer Service Inbound
C.3.3.4 Complaints Management
C.3.4 Claims & Service Management
C.3.4.1 Claims Management
C.3.4.2 Claims Processing
C.3.4.3 Loss Ratio Management
C.3.4.4 Damage Accounting
C.3.4.5 Service Provider Management
C.3.5 Claims Management & Collections
C.3.5.1 Non-payment processing
C.3.5.2 Telephone Collections
C.3.5.3 Judicial Debt Collection
C.3.5.4 Seizure of Vehicles
C.3.5.5 Collections Scoring
C.3.5.6 Insolvency Processing
Category Domain
Sub-
Domain
Capability
S Supporting Functions
S.1 Accounting & Balance Sheet Analysis
S.1.1 Accounting
S.1.1.1 Finance Accounting
S.1.1.2 Debtor Accounting
S.1.1.3 Creditor Accounting
S.1.1.4 Insurance Accounting
S.1.1.5 Asset Accounting
S.1.1.6 Salary Accounting
S.1.2 Balance Sheets & Profit & Loss Accounts
S.1.2.1 Balance Sheets
S.1.2.2 Profit & Loss Accounts
S.1.3 Payments
S.1.3.1 Domestic Payments
S.1.3.2 International Payments
S.1.3.3 Single European Payment Area
S.2 Information Technology
S.2.1 IT-Governance
S.2.1.1 IT Architecture & Standards
S.2.1.2 IT Compliance & Risk Management
S.2.1.3 Information Security
S.2.1.4 IT Sourcing
S.2.1.5 Software Development Process
S.2.1.6 System Operations Process
S.2.2 Software Development
S.2.2.1 Requirements Management
S.2.2.2 Technical Architecture
S.2.2.3 Application Design
S.2.2.4 Programming
S.2.2.5 Test Management
S.2.2.6 Deployment
S.2.3 IT Operations
S.2.3.1 Incident & Problem Management
S.2.3.2 Operating & Monitoring
S.2.3.3 Technical Operations
S.2.3.4 Access & Identity Management
S.2.3.5 Relationship Management
S.2.3.6 Change Management
S.2.3.7 Service Level Management
S.2.3.8 Configuration Management
S.2.3.9 IT Infrastructure
S.3 Contract Supporting Functions
S.3.1 Relationship Management
S.3.1.1 Business Partner Maintenance
S.3.1.2 Business Partner Analysis
S.3.1.3 Partner Contract Management
S.3.1.4 Subsidy Management
S.3.2 Objects & Securities
S.3.2.1 Contractual Object Management
S.3.2.2 Collateral Management
S.3.2.3 Residual Value Management
S.3.2.4 Market Value Management
S.3.3 Information & Document Logistics
S.3.3.1 Input Control
S.3.3.2 Archiving
S.3.3.3 Output Control
S.3.3.4 Document Service
S.4 General Support Functions
S.4.1 Analysis & Reporting
S.4.1.1 Internal Reporting
S.4.1.2 Ad-Hoc Reporting
S.4.1.3 Data Quality Management
S.4.2 Purchasing
S.4.2.1 Tender
S.4.2.2 Order
S.4.2.3 Supplier Management
S.4.3 Facility Management
S.4.3.1 Business Facility Management
S.4.3.2 Technical Facility Management
S.4.3.3 Utilisation Planning
S.4.4 Corporate Security
S.4.4.1 Asset Protection
S.4.4.2 Business Continuity Management
S.4.4.3 Safety Awareness & Training
www.GenericIAM.org
382019-05-23

Why do we need a functional Taxonomy?
A functional taxonomy is a vital part of the enterprise architecture
It serves several purposes …
• To be able to form functional roles
• To detect functional redundancies
• To support business process modelling
• To enable process automation
• To build a foundation for any digital transformation
2023-May-19
www.GenericIAM.org
39
 If not guided by a functional taxonomy, role modelling yields
arbitrary results at best.

How to create a functional taxonomy?
A corporate Taxonomy will not come cheap
• For the construction of a meaningful taxonomy an accepted ontology for a
rigorous naming is required.
• Ontology is a formal naming and definition of the types, properties, and
interrelationships of the existing entities
• E.g. …
• Enterprise functions should be atomic. Hence avoid concatenation operators like ‘and’, ‘or’, ‘xor’ in
any designations.
• Names like ‘Governance & Auditing Tools’ or ‘Identity & Access’ indicate some arbitrariness,.
• We should split the concepts or yet have to find a common name.
• So not surprisingly there is no generally accepted standard taxonomy for the
banking sector in use.
• The creation of a corporate taxonomy can be performed alongside an enterprise
wide business process modelling.
• It is one of the most prominent tasks of an enterprise architect
2019-05-23
www.GenericIAM.org
40

References
• A collection of controlled vocabulary terms organized into a hierarchical
structure. (ANSI Z39.19-2005 (R2010)
• Hedden, Heather. The Accidental Taxonomist. Medford, NJ: Information
Today, 2010
• Stewart, Darin L. Building Enterprise Taxonomies. United States: Mokita.
2008
2019-05-23
www.GenericIAM.org
41

ESSAM – The essential simple static access model
How are the objects of the ESSAM defined?
2019-05-23
www.GenericIAM.org
42

43
Maintain identity
fundamental business process groups
• 3 fundamental business process groups are tied to the digital identity:
• on-boarding,
• off-boarding &
• change processes
• They differ in flavour by the type of the digital identity.
Identity
create
change
terminate
employee
hire
change
terminate
contractor
contract
change
terminate
partner
contract
change
terminate
customer
open
change
terminate
partner
employee
register
change
terminate
inheritance
 These are essential processes – they belong to the conceptual layer.
Adding the physical layer implies more processes (e.g. provisioning).
2019-05-23
www.GenericIAM.org

entitlement
identity
functional
role
Is assigned 1:n
authorisation
information
object
business
role
operation
constraint
The Identity
The digital identity is the digital representation of an individual
• The digital identity is the digital
representation of an individual.
• Defined by a set of attributes.
• The individual has a defined relationship
to the corporation.
• It is stored and maintained as long as …
• the interest in this relationship lasts
and
• no legal or regulatory requirements
restricts its use.
www.GenericIAM.org
442019-05-23

Functional Role
a grouping of business functions from a functional enterprise model
• The functional role is an extract from a
functional enterprise model (domain
model).
• The domain model is purely functional
(as opposed to object-oriented).
• The functional role consists of a
collection of corporate functions.
• It does not contain any access rights to
applications.
• The functional role is the natural
starting point for a role-based
authorisation.
• Since SoD requirements are defined
purely functionally, they can be
expressed in different, mutually
exclusive functional roles.
www.GenericIAM.org
2019-05-23 45
permission
identity
functional
role
authorisation
Information
object
business
role
operation
operate on 1:n
constraint

The „functional role"
• Functional role is a bundle made up of business functions
as defined in a functional enterprise model.
• It re-presents the tasks which have to be performed.
• The functional role just specifies functions to be performed.
• The functional role is a projection of the enterprise model.
• In case of a functional enterprise model the functional role just lists
corporate functions.
• Can’t be used to grant access to information objects or applications.
• Only in special cases it allows to derive the affected information objects
they are acting on from the role's names.
• If there is an object oriented (means class based) enterprise model
available they functions are partly constrained already.
462019-05-23
www.GenericIAM.org

Constraint
a simple rule restricting the applicability of functional roles
• Constraints are used to restrict the
functions assigned via a functional
role.
• They may restrict area, location, time,
organisational unit, authority & more.
• Constraints can be used as a measure
of risk limitation.
• They may limit the handled value
(value constraint) or the range of
influence (structural constraint).
• Constraints can express the division
of labour.
• Constraints can be applied
dynamically
• They can limit operational risks.
472019-05-23
www.GenericIAM.org
permission
identity
functional
role
authorisation
Information
object
business
role
operation
operate on 1:n
constraint

The 7 commonly used static constraint types
But the universe of possible constraints is not limited
• Region
Usually the functions to be performed are limited to a region (US, Germany, Brazil, China ...). It may be useful to explicitly state the
absence of this restriction by the introduction of a region "world".
• Organisational Unit
Often areas of responsibility are separated by the definition of organizational units (OU). It may be useful to make the absence of this
restriction explicit by the introduction of the OE "group".
• Customer group
The segmentation of the market by customer group (wholesale, retail, corporate customers, dealers …) also leads to constraints to
the pure function.
• Authority level
In order to control inherent process risks organisations often set "levels of authority". There may be directly applicable limits, which
are expressed in currency units or indirectly applicable ones. In the latter case they are expressed in parameters, which in turn can be
converted into monetary upper limits, such as mileage allowances, discounts, discretion in the conditions and the like.
• Project
If projects may be considered as temporary OUs. Alternatively they represent a separate dimension: project managers and other
project roles usually are restricted to particular project and cannot access information objects of other projects.
• Object
Sometimes you may be able to restrict entitlements to a defined information object. A tester has to run tests on particular software
object (application or system) only; a janitor is responsible just for a particular house.
• Contract type
Different entitlements also arise from the contractual agreement a person has with the corporation. Hence the entitlements of
permanent employees, interim managers, contractors, consultants and suppliers usually differ considerably.
2019-05-23 48
www.GenericIAM.org

Next step: Using dynamic constraint types
Context comes into play – and requires dynamic constraints
• Device
The device in use might limit what someone is allowed to do.
Some devices like tablets or smartphones might be considered less secure.
• Location
The location the identity is at when performing an action. Mobile, remote use might be considered less secure.
• System health status
The current status of a system based on security scans, update status, and other “health” information, reflecting the attack
surface and risk.
• Authentication strength
The strength, reliability, trustworthiness of authentications. You might require a certain level of authentication strength or
apply
• And more…
Many other types of contextual information might become part of business rules and thus end up in constraints.
49
Use of dynamic context based constraint types requires policy decision, pull type attribute supply and
implemented business rules.
constraint
changes
context
business
rule
is used by
2019-05-23
www.GenericIAM.org

The essential objects of Identity & Access
Objects in the ESSAM model maintain static relationships - a schematic view
Anchor point is the business role …
• The functional role just specifies functions to
be performed.
• The business role binds the functional role to
specific systems.
• Additional constraints may further restrict the
business role’s capabilities.
• Permissions are operations on information
objects. They represent the elementary
privileges.
• There are no systems in the essential view.
They represent a physical implementation of
• The identity is assigned several business roles
to define the planned information access.
• All access information is stored in one or more
authorisation objects per identity.
502023-May-19
permission
identity
functional
role
authorisation
Information
object
business
role
operation
operate on 1:n
constraint
www.GenericIAM.org

Business Role
Here the business justification for automation & access is held
In the essential simple static access model
…
• Functional roles express the function
• Parameters are used as constraints
• They combine to several business
roles
• Business roles are defined in pure
business terms
• Business roles must be mapped to
permissions.
• Permissions are operations on objects
• Business roles may be statically
generated.
• They may be determined dynamically
at run time.
512019-05-23
www.GenericIAM.org
permission
identity
functional
role
authorisation
Information
object
business
role
operation
operate on 1:n
constraint
 The separation of functions & constraints
pays off even in the absence of complex rules.
Technical layer
Business layer

The Business Role
Where everything comes together
• In this model the business role is the central structuring element.
• It contains all information necessary for the privilege assignment on
business level.
• By the introduction of the business role the purely functionally defined
functional roles are finally bound to the specific Information objects
(or alternatively systems).
• This can be done by linking directly to elementary permissions (entitlements).
• In cases, when systems offer some kind of roles already, the business role may link to these
'system roles'.
• Here too the constraints unfold their restricting effect.
• If you (technically) manage to bind the information objects strictly rule driven to the
functional roles you may not need to store the business roles persistently.
• Doing so ‘on the fly’ is a requirement of dynamic authorisation Management.
• In this (lucky) case they can be considered as purely virtual (transient) objects.
• In most - real world - cases however we have to consider them as static (persistent) objects.
• You may imagine the business role as a triple of references - and not much more.
• Those are the identifiers of the functional role, the constraint and the permissions which are
referenced.
522023-May-19
www.GenericIAM.org

The permission
The atomic operation on an information object – aka “entitlement”
• The entitlement is the elementary
object of access management.
• In RBAC it is called ‘permission’.
• It is defined as operation on
• Often access to systems substitutes
the access to information objects.
• But in access control the information
object is the asset to be protected.
permission
identity
functional
role
authorisation
Information
object
business
role
operation
constraint
Technical layer
Business layer
532019-05-23
www.GenericIAM.org

The authorisation
Authorising means assigning a business role to an identity
• Assigning the business role is to
a digital identity creates the
authorisation.
• By this very act the role based
access assignment is done.
• The identity may be assigned
several business roles.
• The authorisation can be
created statically at
administration time or
dynamically at run time.permission
identity
functional
role
authorisation
Information
object
business
role
operation
operate on 1:n
constraint
Technical layer
Business layer
2019-05-23
www.GenericIAM.org
54

Maintenance processes
Good starting point - for derived entities it becomes more complicated
 Maintenance Processes of 5 fundamental
business objects of Access Management:
• Maintain Digital Identity
• Maintain Functional Role
• Maintain Constraint
• Maintain Business Role
• Maintain Authorisation.
 Maintain represents the CRUD-operations
(create, read, update & delete)
 The Maintenance of the information object
is not an IM or AM-Process. Being an
Information Management Process it is out of
scope here.
 The authorisation processes are
represented by the maintenance of the
derived object authorisation.
 The authorisation is maintained by assigning
/ removing business roles to / from digital
identities
www.GenericIAM.org
2019-05-23 55
Constraint
Business
role
Authorisation
Functional
role
maintainmaintain
maintain
essential process
maintain
Digital
identity
maintain
Model Maintenance
IM
information
object
maintain
InfoM
IM
IM & AM AM
IM

Time to introduce some physics
What is still missing to deal with the cruel, dirty world?
• We do not act on Information objects directly – there
are systems involved.
• Most systems hold their own partial copy of the
authorisation - the account is born
2019-05-23
www.GenericIAM.org
56
physical ring
physical ring
essential
core

From essential to physical
Introducing the system role
• In the Core
• The system role
• The account
• In the physical ring
• The Provisioning process
• The Recertification Process
2023-May-19 57
www.GenericIAM.org
physical ring
physical ring
essential
core
www.GenericIAM.org

System
Adding the system role
2019-05-23
www.GenericIAM.org
permission
identity
functional
role
Is assigned 1:n
authorisation
objects
business
role
operation
constraint
system
role
58
Systems host information objects …
• In a non-SOA-world systems represent the
information objects
• They expose the elementary permissions
• They may hold the account, which is a partial
local copy of the authorisation.
• The system role contains only the permissions
of the particular system.
• The business roles combine all system roles.
• Still the corporate assets (information objects)
are to be protected – not the systems.
• A catalogue cross-referencing assets to
systems need to be in place.
• In a service oriented architecture (SOA) there
will be no systems any longer – hence no
system roles.
58

System
2011-06-0859
Introducing the account
59
permission
identity
functional
role
Is assigned 1:n
objects
business
role
operation
constraint
system
role
account
The account is a physical artefact …
• The account combines the identity information
with the system role information.
• The account represents the authorisation on
system level
• Usually there is one account per identity and
system
• Accounts may be used without having system
roles defined too.
• This is often the case in physical
implementations
• Keeping the system role however adds to clarity
2019-05-23
www.GenericIAM.org

System
2011-06-0860
Introducing the account
60
permission
identity
functional
role
Is assigned 1:n
objects
business
role
operation
constraint
system
role
account
The account is a physical artefact …
• The account combines the identity information
with the system role information.
• The account represents the authorisation on
system level
• Usually there is one account per identity and
system
• Accounts may be used without having system
roles defined too.
• This is often the case in physical implementations
• Keeping the system role however adds to clarity
• Likewise maintaining the authorisation is a useful
concept on the business level.
• An authorisation may split into several accounts
• One account belongs to just one authorisation
authorisation
2019-05-23
www.GenericIAM.org

Generic Processes of Identity & Access
• Which processes need to be in place to maintain the model?
• Starting with the maintenance processes
2019-05-23
www.GenericIAM.org
61

The context of Identity & Access
The Access Management draws from 3 sources in the enterprise
622019-05-23
www.GenericIAM.org
Identity & Access
The Identity & Access System …
• Receives attributes & status of a person or
thing from the respective source system.
• Receives enterprise attributes from an
attribute service.
• Receives the information objects, categorized
by its sensitivity.
• Receives the corporations’ functional
taxonomy.
• Receives policies to drive its decision, e.g. SoD-
Policies, retention policies, naming
conventions, …
• Delivers the authorisation decision to some
enforcement processor.
HR-, CR-,
IoT-System Person
Thing
Enterprise
architecture
Information
Objects
Policy
Enforcement
Point
authorisation
corporate
policies
policy
Enterprise
Attributes
Functional
Taxonomy

Grouping of Identity & Access processes
The Identity & Access processes may be viewed from different perspectives
1. Separate Identity from Access
• Identity management has a justification sui generis.
• It is no appendix of security management
• Access management is be built on top of identity processes
2. Separate operate, manage & govern
• Operation: identify, authenticate and authorise
• Management: administer digital identities & their access
• Governance: direct & supervise
3. Separate essential from physical
• Essential: planned processes transforming business objects
• Physical: check, transport, translate.
19-05-2363
63
63
2019-05-23

Separate Identity from Access
IAM = Identity Management + Access Management
64
Identity &
Access
Management
Identity
Management
Define the digital
identity life cycle
& its relation to the
corporation.
Access
Management
Model & manage the
identity's access to
corporate resources.
642019-05-23
www.GenericIAM.org
• Identity management has a justification sui generis.
• It is no appendix of security management
• Access management is be built on top of Identity processes
www.GenericIAM.org

Separate operate, manage & govern
The Processes of the Identity Management may be grouped in several ways
• Business as usual (BAU) represents the prime
justification for running a business.
• Processes here need to follow the rule:
“Workflow avoidance over workflow
management”. They need to be kept short.
• Traditionally operational processes are to be
‘managed’, i.e. designed, supervised, reported
& optimised.
• Driven by governance requirements these back
office processes tend to grow ever longer.
• Regulation, compliance issues and security
concerns are the drivers.
• To provide legally required direction &
oversight, governance processes are to be
implemented separately and on top of the
management layer.
19-05-2365 65
www.GenericIAM.org
Management
keep operations within a defined channel of health
Governance
direction & oversight
Operations
running the business as usual
www.GenericIAM.org
2019-05-23

Operational Processes
• Operational processes are invoked at run time
• In static environments only perform the enforcement
functionality.
• In dynamic access environments (automated) policy
decision can be included too.
2019-05-23
www.GenericIAM.org
66

Operational processes
www.GenericIAM.org
2019-05-23 67
• In a static environment there is just
one operational Identity process and
one operational Access process:
• Identity: Authenticate Identity
• Access: Enforce Authorisation
• Note: in dynamic environments …
• The objects functional role,
constraint, business role will collapse
to the object policy.
• The policy decision (expressed as
authorisation in the static
environment) will be taken at run-
time.
• Note: Business roles belong to both:
to IM and to AM
Functional
role
Constraint
Business Role
Identity
Authenticate
essential process
Authorisation
Enforce
Operational processes
IM
Essential object
AM
Business Role

Management Processes
• Management processes form the bulk of Identity & Access
processes
• Modelling the essence however results in a neat & concise model.
• In the following chapter we focus on access processes only.
2019-05-23
www.GenericIAM.org
68

Maintenance processes for Access
 Maintenance Processes of fundamental
business objects of Access Management:
• Maintain Functional Role
• Maintain Constraint
• Maintain Business Role
• Maintain Authorisation
• Maintain System Role
• Maintain Account
 Maintain represents the CRUD-operations
(create, read, update & delete)
 The Processes of authorisation are
represented by the Maintenance of the
derived Object authorisation.
 The authorisation is maintained by assigning
business roles to digital identities
 Maintenance processes for system role and
account are optional.
 They are necessary only if these objects are
present.
www.GenericIAM.org
2019-05-23 69
Constraint
Business
role
Authorisation
Functional
role
maintain
maintain
essential process
maintain
System
role
maintain
Model Maintenance
Account
maintain
Essential object Physical object
maintain

Maintain Functional Role
Bundling enterprise functions to represent general job tasks
• Functional roles are collections of enterprise functions.
• They are representing job tasks as agreed on in agreements of an
individual with the corporation.
• They are populated from a functional enterprise model, which
hence needs to be on place.
• They must be given meaningful names in business terms to reflect
the task they represent.
• They may be defined flat or hierarchically by implementing an
inheritance hierarchy.
• They must be checked for Segregation of Duties (SoD) conflicts (SP-
01 Check for SoD conflicts).
• Changing functional roles requires a revalidation of all dependent
objects (business roles, authorisations).
• Functional roles can only be deleted, if no more dependent objects
are in use.
2019-05-23
www.GenericIAM.org
70

Maintain Constraint
Maintaining business attributes & optionally rules for their application
• Constraints in their simplest form are attributes, which must be
matched to result in a positive access decision.
• E.g. if an identity is assigned the functional role ‘sales person’ and the
constraint ‘area’ carrying the value ‘area 51’ he or she may only have
access to sales objects of that particular area.
• In this basic form the condition (rule) info.area == ‘area 51’ is assumed.
• More complex rules may well be explicitly introduced.
• Attributes may be personal (e.g. age), resulting from a contract (e.g.
area or authorisation level), corporate or external attributes (e.g. time).
• Often specific attribute services need to control the attribute supply.
• Changing constraints requires a revalidation of all dependent objects
(business roles, authorisations).
• Constraints can only be deleted, if no more dependent objects are in
use.
2019-05-23
www.GenericIAM.org
71

Maintain System Role
The projection of a Business Role to a system
• System roles are an implementation artefact, not mandatory in an
essential model.
• They are defined as the projection of a business role to a system.
• Composing several system roles results in a business role.
• The system roles may or may not be identical with roles exposed by
the system (if any are).
• During role modelling system roles may be used as an intermediate
step regardless if top-down or bottom-up approaches are chosen.
• Changing system roles requires a revalidation of all dependent
objects (authorisations).
• System roles can only be deleted, if no more dependent objects are in
use.
2019-05-23
www.GenericIAM.org
72

Maintain Account
The projection of the object authorisation to a system
• Like the system role the account is an implementation artefact,
unnecessary in an essential model.
• It is defined as the projection of the object authorisation to a system.
• It hence consists of an identity and the permissions applicable to the
particular system.
• Accounts must not be manipulated directly, but are created or
replaced once the authorisation changes via a request & approval
process.
2019-05-23
www.GenericIAM.org
73

Maintain Business Role
General remarks
• The business role is a Janus-headed creature – it links Identity
Management to Access Management.
• Identity, functional role, constraint and the upper half of the
business role can be solely modelled in business terms.
• Only the ‘lower half’ of the business role links to permissions, hence
is part of Access Management.
• Once a business role is assigned to an Identity the authorisation
(Policy Decision) is done.
• It is best to create business roles ‘on the fly’ by selecting functional
role(s) and constraints – to avoid combinatory explosion.
• Changing business roles requires a revalidation of all dependent
objects (authorisations).
• Business roles can only be deleted, if no more dependent objects are
in use.
2019-05-23
www.GenericIAM.org
74

Maintain Business Role I
1st link to functional roles
• In a 1st step, the business role is linked to one or more functional
roles.
• At this point, a check for Segregation of Duties (SoD) conflicts (Check
for SoD conflicts) is carried out.
• Where necessary, compensatory measures (Assign Compensating
Controls) become necessary.
• If necessary business roles must be modified via Maintain business
role
2019-05-23
www.GenericIAM.org
75

Maintain Business Role II
2nd Apply constraints
• In a 2nd step, constraints are applied to the resulting business roles.
• Hereby the focus on corporate entities such as customer groups,
clients, organisational units, etc. is limited such that the need-to-
know principle is met.
• This way from one functional role, several business roles may be
created.
• If necessary, constraints need to be created or modified (Maintain
Constraint).
2019-05-23
www.GenericIAM.org
76

Maintain Business Role III
3rd Assign System Roles or link to information objects
• In the 3rd step, suitable permissions or - if present - to system roles
are assigned to the business roles thus obtained.
• Hereby a constrained business functionality is ultimately mapped to
permissions and hence to access to information objects.
• If necessary, system roles need to be created or modified (IM-05
Maintain System Role) in the course of this process.
• Business roles (respectively there construction rules) need to be
maintained by interdisciplinary teams reflecting knowledge of the
business domain, the access models of the targeted systems and
generic modelling knowledge.
2019-05-23
www.GenericIAM.org
77

Maintain Authorisation = Request & Approve
• Authorisation processes (AM) are variations of the
process “Maintain Authorisation”:
• Grant Authorisation
• Revoke Authorisation
• Deactivate Authorisation
• Activate Authorisation
• Cancel Authorisation immediately
• Change position
• The authorisation object is formed by linking the
identity to one or more business roles.
• Hereby ultimately the Identity is linked to the
information object.
• Hence the decisions of the respective owners of the
objects are required.
• They are the identity owner (superior) and the
information object owners.
• They may approve, reject, or escalate.
• Decisions may be pre-decided driven by a policy.
78
authorisation
maintain
2019-05-23
www.GenericIAM.org
permission
identity
functional
role
authorisation
Information
object
business
role
operation
operate on 1:n
constraint

Maintain Authorisation = Request & Approve
5 steps towards a granted authorisations
1. Select Identity - you might select yourself, your employee or a
colleague. The range of selectable identities may be restricted.
2. Select business roles - you may select 1 to n business roles and assign
them to the identity. The range of selectable business roles may be
restricted for that particular identity.
3. Check for SoD conflicts – only such business roles can be selected
that pass a check for Segregation of Duties Conflicts (Check for SoD
conflicts). Alternatively compensatory measures (Assign
Compensating Control) need to be invoked.
4. Approve - submit the request for approval to the involved object
owner (Line Manager, data owner) via the “Approve request".
5. Provision - in case no authorisation sub-systems is involved, which
may access authorisation directly, permissions are provisioned to the
target systems well ahead of the start date of their validity.
 Note: all 5 steps may be subject to policy driven automation.
www.GenericIAM.org
792019-05-23

Sub-Processes
• The next 5 processes have been factored
out as sub-processes:
• Check for SoD conflicts
• Escalate
• Approve
• Support
• Assign Compensating Control
• These processes are sub-processes that
consist of only one activity.
• However, they are used in several
fundamental processes.
• The benefits of reuse justify a separate
documentation.
80
subject request
decides
decision
approve
reject
may be
or
escalate
or
2019-05-23
www.GenericIAM.org

Determining actors
• Actors can be humans or systems (or things)
• Both are driven by policies
• Object owners are natural actors
• Activities can be delegated to custodians
2019-05-23
www.GenericIAM.org
81

Subjects act on objects
How to find the processors acting on the objects?
In processes subjects (actors) act on objects
• Subjects may be identities or managers
• Managers are owners or a custodians
• Owners are responsible
• Custodians act on behalf of owners
• Owners delegate to custodians
• Subjects act or react
• Their action triggers an event
• Reactions often are approvals
• Event triggered automated processes
• They act on behalf of the organisation
• They are driven by policy
• Time-triggered events are common
19-05-23
82
subject object
act
action
manager
may be
identity
or
owner
custodian
or
may be
2019-05-23
www.GenericIAM.org 82

Responsibilities for Identity & Access Objects
• Each object as one owner
• The owner is responsible for the object
• The owner may delegate object management to a custodian.
• The owner may temporarily transfer ownership (full responsibility) to a delegate.
• Owner designations differ considerably from one organisation to another
• This apparent complexity is a result of customising of a simple model
2019-05-23
www.GenericIAM.org
83
Object
Owner
own
Identity
Line
Manager
own
Constraint
Business
Architect
own
Functional
Role
Business
Architect
own
Business
Role
Business
Architect
own
System
Role
Application
Architect
own
Authorisation
Authorisation
management
own

Adding physical processes
• In the essential core ‚perfect technology‘ is assumed
• No activities need to care for health checks, transportation or translation
• The physical ring however connects to the real world.
• Audit & recertification come in play as we have to deal with errors.
• ‘Provisioning’ traditional stand-alone applications provides ETL functionality.
2019-05-23
www.GenericIAM.org
84
physical ring
physical ring
essential
core

Governance Processes
• Governance consists of Direction and Oversight
• Here we focus on the Oversight process groups: Audit and
Recertification processes
• They are regarded as physical processes without an essential
justification.
2019-05-23
www.GenericIAM.org
85

Provisioning and Reconciliation
Physical processes: transport, translation & audit
• Provisioning is a term borrowed from telecommunication and before that from the
military. Its function is:
• Transporting the system specific part of the authorisation to the target system and
• The translation of the of the authorisation data into the target system compatible
format through a compatible protocol.
2023-May-19
www.GenericIAM.org
86
Identity
&
Access
Management
Target
application
provisioning
reconciliation
• Reconciliation provides a regular comparison of the authorisation fraction in the
target system with the authoritative source in the IAM system.
• This process in mandatory as long as native administration interfaces remain active
in the target systems.
• If IAM and target systems don’t represent a simple master to slave relationship,
complex integrity rules need to be applied in order to detect anomalies.

Recertification processes
in principal each object may be re-certified.
• Recertification represents the re- confirmation or
revocation of the original granting decision.
• Hence for each maintenance process a corresponding re-
certification process can be defined.
• Recertification (or attestation) processes are not provided
in an essential system.
• If all maintenance processes worked reliably, no need for
recertification would occur.
• Recertification is required once we assume that the real
world processes do not work flawlessly.
• The following complementary recertification processes are
possible to complement the respective maintenance
processes:
• Recertify Functional Role
• Recertify Constraint
• Recertify Business Role
• Recertify Authorisation
• Recertify System Role
• Recertify Account
87
physical ring
physical ring
essential
core
Constraint
Business
role
System
role
Authorisation
Functional
role
maintainmaintain
maintain
recertify
recertify
maintain
recertify
essential process physical process
maintain
recertify
recertify
Account
maintain
recertify
Model Maintenance & Recertification
2019-05-23
www.GenericIAM.org

Audit Processes
• In-process Audit processes
• Check recertification
• Check for SoD conflicts
• Verify deputyships
• Inspect critical authorisations
• Sample based Audit processes
• Inspect granted critical privileges
• Check for principle of least privilege
compliance
• Verify business focus
• Check quality of privilege assignments
• Verify compensating controls
• Check the quality of roles
• Ad-hoc Audit Processes
• ad hoc audits
2023-May-19
www.GenericIAM.org
88
In-process Audit processes
Check recertification Check for SoD conflicts
Verify deputyships
Inspect critical
authorisations
In-process Audit processes
Inspect granted critical
privileges
Check for PoLP
compliance
Verify business focus
Check quality of
privilege
Verify compensating
controls
Check the quality of
roles
Ad-hoc Audit processes
ad hoc audits

Agility insertion
• How to add responsiveness to dynamic events?
2019-05-23
www.GenericIAM.org
89
event

permission
identity
functional
role
Is assigned 1:n
authorisation
information
object
business
role
operation
constraint
Agility insertion allows for dynamic authorisation
roles and constraints may be created and / or used dynamically
In a dynamic role meta model …
• Roles can be created at runtime
• So can constraints
• They are rule / attribute pairs
• Roles & constraints can be
deployed dynamically too.
• Dynamicity is propagated from
constraints and/or from
functional roles to business roles
and authorisations
• Permissions and identities remain
static at the same time.
rule
rule
rule
attribute
{
rule
attribute
{
2023-May-19 90www.GenericIAM.org

Segregation of Duties (SoD)
The bedrock of fraud prevention
• How it is defined
• How it can be modelled and
• How to find workaround, if it cannot be properly implemented.
2019-05-23
www.GenericIAM.org
91
Activity #2Activity #1

Goals of segregation of duties
• The goal is to ensure that at least two or three people are needed to
transfer value out of an organization.
• In capital markets, market and credit limits are highly valued intangible
assets.
• In addition, outright theft is discouraged because two or more people
participate in or observe all transactions.
• These goals are achieved by separating three important functions:
1. The authority to approve the transaction.
2. The recording of the transaction, as well as the production of accounting
records.
3. Physical control of the tangible positions or intangible assets (that is, risk
limits).
2023-May-19
www.GenericIAM.org
92

Damages arising from poor SoD
• Societe Generale, $7 billion in losses: Operations expert moved to trading desk,
taking some jobs with him.
• Barings Bank, $1 billion in losses: Operations and trading managed by the same
individual.
• Lehman Brothers, $0.3 billion in losses: Sales manager took over certain simple
operations functions.
• Daiwa, $1.1 billion in losses: Same scenario as Societe Generale.
• Allied Irish Bank, $0.7 billion in losses: Risk limit reporting under control of trader.
• Tyco, $0.3 billion in losses: Three top executives colluded and board of directors
exercised ineffective supervision.
• Orange County, $1.6 billion in losses: Trader seen as the unquestioned maestro,
while back office was underpowered to understand his trading procedures.
2019-05-23
www.GenericIAM.org
93

SoD Management Prozesses
1. Collect & extract SoD rules
2. Document SoD-rules
3. Map to enterprise model
4. Identify organizational units
5. Identify & prioritize applications
6. Implement SoDs & mitigating actions
7. Check adequacy & implementation success
2019-05-23
www.GenericIAM.org
94
Collect &
extract SoD
rules
Document SoD-
rules
Map to
enterprise
model
Identify
organizational
units
Identify &
prioritize
applications
Implement SoDs
& mitigating
actions
Check adequacy
&
implementation
success

Example
Trading should be a separate function
Traders should not be involved in or responsible for securities lending functions:
• Delivery of loaned securities.
• Receipt of collateral.
• Maintenance of broker and client credit limits.
• Market-to-market process.
• Daily balancing of activity.
• Billing of brokers and cash transfers.
• Oversight of daily cash collateral investment decisions.
• Transfer of cash to collateral investment accounts
• this function should either be automated or handled by a non-trader
• Measurement of risks of the management of cash portfolios.
• Performance measurement.
• Client reporting.
2019-05-23
www.GenericIAM.org
95

Compensating Controls
If no SoD can be applied, these Compensating Controls may help
 Implementing a four-eyes principle
Those tasks and activities of the employee, with conflicting interests, must be countersigned
by an other skilled employee.
 Implementing a management review
The tasks and activities of the changing employee, where there are conflicts of interest, are
subject to review by a manager.
 Excluding certain activities / customer groups / products / etc.
The new job description of the changing employee excludes specific tasks and activities /
customer groups / products / etc..
 Introducing a grace period
The taking over of the new tasks and activities within the framework of the workplace
provides for the exclusion of those tasks and activities for a predefined period (waiting
period), in which there are conflicts of interest.
 Combination of the above measures
96
www.GenericIAM.org
2019-05-23

SoD violation handling
1. Detect SoD violation
2. Decide on handling
1. Remediate risk
2. Mitigate risk
3. Accept risk
3. Review action adequacy
2019-05-23
www.GenericIAM.org
97
Detect SoD
violation
Decide on
handling
Mitigate
risk
Accept risk
Remediate
risk
Review
action
adequacy

Degenerations of the Role Meta Model
Consequences of not implementing the total model
but just parts of it.
2019-05-23
www.GenericIAM.org
98
entitlement
identity
functional
role
Is assigned 1:n
authorisation
information
object
business
role
operation
constraint
Business layer
Technical layer
r

permission
identity
functional
role
Is assigned 1:n
authorisation
information
object
business
role
operation
constraint
A simple (static) role meta model
The model may degenerate by not fully implementing it.
Model degenerations commonly
found are …
1. No use of roles at all: assignment of
permissions to individuals.
2. Not parameterising functional roles
with constraints, but designing
business roles directly.
3. No use of roles, but making use of
elaborated constraints, consisting of
attributes and complex rules.
2019-05-23
www.GenericIAM.org
99
Business layer
Technical layer
www.GenericIAM.org

permission
identity
Is assigned 1:n
authorisation
information
object
operation
1. Entitlements not defined in business terms
If not defined in business terms …
• There are no roles. i.e.
• The organizational construct to
reduce complexity is lacking.
• Business responsibles have to deal
with technical authorisation
elements.
• A large number of individual
decisions becomes necessary.
• The risk of errors increases .
• The organization can respond to
changes only slowly.
• It is possible however.
2023-May-19
www.GenericIAM.org
100
Business layer
Technical layer

entitlement
identity
functional
role
Is assigned 1:n
authorisation
information
object
business
role
operation
2. No explicitly defined Constraints
Without explicit constraints …
• a role has to be created for each
function / parameter combination.
• a role inflation is inevitable.
• the distinction between business
role and functional role becomes
pointless.
• Role Selection and Assignment
become time consuming.
• a large number of individual
decisions becomes necessary.
• The risk of errors increases .
• The organization can respond to
changes only slowly.
2019-05-23
www.GenericIAM.org
101
Business layer
Technical layer
www.GenericIAM.org

entitlement
identity
Is assigned 1:n
authorisation
information
object
operation
constraint
3. No roles but constraints
Functionality not bundled in business
terms …
• No roles are modelled.
• However constraints allow for
authorisation based on nu-functional
attributes.
• By generalising constraints to
attributes in general and introduction
of rules functions can be represented
as attributes too.
• Hereby a more ABAC style of
authorisation is implemented.
2019-05-23
www.GenericIAM.org
102
Business layer
Technical layer
www.GenericIAM.org

Questions - comments – suggestions?
103
In this case please discuss on …
• https://www.linkedin.com/groups/95319/
• https://www.facebook.com/GenericIAM-131676523536399/
Or contact Horst Walther: +49 171 2145502 or horst.walther@genericiam.org
You may also look-up: https://www.genericiam.org/ or https://genericiam.blogspot.com/
2019-05-23

Caution
Appendix
Here the notorious back-up-slides follow ...
2019-05-23 104

Avoiding 12 pitfalls
Recommendations for a Successful I&A Program
Dr. Horst Walther
105
2019-05-23
www.GenericIAM.org

• Get your documents organised
The pyramid of corporate regulations
• Be aware of the cross-company nature
IAM-Projects touch multiple corporate functions
• Choose the right project scope
Implementation projects can’t reorganise the
corporation.
• Watch effects of market consolidation
Acquired components don’t necessarily combine
to Suites
• Ensure availability of domain specialists
persons with business domain knowledge are rare
creatures
• Beware of deep vertical integration
Don’t try to reinvent the wheel
• Remember: technical risks still exist
Technology often is more of marketing than reality
• Assign the responsibilities right
IAM is an org. task & needs a Business Owner
• Global approach adds to complexity
Global projects add to effort and skill requirements.
• Provide for a paying customer
often triggered by internal considerations
• Do the priorities right
You will need drivers from operational risk
• Modelling fundamentals
follow the essential systems modelling principles
agenda
12 recommendations and more to expect.
2019-05-23
106www.GenericIAM.org

specifications
&
work instructions
1072019-05-23
Get your documents organised
The pyramid of corporate regulations
policies:
policies are binding corporate documents, usually issued by top
management. They express goals, principles, focal areas and
responsibilities. They represent the top level of the documentation
pyramid.
guidelines:
guidelines like policies are of a high level of abstraction. However
they don’t come with a binding character.
Procedures:
Procedures lay out all management controls for a defined problem
domain on an essential level. They contain (static) functions &
responsibilities and (dynamic) processes.
standards:
They state requirements for generic minimums standards, a choice of
good practice examples or a bandwidth of tolerable quality
parameters.
Specifications:
The Implementation of controls on a physical level is specified in
operational specifications, work flows, specifications, ... Techniques,
configurations of solutions and organisational processes are
documented on this level.
Work instructions:
Based on the defining procedures work instructions specify the
volatile details like configuration parameters or physical techniques.
procedures
&
standards
policies
&
guidelines
www.GenericIAM.org

Complexity factors
• Identity-Management Processes are
typically cross-company.
• There are multiple Stakeholders from
different corporate levels involved in a
project.
• 3 to 5 mal times higher Communication
complexity compared to „normal“ IT-
projects.
• Typical Change Management Process
actions
• Strengthen the project management!
• Add an extra reserve for communication!
• Insist on a power sponsor for your
project!
Be aware of the cross-company nature
IAM-Projects touch multiple corporate functions
2019-05-23

Complexity factors
• At higher levels of maturity of the
management processes (e.g. according to
CMMi) the introduction of IAM- processes, -
rules, -roles, -policies becomes easier.
• You can’t implement mature IAM-processes
in a low maturity process environment.
• The top-down definition of roles needs
defined processes.
Actions
• Only launch IAM-projects relying on a
maturity level as implemented in the
environment.
• Occasionally just say „no”!
Adapt to your process maturity
There are no islands of order in an ocean of chaos
2019-05-23

Choose the right project scope
An implementation project cannot reorganise the corporation.
Complexity factors
• Implementation project will have a hard job
when having to reorganise the corporation
first.
• Model definitions require their own Definition
projects before or in parallel to the
Implementation.
Actions
• Break your work down into loosely coupled
work packages
• Define own projects for the model definition
before or in parallel to the Implementation.
• A program made up of several agile
projects often is a better solution.Avoiding the scope trap e.g. for IAM projects
2019-05-23

Complexity factors
• Mergers & Acquisitions often lead to
less compatible Product collections.
• The software of acquired companies is
often not supported sufficiently.
• It may take a long while, until
components fit together as promised.
actions
• Only a Pilot installation under real
world conditions leads to the
necessary evidence for a product
selection.
Watch effects of market consolidation
Acquired components don’t necessarily combine to Suites
2019-05-23

Complexity factors
• The availability of specialists with domain
knowledge often turns out to be the bottle
neck in role- und process definitions.
• Their involvement is essential for the
requirements definition and the QA.
• Waiting times (for specialists) are driving
the overall effort.
• While in projects they tend to disappear.
Actions
• Assign the project responsibility to the
business departments.
• Think of splitting projects to business
definition and an implementation part.
Ensure availability of domain specialists
persons with business domain knowledge are rare creatures
2019-05-23

Complexity factors
• Only a fraction of the overall IAM-
Processes is really enterprise specific.
• The adoption of processes and / or
Roles from generic Models may speed
up projects.
• Not always it is a good idea to start
with a blank sheet of paper.
Actions
• Ask your integration partner or
consultant for consolidated models
containing his experience.
• Participate in Standardisation
initiatives (like GenericIAM.org).
Beware of too deep vertical integration
Don’t try to reinvent the wheel
2019-05-23

Complexity factors
• IAM-SW-Suites are complex and often not easy
to handle.
• Without implementation experience in exactly
the required environment risk of failure is high.
• „minor“ changes of the version number
sometimes cover oft complete new
developments.
• The support Matrix of environment
components vs. versions often is only sparsely
populated.
• Forced replacement of infrastructure
components leads to higher effort.
Actions
• Always test selected software in a pilot run
before deployment.
• Only choose integration partners with true
product experience.
Remember: technical risks still exist
Technology often is more of marketing than reality
2019-05-23

Complexity factors
• Identity Management is a management
task.
• Identity Management means organising
the enterprise.
• HR could be the natural owner – but
often refuses.
• IT has the implementation capabilities
but is not mandated to change the
organisation.
• On the business side methodological
and technical knowledge is lacking.
Actions
• Shift the responsibility to the business
side.
• Create a new cross functional group for
the operations.
Assign the responsibilities right
IAM is an organisational task & needs a Business Owner
2019-05-23

Responsibility
Who should be responsible for the Identity Management?
HR
 has a natural
relationship to
Persons / person
data.
- Often far from being
business minded
- HR acts not really
“real time”.
Business
 Tasks and
responsibility match
perfectly.
- Doesn’t act
enterprise wide
- Specific skills are
missing.
new function
- Not yet common practice
• Must be responsible for
Identities, Roles & processes
• Needs business organisational
and technical skills.
• Must be mandated for
organisational changes.
 Chance for a tailored design
IT
 Technical
implementation skills
available
- not mandated for
organisational
changes.
- Organisation is not
Technology.
2019-05-23

Global approach adds to complexity
Global projects add to effort and skill requirements.
• Regulation may differ by region.
• One-size-fits-all might not be the
right approach for all subsidiaries.
• But the chain may break
at is weakest link.
• The responsibility for remote
security measures often still stays
with the headquarters.
• Global PM causes considerable
on-top complexity.
• Factor-in a 1.5 times higher
communication overhead for
global projects.
• Not all security issues can be
handled globally in a uniform
way.
• Assign regional responsibility
– but support them from the
headquarters.
• Plan for a phased roll-out – a big
bang approach rarely works.
2019-05-23 117
www.GenericIAM.org

Provide for a paying customer
often triggered by internal considerations
• Often more security does not lead
to increase sales.
• For infrastructure, awareness or
culture it is hard to find an
appropriate cost centre.
• It is often hard to come-up with a
positive business case for
investments into IT-security.
• As IT Security is often seen as an
inhibitor to business there is no
credit for taking ownership.
• Let risk considerations drive the
decision.
• Business is about taking risks.
• IT security feed into operational
and / or reputational risk.
• If risk management is not
sufficiently rooted within the
corporation – insist on C-Level
sponsorship.
• Establishing a risk culture spread
the risk awareness to all corporate
levels.
118
2019-05-23

Get the priorities right
You will need drivers from operational risk
• Often deadlines are set which cannot
be shifted
• Even if not – quick success is expected
• The size of the task often is
overwhelming
• Everything seems to equally
important
• Departments compete for resources
to get out of the auditors
focus.
• What has to be done 1st?
• What may come
later?
• It all boils down to risk considerations
• Operational & reputational risks
• Good enough security = risk based
security
• Priorities of tasks result from ordering
them by their risk.
• Caveat: Dept. „risk Management“
quite often is not managing the risks.
119
www.GenericIAM.org
2019-05-23

Modelling fundamentals
• Follow a top-down approach
• Employ essential Modelling
• Define the model’s scope & context
• Find the essential interacting objects
• Define processes of object maintenance
• Determine actors
• Add physical objects
• Add physical processes
• Separate static from dynamic behaviour
2019-05-23
www.GenericIAM.org
120

Generic Processes for Identity & Access

Recommended

Recommended

More Related Content

Similar to Generic Processes for Identity & Access

Similar to Generic Processes for Identity & Access (20)

More from Horst Walther

More from Horst Walther (8)

Recently uploaded

Recently uploaded (20)

Generic Processes for Identity & Access