3.1.1.2 User Authentication Context

  • Article

When a requestor IP/STS or a resource IP/STS issues a security token, it MUST authenticate the user to obtain the data required to construct a security token. How the user is authenticated is implementation-specific and not addressed in this protocol. Common practices are discussed in sections 3.2 and 3.3 under the topic of message processing. In addition, when a relying party accepts a security token to authenticate a user, it is necessary to map the security token  AuthenticationStatement and AttributeStatement data into the structure that is used by the local system to make access control decisions. This is implementation-specific and not addressed in this protocol. It is useful here to define an abstract data model to record the data returned from the user authentication process. The following is a potential representation to organize this data:<33>

Authentication Context: This record contains data returned from user authentication. An IP/STS MUST maintain a separate record per user. The fields of this record are as follows:

AuthIdentity: A string field that uniquely and authoritatively identifies the user.

AuthMethod: A string field that identifies the authentication mechanism used, as required for the SAML assertion in a security token, as described in section 2.2.4.2.

AuthTime: A date-time field that identifies the most recent time that the user was authenticated.

AuthStart: A date-time field used to hold the beginning of the validity interval for a security token that is specified by the NotBefore attribute, as discussed in section 2.2.4.2.

AuthStop: A date-time field used to hold the end of the validity interval for a security token that is specified by the NotOnOrAfter attribute, as discussed in section 2.2.4.2.

AuthGroups (optional): A string field used to contain a list of group names, if any exist for this user, that are returned by the AuthMethod.

AuthClaim (optional): This record holds a claim from a security token, as defined in section 3.1.1.4. There MUST be one claim per AuthClaim record; thus multiple records can be present.