GenericIAM Neues zu generischen IdM-Prozessen Die bottom-up Modellierung vs. Top-down Ansatz Digital ID World 2007, Frankfurt / Oberursel Donnerstag,

Präsentation zum Thema: "GenericIAM Neues zu generischen IdM-Prozessen Die bottom-up Modellierung vs. Top-down Ansatz Digital ID World 2007, Frankfurt / Oberursel Donnerstag,"—  Präsentation transkript:

1 GenericIAM Neues zu generischen IdM-Prozessen Die bottom-up Modellierung vs. Top-down Ansatz
Digital ID World 2007, Frankfurt / Oberursel Donnerstag, , Track B: Technology, Raum Höhenflug Version 1.1 , Dr. Horst Walther

2 Fragen, die wir heute beantworten …
Warum? - Motivation für GenericIAM. Wohin? - Das Ziel der Initiative. Wer? - Die Mitwirkenden und ihre Erfahrungen. Wie? - Unsere Arbeitsweise. Was? - die erzielten Ergebnisse. Wann? – Historie, Gegenwart und Planung.

3 Agenda Warum? - Motivation für GenericIAM.
Wohin? - Das Ziel der Initiative. Wer? - Die Mitwirkenden und ihre Erfahrungen. Wie? - Unsere Arbeitsweise. Was? - die erzielten Ergebnisse. Wann? – Historie, Gegenwart und Planung.

4 Unsere Motivation Gesucht: ein Baukasten für Standardprozesse des IAM
Prozesse verursachen den meisten Aufwand. so gehen bei PKI-Projekten 2/3 des Aufwandes in die Prozesse. Warum mit einem weißen Blatt Papier beginnen? Warum, das Rad immer wieder neu erfinden? Gibt es nicht auffällige fachliche Ähnlichkeiten? Sollten wir uns nicht lieber auf die Unterschiede konzentrieren? ... Und das Gemeinsame „von der Stange“ verwenden? Die Idee hinter GenericIAM

5 Kontext Die Industrialisierung der Dienstleistung
Wir glauben, Teil einer größeren Bewegung zu sein ITIL, SOA, Compliance Frameworks sind Details eines größeren Bildes Compliance erzwingt die Verwendung von Infrastruktur Standards ITIL ist erst der Anfang – CoBIT, ValIT und andere werden folgen. SOA bietet ein technisches Framework für die Implementierung. Die Marktkräfte zwingen zu einer Konzentration auf Kernkompetenzen. Nicht-wettbewerbsrelevante Aktivitäten werden standardisiert. Sie werden zu niedrigen preisen weltweit beschafft, … oder ausgelagert / von Drittanbietern bezogen. Organisatorische Referenzmodelle beschleunigen diese Entwicklung. GenericIAM als “open org” will wie „open source“ eine Rolle spielen.

6 Agenda Warum? - Motivation für GenericIAM.
Wohin? - Das Ziel der Initiative. Wer? - Die Mitwirkenden und ihre Erfahrungen. Wie? - Unsere Arbeitsweise. Was? - die erzielten Ergebnisse. Wann? – Historie, Gegenwart und Planung.

7 elemente Mission Welchen Auftrag haben wir uns gegeben?
Zielgruppe Für wen ist GenericIAM interessant? Nutzen … generische IAM-Prozesse nützen allen Marktteilnehmern … Nutzen Anwenderunternehmen werden den größten Nutzen haben Ausrichtung Erst national starten und dann international wirken

8 Mission Welchen Auftrag haben wir uns gegeben?
Wir haben das Ziel, für das Identity- und Access Managements (IAM) ein allgemein verwendbares (generisches) Prozessmodell zu entwickeln. Es soll als Vorlage für unternehmensspezifische Prozesse dienen. Es soll in manchen Fällen auch unmittelbar implementiert werden können. Diese Prozesse sollen eine definierte, hohe und angemessene Qualität aufweisen. Sie sollen zu den gängigen regulatorischen Anforderungen "compliant" sein. Q

9 Zielgruppe Für wen ist GenericIAM interessant?
Die Initiative GenericIAM ist für jedes Unternehmen und jede Einzelperson interessant, die sich mit Identity- & Access Management befassen. Vorrangig richten wir uns an Unternehmen an, die Prozesse und Techniken des Identity und Access Management anwenden. Zusammen mit, Herstellern, Beratern, Analysten und Integratoren repräsentieren sie den Markt.  diese gesunde Mischung ist für eine hohe Akzeptanz unserer Ergebnisse bedeutsam. Mitglieder dieser Zielgruppe sind zur Mitwirkung in diesem Arbeitskreis eingeladen. Von jedem Teilnehmer wird ein inhaltlicher, organisatorischer oder finanzieller Beitrag zur Erreichung der gemeinsamen Zielsetzung erwartet.

