Identity Management and Authentication

 In

Revision for “Identity Management and Authentication” created on 20 May 2016 @ 13:03:32

Title
Identity Management and Authentication
Content
<h2>Functional Description</h2><h3>Responsibilities</h3>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:<ol> <li>User Context sharing</li> <li>Profile management</li> <li>Authentication services</li> </ol>Adaptors (or plugins) are used to provide the user service with authentication and profile repository capabilities.<h3>Collaborators</h3><ul> <li>Session Service</li> <li>Authentication Service</li> <li>Profile Storage Service (e.g. LDAP or custom solution)</li> <li>Logging Service</li> </ul><h3>Definitions</h3><ul> <li><strong>User Profile - </strong>is a collection of global and application-specific information that applies to the user such as personal credentials, personal preferences and application configuration.</li> <li><strong>User Context - </strong>is a storage structure that maintains information about a user such as active repository connections, identities and profiles.</li> <li><strong>Personal Device</strong> - is any device that a user has logged into with their personal credentials and selected a personal profile.</li> <li><strong>Communal Device</strong> – is any device that multiple users have privileges to configure due to a communal profile having been selected</li> </ul><h3>Multiple Users</h3>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.<h3>User Roles</h3><span style="line-height: 1.5;">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. Ch</span><span style="line-height: 1.5;">anges to the communal configuration made by any of the users in the layout context should be stored to the experience owner’s chosen profile.</span>[caption id="attachment_532" align="aligncenter" width="643"]<img class="wp-image-532" src="https://2immerse.eu/wp-content/uploads/2016/04/Netflix-users-300x193.jpg" alt="Netflix-users" width="643" height="414" /> Netflix “Who’s Watching?” Screen[/caption]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.<h3>Privileges (<strong>Communal and Personal Devices)</strong></h3>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.<h3>Profiles</h3>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.[caption id="attachment_533" align="aligncenter" width="498"]<img class=" wp-image-533" src="https://2immerse.eu/wp-content/uploads/2016/04/profiles-300x133.png" alt="Data from different profiles are combined to configure an experience." width="498" height="221" /> Data from different profiles are combined to configure an experience.[/caption]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.<h3>Identity</h3>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.<h3>User Service Verbs</h3><strong>GetUserContext</strong> - <span style="line-height: 1.5;">Authenticates user and returns the user context</span><em>Returns:</em> UserContext<em>Params:</em> userService, username, password/certificate, domain<strong>Get/SetCredentialChallengeCallback</strong> - Callback for handling credential challenges (OAuth)User Context Verbs<strong>LoadProfile</strong> - Fetches named profile from server<em>Returns:</em> Profile<em>Params:</em> userContext, profileName<strong>AddProfile</strong> - Adds a named profile to the user context<em>Returns:</em> Profile<em>Params:</em> userContext, profileName<strong>SaveProfile</strong> - Store profile changes<em>Returns:</em> status<em>Params:</em> userContext, profileName<h3>Profile Verbs</h3><strong>GetValue</strong> - Retrieve a named value from a profile<em>Returns:</em> value or Profile<em>Params:</em> profile, attributeName/Path<strong>SetValue</strong> - Store a named value to a profile<em>Params:</em> profile, attributeName/Path, attributeValue<strong>HasValue</strong> - Check for existence of a named value in a profile<em>Returns:</em> boolean<em>Params:</em> profile, attributeName/Path<h3>Events</h3><strong>OnProfileChanged</strong> - Notification that an external change to a profile has been made.&nbsp;&nbsp;&nbsp;<h2>API Specification</h2>To include specific data, communication substrate etc.Here is an example of an API definition - feel free to use similar formatting:<h3>dump</h3>The receiver of this message is expected to dump (part of) its internal state to its logging output, for debugging purposes.<ul> <li><strong>Publisher:</strong> debugging tools</li> <li><strong>Subscriber:</strong> all</li> </ul><strong>Example:</strong> <code class="json">{ "message" : "dump" , "what" : "random string that may influence what is dumped", }; </code>
Excerpt
Markdown content
<h2>Functional Description</h2> <h3>Responsibilities</h3> 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: <ol> <li>User Context sharing</li> <li>Profile management</li> <li>Authentication services</li> </ol> Adaptors (or plugins) are used to provide the user service with authentication and profile repository capabilities. <h3>Collaborators</h3> <ul> <li>Session Service</li> <li>Authentication Service</li> <li>Profile Storage Service (e.g. LDAP or custom solution)</li> <li>Logging Service</li> </ul> <h3>Definitions</h3> <ul> <li><strong>User Profile - </strong>is a collection of global and application-specific information that applies to the user such as personal credentials, personal preferences and application configuration.</li> <li><strong>User Context - </strong>is a storage structure that maintains information about a user such as active repository connections, identities and profiles.</li> <li><strong>Personal Device</strong> - is any device that a user has logged into with their personal credentials and selected a personal profile.</li> <li><strong>Communal Device</strong> – is any device that multiple users have privileges to configure due to a communal profile having been selected</li> </ul> <h3>Multiple Users</h3> 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. <h3>User Roles</h3> <span style="line-height: 1.5;">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. Ch</span><span style="line-height: 1.5;">anges to the communal configuration made by any of the users in the layout context should be stored to the experience owner’s chosen profile.</span>[caption id="attachment_532" align="aligncenter" width="643"]<img class="wp-image-532" src="https://2immerse.eu/wp-content/uploads/2016/04/Netflix-users-300x193.jpg" alt="Netflix-users" width="643" height="414" /> Netflix “Who’s Watching?” Screen[/caption]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. <h3>Privileges (<strong>Communal and Personal Devices)</strong></h3> 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. <h3>Profiles</h3> 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.[caption id="attachment_533" align="aligncenter" width="498"]<img class=" wp-image-533" src="https://2immerse.eu/wp-content/uploads/2016/04/profiles-300x133.png" alt="Data from different profiles are combined to configure an experience." width="498" height="221" /> Data from different profiles are combined to configure an experience.[/caption]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. <h3>Identity</h3> 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. <h3>User Service Verbs</h3> <strong>GetUserContext</strong> - <span style="line-height: 1.5;">Authenticates user and returns the user context</span><em>Returns:</em> UserContext<em>Params:</em> userService, username, password/certificate, domain<strong>Get/SetCredentialChallengeCallback</strong> - Callback for handling credential challenges (OAuth)User Context Verbs<strong>LoadProfile</strong> - Fetches named profile from server<em>Returns:</em> Profile<em>Params:</em> userContext, profileName<strong>AddProfile</strong> - Adds a named profile to the user context<em>Returns:</em> Profile<em>Params:</em> userContext, profileName<strong>SaveProfile</strong> - Store profile changes<em>Returns:</em> status<em>Params:</em> userContext, profileName <h3>Profile Verbs</h3> <strong>GetValue</strong> - Retrieve a named value from a profile<em>Returns:</em> value or Profile<em>Params:</em> profile, attributeName/Path<strong>SetValue</strong> - Store a named value to a profile<em>Params:</em> profile, attributeName/Path, attributeValue<strong>HasValue</strong> - Check for existence of a named value in a profile<em>Returns:</em> boolean<em>Params:</em> profile, attributeName/Path <h3>Events</h3> <strong>OnProfileChanged</strong> - Notification that an external change to a profile has been made.&nbsp;&nbsp;&nbsp; <h2>API Specification</h2> To include specific data, communication substrate etc.Here is an example of an API definition - feel free to use similar formatting: <h3>dump</h3> The receiver of this message is expected to dump (part of) its internal state to its logging output, for debugging purposes. <ul> <li><strong>Publisher:</strong> debugging tools</li> <li><strong>Subscriber:</strong> all</li> </ul> <strong>Example:</strong> <code class="json">{ "message" : "dump" , "what" : "random string that may influence what is dumped", }; </code>


OldNewDate CreatedAuthorActions
20 May 2016 @ 13:03:32Mark Lomas
20 May 2016 @ 13:00:51 [Autosave]Mark Lomas
12 May 2016 @ 17:10:21Mark Lomas
12 May 2016 @ 15:10:33Mark Lomas
3 May 2016 @ 12:07:40Mark Lomas
3 May 2016 @ 11:58:31Mark Lomas
3 May 2016 @ 11:56:16Mark Lomas
18 April 2016 @ 00:39:32Ian Kegel
Recent Posts
Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search