Identity Management and Authentication

Functional Description

Responsibilities

The user identity service is responsible for managing user identity, privileges and profiles. It allows information about users to be created, shared and aggregated for use in distributed media applications and allows the state of an experience to be captured and stored in a persistent way.

The User Service is comprised of three major functional areas:

1. User Context sharing
2. Profile management
3. Authentication services

Adaptors (or plugins) are used to provide the user service with authentication and profile repository capabilities.

Collaborators

• Session Service
• Authentication Service
• Profile Storage Service (e.g. LDAP or custom solution)
• Logging Service

Definitions

• User Profile – is a collection of global and application-specific information that applies to the user such as personal credentials, personal preferences and application configuration.
• User Context – is a storage structure that maintains information about a user such as active repository connections, identities and profiles.
• Personal Device – is any device that a user has logged into with their personal credentials and selected a personal profile.
• Communal Device – is any device that multiple users have privileges to configure due to a communal profile having been selected

Multiple Users

A profile describes how an experience has been personalised for a given layout context by one or more users. This includes tweaking layouts and choosing active DMApp components or media sources. A profile may also contain other types of state data such as history and usage activity.

Personalising a multi-device, multi-user experience can be a time consuming process, so it’s important to store settings that a user is happy with so they can be applied quickly in future. This is useful for quickly swapping between primary users of the system and is especially useful for demonstration purposes.

Each user in the household may want to configure experiences differently to meet their own needs and preferences. The system should select the appropriate stored configuration depending on who is watching.

User Roles

Sometimes multiple people will be watching together, however only one of the users will be responsible for launching the experience. They can be considered the owner of the experience. The ‘Experience Owner’ is the user whose profile is selected to initially configure an experience and store context state data. A profile selection can be achieved using something similar to the Netflix’s “Who’s Watching?” screen. Changes to the communal configuration made by any of the users in the layout context should be stored to the experience owner’s chosen profile.

A user may wish to reuse their profile in a different layout context, such as an upstairs bedroom or friend’s house. It is therefore important to associate profiles with the users that created them as opposed to any specific layout context or device.

Privileges (Communal and Personal Devices)

Any user can make changes to the presentation of an experience on a communal device such as a television and those changes are always stored to the experience owner’s profile. The exception being the “Football in the pub” scenario where configuration privileges are heavily restricted on communal devices with only the landlord being able to substantially reconfigure the experience.

Privileges are important for personal devices too. For example, a mobile phone is generally considered to be a personal device and other users must seek permission to override the layout and presentation choices of the logged-in user. Configuration changes made to a personal device are stored in the logged-in user’s profile as opposed to the experience owner’s profile.

Permissions are much more important in public contexts, such as the “Theatre in Schools” and “Football in the pub” use cases because trust in these environments is a bigger issue.

Profiles

A Profile stores key/value pairs that specify preferences and configuration data for a user. A default profile (authored and distributed by the broadcaster) is used to populate each user profile with sensible values. The user can override the default values at any time with their own personal preferences. Profiles persist from one experience to the next.

Profiles of each user are combined with the default profile to deliver the final configuration. User profiles can store both application-specific and application-independent data. Application-independent data transcends any one experience. Examples include first/last name, credential sets, accessibility settings, usage metrics or settings common to a group of experiences such as a genre.

Identity

User identity is important for personalisation and configuration, but it is also needed by the lobby system for initiating real-time communications and for grouping the right viewers into a shared theatre box. Unique identifiers and human readable names are required per user together with authentication or certification.

User Service Verbs

GetUserContext – Authenticates user and returns the user context

Returns: UserContext

Params: userService, username, password/certificate, domain

Get/SetCredentialChallengeCallback – Callback for handling credential challenges (OAuth)

User Context Verbs

LoadProfile – Fetches named profile from server

Returns: Profile

Params: userContext, profileName

AddProfile – Adds a named profile to the user context

Returns: Profile

Params: userContext, profileName

SaveProfile – Store profile changes

Returns: status

Params: userContext, profileName

Profile Verbs

GetValue – Retrieve a named value from a profile

Returns: value or Profile

Params: profile, attributeName/Path

SetValue – Store a named value to a profile

Params: profile, attributeName/Path, attributeValue

HasValue – Check for existence of a named value in a profile

Returns: boolean

Params: profile, attributeName/Path

Events

OnProfileChanged – Notification that an external change to a profile has been made.

 

 

 

API Specification

To include specific data, communication substrate etc.

Here is an example of an API definition – feel free to use similar formatting:

dump

The receiver of this message is expected to dump (part of) its internal state to its logging output, for debugging purposes.

• Publisher: debugging tools
• Subscriber: all

Example:
{ "message" : "dump" ,
"what" : "random string that may influence what is dumped",
};