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

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

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…

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

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.

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.

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

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.

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 Local policies may dictate that actions on events are postponed.  Example: Students get to keep their for an additional semester after graduation.

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.

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.

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

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.

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.

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.