Initial drafts on the WSS4C architecture

[Sharanka Perera <sh...@opensource.lk>]

Hi all, 

I've attached a document that outlines the initial draft architectural design overview on WSS4C. It's not very comprehensive right now, but we're taking one step at a time. Lots of research work happening concurrently with the design work makes it slow going. 

I've elaborated on both diagrams below: 

Diagram 1: 

This gives a general overall view of the WSS4C project, and how it would plug in to a SOAP Server, such as Axis C++. In this scenario, the wsdd file shown in the diagram would contain the necessary configuration details and/or instructions for SOAP message handling. During the course of SOAP message processing, the SOAP Engine will pass the partially processed message to the security handler (one of possibly many included in the wsdd file). On the client-side, the client-side security handler would add all the necessary security headers, then get the body of the SOAP message, perform all necessary actions and give the secured message back to the SOAP Engine, and where it will be eventually transmitted to its counterpart across a network (in this case the Internet).

On the receiving end, the Transport Listener (for example, the Apache Web Server) will receive the SOAP message and pass it on to the SOAP Engine. After some initial processing, the Engine will call the security handler. The server-side handler would then perform a reverse operation as described by the wsdd file, i.e. decrypt any portion of the message intended for a particular web service, validate signatures, validate tokens etc. before passing it (the message) back to the SOAP Engine. The required functionality for the handlers are provided by the WSS4C API.



Diagram 2: 

This diagram summarizes the list of functions the WSS4C API is expected to have eventually. These are: XML signature handling, XML encryption and Tokenization. 



As always, any feedback would be much appreciated. 

With regards, 

Sharanka

Re: Initial drafts on the WSS4C architecture

[Davanum Srinivas <da...@gmail.com>]

looks good.

-- dims


----- Original Message -----
From: Sharanka Perera <sh...@opensource.lk>
Date: Wed, 23 Jun 2004 04:27:37 +0600
Subject: Initial drafts on the WSS4C architecture
To: fx-dev@ws.apache.org











Hi all, 



I've attached a document that outlines the 
initial draft architectural design overview on WSS4C. It's not very 
comprehensive right now, but we're taking one step at a time. Lots of research 
work happening concurrently with the design work makes it slow 
going. 


I've elaborated on both diagrams 
below: 


Diagram 1: 



This gives a general overall view of the WSS4C 
project, and how it would plug in to a SOAP Server, such as Axis C++. In this 
scenario, the wsdd file shown in the diagram would contain the necessary 
configuration details and/or instructions for SOAP message handling. During the 
course of SOAP message processing, the SOAP Engine will pass the partially 
processed message to the security handler (one of possibly many included in the 
wsdd file). On the client-side, the client-side security handler would add 
all the necessary security headers, then get the body of the SOAP message, 
perform all necessary actions and give the secured message back to the SOAP 
Engine, and where it will be eventually transmitted to its counterpart across a 
network (in this case the Internet).


On the receiving end, the Transport Listener 
(for example, the Apache Web Server) will receive the SOAP message and pass it 
on to the SOAP Engine. After some initial processing, the Engine will 
call the security handler. The server-side handler would then perform a 
reverse operation as described by the wsdd file, i.e. decrypt any
portion of the
message intended for a particular web service, validate signatures, validate 
tokens etc. before passing it (the message) back to the SOAP 
Engine. The required functionality 
for the handlers are provided by the WSS4C API.


 


Diagram 
2: 


This diagram summarizes the list of functions 
the WSS4C API is expected to have eventually. These are: XML signature
handling,
XML encryption and Tokenization. 


 


As always, any feedback would be much 
appreciated. 


With regards, 


Sharanka



architectural draft - 22nd June 2004.pdf - 28K



-- 
Davanum Srinivas - http://webservices.apache.org/~dims/