Overview

IDM provisions Yale's LDAP Directory.  The directory contains records for most non-confidential people, as well as all non-confidential email aliases.  The LDAP Connector is responsible for provisioning people into the directory.

The connector and access policies enforce Yale's confidentiality rules, including FERPA.

With this release, the privacy options have been consolidated and expanded that HR and SIS can control how much data for each person is published.  All directory attributes are classified in one of three areas (Name and Email Information, Role Information, and Address Information).  HR and SIS can choose which areas to suppress in the directory.

Prior to the directory being managed by IDM, being published in the directory was tied to also having an email alias and had to adhear to email policy.  It is now possible to be listed not be in the directory and not have a working email alias.

Updates to the directory occur as soon as IDM picks up the update from the source system.  Email Alias records are updated once a day only as that is the frequency that the mail relays are populated.  if the mail relays are populated more frequently, this should be adjusted.

Data Sources

Source Data

All data for the directory is sourced from the OIM User.

Target Data

In production, the target LDAP is directory.yale.edu.  In all other environments, alternative LDAP directories are used.

Reconciliation

There is no reconciliation against the directory.  OIM will be the only system writing to the directory, so a logical recon should not be necessary. 

Access Policy

See the Directory Access Policy for details on the Access Policy.

The Access Policy provisions and de-provisions directory records.  Suppression of data for published records is handled by the GTC.

Provisioning

The Provisioning Transport Provider responds to the following events below. 

DN is the primary key for directory records in the People ou.  The computed DN is stored in the ID field of the LDAP resource.  No other attributes are required for the LDAP resource as all data comes from the OIM User.

Suppressing Data

The Directory Access Policy controls when a record is published or not.  However, some additional processing must be done in the provisioning events to suppress some data based on the access policy or the status of the person.  If a record is published, name and email related attributes will always be included.

• Suppress the address and phone related information if all of the following are true:   These rules handle the special circumstance for the Standard Policy Before Start Date.
  • The privacy indicator is 0.
  • has_future_assignment is "Y".
  • The source of identity is HR.
• Suppress the role, address and phone related information when all of the following are true: These rules handle the circumstance for the Standard Policy After Leaving Yale for Faculty and Staff.  This also covers the situation after conferees leave.
  • The privacy indicator is 0, 1, or 2.
  • The source of identity is HR.
  • The has_future_assignment flag is "N".
  • The has_current_assignment flag is "N".
• Suppress the role, address and phone related information when all of the following are true: These rules handle the circumstance for the Standard Policy After Leaving Yale for Students.
  • The privacy indicator is 0, 1, or 2.
  • The source of identity is SIS.
  • The has_future_enrollment flag is "N".
  • The has_current_enrollment flag is "N".
• Suppress address and phone related attributes when the following is true:
  • The privacy indicator is 1 or 101.
• Suppress role related attributes when the following is true:
  • The privacy indicator is 2 or 102.
• Suppress role, address and phone related attributes when the following is true:
  • The privacy indicator is 3 or 103.
    

    Special Rules for Students:
    If a person is a student and they have an STN or STH assignment, then suppress the following role related fields:

    • homeOrgID
    • departmentNumber
    • homeOrg
    • ou (aka organziationUnitName)
    • title

    If the person is a student (regardless of assignment), substitute the School Name for the o (organziationName) instead of using the Primary Assignment Org name.

    
    
    

Create and updateFormField Events

Provisioning responds the same way for both create and update events.

• Lookup the DN in the LDAP.
• If found, update the LDAP record with the new values. 
• If not found, insert a new LDAP record.
• Refer to the Suppressing Data rules above for details on what data not to publish.
• Return DN to OIM.

Revoke Event

• Lookup the DN in the LDAP.
• Delete the record if found.
• Do not raise an error if the record is not found. 

Other Events

All other events throw the ProviderException "FUNCTIONALITY_NOT_SUPPORTED".  We do not support locking of LDAP records.

Notes

Throw and log appropriate error messages when accessing the LDAP. 

Data Flow

Documents

	Name	Size	Creator (Last Modifier)	Creation Date	Last Mod Date	Comment
	Directory Data Flow Diagram.pdf	30 kb	Rod Gustavson	Jun 16, 2009	Jun 16, 2009