Tag Archives: Architecture

by Nimal | November 17, 2008 · 10:08 pm

Browser Plug-in Workflow

We are in the process of developing the eID Browser Plug-in. This will be divided into two parts, one plug-in and the second underlying application, which will do the real work.

We just discussed about the basic workflow of messages/actions in the browser plugin. I’ll just summerise what we have decided on.

Starts with the browser plug-in in the user’s browser.

  • Browser page detected – using some tags or some other method
  • Get the signed policy file from the Relying Party
  • Get user acceptance to the policy
  • Pass it down to the application

Now the underlying application will take control.

  • Application access the eID card (Smart Card/USB)
  • Do signing and encryption as needed
  • Policy need to be signed by the user to ensure acceptance
  • Send to Web Service

Now the ball in the court of WS. It does whatever it need to do and it will reply to the application. Application gets control again.

  • Analyse the received reply
  • Send back the reply to the browser plug-in

Control back to the plug-in. Send the reply back to the Relying Party website, and the user continues to do this stuff at the site.

This might be a long list but this need to happen within about a 15-30 seconds, and I think Shayanthan and Ramanan will make sure this works. Will keep updated one more soon.

Filed under Articles, News

Tagged as ,

by anuradha | November 10, 2008 · 10:10 pm

R9: Moving to new Architecture

Due to problem we had with web service developments, we meet Dr. Chandana Gamage within the week started after the vacation. Then we discussed about the current situation of the project and the problems we had regarding the eID system architecture and web service development. Finally in that meeting we figure out several problems with the architecture.

  • High probability of malicious attacks to eID system
  • Most of the processing are happening in the server side (high work load on server)
  • Difficulty of developing a web service with that architecture

Because of that, I proposed new idea about the system architecture. Which is more user controllable and more secured. After the meeting with Dr. Chandana Gamage, we had another group meeting and discussed about problems we had and solutions provided by the new architecture. Also, abilities we have to be continued with the existing architecture.

Then again we had meeting with Dr. Chandana Gamage, regarding the latest condition of the project architecture. Finally we decided, that is better to move in to new architecture which is having more capabilities of implementing eID system.
Also in that meeting Dr. Chandana Gamage advice us to come across a mechanism, which is using read-only USB memory stick for eID card rather than USB smart card.

After that, I start to develop the eID web service according to the new architecture. Also I had read lots of articles about the AXIS2 and AXIOM data modal. Also after some discussions we decided to use “RSA” for encryption, decryption and signing.

Filed under Reports

Tagged as ,

by Shayanth | October 26, 2008 · 12:00 am

R8: Think about New Architecture

After the exam, we had gathered two meeting with our supervisor Dr. Chandana Gamage. After our discussions with the supervisor, we had to change the system architecture. According to our previous architecture we planned to have the eID system in between the Reliant Party (RP) and the clients. For that architecture we identified there is the problem in the client authentication was services. We needed to redirect the request to the client to get his authentication details. So we identified that there is problem in the request redirection part because it is impossible to redirect the request in the web services.
There for I planned to develop a layer in between the Reliant party and the eID services. That layer help to redirect the request and get the client authentication details from the client.
But after the discussion with the supervisor, he didn’t suggest us to maintain that kind of architecture in the eID system. Then we planned another flexible architecture.
Then I started to find out the way to handle the message passing mechanism in between the client and eID card and the eID server. Then finally I found a solution to overcome that problem through the Java Applet. Through the Java Applet client and the eID server can communicate by using HTTP requests.
So finally we all are re planning the system architecture.

Filed under Reports

Tagged as , ,

by Nimal | October 24, 2008 · 2:02 pm

Options for architecture. Which we select?

After the meeting with our project supervisor yesterday, we decided to review the two architectures for online authentication mechanism. I’d like to present some of our findings and thoughts on these two in this post.

The first architecture is the one that we already had. In that model eID systems stays in the middle in the authentication processs between the eID Card Holder and the Relying Party. The system will be using a Java Applet to perform authentication with the eID Card Holder.

The second architecture that we proposed at yesterdays meeting. It keeps the eID Holder in the middle of the process, giving more control over what is happening. In this model the communication between the Relying Party and the eID System happens solely through the eID Card Holder. But for this to work we might have to use a local application or a browser plugin to perform many of the actions.

After some long discussions within the group members, we thought we should stick with the first design than the second one. I’d like to point out some of the points which led us to this decision.

Problems identified in the first design:

  • Session handling method
  • Tie up message flow
  • Possible DoS attacks

How those could be solved:

  • We can use session tokens accross a transaction, which could solve session handling and tie up message flow
  • To prevent DoS attacks, there are many standard procedures. Using CAPTCHAs could be a very basic but an effective method in this. Also there are other measures that could be taken to prevent DoS attacks at system level.

Problems identified in the second design:

  • Complexity on the Relying Party interms of Signing and Verifying Signs. This is a problems as we cannot expect every system developer how wants to use eID System to know and implement these complex tasks.
  • Communication from the local application/plug-in will be a problem, unless we use HTTP. Also this needs certain installation and permission at user computer.

Also there is one important reason for deciding not to use the second design. The second design is very much identical to the Card Space specification. And these is already an implemention of this as WSO2 Identity Solution. Though there are significant differences from this and Project eID, following the same basic design would be like a duplication of systems.

So we have currently decided to use the our earliear design, but we can use any good features in the later design. I hope we could finalize on this by today evening. I’ll try to post an update on this by today night.

Filed under Articles

Tagged as