Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Authentication Service 2.0"

(On startup)
(Adding a new selector to user's account)
Line 35: Line 35:
  
 
===Adding a new selector to user's account===
 
===Adding a new selector to user's account===
*receives an "add selector" message containing (username, password, selector serial number and selector public key) over either SSL or with message encrypted using auth service's certificate
+
*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)
 
*returns with an access token which includes (selector public key, username)
  

Revision as of 15:10, 24 September 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Higgins logo 76Wx100H.jpg

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

  • 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
  • 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

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

Open Issues

  1. Are there any performance issues with all this public key stuff?
  2. Should we worry about "idle time"?

See Also

Back to the top