1. Implementing Kuali Identity Management at your Institution Kuali Days VIII San Antonio Texas Pre-conference Workshop Monday, November 16, 2009 9 a.m. - noon – Salon D

2. 2 Implementing Kuali Identity Management at your Institution Eric Westfall Indiana University ewestfal@indiana.edu Jonathan Keller University of California at Davis jhkeller@ucdavis.edu Mitch Dysart Innovativ Consulting Partners LLC mitch@innovativcp.com

3. What is (and isn’t) KIM?

4. 4 What is KIM? New module in Kuali Rice version 1.0 Common Interface and Service Layer Integrated Reference Implementation Set of User Interfaces KIM is not just Identity Management, it’s also Access Management

5. 5 What KIM is Not A Full-Fledged Identity Management System Provisioning Hooks to update other systems Duplication Management An Identity Aggregator An Authentication Implementation

6. Why Did We Create KIM?

7. 7 Motivations Expansion of Kuali Common Identity Management API Consistent Authorization Implementation

8. 8 What we did not want KF S KC KS IDM

9. 9 What we did want KF S KC KS KI M

10. 10 Design Considerations Existence of Other IdM Solutions Legacy/Existing Implementations Replaceable Services Separation of Concerns Service Bus Maintenance GUIs

11. Business Case Analysis Implementing Kuali Identity Management at your Institution

12. 12 Business Case Analysis Single Authoritative Source Single Directory Multiple Authentication Mechanisms KIM – A Simple Case

13. 13 Business Case Analysis KIM – A Simple Case Authoritative Source Oracle PeopleSoft Human Capital Management (HCM) Student Administration Tables Campus Community Tables Human Resources Tables

14. 14 Business Case Analysis KIM – A Simple Case Single Directory Enterprise Domain Single Forest EduPerson Schema

15. 15 Business Case Analysis KIM – A Simple Case Multiple Authentication Mechanisms

16. 16 Business Case Analysis Multiple Authoritative Sources Multiple Directories Multiple Authentication Mechanisms KIM – A More Typical Case

17. 17 Business Case Analysis KIM – A More Typical Case Multiple Authoritative Sources Oracle PeopleSoft HCM – HR Only KFS Sungard Banner SIS Blackbaud Advancement Desire2Learn LMS Blackboard Debit System

18. 18 Business Case Analysis Multiple Directories Domain Forest #1 KIM – A More Typical Case Forest #2 Domain Directory Server Enterprise Edition

19. 19 Business Case Analysis Multiple Authentication Mechanisms KIM – A More Typical Case

20. 20 Business Case Analysis Typical Identity Management Organization

21. 21 Business Case Analysis Hub Directory Identity Store Provisioning Application Authentication Service Typical Identity Management Organization Authoritative Sources Business Applications

22. 22 Business Case Analysis Total Cost of Ownership Acquisition Licensing & Maintenance Implementation Infrastructure Ongoing Support Assume 5-year horizon

23. 23 Business Case Analysis Total Cost of Ownership Acquisition KIM -- free Commercial – varies widely; $20K - $500K

24. 24 Business Case Analysis Total Cost of Ownership Licensing & Maintenance KIM – free; commercial support potentially available for $1K - $50K per year = $5K - $250K total Commercial – varies widely; $3K - $90K per year = $15K - $450K total

25. 25 Business Case Analysis Total Cost of Ownership Implementation KIM – depends upon Java skills of institution; $100K - $300K internal; $0K - $300K external Commercial – $100K - $300K internal; $50K - $200K external

26. 26 Business Case Analysis Total Cost of Ownership Infrastructure KIM – low cost if implemented on virtual machines; $4K - $50K over lifespan Commercial – low cost if implemented on virtual machines; $4K - $50K over lifespan

27. 27 Business Case Analysis Total Cost of Ownership Ongoing support KIM – assume approx. 1 FTE = $500K over lifespan Commercial – assume approx. 1 FTE = $500K over lifespan

28. 28 Business Case Analysis Total Cost of Ownership 5-year Total KIM – $604K - $1.4M Commercial – $689K - $2M

29. 29 Business Case Analysis Intangibles KIM Strengths: Very customizable, potentially inexpensive Weaknesses: Lacks extensive library of pre-built connectors, requires sound Java expertise

30. 30 Business Case Analysis Intangibles Commercial Strengths: Robust, commercial support, pre-built connectors Weaknesses: Customization can be challenging, potentially expensive

31. KIM Terminology

32. 32 KIM Terminology Namespace Entity Principal Principal ID Principal Name Person Entity Type

33. 33 KIM Terminology Group Role Qualifier Permission / Permission Template Responsibility / Responsibility Template

34. 34 Namespace Prevent Naming Conflicts Allow for Permissions to be Segmented Examples: KR-KNS KR-WRKFLW KFS-SYS KFS-AP KC-SYS

