Overview

This section contains high-level information about how the SIF integration module functions.

Key Terms

Schools Interoperability Framework (SIF)

SIF is a data interchange open standard developed to allow student, staff, course, and school information to be exchanged between a student information system and other SIF-enabled applications through a Zone Integration Server. The SIF specification defines an XML format for this data exchange.

Student Information System (SIS) 

A student information system is a database and management framework which allows school systems to manage their student, staff, and course information. In a SIF integration environment, the SIS serves as the primary source of authority for enrollment (SOA) information.

Zone

A zone is a defined scope for a SIF integration environment. It serves a logical separation of information between various organizational bodies. A zone may represent an entire school district or just one school.

Zone Integration Server (ZIS) 

A ZIS is the central communications hub for a SIF integration environment. All systems participating in the SIF integration communicate through the ZIS via SIF Agents. Typically, the SIS will send information into the ZIS which will be consumed by other SIF Agents, such as bus routing software, library systems, and the Concensus SIF integration module.

SIF Object Class 

The SIF specification defines a number of object classes. These classes represent various actual and logical entities and relationships within the SIS. The Concensus SIF integration module translates a subset of these object classes to eDirectory object classes and relationships to provide student, staff, and enrollment information into an identity management environment.

Identity Manager

Novell® Identity Manager is a service which synchronizes data between servers in a set of connected systems by using a robust set of configurable policies. Identity Manager uses the Identity Vault to store shared information and uses the Metadirectory engine for policy-based management of the information as it changes in the vault or connected system. Identity Manager runs on the server where the Identity Vault and the Metadirectory engine are located.

Connected System

A connected system is any system that can share data with Identity Manager through a driver. The ZIS is the connected system for this connector.

Identity Vault

The Identity Vault (IDV) is a persistent database powered by eDirectory™ and used by Identity Manager (IDM) to hold data for synchronization with a connected system. The IDV can be viewed narrowly as a private data store for IDM or more broadly as a metadirectory that holds enterprise-wide data. Data in the IDV is available to any protocol supported by eDirectory™, including NCP™, LDAP, and DSML.

Metadirectory Engine

The Metadirectory engine is the core server that implements the event management and policies of IDM. The engine runs on the Java Virtual Machine in eDirectory™.

Concensus SIF Integration Module

The Concensus SIF Integration Module is a SIF Agent which connects an IDM environment to a SIF integration environment allowing the SIF data to be utilized by non-SIF applications such as desktop login, email systems, or any other IDM integrated application. This integration is done via policies and parameters implemented in the SIF Integration Module (connector).

Driver Shim

The driver shim is the component of the driver which converts the XML documents used by IDM into native API calls for the connected system, and vice versa. The shim is responsible for implementing events originating in the IDV into the connected system and for creating events in IDM from changes detected in that system.

Remote Loader

A Remote Loader is a software service which allows the execution of a driver shim on a machine which does not have the Metadirectory engine on it. The Remote Loader is typically used when a requirement of the driver shim is not met by the IDM server. The Remote Loader and the IDM server communicate via a defined communications channel. The IDM server sends and receives XML documents over this channel. The shim, on the Remote Loader server, processes these documents and generates new ones, as needed, depending on the configuration. It is recommended that this channel use SSL encryption to protect sensitive data.

When using a Remote Loader, it is necessary for a communications channel to be available between the IDM server and the Remote Loader server as well as communications between the Remote Loader and the connected system.

For more information on the Remote Loader, as well as instructions on how to set up SSL encryption, please see the Remote Loader section in Novell’s Identity Manager Installation Guide.

Data Transfer Between Systems

IDM drivers support two data transfer channels between the IDV and the connected system, called the Publisher and Subscriber channels. The Publisher channel handles data and events from the connected system into the IDV. The Subscriber channel handles data and events from the IDV into the connected system.

The Concensus SIF Integration Module supports publisher events only from the ZIS into the IDV.

Figure 1: SIF Data Flow

Key Driver Features

Key driver features are listed in this section

Local Platforms

A local installation is an installation of the driver on the Metadirectory server. The Concensus SIF integration module is a native Java driver and can be installed on any supported IDM Metadirectory server, with the exception of NetWare (due to JVM version requirements).  In the event your Metadirectory is on NetWare you can utilize a remote loader to a Windows or Linux host.  Note that the remote loader on the host must be version 3.51 or higher.

Remote Platforms

