Authorization Server

1. Principles

The SSP Authorization Server allows the operator to provision data in SSP so that it can authorize license requests autonomously, i.e., without calling back the operator's back-end. This decouples the two systems (SSP and Operator's back-end) and isolates the latter from scalability requirements to cope with peaks of license requests.

Data provisioned in the Authorization Server includes the accounts (an account represents a household, i.e., a paying subscriber), devices and rights (i.e., set of products entitled to the user during a given time frame).

The SSP Authorization Server can be used in both IPTV and OTT. This enables the operator to define provisioning data once and then re-use it across different use cases. Ex, grant rights across IPTV and OTT.

2. Services

The SSP Authorization Server is comprised of the following services:

2.1. ADM Account & Device Manager

ADM exposes an API to provision accounts and devices in SSP.

2.1.1. Account Management

Active users are modeled as Accounts in SSP, where an account represents a billable user that may access the service from multiple devices. By default, all devices in the account will share the same rights unless specified otherwise.

SSP allows the operator to:

• Create accounts

• Manage account status:

  • ACTIVE accounts (default status) can access the service

  • SUSPENDED accounts will not get licenses granted. This status can be restored back to ACTIVE.

  • CANCELED accounts will not get licenses anymore. This is a final status when a user completely unsubscribes from the service.

• Enable / disable the account for PVR service

• Assign the account to one or more blackout areas (see blackout support here).

2.1.2. Device Management

Devices accessing the service shall be provisioned in the SSP platform. The API allows the operator to:

• Create devices for a given account

• Manage device status

  • ENABLED devices (default status) can receive licenses from SSP head-end

  • DISABLED devices will not get licenses granted. This status can be restored back to ENABLED.

• Re-home devices under a different account.

The SSP Account And Device Management API spec is based on web standards (HTTP/ReST/JSON). The spec is available here.

2.2. RMG Rights Manager

Operators shall provision the rights for each account in the SSP platform. Rights are modeled as entitlements in SSP, where an entitlement represents the right of a given account to access the contents granted through a given product during a time window.

The API allows the operator to:

• Create entitlements including:

  • Identifier of the account recipient of the right

  • Identifier of the product being granted (ex, a subscription or a PPV product)

  • Validity of the rights (start & end time stamps)

  • (Optional) Identifier of the device belonging to the account above that will be recipient of the right

• Manage entitlement status

  • SUBSCRIBED entitlement (default status) represents an active right

  • UNSUBSCRIBED entitlement means the right is not active, i.e., it will not be used for license generation. This status can be restored back to SUBSCRIBED

A right is active if the entitlement is in SUBSCRIBED status and within its validity time window.

The operator shall create one entitlement per product subscribed / purchased by the user. This right will be shared by all devices that belong to the user's account. If the entitlement includes a device identifier in addition to the account identifier, then the right will be applicable only to that device.

To remove an existing right from a user, the operator can chose between changing the status to UNSUBSCRIBED (ex., if the user has temporarily unsubscribed from a product) or directly remove the entitlement.

SSP will automatically purge expired and unsubscribed entitlements after a retention period

RMG API is based on web standards (HTTP/ReST/JSON). The spec is available here.

3. Data Archiving

See Authorization Server Data Archiving

4. API Authentication

ADM & RMG APIs require a valid SSP authentication token:

• The token follows the JWT standard and shall be generated using SSP credentials assigned to the operator.

• The procedure to generate tokens and the SSP authentication token format is defined in the Authentication Management section.

• The token shall be sent with each HTTP request sent to ADM or RMG inside an HTTP header (named "nv-authorizations").