Difference between revisions of "Authentication Service 2.0"

Revision as of 17:22, 10 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:

1. Accepts authentication materials, evaluates them, if acceptable generates an access token that it returns to the consumer/client
2. Can authenticate "serialized" selector clients to this service
   • Input from client: selectorId + proof of possession of a secret key

Implementation characteristics:

1. RESTful web service
2. Security is critical
3. Uses open standards where possible (e.g. OpenID/OAuth etc.)

Compatibility:

1. Can be used as the authentication service of an OpenID "OP" (IdP)