The Concensus SIF integration module can use the IDM Remote Loader service to run on any supported IDM Remote Loader platform, except for NetWare (due to JVM version requirements).

Password Synchronization Support

The Concensus SIF integration does not synchronize passwords from or to a ZIS. It will allow for the setting of an initial password on created user objects in the IDV. This is managed through the connector Global Configuration Variables (GCVs), detailed later in this document.

Data Synchronization Support

The Concensus SIF integration module synchronizes User objects and Group objects from the SIF infrastructure into the IDV. This connector does not send any changes or information into the ZIS.

SIF Object Classes and Mapping

The SIF specification supports many object classes and attributes which represent various data elements common to student information systems. This connector supports a subset of these object classes and attributes. This section will detail the supported classes and attributes for this connector as well as their relationship to eDirectory objects in the default connector configuration.

Supported SIF Object Classes:

• RoomInfo
• SchoolCourseInfo
• SchoolInfo
• SectionInfo
• StaffPersonal
• StudentPersonal
• StudentSchoolEnrollment
• StudentSectionEnrollment

RoomInfo

The RoomInfo object represents a physical room in a school. In the default configuration, the connector maps objects of this type to eDirectory groups.

SchoolCourseInfo

The SchoolCourseInfo object represents a course taught in the school system. In the default configuration, the connector maps objects of this type to eDirectory groups. The courses are the general course, not a specific section of a course, which is defined by the SectionInfo object.

SchoolInfo

The SchoolInfo object represents a school in the district. In the default configuration, the connector maps objects of this type to eDirectory groups.

SectionInfo

The SectionInfo object represents a specific instance of a course. This object details the staff instructing the section, as well as the school and room in which this section will be taught. In the default configuration, the connector maps objects of this type to eDirectory groups.

StaffPersonal

The StaffPersonal object represents a staff member in the SIF environment. In the default configuration, the connector maps objects of this type to eDirectory users.

StudentPersonal

The StudentPersonal object represents a student in the SIF environment. In the default configuration, the connector maps objects of this type to eDirectory users.

StudentSchoolEnrollment

The StudentSchoolEnrollment object represents the relationship between a student and a school. When a student is enrolled in a particular school, SIF represents this enrollment in the StudentSchoolEnrollment object. In the default configuration, the connector does not represent StudentSchoolEnrollments as actual objects. The enrollment information is added to the relevant student user object as an auxiliary class with the enrollment’s attributes added to the student’s object.  The connector handles this via the ccSIF-UserEnhancement auxiliary class.

StudentSectionEnrollment

The StudentSectionEnrollment object represents the relationship between a student and a course section. When a student is enrolled in a particular section of a course, SIF represents this enrollment in the StudentSectionEnrollment object. In the default configuration, the connector does not represent StudentSectionEnrollments as actual objects. The enrollment information is added to the relevant student user object as an auxiliary class with the enrollment’s attributes added to the student’s object.  The connector handles this via the ccSIF-UserEnhancement auxiliary class.

Default Driver Configuration

The Concensus SIF integration module is shipped with a default configuration file called Concensus_SIF_v4-IDM3_6_1-V3.xml. When imported with Designer or iManager, this configuration file creates a driver with an initial, default, set of policies and rules to serve as a template for basic SIF integration. This initial configuration will likely need to be modified to match your specific environment and requirements.

Installing the Concensus SIF Integration Module

The Concensus SIF integration module is shipped with a default configuration file called Concensus_SIF_v4-IDM3_6_1-V3.xml. When imported with Designer or iManager, this configuration file creates a driver with an initial, default, set of policies and rules to serve as a template for basic SIF integration. This initial configuration will likely need to be modified to match your specific environment and requirements.

JVM Requirements

The driver shim requires JVM 1.5 or higher.

Where to Install the Concensus SIF Integration Module

The Concensus SIF integration module can run either locally as a module on the Metadirectory server or remotely under a Remote Loader service. The choice of which installation method to use is dependent on individual preference and JVM versions. See JVM requirements above for more details.

Local Installation

To perform a local installation, simply copy the shim and associated files, to the appropriate location (dependent on platform) and restart eDirectory.

Windows

To install on a Windows IDM server, copy the driver files to the eDirectory_home\lib directory. The default location for eDirectory_home is c:\Novell\NDS. Restart eDirectory to make the modules available to IDM.

Linux/UNIX

To install on a Linux/UNIX IDM server, copy the driver files to the dirxml/classes directory.

The default location is /opt/novell/eDirectory/lib/dirxml/classes.

