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: Added CAPTCHA and OTP) |
|||
Line 34: | Line 34: | ||
**selector public key | **selector public key | ||
**selector serial number | **selector serial number | ||
+ | **selector name (human friendly) | ||
+ | **selector state (active/disabled) | ||
+ | |||
===Adding a new selector to user's account=== | ===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 | * Selector requests CAPTCHA | ||
− | * Auth service sends CAPTCHA image | + | * 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 and CAPTCHA answer | + | * 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) | * Auth service sends OTP via out-of-band channel (email, sms, etc) | ||
* Selector sends "add selector" message containing (username, OTP, selector serial number and selector public key) over either SSL or with message encrypted using auth service's certificate | * Selector sends "add selector" message containing (username, OTP, selector serial number and selector public key) over either SSL or with message encrypted using auth service's certificate | ||
Line 44: | Line 49: | ||
===Selector authentication and access token issuance=== | ===Selector authentication and access token issuance=== | ||
− | *Receives a "request for access token" message from (non-cloud) selector containing (username, hash-of-password, | + | *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) | *Returns a fresh access token containing (username, selector public key) | ||
*Access token is signed by private key of auth service | *Access token is signed by private key of auth service | ||
Line 50: | Line 55: | ||
===Password reset=== | ===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=== | ===Removing a selector from user's account=== |
Revision as of 10:19, 15 October 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
- 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 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
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"?