SWITCHcast External Access Authority – Overview

Do you need fine-grained access rights to your videos?

During the channel setup, you can choose the broadness of your audience. The available access rights are public, SWITCHaai federation, same organization andprivate.

In some cases, these settings are not fine-grained enough. You may want to restrict the spectator access to a small group of users, e.g. the students of a class. In most cases, these groups are already defined in another context than SWITCHcast, e.g. your Learning Management System (LMS). Therefore, SWITCHcast does not intend to implement the group access once again (and thus replicate all the groups). Instead, there is a simple interface to your web service (e.g. LMS), where you can check the access rights according to your particular rule set. The corresponding access rights setting in the channel will then be External Authority.

Checklist

What you need to set up an External Authority for SWITCHcast:

  • An SSL certificate (typically the one of your LMS web server)
  • Programmer resources
  • A rule set for the effective access rights, e.g. user groups inside the LMS
  • A generic service URL, where your external authority can be reached

Preface

Each time a clip is delivered by SWITCHcast, its access rights are checked beforehand. The spectator must meet the conditions defined in the channel settings. Public clips are immediately delivered, AAI protected clips require a login on the SWITCHcast server. But for clips with External Authority protection, SWITCHcast cannot decide whether the access is granted or not. The user is thus redirected to the service URLfor the external authority. If the access check is passed successfully there, the user is redirected back to SWITCHcast with a decrypted token as proof that the clip can be safely delivered.

Flow chart

 (click to enlarge)

Security mechanism

SWITCHcast acts as gatekeeper to the requested clip. For channels with external authority protection, SWITCHcast cannot decide whether to grant access or not. Thus, a trusted proof is needed to attest that the spectator is allowed to watch a clip.

The applied security concept is based on public key cryptography. The following steps are performed:

  • The user request a clip. Initially, SWITCHcast denies the access to the clip
  • SWITCHcast creates a (random) plain token and stores it locally
  • Together with channel ID and clip ID, the plain token is encrypted using the public key of the external authority. Only the owner of the corresponding private key, i.e. the external authority web server, can now decrypt the token
  • The user is redirected to the configured service URL, the encrypted token is passed as parameter
  • The external authority decrypts the encrypted token into channel ID, clip ID andplain token
  • Based on custom access rules, the external authority decides whether the user has access to the given clip
  • If the access is granted, the user is redirected back to SWITCHcast, with theplain token as proof
  • Finally, SWITCHcast compares the plain token with the locally stored one. In case of a match, the clip is delivered and the current access token is invalidated to prevent abuse by re-using the same token repeatedly

Sample code

To get started, a (simplified) example implementation in PHP is available:

FAQ

What kind of permission checks are possible?

You can apply arbitrary rules for the access permission check. SWITCHcast will pass the attributes channel ID and clip ID. Additionally, you can use all information from the user session in the LMS.

Example rule sets:

  • Shibboleth attribute based rules (for SWITCHaai users)
  • Course membership in the Learning Management System
  • Teacher/Administrator rights in the Learning Management System
  • Username/Password
  • IP-range check (e.g. Intranet or VPN only)
  • Time-based rules (e.g. accessible for just 1 month after publication)
  • Other rules

Note: Any combination of the choices above is possible.

Is the protection broken if somebody publishes a URL that includes the plain (decrypted) access token?

No. Each request requires a different token. After a successful clip delivery, the token is invalidated and cannot be used again. Users with an invalid token are automatically redirected to the External Authority once again, this time with a new token to be decrypted.

Can channels with External Authority be subscribed as Podcast in iTunes?

No. iTunes does not support HTTP redirection for media files.