GenericIAM Generic Processes for Identity & Access

1. GenericIAMGeneric Processes for Identity & Access 2006 to 2018 - How far we got Public draft and Report of the achievements of the standardisation initiative GenericIAM.org. Dr. Horst Walther, 2019-05-23, for the public, Version 0.163 www.GenericIAM.org

2. Serious WarningStop me – before it is too late. • 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. www.GenericIAM.org

3. Agenda • Driving modelling principlesHow to define a common ground among the diversity of models? • Essential modellingHow to separate essential business activities from implementation artefacts? • Finding the interacting objectsHow to derive a simple static role model? • The broader contextHow 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 physicsWhat is still missing to deal with the cruel, dirty world? • Generic Processes of Identity & AccessWhich processes need to be in place to maintain the model? www.GenericIAM.org

4. Driving modelling principlesHow to define a common ground among the diversity of models? • 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 www.GenericIAM.org

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

6. Top-down Modelling approachThe lessons learnt form our trials Trying to collect the broad experience of existing implementations Modellingbottom-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 modellingis a more promising approach. Start by deriving the basic processes from the interaction of corporations’ fundamental objects. www.GenericIAM.org

7. generic processes elementaryactivities objectssubjects Process modellingBottom-up or top-down - or what? custom processes adapted & extended Top-down approach bottom-up approach • Go for Generic Top-Down Modelling • 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 www.GenericIAM.org www.GenericIAM.org

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

9. Modelling fundamentalsFollow the essential systems modelling (esm) principles • 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) www.GenericIAM.org

10. Essential ModellingIn a four-step Process to the target implementation model • McMenamin and Palmer 1984 recommend following a four-stepspecification process with the analysis of the source model : • Analysis of the current system; creating a model of the current implementation of the system. • 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). • 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. • Designing the target system: creating a model of the implementation model of the target system. www.GenericIAM.org

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

12. Essential ModellingSteve McMenamin & John Palmers essential processes 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. www.GenericIAM.org

13. Essential modelling characteristicsAvoid 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. www.GenericIAM.org

14. Essential system 1st – physical ring 2ndStart 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 oraudit 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. physical ring physical ring essentialcore www.GenericIAM.org www.GenericIAM.org 14

15. Essential Modelling fundamentals To the target implementation model in a 4-step Process 1 2 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 physicalsystem. 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. 3 4 • Essential modelling removes implementation artefacts leaving the functional essence. www.GenericIAM.org

16. RepresentingrequirementsThe essential model represents the functional requirements. 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. www.GenericIAM.org

17. The purpose of finding the essenceAvoid technical folklore by assuming perfect technology 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. www.GenericIAM.org

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

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

20. The interacting objects of Access ManagementAccess is about digital identities accessing information objects DigitalIdentity In the beginning there were … • The information object, • The digital identity • A relationship representing the access accesses InformationObject „The digital identity accesses the information object“ www.GenericIAM.org

21. The interacting objects of Access ManagementAccess, information objects & digital identities represent own process groups IdentityManagement • 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. identity Accessmanagement Information Management Informationobject www.GenericIAM.org

22. The interacting objects of Access ManagementThe authorisation ties digital identities to information objects DigitalIdentity 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“. Authorisation InformationObject www.GenericIAM.org

23. The interacting objects of Access ManagementThe authorisation has to be qualified by action type: The operation DigitalIdentity • 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. Authorisation operation InformationObject www.GenericIAM.org

24. The interacting objects of Access ManagementThe NIST calls this operation on objects „permission“ DigitalIdentity • The NIST groups operations on objects as ”permissions. • Hence a digital identity is authorised by granting it certain permissions. Authorisation permission operation InformationObject www.GenericIAM.org

25. The interacting objects of Access ManagementThe role is the central structuring object of authorisation DigitalIdentity 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. Authorisation Role permission operation InformationObject www.GenericIAM.org

26. The interacting objects of Access ManagementA business role conveys more access determining dimensions beyond function DigitalIdentity 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 constraintsapplied to them. • For role modelling purposes constraints as well as functional rolesneed to reference further context objects. Authorisation BusinessRole Functionalrole permission operation InformationObject www.GenericIAM.org

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

28. The broader contextWhy are digital identities held by an organisation? DigitalIdentity Organisation signs signs Agreement 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 identityinformation. Some form of documented agreement can therefore be assumed. www.GenericIAM.org

29. The broader contextWhere are roles anchored in the organisation? DigitalIdentity Organisation signs defines Agreement Role refers to 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 ManagementRelationship Management. www.GenericIAM.org

30. The broader contextHow Agreements influence the Access Management DigitalIdentity Organisation signs defines Agreement Role refers to determines Authorisation • 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 www.GenericIAM.org

31. The broader contextHow Agreements influence the Access Management Identity Management DigitalIdentity Organisation signs defines Agreement Role refers to determines Access Management Authorisation • 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 www.GenericIAM.org

32. 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. How to find rolesProcesses, Roles & Rules express the Organisation EnterpriseModel Process Function#1 Function #2 Function#3 Role #1 Role #2 Rules Policies delete read approve update reject create delete read Sign off create update escalate Resource#1 Resource#2 Resource#3 Resource#4 2016-02-17 www.GenericIAM.org 2019-05-23

33. Types of Enterprise ModelsEnterprises 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 • Both Models can be mapped towards each others however 2016-02-17 www.GenericIAM.org

34. The Functional Enterprise ModelA functional hierarchy from value chain down to elementary functions Governance functions Core functions Support functions The enterprise value chain • 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. www.GenericIAM.org

35. Whatis 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 www.GenericIAM.org

36. Examples of TaxonomiesMost 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. www.GenericIAM.org

37. A corporate Functional TaxonomyA functional hierarchy from value chain down to elementary functions category domain sub-domain capability function • 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 www.GenericIAM.org

38. Functional TaxonomyA near real world banking example www.GenericIAM.org

39. Why do we need a functional Taxonomy? • If not guided by a functional taxonomy, role modelling yields arbitrary results at best. 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 www.GenericIAM.org

40. 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 www.GenericIAM.org

41. 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 www.GenericIAM.org

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

43. Maintain identityfundamental 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. partneremployee customer employee partner Identity hire contract register contract create open change change change change change change terminate terminate terminate terminate terminate terminate inheritance contractor • These are essential processes – they belong to the conceptual layer.Adding the physical layer implies more processes (e.g. provisioning). www.GenericIAM.org

44. The IdentityThe digital identity is the digital representation of an individual identity constraint functionalrole authorisation businessrole Is assigned 1:n entitlement operation informationobject • The digital identityis 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

45. Functional Rolea 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. identity constraint authorisation businessrole functionalrole permission operation Informationobject operate on 1:n www.GenericIAM.org

46. The „functional role" Functional role is a bundle made up of business functionsas 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 roleis 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. www.GenericIAM.org

47. Constrainta 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. identity constraint authorisation businessrole functionalrole permission operation Informationobject operate on 1:n www.GenericIAM.org

48. The 7 commonly used static constrainttypesBut the universe of possible constraints is not limited www.GenericIAM.org • 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.

49. Next step: Using dynamic constraint typesContext comes into play – and requires dynamic constraints constraint business rule context is used by changes Use of dynamic context based constraint types requires policy decision, pull type attribute supply and implemented business rules. www.GenericIAM.org • 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.

50. The essential objects of Identity & AccessObjects in the ESSAM model maintain static relationships - a schematic view identity constraint 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 information objects. • 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. authorisation businessrole functionalrole permission operation Informationobject operate on 1:n www.GenericIAM.org