Internet2 MACE Identity and Access Management (IAM) Projects

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

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. 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. IAM and Application Integration

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. IAM: Generic Services

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

8. Manage IAM Info and Provide it via run-time calls or provisioning Apps / Resources Enterprise Directory AuthZ Systems of Record Log Reflect AuthN PROVIDE Provision Join Manage Creds AuthZ Manage Groups, Privs.,... Log PROVIDE Relay

9. IAM Services mapped to I2MI Tools Apps / Resources Enterprise Directory Central AuthN/WebISO AuthZ Systems of Record Log Reflect AuthN PROVIDE Provision Join Manage Creds AuthZ Manage Groups, Privs.,... Log PROVIDE Relay Shibboleth Grouper Signet

10. Relative Roles of Signet & Grouper • 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 Grouper Signet

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

15. Systems View • Signet internally maps assigned privileges into system specific terms needed by applications. • 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.

16. Systems Integration • Privileges are exported, transformed, and provisioned into integrated systems and infrastructure services. • 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

17. Privilege Elements by Example Lifecycle Privilege

18. IAM Services mapped to I2MI Tools Apps / Resources Enterprise Directory Central AuthN/WebISO AuthZ Systems of Record Log Reflect AuthN PROVIDE Provision Join Manage Creds AuthZ Manage Groups, Privs.,... Log PROVIDE Relay Shibboleth Grouper Signet

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. 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. 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. Legacy provisioning challenges • Difficult to maintain • Expanding list of managed resources • Outdated technology • New ERPs, upgrades • Expanding customer base

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

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

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. Benefits of run-time provisioning • Clearer data relationships • Verifiable data integrity • Re-use • Change management

27. Nexus

28. NEXUS

29. NEXUS

30. NEXUS

31. Provisioning configuration

32. Provisioning config., cont.

33. Provisioning config., cont.

34. Nexus command modes

35. Nexus command modes, cont.

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. 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. 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. 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. 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. Subject API:Integration with Site’s IAM

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. 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. 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. 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. Q & A • http://middleware.internet2.edu • http://middleware.internet2.edu/dir • http://middleware.internet2.edu/dir/groups/grouper • http://middleware.internet2.edu/signet • http://shibboleth.internet2.edu • hazelton@doit.wisc.edu