Difference between revisions of "Authentication Service 2.0"

Revision as of 14:19, 24 September 2009

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

(Non-cloud) Selector authentication (and access token issuance):

• Receives a request for access token message from 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

1. Access Token Issuing.

1. • Accepts authentication materials, evaluates them, if acceptable generates an access token that it returns to the consumer/client

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

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

See Also

• Selector Authentication