Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Authentication Service 2.0
Revision as of 14:39, 24 September 2009 by Unnamed Poltroon (Talk) (→High Level Design for Auth Service)
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
This page describes a new network Authentication Service 1.1.
Contents
- 1 Objective
- 2 Background
- 3 High Level Design of the Auth Service
- 4 High Level Design of the Higgins Selector
- 4.1 Using access token to authenticate to services
- 4.2 Secure local storage
- 4.3 Login user interface
- 4.4 Authenticating the user
- 4.5 Credential storage
- 4.6 Cloud selector authentication
- 4.7 Adding a new selector to user's auth service account
- 4.8 Removing a selector from the user's auth service account
- 5 Implementation characteristics
- 6 Open Issues
- 7 See Also
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 Design of the 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 Design of 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
- RESTful web service
- Security is of course important
- Uses open standards where possible
Open Issues
- Should we worry about "idle time"?