Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "I-Card Service Web App vs CardSync Web App Authentication"

(CardSynch Web App)
(Add new Auth Credentials type)
Line 62: Line 62:
  
 
==Add new Auth Credentials type==
 
==Add new Auth Credentials type==
The following steps have to be done for supporting new Auth Credentials type:<br>
+
The following steps have to be done for supporting new Auth Credentials type:
1.  Define new AuthCredentialTO.<br>
+
#Define new AuthCredentialTO
2.  Implement  new login modules for validating that credentials.<br>
+
#Implement  new login modules for validating that credentials.
3.  Fix signIn method for supporting  new Auth Credentials type.<br>
+
#Fix signIn method for supporting  new Auth Credentials type.
4.  Add WS methods for associate new Auth Credentials with user account (optional).<br>
+
#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).<br>
+
#Add WS method for creating new user  account by using new Auth Credentials type (optional).
<br>
+
For example, if we're going to support authentication with a SAML token, we have to also add a method for retrieving policy.
For example, if we're going to support authentication with SAML token, we have to also add method for retrieving policy.<br>
+
  
 
==Single sign on logout==
 
==Single sign on logout==

Revision as of 00:11, 1 July 2009

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

Higgins logo 76Wx100H.jpg

All web services (Rest/JAX-WS/JAX-RPC) may/should be deployed into one web app. Latest CardSync build includes all I-card Server WS endpoints.

Authentication with AccessToken

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

AccessTokenTO contain the following fields:

* String id - represents token identifier.
* Date issuedTime - represents issued date time.
* Integer maxIdleTime  - represents max idle time in seconds.
* Integer maxLiveTime - represents 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 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 API for validating user credentials.
org.eclipse.higgins.user.idas project implements LoginService by using hibernate CP.

Rpps.core.tobj.png

I-card Server Web App

I-card Server Web App have two JAX-RPS WS endpoints.

  • RPPSService requires to send username/password every time. (Deprecated)
  • SCRPPSService requires to use authentication with 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.


RppsAuthSequenceDiagram.png

CardSynch Web App

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


CardSynchAuthSequenceDiagram.png

Login modules

Both I-card Server Web App and CardSynch Web App delegate validating user credentials to 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" http://en.wikipedia.org/wiki/Comet_(programming) pattern instead.

Back to the top