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"
(→Adding a new selector to user's account) |
(→High Level Requirements: added de-authorization of selectors) |
||
Line 23: | Line 23: | ||
* Any organization/service that can implement the auth service API can act as a Higgins selector authenticator (no need to use the Higgins reference implementation) | * Any organization/service that can implement the auth service API can act as a Higgins selector authenticator (no need to use the Higgins reference implementation) | ||
* Auth service can authenticate both client-based and cloud-based selectors | * Auth service can authenticate both client-based and cloud-based selectors | ||
+ | * Allows remote de-authorization of selectors | ||
* Secure design/architecture | * Secure design/architecture | ||
Revision as of 15:13, 24 September 2009
{{#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 Requirements
- 4 High Level Design of the Auth Service
- 5 High Level Design of the Higgins Selector
- 5.1 On startup
- 5.2 Using access token to authenticate to services
- 5.3 Secure local storage
- 5.4 Login user interface
- 5.5 Authenticating the user
- 5.6 Credential storage
- 5.7 Cloud selector authentication
- 5.8 Adding a new selector to user's auth service account
- 5.9 Removing a selector from the user's auth service account
- 6 Implementation characteristics
- 7 Open Issues
- 8 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 Requirements
- Separate authentication, provisioning and some account management to a separate "auth" service
- Allow all the existing Higgins services to rely on this auth service to authenticate users/selectors instead of doing it themselves
- Allow the auth service to evolve independently
- Supports uses where one organizational entity is running the auth service and other organizations run the other Higgins services
- Higgins reference implementation of auth service for Higgins 1.1
- Any organization/service that can implement the auth service API can act as a Higgins selector authenticator (no need to use the Higgins reference implementation)
- Auth service can authenticate both client-based and cloud-based selectors
- Allows remote de-authorization of selectors
- Secure design/architecture
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 public key
- selector serial number
Adding a new selector to user's account
- receives an "add selector" message containing (username, hash-of-password, selector serial number and selector public key) over either SSL or with message encrypted using auth service's certificate
- returns with an access token which includes (selector public key, username)
Selector authentication and access token issuance
- Receives a "request for access token" message from (non-cloud) selector containing (username, hash-of-password, proof of possession of selector serial number) in message that was signed by selector's private key
- Returns a fresh access token containing (username, selector public key)
- Access token is signed by private key of auth service
- Access token contains an expiration date/time
Password reset
- 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
On startup
- Selector generates an asymmetric (private/public) key pair
- Selector validates auth service certificate
- Selector sends (username, hash-of-password, selector serial number, selector public key) to auth service
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 for each local username/account
- this selector's serial number
- this selector's private key
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 sends "request for access token" message that contains (username, hash-of-password, proof of serial number possession) either (a) encrypted by using the auth service's certificate or (b) delivered over SSL
- 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
- Are there any performance issues with all this public key stuff?
- Should we worry about "idle time"?