Restart ndsd (eDirectory) to make the modules available to IDM.

Remote Installation

To install the driver on a Remote Loader, copy the driver files to the Remote Loader server. Create a Remote Loader configuration as per Novell’s IDM documentation.

It is recommended the Remote Loader be configured to use SSL. Consult Novell’s IDM documentation for instructions on setting up SSL communication between a driver and a Remote Loader.

Creating a New Driver

To create a new Concensus SIF integration module, you must import the default driver configuration. The default driver configuration file is called Concensus_SIF_v4-IDM3_6_1-V3.xml. Once this configuration is imported, using either Designer or iManager, the driver can be configured for your environment. Please see Novell’s IDM documentation on importing drivers via Designer or iManager.

During the import, the driver will prompt for a number of configuration parameters, detailed here. These parameters can be changed after import, if needed.

Configuring the Driver

This section will detail the Concensus SIF integration module configuration parameters and how to configure them for your environment.

Driver Properties

The driver properties contain various configuration parameters which control the basic operation of the driver.

Authentication

The SIF Specification does not require authentication between the agent (connector in this case) and the ZIS. No authentication parameters are required except those needed for remote loader configurations. Please see Novell’s IDM documentation for remote loader configuration assistance.

Driver Parameters

The driver parameters panel contains driver-specific configuration. The Concensus SIF connector contains additional driver configuration parameters in the Global Configuration Values section of the driver properties. The parameters in this section are not sufficient alone to properly configure the driver.

Driver Options

The following configuration options are available on the driver options panel:

The SIF Agent Name is the name used by the connector to register to the ZIS. This name must be unique on the ZIS for that zone. Please consult your ZIS documentation for details on registering agent names.

The connector will register with the ZIS, by default, with all support SIF Specification versions. These versions are 1.1, 1.5r1, 2.0r1, 2.1, 2.2, and 2.3. Some zone integration servers will provide objects at several different specification levels. The default configuration is recommended as it will allow the ZIS to deliver object data in the version appropriate to it. The connector will automatically handle objects of differing versions. If required, the connector can be configured to register only with specific versions, as shown below. Do this only if your ZIS requires it for proper functionality. Consult your ZIS documentation for more information.

Set each version to true to have the agent register with that version. Any combination of these versions can be selected.

The default SIF transport method is HTTP. If required, this can be changed to HTTPS to instruct the connector to use SSL transport when connecting to the ZIS.

When selecting https as the transport for the SIF driver you will be prompted for the filenames and locations for two keystore files:

Agent Keystore File is the keystore containing the certificate the agent and zis would use if the zis were configured for mutual authentication.

Agent Keystore Password is the password of the file specified for Agent Keystore File.

Truststore file is the keystore file that contains the certificate provided by the ZIS. 

Truststore password is the password for the Truststore file.

Require Authentication is set to false by default.  Set it to true if you would like to require the ZIS to authenticate when contacting the agent.

Please see the SSL configuration instructions later in this document to complete SSL configuration by generating the keystore files.  Setting this value alone will NOT allow the connector to use HTTPS, It is required that the SSL configuration steps detailed later in this document be performed before an HTTPS connection will succeed.

The default SIF messaging mode is push. In this configuration, the ZIS will send events and data to the connector when they become available. In the pull configuration, the connector will periodically connect to the ZIS to check for new SIF messages. The polling interval is set in the Publisher Options panel, documented below.

The SIF Authentication Level and SIF Encryption Level may be set as needed by the ZIS. Please consult your ZIS documentation and the SIF specification for more information on these parameters and how they are to be set. By default, both of these are set to 0, which is sufficient for most environments.

Subscriber Options

This connector has no subscriber configuration options. This panel is intentionally blank.

Publisher Options

There are two publisher options for the SIF connector: Polling Rate and Heartbeat.

The Polling rate (in seconds) controls how often the connector checks the ZIS for new messages. This parameter is only used when the connector is using the pull SIF messaging mode. The default is 60 seconds.

Publisher Heartbeat Interval controls how often heartbeat messages are sent through the publisher channel when there are no other events. Heartbeat messages are not used in this connector in the default configuration. 

Global Configuration Values (GCVs)

The Concensus SIF integration module uses GCVs listed here [revise].

Customization via GVCs

GVCs are used extensively by the Concensus SIF connector to control most aspects of driver functionality. Through the use of these GCVs, the connector can be customized to fit most deployment scenarios without the need to create or modify policies. This section will detail the GCVs and provide guidance on their use. This section is organized by the headings used in the GCV configuration panel.