10 Nutzen … generische IAM-Prozesse nützen allen Marktteilnehmern
Anwenderunternehmen … mit eingeführten IAM-Prozessen werden den größten Nutzen von einer Mitwirkung in dieser Initiative haben. Sie haben überwiegend nur Teile der notwendigen Prozesse definiert und eingeführt. Integratoren und Systemanbieter … können bereits umfangreiche und wirklichkeitsnahe Musterprozesse mitliefern. Damit ermöglichen sie ihren Kunden, die hohen Modellierungskosten vor der Implementierung stark zu senken und gleichzeitig den Einführungszeitraum zu kürzen. Freiberufliche Projektleiter und Berater mit Schwerpunkt Prozessmodellierung … können bereits mit vorgefertigten Baumustern antreten, sofern der Systemanbieter sie nicht bereits implementiert mitliefert. Insgesamt tragen wir … durch das Bereitstellen eines allgemein anerkannten und verwendeten Referenzmodells wesentlich zur Professionalisierung der Disziplin des Identity & Access Management bei. Damit senken wir in vielen Unternehmen die Schwelle zur Einführung von Policies, Prozessen und nicht zuletzt Systemen des IAM. Auch die unmittelbar Mitwirkenden … Können vom Erfolg des generischen Prozessmodells profitieren, indem sie sich dadurch als ausgewiesene Experten für IAM-Prozesse profilieren und eine gewisse Fachöffentlichkeit erreichen können.

11 … Nutzen Anwenderunternehmen werden den größten Nutzen haben
Anwenderunternehmen haben überwiegend nur Teile der notwendigen Prozesse definiert und eingeführt. Hier können sie die Frage beantworten wie vollständig bisher die eigenen Prozesse abgedeckt sind und wo es offensichtlich Lücken gibt. Sie haben darüber hinaus kostengünstig die Möglichkeit, ihr Prozessmodell zu optimieren und zu vervollständigen. Sie erhalten einen Einblick, wie weit andere Marktteilnehmer sind Sie können feststellen, wie "standardisiert" und "harmonisiert" die bisherigen Abläufe sind. Mit diesem Wissen können sie leichter die Frage beantworten: „Wie (zukunfts-) sicher sind wir, wo besteht Handlungsbedarf, wo bestehen Optimierungsmöglichkeiten?“ Mit diesem Wissen können sie die Frage beantworten: „Was müssen wir tun um vollständig compliant zu sein?"

12 Ausrichtung Erst national starten und dann international wirken
Die Initiative GenericIAM ist in Deutschland an gestartet. Um schnell zu inhaltlichen Ergebnissen zu kommen, haben wir  zunächst bewusst darauf verzichtet, uns international zu etablieren In Deutschland haben wir uns als Kompetenzzentrum "Identity Management" unter dem Dach des NIFIS e.V. organisiert. Natürlich darf unser Bemühen, zu einem Standard-Modell für die Prozesse des Identity & Access Management zu kommen, nicht auf Deutschland beschränkt bleiben. Wir haben uns daher bereits international mit „The OpenGroup“ und auf Europäischer Ebene mit der ensia abgestimmt.. Im Frühjahr 2007 haben wir, it den ersten substantiellen Ergebnissen in der Hand, die Internationalisierung gestartet.

13 Agenda Warum? - Motivation für GenericIAM.
Wohin? - Das Ziel der Initiative. Wer? - Die Mitwirkenden und ihre Erfahrungen. Wie? - Unsere Arbeitsweise. Was? - die erzielten Ergebnisse. Wann? – Historie, Gegenwart und Planung.

14 elemente Wir … Wer sind die Personen in und um GenericIAM?
Aktuelle Mitglieder Anwender, Analysten, Berater, Hersteller und Integratoren GenericIAM und die NIFIS Kompetenzzentrum „Identity Management“ der NIFIS

15 Wir … Wer sind die Personen in und um GenericIAM?
Wir sind … eine Gruppe von Freiwilligen mit dem gemeinsamen Ziel, ein möglichst vollständiges generisches Modell der Prozesse des Identity- & Access Management zu entwickeln. Wir kommen … aus kleinen und großen Anwenderunternehmen, von Beratungsunternehmen, Analystenhäusern, Produktherstellern, Systemintegratoren und universitären Einrichtungen. Mit unserer Initiative wollen wir … die Disziplin Identity Management insgesamt voran bringen und damit auch für uns, die sich mit diesem Thema professionell befassen, Nutzen erzielen.

