Auto provision memberships/collections with SSO

MENU Introduction

Institutions can expose membership information to us via their SSO integrations.

In all cases, once you’ve configured your IdP to send this information to MediaCore, some work will be required from the MediaCore engineers to enable it to be used. This work can be minimal, simply enabling the default group mapping, which is included in the one-time setup costs for SSO. However, for a more robust integration, we recommend a customized mapping structure, some of which are described below.
 
 
Mechanism for releasing information

With OneLogin this is via the “MemberOf” attribute (usually passed through from Active Directory). Multiple memberships should be encoded as a single semicolon-separated value.

With PingFederate this is via the “MemberOf” attribute (usually passed through from Active Directory). Multiple memberships should be encoded as a single semicolon-separated value.

With PingOne this is via the “member_of” attribute (usually passed through from Active Directory). Multiple memberships may be encoded as a single semicolon-separated value, or may be exposed to MediaCore as an actual JSON list.

With Google Apps, this is done by giving MediaCore access to read each user’s Group and Organizational Unit information.

With Shibboleth this is via the “eduPersonEntitlement” attributes. Each entitlement value must conform to the urn:oasis:names:tc:SAML:2.0:attrname-format:basic format described in section 8.2.3 of the “saml-core-2.0-os” specification (i.e. it must start with a letter and contain letters, numbers, the characters : . - and _). There may be many eduPersonEntitlements presented in a single SAML assertion.
 
 
Example Group Descriptions

OneLogin, PingFederate, PingOne

For OneLogin, PingFederate, and PingOne, MediaCore will expect the provided memberships to follow ActiveDirectory’s CN,OU,DC format. For example two memberships might be encoded as:

CN=Mediacore-Pupils,OU=Mediacore-Groups,DC=downdata,DC=co,DC=uk;
CN=Mediacore-Staff,OU=Mediacore-Groups,DC=downdata,DC=co,DC=uk


Default Behaviour

MediaCore will use this information to create (and place the user in) two groups:
  • “Mediacore-Pupils”
  • “Mediacore-Staff”

Google Apps

For Google Apps authentication, you might have a user inside the a group named “CSC 101” and inside the Organizational Unit named “Students”. In turn, the “CSC 101” group might be a subgroup of “Computer Science” and the OU “Students” may be a sub-OU of the OU named “West Campus”.

Default Behaviour

MediaCore will use this information to create (and place the user in) three groups:
  • “CSC 101”
  • “Computer Science”
  • “West Campus/Students Unit”

Shibboleth

For Shibboleth, MediaCore can accept multiple values for eduPersonEntitlement.

Default Behaviour

For each value of eduPersonEntitlement, MediaCore will create (and place the user in) a group by the same name.
 
 
Custom Membership Provisioning

In the above section, we’ve seen that the default behaviour for each integration is for the provided Groups, MemberOf, or eduPersonEntitlement values to be mapped to MediaCore Groups.

Other mappings are possible, however, with a bit of planning and some custom integration work from MediaCore’s developers.

Here’s an example of an integration for one of our Universities:

Example

We worked with the institution to determine what roles and collection structure they wanted to organize their course content. Some video content had to be restricted to members of a specific course section, some content could be shared between different sections of the same course.

They also wanted to create new collections on an ad-hoc basis and easily share them with different groups of users on campus. These groups had to have fine granularity, as different types of users would be given different levels of access.

Within each course section, a user could have multiple roles (staff, student, or faculty) and each role would come with its own permissions.

Because there were a large number of courses, we determined that each course should also be categorized by its year and semester.

The institution was able to encode all the necessary information into Shibboleth’s eduPersonEntitlement attributes (though it could be done similarly for MemberOf, etc), like so:

staff-1-students-0-faculty-0-year-2014-term-01-class-CSC100-section-02 staff-1-students-0-faculty-0-year-2014-term-01-class-CSC222-section-B

MediaCore’s developers added some custom logic to that customer’s MediaCore site so that, when a user logs in, it can read this information and create a combination of groups, roles, and memberships.

Groups:
  • staff (*)
  • students
  • faculty
  • 201401 - CSC100 (*)
  • 201401 - CSC100 - 02 (*)
  • 201401 - CSC100 - 02 - staff (*)
  • 201401 - CSC100 - 02 - students
  • 201401 - CSC100 - 02 - faculty
  • 201401 - CSC222 (*)
  • 201401 - CSC222 - B (*)
  • 201401 CSC222 - B - staff (*)
  • 201401 - CSC222 - B - students
  • 201401 - CSC222 - B - faculty
Based on the given eduPersonEntitlement values, MediaCore would create all of the above groups and then add the user to the groups marked with an asterisk.

In this case, you can see it is because the user is “staff”, but not a “student” or “faculty”.

Roles:
  • staff
  • students
  • faculty
The permissions associated with each of these roles can be managed by the institution’s MediaCore administrators.

Collections:
  • 201401 Courses
    ​           201401 - CSC 100
                       201401 - CSC 100 - 02
  • 201401 - CSC 222
               201401 - CSC 222 - B

Content intended to be shared with all CSC 100 classes can be placed in the “201401 - CSC 100” collection. Content specific to individual course sections can be placed in the relevant subcollection (e.g. “201401 - CSC 100 - 02”).

Memberships:

LAST UPDATED:

Oct. 31, 2014