Password Configuration

This connector does not provide password synchronization either from or to SIF. These parameters are not used by the connector.

Driver Configuration

The driver configuration GCVs provide additional configuration parameters not present in the Driver Configuration panels.

The Zone URL list contains the URLs used to connect to the Zone Integration Server(s). This connector is capable of connecting to multiple zones on a single ZIS or multiple Zone Integration Servers. For ease of configuration and to avoid potential collisions, it is not recommended that a single connector be used for multiple zone integration servers without fully understanding the data sources and implications.

The Zone URL takes the form of [transport]://[ZIS address]:[port]/[Zone]. Transport is either http or https. Please see the SSL configuration section for details on configuring SSL connectivity. Setting HTTPS in the Zone URL is NOT sufficient to enable the connector to use SSL with the ZIS. If your ZIS is on zis.concensus.com with the SIF interface on port 7080 and the zone named District, the Zone URL would be: http://zis.concensus.com:7080/District.

The three SIF Timeframe parameters, current, future, and historical, are used to determine which enrollments will be processed by the connector.

Current enrollments are those which are active for this term or academic period. In virtually all environments  this value should be set to true.

Future enrollments are those which are not yet active for the current term or academic period. An example of this type of enrollment would be a school enrollment for students advancing from elementary schools to middle schools at the start of the next school year. This enrollment may already be present in your student information system and set to the future timeframe. Setting this value to true would allow the connector to process these future enrollments. In most configurations, this value should be set to false.

Historical enrollments are those which are no longer active for the current term or academic period. An example of this type of enrollment would be a school enrollment for students who have advanced to a new school. The historic enrollment would contain their old school. Setting this to true would allow the connector to process these enrollments. In most configurations, this value should be set to false.

The Set uniqueID when setting user CN parameter will cause the driver to set the eDirectory Unique ID attribute to the same value as their login ID (CN). This can be useful for LDAP clients or other applications which leverage the Unique ID value. When this value is set to true, unique ID will be set (and updated, if a new login name is generated) by the connector. When false, the unique ID attribute will not be modified by the connector.

The list of school short names is used to provide a mapping between a school’s name in SIF and a short name typically used by staff at a school system. For example, Concensus High School might have a SIF name of Concensus High School, however it is usually referred to by its short name of CHS. If it is required that school objects (or perhaps student placement) be named or managed by the school short name, it will be necessary to populate this list with the desired short names.

This list maps the SIF GUID (Globally Unique IDentifier) for the school to the desired school short name. SIF GUIDs can be determined from your ZIS and are unique to that ZIS. Use the plus sign to add new entries to the list.

SIF Object Class to eDirectory Object Class Definitions

This GCV section is used to precisely define the relationship between SIF object classes and eDirectory objects as well as details around object naming, placement, and relationships.

Conceptually, an eDirectory user or group is composed of one or more SIF objects. For instance, a student user in the Identity Vault will consist of data from: StudentPersonal, StudentSchoolEnrollment, StudentCourseEnrollment, and possibly SchoolInfo, CourseInfo, and SectionInfo objects. The connector must necessarily relate multiple SIF classes to eDirectory objects in a many to one relationship. This relation is managed by the connector automatically via the object class definition GCVs. The default set of definitions provide an initial starting set of relationships and values, however it will be necessary to modify them to match the object naming and placement needs for your environment.

Unlike most IDM connectors, object naming and placement are fully controlled by the GCV values. In the majority of implementations, there is no need to modify the object naming or placement policies in the connector.

Pull down the illustrated option above to select the eDirectory object type to view and modify the configuration. Possible choices are: User, Group, and User-Enhancement. Each will be detailed below.

User Configuration

The user configuration section is used to control how the connector processes StudentPersonal and StaffPersonal SIF objects in the identity vault. A set of default configurations is provided which can be modified as needed.

The class definitions for StudentPersonal and StaffPersonal are the only two SIF classes supported for User mapping. Both of these user types use the same set of configuration parameters, however they can be set differently to meet the needs of the integration.

The StudentPersonal configuration is shown below.

The SIF Object Class Name specifies which SIF class this definition is to be used for. For the User class configuration, only StaffPersonal and StudentPersonal SIF classes may be selected.

