What type of message traffic are you expecting? SOAP? We are working on
a WS-Security acceleration product that currently uses SW and supports
our HW acceleration plans. Yes, signature acceleration et al. Just for
kicks (not like we all have a lot of time), you might want to look at
www.intel.com/software/xml . There is an AXIS2 compatible Beta in Linux
for download.
We will have Windows support and a Java API available in Beta at the end
of March 08.

David E.A. Johnson
Director, Digital Security Products
Intel Corporation
SSG-MMD
1815 S. Meyers Rd., Suite 150
Oakbrook Terrace, Illinois  60441
770-433-3272 direct
404-769-7207 mobile
 

-----Original Message-----
From: Paul Fremantle [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 18, 2008 5:31 PM
To: axis-user@ws.apache.org; Ruchith Fernando
Subject: Re: WS-Security, SSL or both

I'm copying Ruchith... he's the real guru. But here are some answers:

> The web method implementations must be aware of the client identity...
so
> authentication information must be available to the web method..

Would username/token do? Or do you need the authentication to be based
on certificates?

> 1) Is it possible to access two-way SSL authentication information
from a
> web service? (assuming SSL is setup on the axis server - no reverse
proxy)

You can always access the Tomcat/Servlet/HTTP context, so if the SSL
client cert information is available from the servlet context (which
it is) you can get at it in your Axis2 service.


> 2) if not.. would it make sense to have one-way SSL for encryption and
> XML-Signature for authentication? how would that perform? Would
> XML-Signature increase the message size drastically? Any alternatives?

Unfortunately its not just encryption that is slow. Basically the
signature has to do the following:

A) create a hash of the message
B) Encrypt the hash with the private key (which is how signatures work)

The hash uses an xml algorithm called DOMHash, which is not very fast.
The public/private key signature isn't very efficient either.
So, the result is you'll still have a performance hit.

The alternative is to use Username/Token for authentication, or if
that is no good, you can use X509Token for authentication. So
effectively you can use SSL for encryption and use a client cert to
authenticate, but no message signature.

There is another alternative, which is to use WS-Trust and
WS-SecureConversation. This makes life more efficient if you have more
than one message exchange (which I'm guessing you will if this is a
B2B sort of situation). Basically, the client uses UserName token or
the X509 cert to set up the session. Then the server issues a token.
The token acts as an ephemeral key which can be used for traditional
symmetric encryption and signature. So now the conversation can
proceed much more efficiently.

> 3) I also read that PK encryption is too intensive for message
encryption..
> and is normally used to to exchange a session key - does the
performance
> problem apply to digital signatures? is the session key exchange part
of the
> Ws-Security spec or do I have to develop a web method that generates
the
> session key?

Basically this is the model I described with WS-Trust and SecureConv.
Effectively this models the session startup that SSL does in XML. The
upside is the efficiency. The downside is that you need more "stuff".
So for example, you can interoperate with .NET, but some older stacks
don't do WS-SecConv and Trust.

Paul

-- 
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to