Difference between revisions of "Authentication Service 2.0"

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

1. Use OpenID/OAuth where possible (if possible; security is key)
2. Allow Authentication Service 1.1 to also control the metadata (e.g. location) of $contexts via XRD discovery
3. Allow unmodified OpenID OP to be used (optionally) to auth to selector app
4. Allow XRI OP to be used to auth to selector app
5. Preserve today's "local" un/pw auth to be used as another option
6. All identifiers must use http[s] scheme
7. Authentication Service 1.1 requires another factor when directly accessing selector data (e.g. cloud selector functionality)
8. Client side must use native code for auth UI
9. Client code must use secure storage for "saved" passwords
10. Security must be at least as good as overall selector system today

Implementation

Service

• First version should be an OpenID OP and use OAuth for returning the access token
• Would authenticate using a combination of (i) a manually typed in un/pw + (ii) POP of a client-serialized-key + (perhaps) (iii) some digital fingerprint data from the machine
• Returns access token in browser redirect

Selector changes: LICS Authentication

Changes required to the un/pw login dialog box:

• Allow the user to login not just with a "local" un/pw approach, but also via one of a number of trusted OpenID providers. This would mean that the user could choose between "local" login (today's approach) or by clicking on 1..N buttons that represent OpenID or SAML IdPs.
• The login module would initiate an OpenID/OAuth interaction with the IdP. It would only initiate OpenID/OAuth to hard-coded list of IdPs.
• The login module would (through browser redirect back) end up with an access token
• The Local I-Card Service Package would send this access token (in addition to proof of possession of a serialization key) on every message to the I-Card Service 1.1, CardSync Service 1.1, IdAS Proxy Service 1.1 and the Attribute Service 1.1 "meta" Context.

While we're making changes to the login module:

• There could be a checkbox: "Clear all data from this machine when quitting this application". If checked, the LICS would delete all locally stored data from the machine when the Azigo app quit.

Changes to Selector-Supporting Services

The I-Card Service 1.1, CardSync Service 1.1, IdAS Proxy Service 1.1 and the Attribute Service 1.1 would all need to be changed to rely on the access token generated by the Authentication Service 1.1 for authentication.