1. Internet2 MACE Identity and Access Management (IAM) Projects http://arch.doit.wisc.edu/keith/i2/ integ-tb-kh-02.ppt Keith Hazelton, U Wisconsin With help from Tom Barton and Walter Hoehn JA-SIGDecember 5, 2005, Austin, TX http://arch.doit.wisc.edu/keith/i2/ integ-tb-kh-02.ppt Keith Hazelton, U Wisconsin With help from Tom Barton and Walter Hoehn JA-SIGDecember 5, 2005, Austin, TX

2. 2 http://arch.doit.wisc.edu/keith/i2/ integ-tb-kh-02.ppt Identity and Access Management (IAM) service-based model & Internet2 Middleware Initiative (I2MI) tools I2MI suite and integration techniques Addressing gaps in the tools and the model Harmonization objectives for I2MI tools

3. 3 Identity & Access Management in the IT Ecosystem Each person’s online activities are shaped by many Sources of Authority (SoAs) or Systems of Record (SoRs) Resource managers Program/activity heads Other policy making bodies Self Common middleware infrastructure should be operated centrally To not oblige departments/programs/activities to build their own core middleware Management of the information it conveys should be distributed Hook up all of those SoAs to the middleware

4. 4 IAM and Application Integration

5. 5 From Construction to Integration Construction Raw materials into systems Integration Subsystems into whole systems Multiple systems into ecosystems We’re all moving from construction to integration The integration story across IAM services and with IAM services

6. 6 IAM: Generic Services VerbObjects ReflectData of interest from systems of record into registry, directory JoinIdentity information across systems ManageCredentials, group memberships, affiliations, privileges, services, policies ProvideIAM info via - relay thru run-time request/response - provisioning into App/Service stores Authenticate (AuthN)Claimed identities Authorize (AuthZ)Access or denial of access LogUsage for audit

7. 7 Reflect, Join, and Manage Credentials: One mapping to I2MI Systems of Record Stdnt HR Other Enterprise Directory Registry LDAP

8. 8 Manage IAM Info and Provide it via run-time calls or provisioning Systems of Record Apps / Resources Enterprise Directory

9. 9 IAM Services mapped to I2MI Tools Systems of Record Central AuthN/ WebISO Apps / Resources Enterprise Directory GrouperSignet Shibboleth

10. 10 Relative Roles of Signet & Grouper Grouper Signet Role-Based Access Control (RBAC) model Users are placed into groups Privileges are assigned to groups Groups can be arranged into hierarchies to effectively bestow privileges Signet manages privileges Grouper manages, well, groups

11. 11 Nutshell Description of Grouper Mix of manual and automation processes manage a common Group Registry Many sources of authority are reflected in group memberships Automation processes provision info from the Group Registry into LDAP, AD, directly into app-specific databases, or … Wherever the value of the info warrants spending the resources to place it there Group management authority is delegatable

12. 12 Grouper Groups Attributes of groups Names: name, displayName, guid Description Members Can extend the set of attributes to support groups with more specific purposes Subgroups, compound groups, and aging Stored in an RDBMS, the Group Registry

13. 13 Signet Overview Analysts define privileges in Signet in “business terms” and specify associated permissions. Signet presents this view in a Web UI where users assign privileges and delegate authority across all areas in which they have authority. Signet internally maps assigned privileges into system- specific terms needed by applications. Privileges are exported, transformed, and provisioned into applications and infrastructure services.

14. 14 Business View Categories Functions Subsystems Clinical Trial Protocol A Patient Records Materials Control Manage Grant Lab Access Administration Student Admin Course Support Add/Drop students Schedule Classes Process Applicants Award Scholarships Manage Accounts Financial Aid Limits Which term From Fund… Read/Write Hours For school… For fund… Which campus Qty/day $ constraints organizing actions

15. 15 Systems View Permissions Atomic units of control that map to specific access rules in systems. Includes limits that must be evaluated when interpreting permissions. Resources The target of a specific privilege; things that have access rules to control their use. Signet internally maps assigned privileges into system specific terms needed by applications.

16. 16 Systems Integration Privileges document XML representation of privileges for an individual or group. Compatible with SAML and XACML representations of Subjects and Access Rules. Integration Site-specific Privileges are exported, transformed, and provisioned into integrated systems and infrastructure services.

17. 17 Privilege Elements by Example By authority of the Dean grantor principal investigators grantee (group/role) who have completed training prerequisite can approve purchases function in the School of Medicine scope for research projects resource up to $100,000 limit until January 1, 2006 as long as a faculty member at … conditions Privilege Lifecycle