35. 35 Entity Principal Principal ID Principal Name Entity Type Names Addresses Phone Numbers Email Addresses

36. 36 Group Namespace Group Type Attributes

37. 37 Role Namespace Role Type Qualifiers Role Type Services Delegations Primary Secondary

38. 38 Permission / Permission Template Permission Template Permission Permission Details Permission Type Service Assigned to Roles

39. 39 Responsibility / Responsibility Template Responsibility Template Review Resolve Exception Responsibility Responsibility Details Responsibility Type Service Assigned to Roles

40. KIM Services

41. 41 Components Service Interface API KNS-Based Default Implementation Functional Maintenance User Interfaces

42. 42 KIM Services Authentication Service Identity Service Group Service Role Service Permission Service Responsibility Service

43. 43 More KIM Services Identity Management Service Role Management Service Person Service Identity Archive Service “Update” Services

44. 44 KIM Service Architecture

45. 45 15-minute Break Intermission

46. KIM Roles and Role Type Services Implementing Kuali Identity Management at your Institution 46

47. 47 Namespaces Part of the Visible Unique Identifier Types Roles Groups Permissions Responsibilities Allows KIM to Support Multiple Apps Allows KIM UIs to Control Access

48. 48 Sample Roles

49. 49 Role Types KRIM_TYP_T

50. 50 Definition of Role Type Services Kuali: Define via Spring/KSBExporter Non-Kuali: SOAP/KSB

51. 51 Role Type Services Qualifier Matching Validation (through UI) Application/Derived Roles

52. 52 Role Qualifier Matching KimRoleTypeService API Methods boolean doesRoleQualifierMatchQualification( AttributeSet qualification, AttributeSet roleQualifier ); List doRoleQualifiersMatchQualification( AttributeSet qualification, List roleMemberList );

53. 53 Delivered Base Types

54. 54 Derived Role Type Services KimDerivedRoleTypeServiceBase API boolean isApplicationRoleType(); List getRoleMembersFromApplicationRole( String namespaceCode, String roleName, AttributeSet qualification ); boolean hasApplicationRole( String principalId, List groupIds, String namespaceCode, String roleName, AttributeSet qualification );

55. 55 Special Case: Permission Derived Roles PermissionDerivedRoleTypeServiceImpl

56. 56 Role Design Discrete Functional Areas Assign Each Permission Once Role Nesting

57. 57 Nested Roles KFS Example: Nested Role Qualifier Conversion AttributeSet convertQualificationForMemberRoles( String namespaceCode, String roleName, String memberRoleNamespaceCode, String memberRoleName, AttributeSet qualification );

58. 58 Complex Role Qualifier Matching Wildcard Matching Hierarchy Matching Priority Matching

59. 59 Integrating with External Role Systems Batch Data Load Role Service Override Application Roles

60. 60 Methods of Role Type Service Integration Expose Service on External System Implement Integration Code in Rice Server

61. KIM Permission Design and Implementation Implementing Kuali Identity Management at your Institution

62. 62 Permission Structure Permission Types Permission Templates Permission Type Services

63. 63 Rice Permission Templates

64. 64 Rice Permissions

65. 65 Permission Type Service PermissionService API List getMatchingPermissions( AttributeSet requestedDetails, List permissionsList );

66. 66 Priority Detail Checking in KFS

67. 67 Permission Types and the Document Hierarchy

68. 68 Creating Your Own Permissions Example KFS Permission Templates

69. November 16, 2009 Implementation Options

70. 70 KIM Implementation Options Out-of-the-box (no changes) Data feeds into KIM database Service Customization Hybrid of the Strategies above

71. 71 Out-of-the-box Use the delivered KIM service reference implementations Use the delivered KIM database tables Create Persons, Groups, Roles manually via the GUI – May do an initial load of person data Set of identities available will likely be small Only feasible for small applications on a Kuali Rice infrastructure that’s not institution-wide

72. 72 Data feeds into KIM database Use the delivered KIM service reference implementations Use the delivered KIM database tables Use batch or external processes to periodically populate KIM database with identity data Allows for KIM identity data set to match that available at institution No need to maintain data separately Care must be taken to ensure data parity

73. 73 Service Customization Override or replace the reference implementations for the various KIM services Each of the services in KIM can be customized piecemeal Example: LDAP integration Has implications on the KIM user interface screens

74. 74 KIM Services Authentication Service – likely to override Identity Service – likely to override Group Service – might override Permission Service – unlikely to override Role Service – unlikely to override Identity Archive Service – unlikely to override Both Permission and Role Service have an extra abstraction layer behind them that allows for customization without overriding

75. 75 Hybrid Solutions In practice, many implementations will use a hybrid of these various options For example: – Load entity and principal data periodically into KIM database, use reference IdentityService implementation – Use standard out-of-the-box GroupService implementation (no external integration) – Customize the IdentityArchiveService to read historical identity data from an external source

