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"
(added OTP idea) |
|||
| Line 1: | Line 1: | ||
| − | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} | + | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins logo 76Wx100H.jpg|right]] |
| − | [[Image: | + | |
This page describes a new network [[Authentication Service 1.1]]. | This page describes a new network [[Authentication Service 1.1]]. | ||
| − | == Objective == | + | == 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]]. | 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 == | + | == 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | Implementation characteristics: | + | == High Level Requirements == |
| − | #RESTful web service | + | |
| − | #Security is of course important | + | 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 | #Uses open standards where possible | ||
| + | |||
| + | ==See Also== | ||
| + | * [[Selector Authentication]] | ||
Revision as of 14:16, 15 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