How to Set Up OAuth 2.0 Support in Vidispine
Applies to
OAuth 2.0 is a technique for enabling authorization of users without having to deal with the secrets of the user. It also allows you to create truly single sign-on solutions.
Summary
Vidispine supports OAuth 2.0 from version 4.4, to make integrations with your systems easier, using, for example, Azure AD or Google API. This article explains how to configure Vidispine with OAuth 2.0.
Pre-requisites and system requirements
verified installation of Vidispine API 4.4 or later
basic understanding to configure Vidispine using Postman or similar
It might be a good idea to browse the OAuth 2.0 standard first.
Background.
OAuth works by using the redirect functionality in the HTTP protocol. This means that neither your application or the Vidispine API will ever see the user's password. Instead, the user will log in directly to the Authorization Server (e.g. Azure AD, or Google API). Once logged in, the user's browser will receive an authorization code and a redirect request back to your application. That authorization code is used to get a resource token (JWT). The resource token is then sent to Vidispine for all API calls using Authorization: Bearer HTTP header, instead of Basic authentication.
Authorization flow
![](../../__attachments/2719220871/Authorisation%20flow.png?inst-v=c263b046-0db3-4e5e-9b28-d475c958150e)
Token Validation
When Vidispine receives the token, it has to be validated. There are today three ways of doing this. If you want to authenticate against a service that provides an API to validation (e.g. Google API), you just have to enter the endpoint information in your shiro.ini
. As usual, apidoc has the details. In order to reduce the load on the authorization service (and provide you with a faster API), the information is cached in Vidispine.
If you use Azure AD, you can use Federation Metadata instead. Here, Vidispine will download a set of X.509 certificates in a separate process from the Authorization source. This is done in the background, so it will not cause any delay to the API. Also, HTTPS is used to secure the transfer.
A third alternative is to provide Vidispine with a set of static X.509 certificates directly in the shiro.ini file.
Mapping Vidispine users
If the JWT contains a unique_name
object, that is used as the username. Otherwise, if the validation endpoint returns a JSON with a unique_name
, that is used. If the user does not exist in Vidispine, a simple authentication error response is given, with HTTP header Reason: User was not found: {username}
. Your application can then decide what to do, e.g. simply add the user in Vidispine and attach it to a default group.
Related articles
Related articles
Install and use Python SDK with Vidispine API
How to build media applications with VidiCore Development Toolkit (PT2)
How to build media applications with VidiCore Development Toolkit (PT3)
How to build media applications with VidiCore Development Toolkit (PT4)
How to test LDAP connection OpenLDAP Docker Image
Configuring Vidispine API using CURL
Using Azur Blob Storage in VidiCore
How to Set Up OAuth 2.0 Support in Vidispine
How to connect Glacier Storage to Vidispine API-NEW
How to connect Glacier Storage to Vidispine