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"
(→High Level Requirements) |
(added OTP idea) |
||
| Line 18: | Line 18: | ||
#Accepts authentication materials, evaluates them, if acceptable generates an access token that it returns to the consumer/client | #Accepts authentication materials, evaluates them, if acceptable generates an access token that it returns to the consumer/client | ||
#Can authenticate "serialized" selector clients to this service | #Can authenticate "serialized" selector clients to this service | ||
| − | #* | + | #* Can provision selector clients with serialized key |
| + | #* For Selector clients, input from client: userid + password + selectorId + serialized key (usage of this is TBD - maybe these items are sent, or maybe just proof of them is sent) | ||
| + | #* For clientless access (i.e., web 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. | ||
Implementation characteristics: | Implementation characteristics: | ||
Revision as of 16:20, 11 September 2009
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
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
Functionality:
- Accepts authentication materials, evaluates them, if acceptable generates an access token that it returns to the consumer/client
- Can authenticate "serialized" selector clients to this service
- Can provision selector clients with serialized key
- For Selector clients, input from client: userid + password + selectorId + serialized key (usage of this is TBD - maybe these items are sent, or maybe just proof of them is sent)
- For clientless access (i.e., web 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.
Implementation characteristics:
- RESTful web service
- Security is of course important
- Uses open standards where possible