A curricular system of reference needs to be created that will be able to access user, group and role information from student information services (SIS) as well as administrative systems and then define authorizations for those users, groups and roles as well as its own groups and roles.  This system of reference needs then to be able to provide access to this authentication and authorization data to other supported web applications and record how other applications use this information.

Connectors will need to be created for every supported web application that “loosely couple” these applications.  This connector code should be as lightweight and as encapsulated as possible so as minimize the need for updating and simplify application life-cycle management.  As well, the methods used should following standards such as the Open Knowledge Initiative (O.K.I.) open service interface definitions (OSIDs).  The functionality offered by these connectors will depend on the granularity of content/resource/module linking and authorization mapping that can be achieved and is needed between the connected systems.

This is the simplest type of connector which essentially passes authentication information from one system to another and then uses this information to authenticate the user into the system that has received this information.  To accomplish this, the connector will need to check if the receiving system has a user that corresponds to the user whose authentication information it has received and if not, create a record of that user.

This connector builds upon the Authentication connector.  This connector needs to map authorizations in one system to those of another.  Thus a system’s connector must pass authorization information to another system’s corresponding connector and that authentication information should be mapped to corresponding authorizations in the receiving system.

This connector builds upon the Authorization connector to include “node” information.  Node here can refer to a particular “site” in a content management system (CMS), a course in a learning management system (LMS) or a collection in a digital asset management system (DAM).  Node can also refer to a “content block” or “micro-content” or asset, resource, blog entry and so on.  To this end, one system’s node connector must passes information about one of its node, some form of identification (ID), and/or the node in the receiving system that is to be connected, along with information about the currently authenticated user and their authorizations.  Based on this information, the receiving system then determines the type of access the authenticated user has rights to.  If no receiving system node is specified and the authenticated user has the appropriate authorizations, then a new node in the receiving system is created.  If nodes for both sending and receiving systems are specified, then links between nodes should be established.
Node connectors can be of two types:

1. Linked nodes:
Nodes in connected systems that are linked simply include hyperlinks with URL’s that pass authentication, authorization and node information from one system to another.

2. Embedded nodes:
Embedded nodes are nodes in one system that embed the “content” of a node from another system.

This connector builds upon the Node connector to include information about a node’s sub-nodes as defined by a hierarchy.  This connector then maps hierarchy across systems so that the sub-nodes in one system can be displayed appropriately in a node of another system.  The Hierarchy connector is only needed for nodes from one system that are embedded in another.

This connector builds upon the Node connector to include information about other nodes associated to the given node as defined by some sort of cataloguing or tagging system.  This connector then maps associations across systems so that the associated nodes (e.g. tags) in one system can be displayed appropriately in a node of another system.  The Association connector is only needed for nodes from one system that are embedded in another.

This connector builds upon the Node connector and is by far the most complex connector.  Module here refers to an encapsulated set of methods in a web application that conform to that application’s API.  There are a number of ways this type of connectivity can be accomplished.  One way is simply to pass authentication, authorization and node information to a receiving system (using above connectors) as well as any module information that may be needed and then load the receiving application into an IFrame (i.e. inline frame).  Alternatively, the Module connector can pass specific requests from one system to another with the connectors mapping these requests to specific module methods.  The sending system must then have methods for rendering what is requested in a way that preserves the modules functionality.  It is possible that a module connector only requests a subset of a modules functionality…