16 Aktuelle Mitglieder Anwender, Analysten, Berater, Hersteller und Integratoren
as of :

17 GenericIAM und die NIFIS Kompetenzzentrum „Identity Management“ der NIFIS
Das an der Nahtstelle zwischen fachlich / organisatorischen und technischen Aufgaben gelegene Identity & Access Management ist eine der Schlüsseldisziplinen einer unternehmensweiten Sicherheitsarchitektur. Die "Nationale Initiative für Internet-Sicherheit" (NIFIS e.V.) ist die Selbsthilfeorganisation der Wirtschaft im Kampf gegen die wachsenden Gefahren aus dem Internet. Sie ist grundsätzlich für alle sicherheitsrelevanten Themen im Umfeld der Internet-Sicherheit offen und dient als Anlaufstelle bei Fragen und Problemen. Die Initiative GenericIAM passt von ihrem Wesen her hervorragend zu dem Selbsthilfecharakter dieser Organisation bei gleichzeitig großer inhaltlicher Überdeckung. Seit dem haben wir uns daher als Kompetenz- zentrum Identity Management in die NIFIS eingegliedert. Kontakt zu Nifis: Nifis e.V. Kompetenzzentrum Identity Management Weismüllerstraße Frankfurt Fon: Fax:

18 Agenda Warum? - Motivation für GenericIAM.
Wohin? - Das Ziel der Initiative. Wer? - Die Mitwirkenden und ihre Erfahrungen. Wie? - Unsere Arbeitsweise. Was? - die erzielten Ergebnisse. Wann? – Historie, Gegenwart und Planung.

19 elemente Ebenenstruktur der Prozesse Wie fügen sich die generischen IAM-Prozesse in ein Gesamtmodell? Unsere Arbeitsweise von der unternehmensspezifischen Lösung zum Standardmodell Sicherung der Ergebnisqualität QS-Schritte sind integraler Bestandteil der Ergebniserstellung. Meetings Einmal im Quartal treffen wir uns zu einem ganztägigen Meeting Lizenzmodell Die Ergebnisse werden wir unter einer offenen Lizenz (creative commons) publizieren.

20 custom processes adapted & extended
Modelling approach bottom-up- and top-down-approach lead to one generic model custom processes adapted & extended generic processes elementary actions objects & subjects Top-down approach bottom-up approach

21 Unsere Arbeitsweise von der unternehmensspezifischen Lösung zum Standardmodell
Das Unternehmen bringt Prozesse es in die Standardisierung ein. Diese sind im Regelfall nicht wettbewerbsrelevant. Ihnen wird eine gewisse Allgemeingültigkeit zugetraut. Übergabe kleiner Modelle als komprimierter -Anhang. Größere Modelle per FTP-Download oder auf CD oder DVD an die NIFIS. ggf übernimmt ein NIFIS-Vertreter die Ergebnisse persönlich. In zwei Formaten: 1. dem ursprünglichen Modellierungsformat und 2. einer vollständig in ein pdf-Dokument umgewandelten Form. Herausfaktorisieren generischer Bestandteile aus den unternehmensspezifischen Modellen. Diese Sachverhalte kennt nur einem kleines Modellierungsteam. Anonymisieren, generalisieren, standardisieren. (Erst danach) Prüfen durch erweiterten Reviewerkreis. Modellierte Prozesse werden offiziell für GenericIAM freigegeben. Reviewer von GenericIAM und bei Bedarf auch externen Experten Sie geben mängelfreie Exemplare frei Schwere Mängel führen zur Zurückweisung Leichte Mängel führen zu Nachbesserungsauflagen. Die Modelle werden einmal jährlich publiziert. GenericIAM-Mitglieder sie kostenfreie. Interessenten beziehen sie zu einem nicht-diskriminierenden Entgelt. auswählen übernehmen modellieren prüfen publizieren

22 Sicherung der Ergebnisqualität QS-Schritte sind integraler Bestandteil der Ergebniserstellung.
Ergebnisplan Bei der Planung die Zeiten für QS berücksichtigen! Verfahren festlegen, Q-Kriterien als Checkliste bereitstellen, Ergebnis erarbeiten, Ergebnis im Review prüfen, Das Ergebnis entweder freigeben mit Auflagen freigeben oder zurückweisen Planen QS-Verfahren Checkliste Vorbereiten Ergebnis Erarbeiten Review-Protokoll Prüfen D ü G ü