76. 76 Choosing the option that’s right for you! Might depend on: which external systems or data sources you want to integrate with KIM size of your KIM implementation (amount of data) performance considerations expected usage of the KIM GUI screens the role that KIM will play at your institution

77. November 16, 2009 Case Studies

78. 78 Case Studies Indiana University Colorado State University San Joaquin Delta College University of Arizona

79. November 16, 2009 Case Study: Indiana University

80. 80 Indiana University Has an existing Kuali Rice implementation based on version 0.9.1 Upgrading to Rice 1.0.1 - February 2010 KFS 3.0 implementation - March 2010 Planned implementation of KIM includes a hybrid of data loading into KIM database tables and service overrides KIM will be the primary identity system for many of our enterprise software applications

81. 81 Identity Data Indiana University uses a tool from Microsoft called Identity Lifecycle Management (ILM) ILM aggregates identity data from various sources – HR, Peoplesoft, etc. It can then feed that data in close to real time to other systems At IU, KIM will be one of those systems Built a web service that sits on top of KIM that implements CRUD operations for identity data Indiana University

82. 82 ILM-KIM Architecture Indiana University

83. 83 Principal ID and Principal Name In KIM the Principal ID must be unique across the implementation At IU we are using our “Employee ID” for both our principal and entity ids We are using the user’s “network id” for their principal name Indiana University

84. 84 Dealing with Tax ID KFS requires a Tax ID be stored in the External Identifier table At IU this is the Social Security Number which is highly sensitive! ILM process sends us SSN encrypted and we store it that way in the external identifier table as Tax ID Indiana University

85. 85 Historical Data IU has a large historical data set of users Many of these could have participated in workflow transactions as long as 6 years ago KIM has the IdentityArchiveService that can be used to retrieve historical entity data – A subset of the full entity data We pull this historical data into the designated KIM table from an external source when it is requested Indiana University

86. 86 Groups and Active Directory IU has a large Microsoft Active Directory implementation Contains many, many groups that customers want to use for role assignment and routing We override the so that it pulls from both the KIM database and from ADS (via LDAP) We identify ADS groups by giving them an “ADS” namespace Generate group ID based on ADS group name Indiana University

87. 87 Authentication Use a customized version of CAS Override the default AuthenticationService implementation Pulls authenticated principal name from our custom CAS filter which we use for Java applications Indiana University

88. 88 User Interfaces Person – won’t be used to maintain person data, but will permit role/group assignment Group – can be used to create and edit groups unless their namespace is “ADS” Accomplished using permissions Role – can use out-of-the-box implementation Indiana University

89. 89 Future Plans Kuali Financial System implementation Kuali Coeus implementation Integrate Role assignment with our HR system at time of hire or position change Integrate KIM roles and permissions with our Decision Support and reporting environments Begin modeling more Roles at IU using KIM to facilitate authz and role-based routing Indiana University

90. Case Study: Colorado State University

91. 91 Colorado State University Implemented KFS in July 2009 Load HR data into KIM with a nightly batch Nightly comparison of HR data with KIM data to maintain consistency Deactivate – update the principal and set to inactive Report produced showing people deactivated that are in KFS approval roles so new principals can be assigned

92. 92 Colorado State University KFS users use the KIM screens for creating roles and assigning permissions and responsibilities EID used for principal name Banner CSU id as employee id

93. 93 Future Plans Plan to continue nightly batch synchronization as KIM implementation strategy HR Banner Student Planning to implement Kuali Coeus 2.0 in 2010 At that point will unbundle Kuali Rice from KFS so both use a single standalone Rice instance Colorado State University

94. Case Study: San Joaquin Delta College

95. 95 Implemented KFS in July 2009 Use a hybrid approach for identity data – Principal id and entity id are populated with “College Id” the unique id at SJDC – Have basic KIM records for this in KRIM_PRNCPL_T and KRIM_ENTITY_T – Store system users in the KIM database – Other users are pulled from LDAP via an overridden Identity Servic e Do not use KIM GUI screens – Manually manage tables because of small number of users San Joaquin Delta College

96. 96 Future Plans For next release of KFS implementation, plan on switching to a model more similar to CSU Would like to make KIM the “master” for data and duplicate from KIM to LDAP system San Joaquin Delta College

97. November 16, 2009 Case Study: The University of Arizona

98. 98 Working on a KFS implementation UA netid is used for authentication Identity information is available in UA’s Enterprise Directory Service (EDS) Connect to EDS using Spring LDAP and overriding the KIM IdentityService -The entity attributes from LDAP are then loaded into the standard KimEntityDefaultInfo (and related) objects In order to use the KIM GUI’s properly, the UIDocumentService is also overridden The University of Arizona

99. 99 To Learn More… Leo Przybylski from University of Arizona is giving a session in the Rice Track Will cover all of this in much greater detail Integrating LDAP and KIM Wednesday November 18, 2:15 PM, Salon C The University of Arizona

100. November 16, 2009 Questions???