Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

I-Card Service Web App vs CardSync Web App Authentication


Higgins logo 76Wx100H.jpg

This page compares the authentication implementations used by two important Higgins services: I-Card Service and CardSync.

Deployment Configuration Alternatives and Issues

The I-Card Service is used to support what might be called "presentation-only" selectors (e.g. Cloud Selector, iPhone Selector, AIR Selector). In these selectors the selector client is mostly user interface code with the core processing done by the I-Card Service. The CardSync service, on the other hand, is used to support regular selectors (e.g. GTK Selector) where the core processing happens on the client--with the server performing card sync services across selector instances, some "core" authentication, and other lighter weight services. Since we plan to support BOTH types of selectors indefinitely in Higgins, the Higgins service "back end" must support both the I-Card Service and the CardSync Service.

These two web service may be deployed as two separate web applications or as one web application which includes both services (WS).

However, these two WSes delegate operations to the same underlying Higgins components (e.g. I-Card providers, UserProfile Service, etc ) which are cached user data (cards, user profile, etc). If we deploy I-Card Service and Cardsync as two separate web apps, they create two separate instances for each cache (cards, user profile, ...). Using two cache instances may cause some issues, if the user works with Cardsync from laptop and with I-Card Service from iphone.

Of course, we may synchronize these cache instances (we've already done it on for synchronizing them between clustered tomcat nodes, by using EhCache), but it may be preferable to deploy both WS's into one web app.

Authentication with AccessToken

This first section describes aspects of authentication that are common to both the I-Card Service Web App and the CardSync Web App.

Authentication workflow:

  1. Obtain an AccessToken by using AuthCredentialTO (signIn).
  2. Request protected data by using AccessToken.Id, Selector client has to pass AccessToken.Id by using authorization http header with prefix HWS "Authorization: HWS <Access Token Identifier>".
  3. Delete AccessToken (signOut).


AccessTokenTO contain the following fields:

  • String id - token identifier
  • Date issuedTime - issued date time
  • Integer maxIdleTime - max idle time in seconds
  • Integer maxLiveTime - maximum live time in seconds

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).


  • org.eclipse.higgins.sync.auth.IAuthenticateService defines the API for managing AccessToken entities.
  • org.eclipse.higgins.sync.auth.ehcache project implements IAuthenticateService by using EhCache libraries.
  • org.eclipse.higgins.user.login.LoginService defines the API for validating user credentials.
  • org.eclipse.higgins.user.idas project implements LoginService by using hibernate CP.


I-Card Service Web App

The I-Card Service Web App has two JAX-RPS WS endpoints.

  • RPPSService - each message includes username/password. (Deprecated)
  • SCRPPSService - each message is authenticated using an AccessToken.

Selector client has to:

  1. Invoke signIn WS method by using AuthCredentialTO.
  2. Invoke protected WS operations by using AccessToken.Id.
  3. Invoke signOut WS method.


CardSync Web App

Both CardSync endpoints Rest(/rs/) and JAX-WS (/ws/CardSync) support authentication with AccessToken. Rest selector client has to:

  1. POST AuthCredentialTO to "/AuthCredential" (signIn).
  2. GET/PUT/POST/DELETE protected data by using AccessToken.Id.
  3. DELETE AccessToken (signOut).


Login modules

Both I-Card Server Web App and CardSynch Web App delegate the validation of user credentials to the LoginService. It includes two login modules for validating user password.

  • First validates clean user password (old selector send clean user password to server)
  • Second validates sha-256 password hash (Serialized selector client send sha-256 password hash)

Auth Credential type

Both web apps support username/password credentials UsernamePasswordAuthCredentialTO and serialized client credentials SelectorAuthCredentialTO.

Add new Auth Credentials type

The following steps have to be done for supporting new Auth Credentials type:

  1. Define new AuthCredentialTO
  2. Implement new login modules for validating that credentials.
  3. Fix signIn method for supporting new Auth Credentials type.
  4. Add WS methods for associate new Auth Credentials with user account (optional).
  5. Add WS method for creating new user account by using new Auth Credentials type (optional).

For example, if we're going to support authentication with a SAML token, we have to also add a method for retrieving policy.

Single sign on logout

Authentication with AccessToken may implement single sign on log out pattern. I'm not sure, but i thing we shouldn't restrict active user sessions. For example user may use few selector clients from laptop and iphone or android phone in the same time.

Online/Offline user status

We may use AccessToken for checking online/offline user status. it may be useful for sending some user notifications in r-card forkflow.
However, we also may use "comet" pattern instead.

Back to the top