The desired initial password for objects of this type can be specified with the initial password GCV. This initial password can be derived from an attribute of that object or can be a defined text string.  If Universal Password is configured for this environment, the initial password must be compliant with the effective UP policy or the driver will return an NMAS error when attempting to set the initial password. It is important to note that the values used in this step are only used during the creation of the user object. Therefore, they are based entirely off of the values in the student information system through SIF. The available attributes to be used for initial passwords are:

• None
  • No initial password (not recommended)
• Surname
  • This user’s last name
• Given Name
  • This user’s first name
• middleName
  • This user’s middle name
  • Be aware that this value may not exist for all users, it is not required by most student information systems
• Student ID
  • This is the SIS ID number for this user, in most cases this number is the one generated and used by the student information system
• EMail Address
  • The email address of this user, as known by the student information system
  • Be aware that this value may not exist for all users, it is not required by most student information systems
• Text
  • Enter the desired text to be used as the initial password
  • This will give all users of this type the same initial password

Object Name Configuration

The object name configuration section uses a composite method where the desired object name, CN, of the eDirectory object is built out of one or more components which are concatenated together. This structure is used for both users and groups. The available components differ dependent on the object type, but the method of construction remains the same.

The connector will automatically test and resolve any name collisions. Object names are globally unique for SIF objects. If, for example, object names are formed by the first initial plus the last name and two students would have the same name, jsmith, the second user created would have their username made unique by appending a three digit integer, jsmith001 in this case.

To view and configure object naming, set the “Display object name configuration section” value to true.

Below is the default name configuration for StudentPersonal user objects.

The “Rename these objects on attribute changes” value controls whether or not the connector will automatically rename objects of this type, StudentPersonal in this case, when any of the attributes used to form the object name change (from SIF). When set to true, the objects will be renamed to match the new attribute value (the name will be recalculated). When set to false, the object will not be renamed. The default value for this is false.

The option “Strip non alpha-numeric characters from the UserID” setting will control whether or not the connector will clean the final object name of any characters which are not letters or numbers. For example, any hyphens, periods, quotes, etc will be removed. As many of these characters are not legal characters in object names, it is recommended that this value be left to the default setting of true.

The next section of the name configuration consists of the name components. There may be one or more components which are concatenated to form the object name. There must be at least one for the connector to function. The components are concatenated in the order listed. The first component is the left-most portion of the object name, with each additional component appended on the right.

Name Component

Each name component consists of three values. These values define what text to use for the component (a defined text string or an attribute value), how many characters of that element to use for naming, and from which side of the element those characters should be pulled.

The above image shows one naming component for users.

The value to use for this naming component can be one of several values. This value list will vary dependent on whether this configuration is for users or groups. The acceptable values for users are:

• Surname
  • The user’s last name
• Given Name
  • The user’s first name
  • middleName
• The user’s middle name
  • Be aware that many users may not have a value for this attribute!
• Student ID
  • The SIS ID number for this user
  • This value is managed by the student information system
• On Time Graduation Year
  • The SIF On Time graduation year for this user
  • Dependent on your SIS, this value may contain the correct expected graduation year for this user
  • Only relevant for students
• Projected Graduation Year
  • The SIF projected graduation year for this user
  • Dependent on your SIS, this value may contain the correct expected graduation year for this user
  • Only relevant for students
• EMail Address
  • The email address of the user
  • Be aware that this attribute may not have a value for all users
• Text
  • A static text string for all objects of this type
  • Enter the text string desired

IMPORTANT NOTE: Use care when selecting attributes for name components. All name components MUST have a value for the object to be properly named. If one or more components for the object name are missing or do not have a value, the object will be named using its SIF GUID and placed in the appropriate Incomplete container, defined at driver import or in object placement. Consider adding a “default” value policy for that attribute to the connector and/or validate your SIF/SIS data prior to using a particular attribute as a name component.

Use name component length to determine what portion of the name component value will be used to generate the final username. The value of -1 is evaluated as “the entire string”. Use -1 if you wish to use all of the value. If a portion of the value is desired, such as the first letter of the first name, use a positive integer representing how many characters to use, 1 in the example mentioned. A value of 0 or any negative values other than -1 are not supported.

Use name component orientation to control from which side of the value the characters will be taken. This value has no impact if the length is set to -1. There are two values supported, From the Right and From the Left.

In general, leading and trailing spaces are removed from a component value prior to processing the length value. Spaces within a value, such as the surname Von Braun, are removed and replaced with underscore characters.

Name Component Examples