18. 18 IAM Services mapped to I2MI Tools Systems of Record Central AuthN/ WebISO Apps / Resources Enterprise Directory GrouperSignet Shibboleth

19. 19 Empty spaces in the I2MI toolbox Those pesky lines between the boxes-- left to the reader The lines are where service integration happens Metadirectory functions Provisioning (in the general sense) ?? Should I2MI try to help with integration tasks?

20. 20 Modeling the lines: Initial thoughts Data flows? Event publication on a service bus Content-based routing Service invocations? SAML request/responses WS-* wide world of web services Is it a particle or a wave? Document-oriented transformation services

21. 21 New under the sun Roland Hedberg’s deep design (mantra: OM) Content based information routing Governed by embedded policy engine (SPOCP’s brain) Walter Hoehn’s Nth generation provisioner, Nexus Consumer-specific mappings & transforms configured transparently

22. 22 Legacy provisioning challenges Difficult to maintain Expanding list of managed resources Outdated technology New ERPs, upgrades Expanding customer base

23. 23 Evolution vs. Revolution Validate approach along the way Realize the benefits sooner Avoid extended design process Ease the pain of conversion

24. 24 Nexus: Basic Requirements Robust technologies Resource connector API Timely updates to consumer systems Resource integrity verification Change Management / Component Testing Administrative interfaces

25. 25 Nexus Features Runtime configuration (mapping logic) Single provisioning engine Integrity verification / repair Dependency analysis Abstract consumer interface (SPML) Robust queueing Multi-threaded Platform independent

26. 26 Benefits of run-time provisioning Clearer data relationships Verifiable data integrity Re-use Change management

27. 27 Nexus

28. 28 NEXUS

29. 29 NEXUS

30. 30 NEXUS

31. 31 Provisioning configuration

32. 32 Provisioning config., cont.

33. 33 Provisioning config., cont.

34. 34 Nexus command modes

35. 35 Nexus command modes, cont.

36. 36 Nexus command modes, cont. Daemon mode nexus --daemon --map=conf/provisioning.map.xml --file=conf/nexus.properties Runs continuously Queues and processes registry changes Keeps all consumer systems synchronized

37. 37 Nexus command modes, cont. Show mode nexus --show=wassa --map=conf/provisioning.map.xml --file=conf/nexus.properties Displays correct provisioning for a given user Can be run for a set of users

38. 38 Nexus command modes, cont. Verify mode nexus --verify=wassa --map=conf/provisioning.map.xml --file=conf/nexus.properties Displays synchronization status for a given user Helps in diagnosing account problems Useful for testing configuration changes Can be run for a set of users

39. 39 Nexus command modes, cont. Repair mode nexus --repair=wassa --map=conf/provisioning.map.xml --file=conf/nexus.properties Fully synchronizes a user’s data in all consumers Helpful in fixing account problems Useful for adding new consumer resources Can be run for a set of users

40. 40 Grouper & Signet: Site IAM Integration Requirements Subject - a person, group, application, or other type of object whose identity is managed by your IAM system Abstract the underlying technology and data model from a relying application Enable identifier namespaces to be selected to match application needs Username vs. opaque registryID vs. … Scenarios Map authenticated user to internal security principal Search for or select subjects within application

41. 41 Subject API: Integration with Site’s IAM

42. 42 More Subject API Info Subject and Source interface specs are at v0.1 – they may yet change Searching Some per-subjectType methods? Grouper includes a GroupSourceAdapter that is a provider of ‘group’ subjectTypes from the Group Registry Subject API will not support the Join function JDBC source adapter is included now, JNDI source adapter will be provided in a subsequent release

43. 43 Harmonizing I2MI Tools: Objectives We should eat our own dogfood Common technique for integration with site IAM infrastructure Capable of integration with external privilege and/or group management Common or coordinated web presence, documentation, product placement info Just starting to address this Steering group formed & documentation resource assigned

44. 44 Further I2MI Integration Needs Cookbook of ways to deploy I2MI tools to address various attribute and access management scenarios Mechanism for sustained viability of I2MI tools On-going support Post-working-group model for continued development & QA

45. 45 Alternative boxes & lines The service model could be implemented with any number of toolsets I2MI Home-grown (perl scripts, SQL tables & procedures, OpenLdap directories,…) Vendor offerings Novell, Sun, Oracle, Microsoft, IBM,…

46. 46 Q & A http://middleware.internet2.edu http://middleware.internet2.edu/dir http://middleware.internet2.edu/dir/groups/ grouperhttp://middleware.internet2.edu/dir/groups/ grouper http://middleware.internet2.edu/signet http://shibboleth.internet2.edu hazelton@doit.wisc.edu

47. 47