Device-type-sensitive licence checks

This page was never published on the Drupal site.

Overview

This feature optionally extends the SDP licence authorisation logic with an additional check using the device type:

• Devices are assigned device types.
• Products are assigned to these device types.
• A license is (optionally) authorised for a product only if the requesting device's device type is in the list of permitted device types for the product.

The functionality is achieved in two steps:

1. When SDP ingests a CMS export file, it assigns products to the existing device types.
2. When a license is requested, the authorisation logic can enforce the device-type-sensitive check.

Terms

• Device type: this is an arbitrary label, defined by the operator, that is used to categorise devices. It can be anything (for example, iOS, Android, smartphone, tablet, OTT, CableSTB, and so on).
• DeviceProfile: this is the entity in the SDP data model that represents a type of device. The actual "device type" label that is assigned to the device one of this entity's fields (DeviceProfile.deviceTypeList).
• DeviceInformation: this is a list of name-value pairs, reported by the client device to the back-end, which includes device characteristics like the OS name and version, screen size and resolution, manufacturer, and so on.
• DeviceClassifier: this is the entity in the SDP data model that contains the rules that the DeviceInformation must match for a DeviceProfile to be assigned to a particular device.
• PolicyGroup: the SDP data model name for products.
• Platform: the CMS data model entity that contains a list of "features". This is used to assign one or more DeviceProfiles to products.

Mapping products to device types

(A product is actually mapped to a DeviceProfile, of which the device type is a part.)

• This feature reuses the existing CMS capability to link Platforms to Products.
  A Platform is a container of features, which effectively assigns a set of features to a Product.
• A Product is then eligible for a device if the DeviceProfile contains all the features present in the Platform linked to that Product.
• If a Product has no Platform assigned to it, it means the Product is eligible for all DeviceProfiles.
• If a Product has a set of features that is not contained by any DeviceProfile, this product is not eligible for any license authorisation (if device-type-sensitive check is enabled).

The following figure shows a sample configuration that illustrates the relationship between Products and Devices:

Enabling the device-type-sensitive licence check

• This extra check can be enabled or disabled via the configuration.
  The default value is false (disabled)
• When enabled, it is applied in both post-delivery (isContentAuthorized) and pre-delivery (getContentRights).

Updating products when a new device type is added

When the operator adds, deletes, or updates a DeviceProfile, existing products (PolicyGroup instances) in SDP may need to be assigned to or removed from that DeviceProfile.

This re-mapping can have a significant performance impact if the number of existing products is very large. On the other hand, changing the existing DeviceProfiles only happens very infrequently.

Alternatively, the operator can trigger a full CMS export to force a full re-mapping of products to device types.

Since a full CMS export does not transmit any data deletions done since the last export, a successful delta export must have been performed just before the full export.

Use cases

Updating products in the CMS

Creating a Product with no features linked to it

1. The CMS exports the Product downstream with no link to a Platform.
2. The SDP ingests the Product and creates a PolicyGroup with no features.
3. The SDP assigns all existing DeviceProfile instances to this PolicyGroup.

Creating a Product with features via REST API

1. The CMS exports the Product downstream and also the link to the Platform that contains the features.
2. The SDP ingests the Product and creates a PolicyGroup with the associated features.
3. The SDP looks at the DeviceProfile table and assigns all the DeviceProfile instances whose features contain the features in the PolicyGroup to this PolicyGroup.

Editing a Product

1. The CMS exports the Product downstream linked to the Platform with the new list of features.
2. The SDP ingests the Product and updates the list of features assigned to the PolicyGroup.
3. The SDP looks at the DeviceProfile table and assigns/removes DeviceProfile instances to/from this PolicyGroup according to the PolicyGroup's new feature list.

Updating a Device Profile in SDP

Creating a new Device Profile

1. The SDP creates the new DeviceProfile instance.
2. The SDP looks at the PolicyGroup table and assigns the new DeviceProfile to the PolicyGroups whose features are contained by the DeviceProfile's features.

   Note that PolicyGroups with no features (PG2 in the example above) are also assigned to the new DeviceProfile.

Removing a Device Profile

1. The SDP deletes the DeviceProfile instance.
2. The SDP removes this DeviceProfile from all PolicyGroup instances.

Editing a Device Profile

In this use case, the operator adds/removes features to/from a DeviceProfile.

1. The SDP updates the DeviceProfile instance as requested.
2. The SDP looks at the PolicyGroup table and assigns/removes the DeviceProfile to/from the PolicyGroups according to the new list of features.

Requesting a licence (end user)

Device type licence check is not enabled

SDP's isContentAuthorized and getContentRights APIs either authorise the license or not, depending on whether the content is included in a PolicyGroup that is linked by an ACL of the account (that is, if the user has purchased the content).

Device type licence check is enabled

In addition to what it does when this check is not enabled (above), the SDP:

1. Looks up the DeviceProfile from the device identifier in the token.
2. Verifies that the PolicyGroup that is linked in the account's ACL points to the above DeviceProfile.