23 Meetings Einmal im Quartal treffen wir uns zu einem ganztägigen Meeting
in der Regel bei einem unserer Mitgliedsunternehmen. Dort werden erarbeitete Ergebnisse diskutiert und freigegeben. Neue Aufgaben vergeben und die Weichen für die weiteren Arbeiten gestellt. Die Ergebnisse der Quartalsmeetings werden protokolliert. Die bisherigen Meetings waren ... , Frankfurt, Gastgeber: Kuppinger, Cole + Partner , München, Gastgeber: Kuppinger, Cole + Partner , Wiesbaden, Gastgeber: Digital ID-World , München, Gastgeber: ORACLE , Düsseldorf, Gastgeber: WestLB AG . , München, Gastgeber: CSC Das nächste Meeting: , Frankfurt, in den Räumen der NIFIS

24 Agenda Warum? - Motivation für GenericIAM.
Wohin? - Das Ziel der Initiative. Wer? - Die Mitwirkenden und ihre Erfahrungen. Wie? - Unsere Arbeitsweise. Was? - die erzielten Ergebnisse. Wann? – Historie, Gegenwart und Planung.

25 Prozess Liste bottom-up Prozesse - anonymisiert, standardisiert noch nicht generisch
hire employee Eintritt eines Mitarbeiters in eine Organisation. release employee plan- oder außerplanmäßiges Ausscheiden eines Mitarbeiters. logout globally beendet unmittelbar alle aktiven sitzungen. sack globally sperrt unmittelbar alle Zugriffsrechte eines Mitarbeiters (Ausnahmeprozess). re-certify periodische Rückbestätigung der Notwendigkeit bestimmter Zugriffsrechte. certify Bestätigen der compliance von Prozessen oder rechten mit Unternehmensrichtlinien. clean data Bereinigen inkonsistenter, fragmentarischer und redundanter IAM Daten. request account Beantragen und genehmigen eines Zugriffs auf eine Ressource. request roles Beantragen und genehmigen eines Zugriffs auf eine Rolle. request groups Beantragen und genehmigen eines Zugriffs auf eine Gruppe.

26 Input-Beispiel nicht-generischer Prozess “Hire employee”
Wenn eine Mitarbeiter keiner Organisationseinheit angehört: Zentrale Verwaltung benachrichtigen. Wenn erforderliche Nutzerattribute unbekannt: Identifizieren und informieren des Zuständigen. Fehlende Attribute einfügen. Wenn erforderliche Systemattribute nicht bekannt sind: Informieren des System-Owners Basisrechte über Basisrollen automatisch zuweisen. Logon-Namen nach Bildungsregel automatisch zuweisen Zugriffsrechte in den Systemen automatisch anlegen (Provisioning) oder Mail an System Administrator senden. Technische Überwachung der Konnektoren. Informiere Manager über Mitarbeiterrechte. * * Modeled by ism – Institute for System Management

27 Prozess Liste bottom-up Prozesse - anonymisiert, standardisiert noch nicht generisch
IM10 Mitarbeitereintritt IM11 Stammdatenerfassung IM12 Basiszugang einrichten IM13 Erweiterte Zugänge einrichten WM10 Antragsverfahren Nutzerkonto WM20 Antragsverfahren Rollen WM30 Antragsverfahren Gruppen

28 Prozess Liste I bottom-up Prozesse - anonymisiert, standardisiert noch nicht generisch

29 Prozess Liste II bottom-up Prozesse - anonymisiert, standardisiert noch nicht generisch

30 The modelling cycle finding the essence removes implementation artefacts
enterprise strategy Enterprise models [abstraction] Evolution essential current model essential target model essential layer the enterprise Modelling cycle value chain object model process model state model abstraction projection “forbidden" transition physical current model physical target model physical layer Implementation [time] today future classic systems analysis technological development

31 Grouping to obtain business processes elementary processes are grouped by their business relationship The elementary processes found are grouped by their inherent business relationship to result in business processes. The elementary processes can be found by discovering state transitions of the fundamental (persistent) business objects. The business relationship is expressed in the value chain and can be taken from there. Business processes behave like travelling guests – they are transient objects. They are created by an event, They undergo several state transition. They are transferred from one state to the other by elementary processes. They carry along their local knowledge about triggering events, acting processor, affected business objects.

