CardSync Authentication

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

With the exception of addUserProfile, getPasswordResetCode etc. all CardSync Web App methods require authentication. This page describes the auth flow.

Sequences

These diagrams illustrate the sequence of interactions between a selector and the CardSync Service.

Authentication Process

1. Get Access Token (Sign on).
   
   1. Local ICard Selector may request AccessToken by passing one of the following types of credentials:
      • SamlTokenCredentialTO - for authenticating by using SAML token;
      • UsernamePasswordCredentialTO - for authenticating by using username/password.
   2. Card Sync Web App invokes authenticate(AuthCredentialTO) method of Card Sync Service.
   3. Card Sync Service delegate authentication to ILoginService (JAAS).
   4. if ILoginService authenticates user it returns a UserAccount instance (it needs for accessing protected data).
   5. Card Sync Web App invokes buildAccessToken(userAccount) Card Sync Service method for generating an AccessToken.
   6. Card Sync Service builds and stores AccessToken.
   7. Card Sync Web App returns AccessTokenTO to Local ICard Selector.
2. Get user protected data.
   
   1. Selector application asks Card Sync Web App for protected data by using Access Token Identifier (AccessTokenTO.id).
   2. Card Sync Web App delegates validation of Access Token Identifier to Card Sync Service's checkAccessToken(AccessTokenTO.id) method.
   3. if Access Token Identifier is valid Card Sync Service returns AccessToken.
   4. Card Sync Web App retrieves protected data by using AccessToken.
   5. Card Sync Web App returns protected data to Selector.
3. Delete Access Token (Sign out).
   
   1. Selector has to invoke deleteAccessToken(AccessTokenTO.id) Card Sync Web App method.
      
   2. Card Sync Web App delegates it to Card Sync Service by using deleteAccessToken(id) method.
      

Pass Access Token Identifier with HTTP header

We're going to support Rest API for synchronizing user cards. It assumes the use of http GET requests for retrieving protected data, so it has to include Access Token Identifier in request url. If we pass Access Token Identifier in the 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.

The Selector application should pass the Access Token Identifier by using http "Authorization" header according to the following format. Authorization: HWS <Access Token Identifier>

Access Token idle timeout and max live time

Access Token will be deleted automatically on server side:

• if it isn't used more than idle timeout;
• if maximum live time expires (difference between creation time and current server time).

Authentication with SAML token

1. Local ICard Selector has to invoke getSecurityPolicy() Card Sync Web App method for obtaining security policy.
2. Local ICard Selector has to invoke getAccessToken(SamlTokenCredentialTO) Card Sync Web App method for authenticating with SAML token.

Authentication with OpenId, X509Certificate, ...

To support new authentication types we have only to add one method, getAccessToken(<new credential data>).