• Name: Authenticate
• Alternate Name: Authentication, AuthN
  

This Service Genre has been developed to describe the behaviours and functionality required of Services that enable users to authenticate to systems.

• e-Framework Service Genre Version: v1.1

The Service Genre describes authentication, the process of uniquely identifying an individual or entity (the principal) based on objects provided for verification (credentials). Credentials should be difficult to falsify or forge, either by keeping them secret or by making them difficult to replicate. Authentication seeks to ensure that the principal is who they claim to be. The degree of certainty varies according to implementation and business context.

Authentication typically verifies the principal’s association with an electronic identifier. Authentication may also determine that the principal has certain attributes or is a member of specified or predetermined groups.

In security systems, authentication is distinct from authorisation, which is the process of establishing what a principal is permitted to do, their access rights to system objects based on their identity.

Terms:

• Principal – individual (end-user), service, server, group or organisation that may wish to authenticate.
• Credential – an object, generally bound to the principal, that can be verified in order to authenticate the principal. e.g., username and password, digital certificate. More than one credential may be necessary for authentication.
• Identifier – a unique object (generally string) used to represent a principal once authenticated. This may be part of a user credential, for example username or certificate subject, or may be an authentication token.
• Authentication Token – a digital token given to a principal once authenticated. This can be passed to one or more relying parties to indicate authentication has occurred and to identify the principal.
• Attribute – a single piece of information or property of the principal that has been provided by authentication or by association with their identifier. Attributes may be used in authorisation.
• Provisioning – the process of adding principals to an identity store, establishing initial credentials, and determining their entitlements (authorisation).
• Authorisation – the process of establishing what a principal is permitted to do, or their access rights to resources.
• Relying Party – a service, system, resource, application or entity that relies on the authentication.

Authentication allows a principal’s credentials to be validated. This MAY then allow further access to relying parties. Authorisation MAY occur after authentication to determine the principal’s access rights. The behaviour and structure of relying services MAY change depending on the principal. The mechanism used for authentication and the context in which it has occurred (eg. principal’s physical location) MAY also affect the relying service behaviour and structure.

Services may be given delegated credentials to allow them to access relying parties on a principal’s behalf. Such a service may act on behalf of multiple principals.

Authentication can occur at any point in an application or choreography of services. It may occur once for a specified time period, once on initial access, prior to certain privileged actions, or prior to every service.

In scenarios where an authentication token is returned this is generally an opaque identifier that cannot be attributed to the principal outside of trusted relying parties. An authentication token is generally passed back to the principal. The mapping of authentication token to the principal’s identifier MAY be a separate service or MAY be embedded within other services. This scenario may be used when a principal wishes to make multiple requests to relying parties without the need to present credentials each time. This is often used to add state to relying parties and to share authentication across relying parties.

Any Service Expression that conforms to the Authenticate Service Genre:

• MUST accept a principal’s credentials for validation
• MUST return success if validation succeeded
• MAY return failure and/or reason for failure, if validation failed
• MAY provide a principal’s identifier
• MAY provide a principal’s attributes
• MAY provide an authentication token

Other requests and behaviours MAY exist.

The following is the typical processes for authentication:

• a principal’s credentials are passed to Authenticate
• if validated the principal’s identifier is returned
• the identifier is then used by relying parties

The principal’s identifier MAY or MAY NOT be passed back to the principal, but is generally used by trusted relying parties.

If a principal’s credentials cannot be validated an identifier or authentication token SHOULD NOT be returned.

An Authenticate service may validate a principal’s credentials based on a directory of identities containing credentials or validation information. Alternatively, authentication may validate credentials based on what a trusted authority says about the credentials.

An Authenticate service may create a “session” for the principal which is shared by other service and indicates that the principal has authenticated. An authenticate service may check for the existence of a “session” and associate the principal to this rather than create a new one, to preserve authenticated state. (Note: A session identifier is a type of authentication token.)

None

Service Expression for Authenticate may choose not to return an indication of failure for security reasons.

Authentication may be supported by one or more directories used to store identities, attributes and credential validation information. Common examples are LDAP and SQL databases. Such directories may be maintained by provisioning systems responsible for the creation, update and deletion of identities.

Authentication may provide (or support) an audit trail of authorising principals and other information.

• Blog v1.5
• Early Notification v1.0
• FRED Authenticated Harvest v1.0
• MAMS - Federated IAM v1.0
• UK HE Admissions Structured Personal Statement v1.2