Use Case 12 - User Authentication

Goal

User Authentication - Person or service via client software authenticates against an identify provider to establish session token that can subsequently be used as a proxy for the user.

Summary

Many operations in the DataONE system require affirmation of user identity to ensure that appropriate access controls can be asserted and other services such as citation and notification operate as expected.

The actual identity and authentication framework may exist outside of DataONE, and the first version of the infrastructure will be utilizing the certificate based services of the CILogon service.

The user obtains a certificate from the CILogon service, then uses that certificate to obtain an authentication token that can be used in the DataONE system. The authentication token is (perhaps) a SAML document that contains information mapping the user to n identities that may be recognized by the DataONE participant nodes.

Figure 1. (Note: This diagram is an initial draft subject to significant change). Rough sketch of an authentication scenario augmented by a centralized identity mapping. A user logs on to the CILogon service (1) and retrieves a certificate (2). A later connection to login to the DataONE system uses the previously generated certificate to assert identity with the Coordinating Node (3). The Coordinating Node looks up the user’s identities (4), retrieving multiple known identities for the user (5). The Coordinating Node generates an encrypted XML document (e.g. SAML) which contains the known identities of the user and returns the document as the authentication token (6). The token is the used to identify the user in a get() request against a Member Node, which checks for a known alias in its own user database (8). A successful verification (9) indicates the identity of the user, and verifies that the user has access to the object (not shown), then returns the object (10). An initial process of identity sharing (0) is used to generate the identities database at the Coordinating Nodes.

Figure 2. Sketch of an authentication scenario where the CILogon certificate is used the authentication token when interacting with the DataONE system. The user logs on to the CILogon service (1) and receives a certificate (2). The user makes a request to a Member Node using the certificate credentials as the authentication token (3). The Member Node does not recognize the user identity in its local user database (4) and so requests identity resolution from a Coordinating Node (5). The Coordinating Node inspects its identity mapping tables and determines the identity of the user according to the Member Node, and returns that information (7). The Member Node asserts that the user has read access to the object and returns it to the user (8). This approach assumes that the user has had the opportunity to perform the necessary identity mapping, and that the Member Node trusts the Coordinating Node’s assertion about the identity of the user.

Actors

User, Member Node, Coordinating Node, Authentication System

Preconditions

• User is not authenticated in the system

Triggers

• A user logs on to the DataONE system.
• A user tries to perform an operation in the DataONE system that requires authentication.

Post Conditions

• An auth_token is returned to the user (application) that can be used for future interactions with the DataONE system.
• In the event of authentication failure, the auth_token will provide identity equivalent to an anonymous user.
• The authentication operation is recorded in CN logs (depending on where the authentication attempt was made)
• The auth_token is trusted by participant Member Nodes as a proxy for the actual user.

Figure 3. Interactions for use case 12.

Notes

• To be a bit more abstract, it might be good to use something like login(user, credentials) or login(subject) for the method signature. Here “subject” would be similar to the javax.security.auth.Subject concept. (PEA)
• Can logins also happening against a MN, which simply proxies the request up to the CN? (PEA)
• Need to specify a time to live for auth_tokens. Is this part of the authentication sub-system? If so, can the TTL be altered by the DataONE system?