Difference between revisions of "CardSync Authentication"

Revision as of 11:12, 7 April 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

With the exception of addUserProfile, getPasswordResetCode etc. all CardSync API methods require user authentication. These diagrams illustrate the sequence of interactions between Local I-Card Selector and CardSync Web App.

NOTE: this page is obsolete after a discussion on this topic week of 3/30/2009

Authentication Process

1. Get Access Token (Sign on).
1.1 Local ICard Selector may request AccessToken by passing the following credentials:

• SamlTokenCredentialTO - for authenticating by using SAML token;
• UsernamePasswordCredentialTO - for authenticating by using username/password.

1.2 Card Sync Web App invokes authenticate(AuthCredentialTO) method of Card Sync Service.
1.3 Card Sync Service delegate authentication to ILoginService (JAAS).
1.4 if ILoginService may authenticate user it return UserAccout instance (it needs for accessing protected data).
1.5 Card Sync Web App invokes buildAccessToken(userAccount) Card Sync Service method for generating AccessToken.
1.6 Card Sync Service builds and stores AccessToken.
1.7 Card Sync Web App return AccessTokenTO to Local ICard Selector.

2. Get user protected data.
2.1 Local ICard Selector asking Card Sync Web App for protected data by using Access Token Identifier (AccessTokenTO.id).
2.2 Card Sync Web App delegates validation of Access Token Identifier to Card Sync Service checkAccessToken(AccessTokenTO.id).
2.3 if Access Token Identifier is valid Card Sync Service return AccessToken.
2.4 Card Sync Web App retrieve protected data by using AccessToken.
2.5 Card Sync Web App return protected data to Local ICard Selector.

3. Delete Access Token (Sign out).
3.1 Local ICard Selector has to invoke deleteAccessToken(AccessTokenTO.id) Card Sync Web App method.
3.2 Card Sync Web App delegates it to Card Sync Service by using deleteAccessToken(id) method.

Pass Access Token Identifier with HTTP header "access_token"

We're going to support Rest API for synchronizing user cards. It assumes to use http GET requests for retrieving protectedn data, so it has to include Access Token Identifier to request url. if we pass Access Token Identifier by using http header, it may be more protected way (of course only with https).

Both Rest and Soap web services would read access token from http headers.

Encrypt/Decrypt Access Token Identifier

For prevent unauthorized access, we would encrypt Access Token Identifier by using public user key (on server side) and public server key (on client side).

Access Token idle timeout

if Access Token wasn't used more than idle timeout, it will be deleted automatically.

Single sign on

We would support single sign-on/sign-out workflow. it makes sense by secure reason ( and it may be useful for r-card solution).

Authentication with OpenId, X509Certificate, ...

For supporting new authentication type we have to add just one method getAccessToken(new credential data ).