Authentication Service 2.0

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

This page describes a new network Authentication Service 1.1.

Objective

A new service that performs authentication of selector clients and issues an access token that can be consumed by both the Higgins Selector (e.g. GTK Selector 1.1-Win) and all of its various supporting services including the I-Card Service 1.1, CardSync Service 1.1.

Background

At present authentication is performed within the RPPS Package within the I-Card Service. Here are some implications:

• In deployments where the I-Card Service and CardSync Service are co-resident, the CardSync Service can rely on this same authentication capability within RPPS Package. However if these services are deployed separately, the [[CardSync Service will have no way to authenticate the selector client.
• As we move towards Higgins 1.1 other new services may be added that also need to authenticate the selector client. With the current design this is difficult.
• We can envision deployment architectures where organization A would host the authentication service, and organization B would host the others. By having a separate authentication service, this deployment option becomes available.

High Level Requirements for Auth Service

Account management

• Maintains accounts for users.
• Each account is identified by a unique (to this service) account id (aka username)
• Each account holds multiple selector entries, each of which consists of:
  • selector serial number (see below, (symmetric key))

Selector provisioning

• Generates a symmetric key (also known as the selector's serial number)
• Generates a selector download file such that that after the selector installer has run the selector has access locally (e.g. in secure OS storage) to this key

Selector authentication and access token issuance

• Receives a request for access token message from (non-cloud) selector
• Service verifies the signature of the message by comparing it with its own HMAC hash of its locally stored (serial number + password + username)
• If HMAC signature matches then it returns an access token
• Access token is signed by private key of auth service
• Access token contains an expiration date/time

Password reset

• to-be-written

Adding a new selector to user's account

• to-be-written

Removing a selector from user's account

• to-be-written

Cloud-selector authentication

• to-be-written: For clientless access (i.e., cloud selector) this could be a two-step process: Step 1: userid + password. Then auth service initiates an out-of-band (i.e. email, sms, voice call, etc.) OTP to the user. Then step 2 is user enters this OTP to get the access token.

High Level Requirements for the Higgins Selector

Using access token to authenticate to services

• After getting an access token from the auth service, the selector will, before using any other service (e.g. CardSync) send this access token to the service and get a session token in response
• If the service responds with an error code that indicates that the access token has expired then it will request a fresh access token from the auth service and repeat the process

Secure local storage

• After installation the selector securely stores the this selectors serial number
• After the user

Login user interface

• Has UI that prompts the user for username and password
  • The purpose of the username is to allow a set of the user's selectors to be treated as a logical group by the auth service
  • The purpose of the password is to authenticate the user to the selector (and to a lesser extent the user to the auth service)

Authenticating the user

• Selector pops up the UI described above
• Selector checks that the username entered by the user matches the stored username and that the hash of the password stored locally matches the hash of the stored password
• Selector requests a nonce from auth service
• Selector sends "request for access token" message that contains a HMAC of (serial number + password + username + nonce)
• Selector gets an access token in response
• Selector sends this access token to a Higgins service (e.g. CardSync service) and gets a session token in response
• Selector uses this session token to access service

Credential storage:

• The selector never stores the password, only a hash of the password
• The selector locally stores the username

Cloud selector authentication

• to-be-written

Adding a new selector to user's auth service account

• to-be-written

Removing a selector from the user's auth service account

• to-be-written

Implementation characteristics

1. RESTful web service
2. Security is of course important
3. Uses open standards where possible

Open Issues

1. Should we worry about "idle time"?

See Also

• Selector Authentication