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.
Difference between revisions of "Authentication Service 2.0"
(→Adding a new selector to user's account) |
|||
| Line 1: | Line 1: | ||
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins logo 76Wx100H.jpg|right]] | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins logo 76Wx100H.jpg|right]] | ||
| − | This page describes a new network [[ | + | This page describes a new network [[Authentication_Service_1.1]]. |
== Objective == | == Objective == | ||
| Line 15: | Line 15: | ||
*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. | *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 == | + | == 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 | + | *Separate authentication, provisioning and some account management to a separate "auth" service |
| − | * Allow the auth service to evolve independently | + | *Allow all the existing Higgins services to rely on this auth service to authenticate users/selectors instead of doing it themselves |
| − | * Supports uses where one organizational entity is running the auth service and other organizations run the other Higgins services | + | *Allow the auth service to evolve independently |
| − | * Higgins reference implementation of auth service for Higgins 1.1 | + | *Supports uses where one organizational entity is running the auth service and other organizations run the other Higgins services |
| − | * 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) | + | *Higgins reference implementation of auth service for Higgins 1.1 |
| − | * Auth service can authenticate both client-based and cloud-based selectors | + | *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) |
| − | * Allows remote de-authorization of selectors | + | *Auth service can authenticate both client-based and cloud-based selectors |
| − | * Secure design/architecture | + | *Allows remote de-authorization of selectors |
| + | *Secure design/architecture | ||
== High Level Design of the Auth Service == | == High Level Design of the Auth Service == | ||
| − | ===Account management=== | + | === Account management === |
| + | |||
*Maintains accounts for users. | *Maintains accounts for users. | ||
| − | *Each account is identified by a unique (to this service) account id (aka username) | + | *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: | + | *Each account holds multiple selector entries, each of which consists of: |
| − | **selector public key | + | **selector public key |
| − | **selector serial number | + | **selector serial number |
| − | **selector name (human | + | **selector name (human friendly) |
**selector state (active/disabled) | **selector state (active/disabled) | ||
| + | <br> | ||
| − | ===Adding a new selector to user's account=== | + | === Adding a new selector to user's account === |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | ===Selector authentication and access token issuance=== | + | *Selector requests list of supported transport channels |
| − | *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 | + | *Auth service sends list with channel names (email, sms, etc) (it'll be pluggable feature, so it depends on deployment cnf) |
| − | *Returns a fresh access token containing (username, selector public key) | + | *Selector requests CAPTCHA |
| − | *Access token is signed by private key of auth service | + | *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 | *Access token contains an expiration date/time | ||
| − | ===Password reset=== | + | === Password reset === |
| − | * Selector requests CAPTCHA | + | |
| − | * Auth service sends | + | *Selector requests CAPTCHA |
| − | * Selector sends request | + | *Auth service sends CAPTCHA ID (selector may load captcha image by using GET request like /captcha/<captchaId>) |
| − | * Auth service sends OTP via out-of-band channel which was used for adding last user selector | + | *Selector sends request "get reset password OTP" message containing username, selector serial number , CAPTCHA ID and CAPTCHA answer |
| − | * 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 | + | *Auth service sends OTP via out-of-band channel which was used for adding last user selector |
| − | * "reset password" request should be signed by 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 |
| − | * Auth service returns an access token which includes (selector public key, username) | + | *"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 | *to-be-written | ||
| − | ===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 Design of the Higgins Selector == | + | == High Level Design of the Higgins Selector == |
| − | ===On startup=== | + | === On startup === |
| − | + | ||
| − | + | ||
| − | + | ||
| − | ===Using access token to authenticate to services=== | + | *Selector generates an asymmetric (private/public) key pair |
| − | *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 | + | *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 | *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=== | + | === Secure local storage === |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | *After installation the selector securely stores for each local username/account | |
| − | * | + | **this selector's serial number |
| − | ** | + | **this selector's private key |
| − | ** | + | |
| − | ===Authenticating the user=== | + | === Login user interface === |
| − | *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 | + | *Has UI that prompts the user for username and 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 | + | **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 |
| − | *Selector gets an access token in response | + | **The purpose of the password is to authenticate the user to the selector (and to a lesser extent the user to the auth service) |
| − | *Selector sends this access token to a Higgins service (e.g. CardSync service) and gets a session token in response | + | |
| + | === 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 | *Selector uses this session token to access service | ||
| − | ===Credential storage=== | + | === Credential storage === |
| − | *The selector never stores the password, only a hash of the password | + | |
| + | *The selector never stores the password, only a hash of the password | ||
*The selector locally stores the username | *The selector locally stores the username | ||
| − | ===Cloud selector authentication=== | + | === Cloud selector authentication === |
| − | + | ||
| − | ===Adding a new selector to user's auth service account=== | + | *to-be-written |
| − | * 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 == | ||
| − | === | + | {| cellspacing="1" cellpadding="1" border="1" width="100%" |
| − | + | |- | |
| + | | align="center" | '''Resource''' | ||
| + | | align="center" | '''Path''' | ||
| + | | align="center" | '''HTTP operations''' | ||
| + | |- | ||
| + | | Captcha | ||
| + | | /captcha | ||
| + | | Get | ||
| + | |- | ||
| + | | byte[] | ||
| + | | /captcha/<captchaId> | ||
| + | | Get | ||
| + | |- | ||
| + | | User | ||
| + | | /user | ||
| + | | Post|Put | ||
| + | |- | ||
| + | | User | ||
| + | | /user/<username> | ||
| + | | Get|Delete | ||
| + | |- | ||
| + | | Selector | ||
| + | | /selector | ||
| + | | Get|Post|Put|Delete | ||
| + | |- | ||
| + | | Channel | ||
| + | | /cahnnels | ||
| + | | Get | ||
| + | |} | ||
| − | ==Implementation characteristics== | + | == Implementation characteristics == |
#RESTful web service | #RESTful web service | ||
| Line 117: | Line 169: | ||
#Uses open standards where possible | #Uses open standards where possible | ||
| − | ==Open Issues== | + | == Open Issues == |
| − | #Are there any performance issues with all this public key stuff? | + | |
| + | #Are there any performance issues with all this public key stuff? | ||
#Should we worry about "idle time"? | #Should we worry about "idle time"? | ||
| − | ==See Also== | + | == See Also == |
| − | * [[Selector Authentication]] | + | |
| + | *[[Selector Authentication]] | ||
Revision as of 06:39, 19 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
- 7 Rest API
- 8 Implementation characteristics
- 9 Open Issues
- 10 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 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 | Path | HTTP operations |
| Captcha | /captcha | Get |
| byte[] | /captcha/<captchaId> | Get |
| User | /user | Post|Put |
| User | /user/<username> | Get|Delete |
| Selector | /selector | Get|Post|Put|Delete |
| Channel | /cahnnels | Get |
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"?