How's calling my SSL Webservice ?

Hi,

first of all I have to admit I'm not that familiar with all the SSL terms, so I might mixed something up...

Ok - I have a SOAP / Axis Webservice which is called via a SSL connection. This works.

I have my private key and i want to create a certificate/public key (?) and give it to Person A and i create another certificate/public key and give it to person B... first question: is it possible to create different public keys for the same private key ?

The main question is, how can i distinguish between the two persons on the webservice level ?
So how do I retrieve from Axis the information "Zertificate A" was used or "Zertificate B", respectively.

Hope this was understandable... thanks very much for any comment.
Joerg

Welcome to Javaranch!

Originally posted by J�rg Herren:
So how do I retrieve from Axis the information "Zertificate A" was used or "Zertificate B", respectively.

SSL/TLS wasn't designed for non-repudiation - it merely keeps the recipients data safe from prying eyes (See SOAP security extensions: digital signature). And the idea of a "public key" is that you can hand it out freely to anyone without exposing your confidential data. If you give each user a separate key it would no longer be "public".

There are a variety of XML-based non-repudiation schemes - XML digital signature is used in some of them.
WS-Security also addresses non-repudiation and is implemented as Rampart for Axis2. With Axis 1.x you are limited to WSS4J.
[ November 20, 2008: Message edited by: Peer Reynders ]

thank you for this information... i will definitely have a look at this.

what i found additionally was:

To switch on authentication in axis web.xml via security-constraint and via MessageContext && HttpServletRequest I'm able to retrieve the user at the webservice...

it looks neatly - but i will have a look at the other stuff.

Thanks !

Originally posted by J�rg Herren:
I'm able to retrieve the user at the webservice...

From the above artice SOAP security extensions: digital signature:

Remember that in order to satisfy the requirement of non-repudiation, at a minimum you need to simultaneously guarantee both message authentication by using a digital signature and sender authentication.

The only thing you have achieved is "sender authentication" (actually "client account/machine" authentication) which is considered insufficient to establish non-repudiation. Also SSL/TLS can secure connections without client certificates - it only needs a server certificate.

From the perspective of an "interoperable" web service you are using information that is considered out-of-band from the SOAP traffic - making your web service less interoperable. SOAP by design is transport agnostic - i.e. it does not rely on any information that is available from its transport. So SOAP web services are discouraged from using any HTTP headers. In HTTPS the HTTP protocol runs on top of SSL/TLS - so SSL/TLS information is even more "out of bounds". A SOAP web service is supposed carry all the necessary information inside the SOAP envelope. So WS-Security would be considered the better option.
[ November 21, 2008: Message edited by: Peer Reynders ]

Peer,

Is it a good idea/possible to use HTTP digest authentication with web services?

Regards,
Dan

Any form of HTTP authentication ties the service to HTTP. That may not sound like a big deal (given that most web services are accessed over HTTP), but it also moves the authentication from the application layer to the transport layer. It "ends" wherever the SOAP call enters the server; if the call is transported onwards, it's no longer available.

So, I'd say that neither SSL nor HTTP Basic/Digest Authentication should still be used. Implementations of WS-Security (the SOAP standard that defines Authentication, Encryption and Signature) are widely available and well integrated with SOAP stacks. That's what I would use today.

Many thanks Ulf!