Proposals/Isolated Institutions

Preamble

Mahara is designed to allow many "institutions" all share the same instance, which allows their pupils to interact together across institution boundaries. This can be a very useful feature, not least because it allows several institutions to share the cost of running a Mahara instance. But some schools still wish to maintain the "walled garden" effect of not allowing their students to see others outside their institution - or potentially allowing only some of the institutions in the system to interact with their students. (Taken from http://wiki.mahara.org/Roadmap/School_Usage)

Implementation

"Isolated Institutions" feature makes possible to control interaction between members of different institutions. Whether the institution is in an isolated institution or not is controlled by additional setting at "Administer Institution" page. If the "Isolated Institutions" setting is set to “Yes”, users are allowed to interact with members of the same institution only. Access to users outside the isolated institution is also possible for users in a "Isolated Institutions" institution. The trust relationship control mechanism is designed for that purpose. Trust relationships are controlled by an "Institution Administrator" and "Site Administrator" only. On the "Institution Administrator" level, trust relationships are controlled on request/approve basis: An Institution administrator is able to list existing institutions and send a trust request to those institutions they want to create trust relationships with, once a request is sent and approved by aimed institution's admin, a reciprocal trust relationship between institutions is established (pretty similar to friendship maintaining mechanism that already exists in Mahara). On the "Site Administrator" level trust relationships are controlled through the "Institution Trust Relationships" interface that allows an administrator to maintain reciprocal trust relationships between any institutions directly as well as allowing replies to trust relationships request on behalf of the admin of any institution.

Therefore, members of an "Isolated Institutions" institution are able to communicate with members within their institution and members of institutions outside the their isolated institution with which trust relationships have been established (by an Institution or Site Administrator). When a new institution is created, by default institutions have"Isolated Institutions" set to "No", i.e. members of the particular institution can interact twith any users in the system except members of any "Isolated Institutions" institutions. Any user that does not belong to any institution will only be able to communicate with similar users and members of institutions with "Isolated Institutions" setting set to “No”.

To illustrate what is said above, say a member of an institution is finding friends using the Groups->Find friends menu. Depending on the "Isolated Institutions" option setting for the institution, the following users will be listed:

Members of "Isolated Institutions" institution are able to find:

• users in all institutions with a trust relationship
• users in own institution

Members of "No isolated institution"(default) institution are able to find:

• users in all default institutions (which includes own institution)
• users in all institutions with explicit trust relationships

Members of "no institution" are able to find:

• users in all default institutions

It is important to understand that the "Isolated Institutions" concept relies on a trust relationship control mechanism, but it does not depend on it, i.e. an institution may have several trust relations, but it should not necessary be in the "Isolated Institutions" (have "Isolated Institutions" setting on). This allows users of an "Isolated Institutions" institution to communicate with those in an institution without a walled garden if a trust relationship is defined.

Trust Relationships Control on Institution Admin Level

For the institution admin level, Isolated Institution Trust Relationships are controlled using two additional sub-menu items on the “Isolated Institution Control” page: "Institutions we trust" and "Find Institution". Both of these pages allow the institution admin to choose the institutions to act on behalf of, which is relevant when the user can administer more than one institution. The "Find Institution" page shows all available institutions, provides direct links to actions and provides searching and pagination features for convenience. The "Institutions we trust" page shows only institutions with which trust relationships are already established, and allows the admin to filter the list based on trust relationship status (pending or current).

The following actions are possible depending on the current relations:

• Sending trust request – if there is no trust relationship with destination institution.
• Denying trust request – if incoming trust relationship request is pending.
• Approving trust request - if incoming trust relationship request is pending.
• Breaking trust relationships – if a trust relationship already exists

As a result of each action, institution admins of the affected institutions will be notified.
If the chosen institution is one the user can administer, the interface for explicit trust relationships control between all "own" institutions is shown (similar to one that is used by site administrator but the number of institutions is limited to those each user is administrator of).

Trust Relationships Control on Site Admin Level

For the site admin, Isolated Institutions Trust Relationships are controlled explicitly. A search block and pagination has been added to the institutions page in order to facilitate institution management. The "Trustees" column shows the number of current trustees and it is also the link to “View Institution” page for controlling trust relationships between corresponding institution and any other.  As was mentioned above, the “View Institution” page shows elements based on user type and institution for administering permissions. For site admin it shows an interface for explicit trust relationships control by default (institutions mode), and it can also show an interface for responding to trust proposals addressed to the chosen institution (requesters mode). The desired interface is controlled by the “mode” dropdown menu. In the case of changing trust relationships or replying to a trust request, all affected institutions (institution admins) will be notified.

Communication Paths

The isolated institutions framework is applied to the following communication paths:

• User to user – the access check is based on whether a user can access the institution which the destination user belongs to. If the destination user is a member of multiple institutions, access is granted if user can access at least one of destination user’s institutions. If the destination user is already a friend, access is permitted.
• User to group – the access check is based on whether the user can access the institution which the destination group admins belong to. If destination group has several admins or any admin is a member of multiple institutions, access is granted if the user can access at least one of institutions which the destination group admins belong to. If the user is a member of destination group, access is permitted.
• User to institution - the access check is based on whether user can access the destination institution. If a user is a member of the destination institution, access is permitted.

A variety of checks are performed based on the above framework, for example the check if a user can access view or artefact uses this approach (each page or artifact can belong to either user, group or institution).

If trust relationships between institutions have been broken, current group membership in an “enemy” group as well as friendships and view access permissions will not be broken. If this is required, one should use “Break external relationships” group of buttons in institution settings. As a result of this action corresponding permissions will be broken and all affected users will be notified by email. Institution admins will receive a digest email with a list of all users that were affected.

Proposed features

User exemption from isolation

As proposed in the forum, there should be a feature that would allow to exempt some users within the institution from isolation. Users who are exempted will have communication permissions similar to as if they were in "default" institution, while other institution members will stay isolated.

Thus, using the example with User Find above, users exempted from isolation will be able to find:

• users in all default institutions (which includes own institution)
• users in all institutions with trust relationships

There should be a flexibility of assigning exemption to an individual or a number of users upon account creation, via manual account changes and in bulk for existing user accounts. Also administrator should be easily able to see which users are isolated within the institution. The feature should work correctly when the user is a member of multiple institutions (in which case the least restrictive membership or tag wins).

This feature can be achieved through the user tags in two different ways:

• Exception is determined by a system tag 'exempt isolation' (like lastinistitution system tag we already have). The tag can be listed among custom tags and assigned to particular user or the list of users using the user tagging tools (not yet in Mahara), also can be applied to user on user creation (single or bulk). If institution changes its isolation setting to default, the tag is removed from all accounts.

• Exception is determined by any custom tag that is labelled as 'exempt isolation' on the special page. This solution is more flexible than previous as it allows to make any tag "exempt" from isolation, so admin can make existing "tagged" users isolated or not. Similarly to previous solution, it requires a tool for tagging multiple users and functionality to apply tags on user creation. If institution changes its isolation setting to default, the isolation labelling to the tags is removed, but tags remain assigned to the users.

Either solution requires additional interfaces for site or institution admins to control the isolation exemption users and tagging.

Technical Details

Database

The "Isolated Institutions" option in "Administer Institution" interface requires a corresponding flag in 'institution' table. Trust relationships control requires two extra tables for its functioning: "institution_trust" is a mapping table which is used for storing current trust relationships between institutions. "institution_trust_request" is used for registering trust requests initiated by the "requestor" institution and addressed to the "owner" institution, it also stores the message that has been specified at the time a trust request had been sent.

Implementation

All checks related to a single item are performed using following methods in the user class (auth/user.php):can_access_group, can_access_user, can_access_institution For multi-item output, walled garden checks are usually embedded in the SQL queries for scalability reasons (see for details search_user, search_group functions in search/internal/lib.php).

Useful links

Forum discussions (ordered chronologically)

• Comments on walled garden feature proposal
• How isolated / flexible will Isolated Institutions be?
• Richard Mansfield's comments on the 1.2 patch

Presentations:

• Mahara Isolated Institution - presentation on MaharaUK11

Source code:

• Patched 1.2 branch