1. Managing time-driven entitlement policies with Identity Manager E. Axel Larsson Drew University 20 July 2005

2. An overview of entitlements What is an entitlement?  Accounts created/deleted on connected systems.  Group memberships  Distribution lists  Placement of users in particular OUs.  Values of attributes  Custom entitlements

3. An overview of entitlements Methods for implementing entitlement policies.  On the drivers themselves (XSLT or DirXML script)  Role based entitlements (IDM 2)  Workflow based entitlements (IDM 3)  Roll your own…

4. Implementing Entitlements In DirXML script or XSLT  No abstraction – policies act directly on object and attribute changes in eDir or an application.  Conflict resolution – you’re responsible for accounting for all cases in your policy.  Duplication of policies and efforts: Within a driver Across multiple drivers

5. Implementing Entitlements Role-based entitlements (IDM 2)  Abstraction: Entitlement policies – contain business rules stating the criteria for entitlements. Drivers – are responsible for implementing the entitlements on the connected systems.

6. Implementing entitlements Role-based entitlements (IDM 2)  The pieces: Driver manifest – XML specifies which entitlements the driver supports. Driver policies – React to changes in entitlement and apply them to connected systems.  DirXML script condition – if entitlement (changing, changing from, changing to, available, equal)  DirXML script nouns – Added Entitlement, Removed Entitlement  All done via policies, no shim change to support entitlements.

7. Implementing Entitlements Role-based entitlements (IDM 2)  The pieces: Entitlement policies – eDirectory dynamic groups.  Membership – dynamic or static Entitlements service driver  Monitors for changes to entitlement affecting attributes.  Evaluates entitlement policy membership. Conflict resolution  Updates DirXML-SPEntitlements on the user object

8. A slight problem… Identity Manager works in real-time  IDM can only take action when an event has occurred in the directory or an app.  Assumption: Any changes to directory data have an immediate impact on provisioning of accounts and services.

9. Is this really a problem? Does your HR, SIS, etc. system produce useful events for IDM?  John Doe starts work today. (vs)  The hire date attribute for John Doe has changed to 2005-09-01. Local policies may dictate that actions on events are postponed.  Example: Students get to keep their email for an additional semester after graduation.

10. Hacks Slicing/dicing dates in an IDM policy.  Java extension functions: java.util.Date IDM needs events  “Ping” the objects. Externally via LDAP… scripts and cron jobs. Inside of IDM… driver heartbeat. A variety of variations on this technique.  See Cool Solutions and the IDM forums.

11. What I wanted… Something like RBEs with dates.  Policies defined independently of each other. HR entitlement policies don’t need to check for student entitlements and vice-versa.  Policies return date ranges when their entitlements are applicable.  Handles real-time entitlement changes and scheduled changes.  Automatically resolves overlapping entitlements.

12. An example: uidService Class StartEndReason 0000002StuFull8/20/20041/31/2005Registered for 2004FA 0000002StuFull1/31/20058/20/2005Registered for 2005SP 0000002Emp2/1/20056/1/2005Drew employee – ENGL department 0000002StuFull8/20/20051/31/2005Registered for 2005FA 0000014Emp1/1/20057/1/2005Drew employee – HIST department 0000014Mail7/1/20057/1/2006Sponsored – email only

13. What we’re doing… “Entitlements engine” – MS SQL app.  IDM driver for JDBC. Subscriber channel – all “entitlement affecting” attributes  Employment status (start date, term date, leave dates, etc.)  Student status (based upon terms, resolved to dates by code within the app.)  Sponsored accounts info (range of sponsorship). Publisher channel  Updates to the drewEntitlements attribute.

14. What we’re doing…  Process When changes occur to entitlement affecting attributes.  Changes flow to entitlement engine.  Triggers execute each entitlement policy, updating the EntitlementCache table.  Find current entitlements.  Current entitlements written back to eDir.  IDM drivers provision accounts, group memberships, etc. On a nightly basis.  Find current entitlements (no need to re-evaluate all policies)  Write changes to current entitlements back to eDir.  IDM drivers provision accounts, group memberships, etc.

15. In summary… Using a database was a natural fit. Relatively easy to add new entitlement policies.  A small bit of T-SQL code for each policy.  Easier to handle dates in T-SQL than in IDM2 with Java extensions. Independent policies. EntitlementCache table provides for better reporting and early warning of changes.