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:
- User Context sharing
- Profile management
- 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.
Netflix “Who’s Watching?” Screen
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.
Data from different profiles are combined to configure an experience.
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",
};