32 The Identity and its “less rich” sibling the digital identity
Identity is the fundamental concept of identity management In philosophy Identity is the sameness of two things. In object-oriented programming Identity is a property of objects that allows the objects to be distinguished from each other. But in Identity Management … “We usually speak of identity in the singular, but in fact subjects have multiple identities.” “These multiple identities or personas, as they are sometimes called, …”. The sum of all these Personas makes up the identity. In turn personas are to be understood as its projection to the space of information demand in a specific context. Biometrics ties the digital identity to the real world physical identity. Attributes ID

33 The central digital identity whenever an individual enters the enterprise ecosystem first time …
Its digital identity is created whenever an individual enters the enterprise ecosystem 1st time. Regardless if it is a user or not Being a user represents a class of roles already The digital identity is the individuals digital sibling. Its lifetime is determined by the lifetime of the enterprises interest. The digital identity is global and unique It carries the minimal identifying attributes. enterprise ecosystem employee PRM HR partner ID customer IAM CRM prospect

34 The User: Identity uses a Resource
Identities are often tied to resources They „use“ resources They do so by performing operations This relations may carry attributes It turns to a derived object: the user. Account is a synonym for user. The “user” is the identity's relationship to the resource. identity resource use user

35 The Operation: user operates on the Resource
users perform different operations on resources They „operate“ on resources They do so by performing operations This relations may carry attributes It turns to a derived object: the user. user resource operates operation

36 Permission = Operations on Resources
The user performs an operation The operation acts on the resource Operations on resources (objects) may be labelled with “permissions”. Permissions are elementary They are simple by definition There may be a large number There is a limited set of permissions user Resource Permission perform act Operation

37 The Identity belongs to an organisation
The Identity has a relationship to an organisation It typically has an owner in this organisation There might be more than one relationship There are many specialisations to this relationship This relationship may carry attributes It turns to a derived object: the individual role. The role type is a predefined class of relationships of an identity to an organisation. When the role type is assigned to an identity parameters are set to form the individual role. identity organisation belong role

38 To each object policies can be applied
organisation object apply rule policy Policies are sets of rules The rules are generally applied on an objects state change Applying rules to objects needs to be expressed as an abject of its own. Policies can be attached to all objects Most obvious are SoD- (separation of duties) policies A SoD policy applies to roles A SoD policy contains several SoD rules Only static SoD is considered here Dynamic SoD requires the introduction of the object ‘session’ object policy applies to contains role role rule

39 The Identity is linked to resources via other objects
organisation The picture grows and soon becomes complex Policies may be applied to all objects Every object has an owner role user resource operation

40 The role The role is an abstraction
Like the „product“ abstracts the „contract“ Hence the role type relates to role like products to contracts. The assigned individual role looks similar to an employee contract. Both may in fact may be one “agreement”. They may as well be left separate. A customer may receive a role as well. The role and the contract may well be one agreement (collapse to one).

41 The concept of a role is an abstraction like the product to the contract.
The product generalises the contract. It is a contract type. The contract instantiates the concept of a product (or contract type). The role type generalises the role. The role instantiates the concept of a role type. Org. to its customers to its workers Concept / abstraction (type, class) Concept / abstraction (type, class) product role type contract role instantiation (object)

42 Central vs. Local IDs & roles are central by nature, while permissions are local
Users are assigned roles Roles may belong to a role-hierarchy Generally (but not always) senior roles have all permissions assigned to junior roles Permissions are operations on objects. Permissions can be assigned + (additional) or - (subtractive) Roles can be assigned temporarily per session The central idea behind roles is to simplify authorisation management by associating permissions with a role and then assigning this role to a user. Roles are often used in applications to enforce policy. For example, an application might impose limits on the size of the transaction being processed depending on whether the user making the request is a member of a specified role. A bank teller might have permission to process transactions only less than a specified threshold, supervisors might have a higher limit, and managers might have a higher limit, etc. In other words, roles can be related to various job positions and the permissions associated with them. A way to look at Roles is the collection of resources and permissions associated with a class of user(s). The class will be granted a consistent set of services based upon their Role. Roles are often equal to job functions in many organisations. Currently, different administrators or application vendors have different definitions of roles. As this situation may serve as a source for confusion, we therefore henceforth will refer to the deserving research of the National Institute of Standards and Technology (NIST). central Source: Ferraiolo, Sandhu, Gavrila: A Proposed Standard for Role-Based Access Control, 2000.

43 Relationships are expressed in contracts
role identity organisation operation user Role ressource contract contract type role type specifies contains An Identity performs operations on the organisation’s resources through several intermediate organisational constructs: The relationship's fine structure: a contract defines the total relationship the role represents the entitlements and the planned behaviour. the role hence is a fraction of the contract. the contract may contain several roles. The actual (contract, role) defines incarnation details of the type (contract type, role type).