Example 1: You wish to use the first letter of the first name as a component of the object name. The image below illustrates the correct settings for this name component.

First name is presented as Given Name. The length is set to 1, so one character will be used. Finally, the character is pulled from the left side of the name, which, in this case, would represent the first initial.

Example 2: You wish to use the last two digits of the graduation year as part of the object name. The image below illustrates the correct settings for this name component.

In this example, the correct SIF attribute for a student’s graduation year is On Time Graduation Year, so that is the attribute selected. Only the last two digits are desired, so the length is 2. Finally, since it is the last two digits that are needed, the orientation is set to from the right.

Example 3: This example shows a complete name configuration for student objects. The naming scheme desired is First Initial + Last Name + YY where YY is the last two digits of their graduation year.

Recommendations

When developing object name configuration settings, it is recommended that the name configuration selections:

• Only choose attributes which will have values. A missing value or attribute will cause the object to be named based upon its SIF GUID and placed in the appropriate incomplete container
• Text components can be used to insert characters, if needed, such as hyphens
• Any object definition must have at least one name component
• The order, top to bottom, of the name components will be concatenated from left to right
• Group object naming is done identically to user object name. The only differences are only in the list of available name component attributes

Object Placement Configuration

The next section of an object definition is the object placement configuration. Object placement is done in a very similar fashion to object name configuration. Placement components are defined which, when concatenated together, will form the destination DN of the object in question. Just like with name configuration, it is important to ensure that any attributes used for placement have values for objects. In the event that one or more components needed for placement are missing, the object will be placed in the appropriate incomplete container.

The destination DN formed by the placement components is appended to the base DN for this object type to form the final destination DN. If this container does not exist, it will be automatically created by the driver. NOTE: the base DN will not be automatically created, it must already exist in the IDV.

The above image shows a sample placement configuration for student user objects.

This section of the object definition provides the following configuration elements:

-          Automatically move objects of this type

• This value, when set to true, will cause the connector to move objects of this type to a new container when any of the placement configuration attribute values change

-          Base container for objects

• This is a DN in the IDV which forms the root-most container for placement of objects of this type
• This container MUST exist in the IDV. The connector will not create it automatically.

-          Incomplete container

• This DN specifies the incomplete container for objects of this type
• The incomplete container is used in two cases
  • The object’s name cannot be constructed due to missing attribute values
  • The object’s placement cannot be constructed due to missing attribute values
• This container MUST exist in the IDV. The connector will not be created it automatically.

-          Object Placement Configuration

• This section contains the placement components for this object type.
• The destination DN is formed by starting with the base DN then appending each placement component from top to bottom
• The top-most component is the root-most portion of this section of the DN
• The bottom-most component is the leaf-most portion of the DN (with the exception of the object name, which is defined elsewhere)
• The connector will automatically add slashes to the DN components when they are assembled, there is no need to add them as text components

Object Placement Component

The object placement component elements are formed similarly to name components. The differences are:

-          The attributes to be selected are different

-          Only the entire string value can be used

The above image is an attribute placement component. Note that, unlike name components, there is no length or orientation available. The entire value is used.

The above image is a static text placement component.

For users, the following attributes are available:

-          School Short Name

• This attribute can only be used if the School Short Name list in the driver configuration GCV section is populated
• User to School Associations aren’t defined until all SIF elements are imported. Using this value will result in users initially being placed in the incomplete container until the school information is imported. At that time, the users will be moved to the correct container as School Short Name is defined.
• This attribute is not, by default, set on user objects. It is determined through their relationship with a school object (group).

-          School Name

• User to School Associations aren’t defined until all SIF elements are imported. Using this value will result in users initially being placed in the incomplete container until the school information is imported. At that time, the users will be moved to the correct container as School Short Name is defined.
• This attribute is not, by default, set on user objects. It is determined through their relationship with a school object (group).

-          Grade

• The user’s grade level from SIF
• Relevant only to students

-          On Time Graduation Year

• The SIF On Time graduation year for this user
• Dependent on your SIS, this value may contain the correct expected graduation year for this user
• Only relevant for students

-          Projected Graduation Year

• The SIF projected graduation year for this user
• Dependent on your SIS, this value may contain the correct expected graduation year for this user
• Only relevant for students

-          Home Room

• Like school name, this value is only instantiated after the remaining SIF objects which define the relationships between users and schools are imported

-          ccSIF-Class

• This is the SIF Class of the object, such as StudentPersonal or StaffPersonal

