Authors: Jim Taylor, DECE; Peter Davis, Neustar
This article provides details of the UltraViolet Authentication UI. Authentication is part of the larger linking process. (See Linking and Security Tokens for more information.)
In addition to credential-based authentication, described below, Nodes can take advantage of two forms of email-based linking. If a Node has previously verified the user's email address, it can use the InstaLink feature to directly link to the user's UltraViolet account without the user needing to remember and enter their UltraViolet username and password (see Instalink for more information). For unverified email addresses, the Node can use the UserValidationTokenCreate API to have the Coordinator send a link request email. When the user responds to the email, the link is completed.
Nodes have two approaches for Users to authenticate to the Coordinator: delegation and federation. In short, delegation "delegates" the UltraViolet user identity to a Node so that the Node can represent the user in API calls based on its own identity scheme. Federation "federates" the UltraViolet user identity to a Node so the user can authenticate to the Node using only their UltraViolet identity, without requiring the Node to maintain a separate account for the User. In other words, delegation is "Node ID oriented" access for a Node (where sign in happens through the Node, after the initial UltraViolet sign-in to establish the delegation) whereas federation is "UltraViolet ID oriented" single sign-on (where sign-in always happens through the Coordinator).
A Node has the choice to:
A Security Token in this case is a SAML assertion, which must be included in Coordinator API calls when the Node is representing a User. See Linking and Security Tokens for more.
Nodes can request a compact version of the authentication UI, suitable for embedding in a iFrame or using on devices with small screens, with the dece:EmbeddedInteraction attribute (see DSecMech 5.9.1.1).
All authentication is handled by the s-host interface of the Coordinator to provide a consistent and recognizable interface for users to enter their UltraViolet username and password. Forgotten password recovery, option to re-open a closed account, email disambiguation (for users who have the same email and password for two different accounts), and security (CAPTCHA, etc.) are all build into the Coordinator s-host interface, so the retailer doesn't need to worry about these aspects of user authenticaion.
There is no limit to the number of federation or delegation requests a Node can make, although repeated requests in a short period of time will result in the s-host presenting a CAPTCHA or other reverse Turing test.
The s-host provides session management for the authentication process using browser cookies. (Future versions could use other platform-specific methods to establish sessions for Android apps, iOS apps, etc.). Session management primarily means that if the user chooses "Keep me logged in," which is usually automatically presented by s-host as part of the authentication UI, a long-term browers session will be established (currently 6 months with a 7-day idle timeout). Otherwise a short-term (currently 24-hour) session is established. Nodes have no ability to control whether or not s-host presents the "Keep me signed in" option, and Nodes have no control over s-host session lengths (other than the ability to force a session logout).
Once a session is established and another authentication request is made (e.g., the user links from another retailer or visits the Web Portal), the user will not be required to enter their username and password, only to grant access to the requesting Node. (See the flows below.)
Sessions are browser-specific, per User. Sessions can be cancelled by the User by choosing the "Not you?" option to log out of the current session, and then choosing "Cancel." (And of course Users can delete the browser cookie themselves.) Nodes can also provide a mechanism for Users to cancel the UV session by using SAML logout (see DSecMech 5.10).
If the user cancels a delegation or federation request (without choosing "Not you?"), the existing session (and any existing delegation and/or federation security tokens) is not affected.
Sessions are not affected by repeated federation or delegation requests. However, an FST request that occurs just before a session is about to expire (currently within 14 days of expiration) results in early session termination so that a new session must be established. This ensures that an inconveniently short federation of days or hours is not produced.
Centralized third-party ID could be added in the future by including a third-party sign-in link in the UltraViolet authentication UI. (When the user chooses to sign in with a third party ID service, the Coordinator is delegating trust, so that the third-party identity federation would then be "re-federated" to Nodes using the matching UltraViolet identity.) Federation Security Tokens would indicate whether or not a third-party was used to authenticate the user.
Nodes using the UVConnect federation mechanism will presumably always create their own transient browser session so that the user only has to authenticate once at the beginning of a series of UV-related actions. A Node requesting UserLinkConsent and storing a long-term Delegation Security Token (instead of a Federation Security Token) can be thought of as maintaining its own persistent session, which can last indefinitely, supported by the Node's own authentication mechanisms.
In essence, federation is used by Nodes that want to rely on session management at the Coordinator, whereas delegation is used by Nodes that want to manage their own authentication and sessions (although initial user sign-in for delegation requests is simplified if there is an active session at the Coordinator).
Implementers no longer need to request account management consent and should not set (or check) the corresponding ManageAccountConsent or ManageUserConsent policies.
Implementers no longer need to request account management consent and should not set (or check) the corresponding UserDataUsageConsent policy.
<samlp:authnrequest assertionconsumerserviceindex="0" destination="https://s.uvvu.com/security/delegation/saml/loginservice/login"
id="c8206ddb-8877-44ef-9f51-4e5a5d7d8ca4" issueinstant="2012-10-22T19:04:10" version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:dece:org:org:dece:{retailerid}:retailer</issuer>
<samlp:extensions>
<dece:policylist xmlns:dece="http://www.decellc.org/schema/2011/08/coordinator">
<dece:policy>
<dece:policyclass>urn:dece:type:policy:UserLinkConsent</dece:policyclass>
</dece:policy>
</dece:policylist>
</samlp:extensions>
<samlp:nameidpolicy format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
<samlp:requestedauthncontext>
<samlp:authncontextclassref xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Password
</samlp:authncontextclassref>
</samlp:requestedauthncontext>
</samlp:nameidpolicy></samlp:authnrequest>
Note that the <extensions> element with the <policylist> and <policyclass> elements is optional. (It was formerly required.)
Ensure there is no whitespace (spaces, tabs, newlines, etc.) in the Extensions element, as it may cause signature errors.