44 Subjects are acting on objects
action owner custodian may be or time In workflows subjects (actors) act on objects Subject may be owners or a clerk 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 Time may act as a (virtual) subject

45 Request & approval The request is a transient object.
It is the central workflow object It can be understood as the instantiation of a process type. The request is created by an event. when a subject requests access to an object. when time has come to re-validate a role / privilege. when the defined response period has been passed without an action (escalation) Subject Object requests request Process type: approve request instantiation request #4 request #3 request #2 request #1

46 Request & approval requests own The request is a transient object.
It is the central workflow object It can be understood as the instantiation of a process type. The request is created by an event. when a subject requests access to an object. when time has come to re-validate a role / privilege. when the defined response period has been passed without an action (escalation) The objects owner decides on the request Changes its state States are: Approved Rejected Escalated As many requests as objects owners can be expected. Subject Object requests own request escalate approve time Owner reject Process type: approve request instantiation request #4 request #3 request #2 request #1

47 Subjects decide on requests
In workflows subjects (actors) act on objects Subject may be owners or a clerk Owners are responsible Clerks act on behalf of owners Owners delegate to clerks Subject act or react Their action triggers an event Reactions often are approvals subject request decides approval decision may be or rejection or escalation

48 Every object has an owner
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 delegate. Owners differ considerably from one organisation to another This apparent complexity is a result of customising a simple model owner individual Superior resource owner org. dept. Superior HR Puchasing Line Mgr. Sales, … role- Manager process- Manager Line-Mgr. own own own own own own own object identity resource organisation contract type role type operation

49 events There are events … State transitions fire events
Created by an subject Time triggered events State transitions fire events event S1 transition S2

50 Processes of the Identity Management
The Processes of the Identity Management may be grouped ... into operational, managerial and change operational: identify, authenticate and authorise managerial: administer digital Identities Change: changing the implementation of objects into essential and physical essential: administer and use physical: integrate, transport, transform and “provision” By the leading objects, they act on authenticate authorise create certify transport change archive operational managerial strategic each classification has its specific value.

51 Elementary actions – changes on objects
The Identities role in an organisation performs operations on resources The Processes consist of >= 1activities. They are triggered by an event. They lead to a meaningful result to a subject. Process types (the class or definition) and process instantiations (incarnation, actual). Operational processes and managerial processes. Operational processes: identification, authentication and authorisation. The managerial: administrative processes, audit processes and change processes. The administrative processes represent the “lions share” of all IAM processes. Its most prominent representative is the “request & approval process”. defines the relationship a role defines incarnation details “the contract is expressed by several roles” role identity organisation operation user Role ressource contract contract type role type specifies contains maintain Identity maintain organisation maintain role typs derive roles maintain resources maintain operations Maintain role maintain user assign operations

52 Deriving elementary actions is an obvious process
Each object in the big picture needs a maintanance process Maintenance covers CRUD (create, read update, delete) and assignment

53 Caveats - some not so obvious cases
identity superior own Who is the superior depends on the context To determine the superior it is important to ask … For which task, process or project does the individual work Who allocates the individuals working time there For different tasks, or processes or projects the superior might be different The superior might be a project leader Change role is more complex than it seems identity contract role When an individuals role in an organisation changes Often the old role need to be active for a defined period Sometimes the new role needs to be active beforehand as well Generally some operations on objects must be activated in advance Generally some operations on objects need to phase out later (e.g. access to old mailbox) Occasionally transfer operations must be inserted (e.g. migrate mailbox)

54 Applying the generic essential model
The model enables deriving a complete set of elementary actions. Otherwise the number of ‘trivial’ maintenance processes is easily underestimated. processes consisting of only one elementary action dominate. A minority of processes are more complex. Customising the model to a specific situation covers … Naming all resources listing all operations Fleshing out the organisation Naming the specific owners Stating policies e.g. for pre-approved role assignments Adding physical actions

55 Approve request generic process example using petri nets
Result of the conclave workshop

56 Agenda Warum? - Motivation für GenericIAM.
Wohin? - Das Ziel der Initiative. Wer? - Die Mitwirkenden und ihre Erfahrungen. Wie? - Unsere Arbeitsweise. Was? - die erzielten Ergebnisse. Wann? – Historie, Gegenwart und Planung.