-          Text

• A static text string

Placement Examples

Example 1: It is desired that all student users be placed in Concensus\Students. The correct placement configuration for this would be:

The final DN for students would be:

Concensus\Students\ObjectName

Example 2: Students should be placed in Concensus\Students\GraduationYear. The proper configuration would be:

The final DN for a student graduating in 2015 would be:

Concensus\Students\2015\objectName

Recommendations

Like with name components, only choose attributes which will have values. Unless the architecture requires it, it is recommended to leave move on. Check with your ZIS and SIS to ensure that the value provided for any attribute desired is actually useful. It may be necessary to do data cleanup or transformation in the connector before it can be used for placement. Group placement works in exactly the same manner, with the only difference being the available attributes for forming the DN.

Attributes Representing group memberships

This section of the user object definition defines how the connector will determine group memberships for this user. The section is only to be used for managing group memberships with groups created and managed by the connector. This section cannot be used to manage group memberships for any other category of group in the IDV.

When a StudentPersonal or StaffPersonal object (enrollments as well)  is delivered to the connector, it may have one or more SIF GUID pointers to other SIF objects, such as schools, rooms, and course sections. The connector will search the IDV for the groups representing these objects and, if one is found, will make this user a member of that group.

The default values for students are:

-          ccSIF-HomeRoom

• The SIF GUID for the student’s home room. Will resolve to the room object group (if present) in the IDV. This value is stored in the IDV as a DN to the group representing the home room.

-          ccSIF-SchoolRecord

• The SIF GUID for the school to which this user is associated. Will resolve to the school group object (if present) in the IDV. This value is stored in the IDV as a DN to the group representing the school.

-          ccSIF-SectionRecord

• The SIF GUID for the course section to which this user is associated. There will likely be many of these, representing enrollments for students and instructors for staff. It is used to resolve the course section group in the IDV. This value is stored as a DN to the group object representing the section in the IDV.

In most deployments, it is recommended that these values remain as the default values.

There are no default group membership values for staff, however this can be customized to fit the solution requirements. 

Group Configuration

The Group configuration section covers the mapping of SIF classes to IDV groups. The SIF classes which are mapped to group objects, by default, are:

-          SchoolInfo

-          SchoolCourseInfo

-          RoomInfo

-          SectionInfo

In the default configuration, the connector will receive these classes from the SIS. It will use these objects, along with users and enrollments, to build interrelated memberships between schools, instructors, courses, sections, and students.

When fully migrated, students will be made members of groups representing:

-          The school to which they are enrolled

-          The course sections to which they are enrolled

-          The room which is designated as their home room

Sections will be members of the courses to which they belong.

Sections will be members of the rooms in which they are instructed.

Rooms will be members of the schools to which they belong.

This allows rights, policy, and other group-based services to be assigned to courses, course sections, rooms, and schools. This is useful for a number of applications such as ZENWorks and Novell Storage Manager.

The object naming and placement configuration sections for each of these group types are virtually identical to the user definitions. The only key difference for the group objects is the selection of attributes available to construct the names and placements.

Naming Component Options (object with which this can be used):

-          SIS ID (All)

• The SIS ID number of the object in question

-          School Record (RoomInfo and CourseInfo only)

• The group name  of the school to which this object is associated
• Can only be used once all objects are imported

-          School Name from SIS (SchoolInfo only)

• The school’s name in the SIS

-          School Short Name (SchoolInfo only)

• The school short name from the driver configuration parameters
• Can only be used if the School Short Name list has been populated

-          Course Code (CourseInfo only)

• The course code in the SIS

-          Course Title (CourseInfo only)

• The course title in the SIS

-          Course Record (SectionInfo only)

• The group name of the course to which this object is associated
• Can only be used once all objects are imported

-          Room Record (SectionInfo only)

• The group name of the room where this section is taught
• Can only be used once all objects are imported

-          Room Number (RoomInfo only)

• The room number for this room from the SIS

-          Text

• A static text string

The attributes available for placement components are:

-          SIF Class

• The SIF object class of this object

-          School Object Name in eDirectory

• The name of the school group in the IDV to which this object is affiliated

-          Text

• Static Text string

Group Owners can be set and managed by the connector. If desired, for each class definition, an attribute can selected to define the group owner. The group owner will be set to the user record identified by the attribute, if available.

The available group owner attributes are (classes):

-          Staff Record (RoomInfo only)

• The DN of the staff assigned to this room

