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"

(Rest API)
Line 132: Line 132:
 
{| cellspacing="1" cellpadding="1" border="1" width="100%"
 
{| cellspacing="1" cellpadding="1" border="1" width="100%"
 
|-
 
|-
| align="center" | '''Resource'''  
+
| align="center" | '''Resource item'''
| align="center" | '''Path'''  
+
| align="center" | '''Representation path'''  
| align="center" | '''HTTP operations'''
+
| align="center" | '''Supported HTTP operations'''
 +
| align="center" | '''Note'''
 
|-
 
|-
 
| Captcha  
 
| Captcha  
 
| /captcha  
 
| /captcha  
| Get
+
| Get  
 +
| Generates new captcha and return <captchaId>
 
|-
 
|-
 
| byte[]  
 
| byte[]  
 
| /captcha/<captchaId>  
 
| /captcha/<captchaId>  
| Get
+
| Get  
 +
| Returns captcha image
 
|-
 
|-
 
| User  
 
| User  
 
| /user  
 
| /user  
| Post|Put
+
| Post|Put  
 +
|
 +
Post - create new user account
 +
 
 +
Put - update user (email, tel, etc) 
 +
 
 
|-
 
|-
 
| User  
 
| User  
 
| /user/<username>  
 
| /user/<username>  
| Get|Delete
+
| Get|Delete  
 +
| Returns or delete user account
 
|-
 
|-
 
| Selector  
 
| Selector  
| /selector  
+
| /user/<username>/selector  
| Get|Post|Put|Delete
+
| Get|Post|Put|Delete  
 +
|
 +
Get - returns all user selectors
 +
 
 +
Post - add new selector
 +
 
 
|-
 
|-
 
| Channel  
 
| Channel  
 
| /cahnnels  
 
| /cahnnels  
| Get
+
| Get  
 +
|
 +
|-
 +
| AccessToken
 +
| /token
 +
| Post
 +
|
 
|}
 
|}
  

Revision as of 06:57, 19 October 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
  • 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
    • selector name (human friendly)
    • selector state (active/disabled)


Adding a new selector to user's account

  • Selector requests list of supported transport channels
  • Auth service sends list with channel names (email, sms, etc) (it'll be pluggable feature, so it depends on deployment cnf)
  • Selector requests CAPTCHA
  • Auth service sends CAPTCHA ID (selector may load captcha image by using GET request like /captcha/<captchaId>)
  • Selector sends "request add selector token" message containing username, hash-of-password, transport channel (email, sms, etc), email (optional), tel (optional), CAPTCHA ID and CAPTCHA answer
  • Auth service sends OTP via out-of-band channel (email, sms, etc)
  • Selector sends "add selector" message containing (username, OTP, selector name, 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, 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

  • Selector requests CAPTCHA
  • Auth service sends CAPTCHA ID (selector may load captcha image by using GET request like /captcha/<captchaId>)
  • Selector sends request "get reset password OTP" message containing username, selector serial number , CAPTCHA ID and CAPTCHA answer
  • Auth service sends OTP via out-of-band channel which was used for adding last user selector
  • Selector sends request "reset password" message containing (username, OTP, selector serial number, new hash-of-password) over either SSL or with message encrypted using auth service's certificate
  • "reset password" request should be signed by selector private key
  • Auth service returns an access token which includes (selector public key, username)

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

Rest API

Resource item Representation path Supported HTTP operations Note
Captcha /captcha Get Generates new captcha and return <captchaId>
byte[] /captcha/<captchaId> Get Returns captcha image
User /user Post|Put

Post - create new user account

Put - update user (email, tel, etc) 

User /user/<username> Get|Delete Returns or delete user account
Selector /user/<username>/selector Get|Post|Put|Delete

Get - returns all user selectors

Post - add new selector

Channel /cahnnels Get
AccessToken /token Post

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