57 History & Orientation Starting small & national, acting globally.
GenericIAM started in Germany in May 2006. GenericIAM is set up as a competence center within NIFIS e.V.. After one year (~ May 2007) we decided to internationalize our work. We synchronized our activities with The OpenGroup so far. We are in talks with several other standardization bodies and focus groups: ITU-T, enisa, more … Our first results will be delivered in autumn 2007. From then on we will publish them yearly. An appropriate success provided, we will feed our results to an established international standardization body.

58 Wann? Gestern, heute und morgen
Wir kamen erstmalig im Q1/2006 zusammen – anche inem aufruf von Kuppinger, Cole + Partner. Seither treffen wir uns einmal pro Quartal. Die ersten Ergebnisse wollen wir noch in 2007 publizieren. organize, acquire model booth EIC 2007 GenericIAM 2007 kickoff meeting Meeting # Frankfurt Meeting # München Meeting # Wiesbaden Meeting # München Meeting # Düsseldorf Meeting #6 Meeting #7

59 Fragen – Kommentare - Beiträge?

60 Vielen Danke für Ihre Aufwerksamkeit!
The end ... Vielen Danke für Ihre Aufwerksamkeit! sollten Sie noch Fragen haben: skype: HoWa01 VoIP:

61 Achtung Backup Folien

62 Die NIFIS im Überblick Nicht gewinnorientierter, eingetragener Verein
Motto - „aus der Wirtschaft für die Wirtschaft“ Position - „neutrale, herstellerunabhängige Institution“ Gegründet im Juni 2005 mit Sitz in Frankfurt am Main Mitglieder (Auszug):

63 Wissenschaft und Politik
Der Sicherheitsbedarf in Unternehmen Sicherheit beginnt nicht erst beim Virenscanner und hört auch nicht an der Firewall auf: Informationen Publikationen Veranstaltungen S I C H E R H E I T Passive Hilfe Aktive Hilfe Pro-Aktive Hilfe Dienste Notruf Notfallhilfe Siegel Zertifikat Award Wissenschaft und Politik

64 Die Sicherheitsstufen
Zwischen „keinem Schutz“ und einem „optimalen Schutz“ muss kein Vakuum sein: Validierung Gehobener Schutz ISMS Zertifizierung nach ISO/IEC (BS7799) Siegel Rudimentärer Schutz Diverse bisher unkoordiniert genutzte Schutzmaßnahmen Werkzeuge und Hilfsmittel

65 Mitgliederversammlung
Aufbau der NIFIS Exekutivbeirat Fr. Dr. Krogmann MdB, CDU - Hr. Otto MdB, FDP - Fr. Stokar von Neuforn MdB, BÜNDNIS 90 DIE GRÜNEN - Hr. Tauss MdB, SPD Wissenschaftlicher Beirat - Hr. Prof. Dr. Heckmann - Hr. Prof. Dr. Herberger - Hr. Prof. Dr. Merle Vorstand Peter Knapp (Vors.) Dr. Thomas Lapp (stellv. Vors.) Brad Chapman Mathias Gärtner Mitgliederversammlung

66 NIFIS ist primär Kompetenzzentrum für
Informations-Sicherheits-Management-Systeme Identity Management Business Continuity Management Datenschutz Flächendeckende CERT-Infrastruktur Förderung sicherer IP-Kommunikation in Unternehmensnetzwerken Sicherheit von Rechenzentren und Informationstechnologie Sicherheit von Software-Anwendungen Sicherheit von VoIP