-          Teacher Record (SectionInfo only)

• The DN of the staff (instructors) assigned to this section

The group definitions also support, like users, group membership attributes which will be used when the group is added or updated to manage the membership of this group to other groups. The default configurations are displayed below:

-          SchoolInfo

• no default mappings as school records are not made members of other groups.

-          SchoolCourseInfo

• ccSIF-SchoolRecord

-          RoomInfo

• ccSIF-SchoolRecord

-          SectionInfo

• ccSIF-SchoolCourseRecord
• ccSIF-RoomRecord

In most deployments, the default values are sufficient for group membership attributes.

User Enhancements

 User Enhancements are relationships which represent StudentSchoolEnrollment and StudentCourseEnrollment. Their purpose is to join students with their school and with their courses. The enrollments are processed depended on the configuration settings for the SIF timeframe. By default, only the current enrollments are processed.

Unlike users and groups, the object definitions for the user enhancements do not require naming or placement configurations. These objects are created as system objects in two containers within the SIF connector object in eDirectory. As they are used only for processing the relationships between students, courses, and schools, these objects are not directly useful as objects in eDirectory.

In general, the default configuration is sufficient for most deployments and these definitions should be modified only as needed to meet specific solution requirements.

The above image shows the default configuration for the StudentSchoolEnrollment definition.

The above image shows the default configuration for the StudentSectionEnrollment

There are three configuration values for these definitions:

-          SIF Object Class Name

• The class this definition refers to

-          Attribute that references the object to enhance

• This is the value that the connector will use to find the student record identified by the SIF GUID on this SIF class. Only change this if the basic schema for the connector has been modified and students and SIF GUIDs are represented differently
• Default value: ccSIF-StudentRecord

-          Attributes that should be added to the user

• When the referenced student is located, the enrollment can be used to add additional attribute values to the student
• Each entry in these lists represents data on the enrollment object which will be made an attribute of the student object when the association is made

The options are limited to the attributes which are available on each enrollment. Please see the SIF class definitions for more information

SSL Configuration

To create the Keystores we recommend using Portecle.  Other utilities work just as well, including the Java keystore utilities.  Portecle is available on Windows and Linux and is easy to use.

Portecle can be downloaded from:  http://sourceforge.net/projects/portecle/

Creating Agent.ks

1. Run Portecle
2. Select File | New Keystore
3. In the New Keystore Type dialog select JKS and press Okay.
4. Select Tools | Generate Key Pair
5. In the Generate Key Pair dialog
   1. Select RSA for the Key Algorithm
   2. Enter 1024 for the Key Size.  
   3. Press OK.
6. Fill out the Generate Certificate Dialog identifying this certificate as being published by this your server.  None of the fields is required individually, but at least one of them must have a value.
7. Be sure to set the certificate validity to the number of days desired.  Simply adding a 0 to the default will increase the time before expiration from 1 year to 10 years.  An example is shown below.  Press OK.
8. In the Certificate Name dialog give the certificate a name.  This certificate will be displayed in portecle using this name.  Press OK.
9. In the Create Key Pair Entry Password dialog specify the password for this certificate.  Select File | Save Keystore. 
   1. Specify the password for this keystore.  This will be the value that should be entered in the driver configuration for the Agent Keystore Password.
   2. Select the location and filename for this keystore.  We recommend agent.ks for this keystore.

.

Creating Trusted.ks

1. Obtain the ZIS certificate from the ZIS server by exporting it.  Consult your ZIS documentation to learn how to do this.
2. Run Portecle
3. Select File | New Keystore
4. In the New Keystore Type dialog select JKS and press Okay.
5. Select Tools | Import Trusted Certificate
   1. Browse to the exported certificate and select it.
   2. Click Import
   3. If a warning dialog is displayed click OK
   4. Select OK on the Certificate Details dialog
   5. Accept the certificate as trusted.
   6. Change the alias if you wish.
6. Select File | Save Keystore
   1. Specify a password for the keystore.  This will be the value that should be entered in the driver configuration for Truststore Password.
   2. Select the location and filename for the keystore. We recomment trusted.ks for this keystore.
      
      

Appendix A: Schema

The Concensus SIF integration module includes new schema for the IDV eDirectory instance to support some of the extended functionality of the connector. The SIF schema is provided with the connector as a separate .sch file which will need to be imported into the tree hosting the connector prior to deployment.

The Schema consists of three classes and many attributes, detailed below.

Custom Attributes

 Goto Top of Page