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.
Difference between revisions of "Authentication Service 2.0"
(→High Level Requirements for Auth Service) |
|||
Line 33: | Line 33: | ||
**Access token is signed by private key of auth service | **Access token is signed by private key of auth service | ||
− | + | Access Token Issuing: | |
− | + | *Receives a request for nonce message, replies with nonce | |
− | + | *Receives a "request for access token" messages, validates signature, generates an access token and returns it | |
− | + | ||
Password reset: | Password reset: | ||
Line 49: | Line 48: | ||
Cloud-selector authentication: | 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. | *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 == | == High Level Requirements for the Higgins Selector == |
Revision as of 14:21, 24 September 2009
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}This page describes a new network Authentication Service 1.1.
Contents
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
Access Token Issuing:
- Receives a request for nonce message, replies with nonce
- Receives a "request for access token" messages, validates signature, generates an access token and returns it
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
- RESTful web service
- Security is of course important
- Uses open standards where possible