67 Identity and Access Management Terminology
Access management. Processes and technologies for controlling and monitoring access to resources consistent with governing policies. Includes authentication, authorization, trust, and security auditing. Authentication. A process that checks the credentials of a security principal against values in an identity store. Authentication protocols such as Kerberos version 5, Secure Sockets Layer (SSL), NTLM, and digest authentication protect the authentication process and prevent the interception of credentials. Authorization. The process of resolving a user's entitlements with the permissions configured on a resource in order to control access. Authorization in the Windows operating system involves access control lists (ACLs) on files, folders, shares, and directory objects. Applications such as SQL Server, SharePoint® Portal Server, and Exchange Server implement access control mechanisms on resources they manage. Application developers can implement role-based access control using Windows Authorization Manager or ASP.NET roles. Credential. Typically a piece of information related to or derived from a secret that a digital identity possesses, although secrets are not involved in all cases. Examples of credentials include passwords, X.509 certificates, and biometric information. Digital identity. The unique identifier and descriptive attributes of a person, group, device, or service. Examples include user or computer accounts in Active Directory, accounts in Microsoft Exchange Server 2003, user entries in a database table, and logon credentials for a custom application. Entitlement. A set of attributes that specify the access rights and privileges of an authenticated security principal. For example, Windows security groups and access rights are entitlements. Federation. A special kind of trust relationship between distinct organizations established beyond internal network boundaries. Identity integration services. Services that aggregate, synchronize, and enable central provisioning and deprovisioning of identity information across multiple connected identity stores. MIIS 2003 SP1 and the Identity Integration Feature Pack 1a (IIFP) for Active Directory provide identity integration services. Identity life-cycle management. The processes and technologies that keep digital identities current and consistent with governing policies. Identity life-cycle management includes identity synchronization, provisioning, deprovisioning, and the ongoing management of user attributes, credentials, and entitlements. Identity store. A repository that contains digital identities. Identity stores are usually some form of directory or database managed and accessed through a provider such as Active Directory or Microsoft SQL Server. Identity stores can be centralized, for example on a mainframe computer, or distributed; Active Directory is an example of a distributed identity store. They generally have well-defined schemas for what information can be stored and in what form it can be recorded. They usually incorporate some form of encryption or hashing algorithm to protect both the store and components of the digital identity, such as credentials. Older and custom identity stores may not have such strict security mechanisms and may store passwords in plaintext (with no encryption). Identity synchronization. The process of ensuring that multiple identity stores contain consistent data for a given digital identity. This process can be achieved using programmatic methods such as scripts or through a dedicated product such as MIIS 2003 SP1. Provisioning. The process of adding identities to an identity store and establishing initial credentials and entitlements for them. Deprovisioning works in the opposite manner, resulting in the deletion or deactivation of an identity. Provisioning and deprovisioning typically work with identity integration services to propagate additions, deletions, and deactivations to connected identity stores. Security auditing. A process that logs and summarizes significant authentication and authorization events and changes to identity objects. Organizations will differ in their definition of significant events. Security audit records can be written to the Windows Security Event Log. Security principal. A digital identity with one or more credentials that can be authenticated and authorized to interact with the network. Trust. A state that describes the agreements between different parties and systems for sharing identity information. A trust is typically used to extend access to resources in a controlled manner while eliminating the administration that would otherwise be incurred to manage the security principals of the other party. Trust mechanisms include cross-forest trusts in Windows Server 2003 and trusts between realms using the Kerberos version 5 authentication protocol.

68 Roles, tasks, and operations according to Microsoft
A role … is a set of permissions that a user must have to do a job. Well-designed roles should correspond to a job category or responsibility (for example, receptionist, hiring manager, or archivist) and be named accordingly. A task … is a collection of operations, and sometimes other tasks. Well-designed tasks are inclusive enough to represent work items that are recognizable (for example, "change password" or "submit expense"). An operation … is a set of permissions that you associate with system-level or API-level security procedures like WriteAttributes or ReadAttributes. You use operations as building blocks for tasks. Role definitions The role definitions that are appropriate depends on the structure and goals of your organization. Roles support inheritance from other roles. To define a role, you specify a non-arbitrary name, a friendly description, and some lower-level tasks, roles, and operations that are part of it. This provides a mechanism for role inheritance. For example, a Helpdesk role might include a Product Support role. Role assignments A role assignment is a virtual container for application groups whose members are authorized for the role. A role assignment is based on a single role definition, and a single role definition can be the basis of many role assignments. Task definitions A task definition is smaller than a role definition and can be used to define roles and other tasks. You associate tasks with roles in an intuitive way. For example, the Recruiter role might include the Interview task. Tasks, like roles, are defined in a way that is appropriate to the organization. To define a task, you specify a name, a friendly description, and some lower-level tasks and operations that are part of it. Operation definitions Operations are small computer-level actions that are used to define tasks and are not relevant to an administrator. You define operations only in developer mode.

69 How Does XPDL Compare to BPEL?
BPEL and XPDL are entirely different yet complimentary standards.  BPEL is an "execution language" designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from point-to-point. For this reason, it is best suited for straight-through processing or data-flows vis-a-vis application integration.  The goal of XPDL is to store and exchange the process diagram, to allow one tool to model a process diagram, and another to read the diagram and edit, another to "run" the process model on an XPDL-compliant BPM engine, and so on. For this reason, XPDL is not an executable programming language like BPEL, but rather a process design format that literally represents the "drawing" of the process definition. Specifically, it has ‘XY' or vector coordinates, including lines and points that define process flows. This allows an XPDL to store a one-to-one representation of a BPMN process diagram. For this reason, XPDL is effectively the file format or "serialization" of BPMN, as well as any non-BPMN design method or process model which use in their underlying definition the XPDL meta-model (there are presently about 70 tools which use XPDL for storing process models.)