SIF-based Identity Management Foundation

Overview

Visual Software's Identity Management Solution is a scalable, enterprise-class solution built using existing SIF standards and a combination of two of our existing products: Envoy (the SIF Virtual Zone Manager) and ZIAgent Runtime Edition with two rule sets: one for Directory Management and another for Shibboleth.

The general purpose of a schools-based Identity Management system is to provide one or more ID numbers or names that are unique to a learner, teacher or parent. A person may get more than one ID if the system assigns him or her both a Shibboleth ID and an email account name, for example. The thing that the system must not do is to assign more than one ID of the same type to the same person - and this is the difficult part.

Merging Duplicates

Many people or things represented by SIF objects may be represented in more than one Student Information System (SIS) (or UK Management Information System (MIS)). For example, a learner may attend more than one school during a given day and he or she is tracked in two different systems. Parents may have children in different schools. Teachers may teach in more than one school. School buses may be shared between multiple schools.

There are two logical options:

1. Have all the systems align the SIF identifiers as they're assigned. Although this is possible, this isn't very practical especially since objects are allocated so frequently (such as attendance/assessment objects) and it would require that remotely connected machines be continually conferring on possible duplicates.
2. Have an external application match objects from the different systems according to rules that have been pre-defined to find the "like objects" and virtualize zones as needed.

Our solution implements the second option. Using Envoy as the foundation, we install ZIAgent with one or more rule sets registered in a zone that includes all schools. These rule sets correspond to the identities being managed (Shibboleth, Active Directory, etc.).

The Envoy component performs the object matching for all SIF objects for the top level zone containing these three SIF agents (and all of the other zones in the implementation), presenting these three SIF agents with a simplified set of SIF objects: one LearnerPersonal object per learner, one SchoolInfo per school, etc..

The Identity Management SIF agent keeps track of each object and applies the rules for identifiers for that type of object, making sure not to assign two identifiers to the same object, nor the same identifier to two different objects. When the ID has been assigned, it publishes the SIF "Identity" object if appropriate.

The Shibboleth SIF agent manages the internal tables required by the Shibboleth software using the information it received both from the schools (in the form of LearnerPersonal, WorkforcePersonal, etc. objects) and from the Identity object that was published by the Identity Management SIF agent. For more information about Shibboleth, see Shibboleth.

If part of the deployment, the Active Directory SIF Agent has a great deal of flexibility. It can either simply assign IDs or can assign IDs as well as create and manage the accounts. The SIF agent can support implementations where the forest is centralized at the top level, is located at the school or anywhere in between - it depends on how it is configured.

What About Relationships?

What about parent-child relationships?  How do you manage who can see what information in your portal application?  Do you use something like an address or a phone number?  What about divorce combinations like blended families or joint custody where one parent may only see information for only some of the children at a particular address?

This technique has proven very useful whenever there has been a need for assigning permissions, for example, that correspond to access rights for learner records.  These might be used to control access to portal pages or sites.  What we do in ZIAD is the following:

1. Each learner is assigned a separate AD account
2. Each learner has an AD group created – we refer to this group as the Learner Personal AD Group
3. The learner is assigned as a member of this group
4. Each contact (parent) has an individual AD account created for him or her
5. If that parent has access rights to the learner’s records, he or she is made a member of the Learner Personal AD Group
6. The Learner Personal AD Group is used for access to the portal site containing the learner’s records

By following these rules, these benefits are seen:

• By looking at the Learner Personal AD Group membership, you can see everyone who has access to student records.
• If the parents get divorced and one gets remarried, then after the remarriage the step-parents do not automatically gain access to the student records.  Only the parent accounts have access to the learner records.
• If a step-parent is to be added to the list of people who should have access to these records, he or she can be added but this action must be done as a manual activity.  This activity would normally follow an explicit request by someone and the event to add this person would be audited.
• Likewise, if one of the parents no longer has access to a child's records after a divorce, that access must explicitly be removed - the default is that the natural parents retain rights to the records.
• In the US, if you look to see to which groups a contact belongs, you can get a list of the learners for whom he or she has record access rights (in the UK, the data model is different and doesn’t it have this issue).

A Sturdy Foundation

We refer to the Visual Software Identity Management solution as a "foundation" for a few reasons. 

1. Although it provides comprehensive Identity Management features, at the same time it provides a substantial infrastructure for the organization implementing it. One that can provide a flexible, secure and scalable framework that can reduce costs and improve performance for every school in the organization. For more information on the backbone of the foundation, see Envoy.
2. Since the Identity Management component is separate and uses the Identity SIF object (in the UK or in Australia; the "Authentication" SIF object would be used in the US) to convey this information to other applications, it can be used to feed other systems, such as Microsoft Forefront Identity Manager for higher level management functions.
3. It can attach to zones in other regions. Since Envoy is a SIF agent, designed to work with any Zone Integration Server and any MIS (SIS), it can be attached either to zones in the local school organization or from an neighboring county, for example. This would be important, if a school that was located in your region was fed from schools in neighboring regions.
4. It can be combined with the Veracity product to provide a framework for data quality management and vertical reporting.

To learn more, give us a call at the number below or ask us to have someone contact you.