Supun Kamburugamuva wrote:
On Mon, Jun 2, 2008 at 2:14 AM, Kaushalye Kapuruge <[EMAIL PROTECTED]>
wrote:
Supun Kamburugamuva wrote:
Hi List,
At the moment a Rampart/C service can handle single client for signed
messages. This is because of the static configuration of the certificate
files. Now Rampart/C supports the PKCS12 key stores. A PKCS12 key store
allows the service writer to specify multiple certificates. These
certificates can be used by the service to verify weather the actual
signature is from a trusted user.
This is the proposed way of handling multiple clients in the server side.
Service writer has to create a key store with the certificates of all the
trusted parties. A request has a reference to the certificate that it used
for signing. Usually there are various ways to refer an X509 certificate.
First case is to embed the certificate in the message itself. In this case
the reference will be a direct one. Rampart/C will extract the certificate
from the message and checks weather it is in the certificate store. If it
is
in the store it indicates that a trusted user has signed the message. If
the
certificate is not in the store the request is rejected.
In the second case the certificate is not embedded in the message and a
reference to the certificate is sent. In this case the reference will be
used to query the PKCS12 key store and if a matching certificate is found
it
will be used to verify the signature of the message. If a match cannot be
found the message is rejected.
In both these cases the certificate that is loaded in the in path will be
used for the encryption in the out path. So we are assuming that the
response is always going to the end point where the message originated.
In the client side the situation is different. Usually a single client
will
talk with a single service. So the existing mechanism is enough to handle
most of the cases. But if the client wants to change the certificates
among
different requests he should be able to do that. We can easily achieve
this
by introducing a new parameter to the rampart client configuration.
I hope you are trying to suggest a way to a scenario, where a client needs
to call the "same service" by using different certificates on multiple
requests. And I'm sorry I do not see a relationship between the start of the
mail and the end. Are you trying to say that we can achieve above
requirement using PKCS12? And what the "parameter" you are trying to
introduce and how exactly that effects the client behavior?
If it's different services then existing features would be enough I guess.
Client needs to change bunch of other parameters apart from the certificate.
As I have mentioned earlier our existing infrastructure is enough to handle
the scenario where client always knows who he is going to talk and he has
the certificate file of the resource provider (Most of the time this will be
the case). But imagine a situation where a client doesn't have the receiver
certificate as a file. In that case he needs to specify the certificate to
the Rampart/C. The best way to do this is to set the certificate to the
rampart_config_t in the client side. We don't have to worry about the place
where the client get the certificate. It can be a database, PKCS12 store,
network call etc.
OK. Now I know where this originated. :-)
Definitely +1 for expanding rampart_config_t. I was confused with the
pkcs12 discussion and the "new" parameter you mentioned.
So Yes... giving client code the flexibility of building configurations
is definitely a good idea.
But even in this case also client must know about the receiving party
(Obvious). The advantage is that Rampart/C doesn't need to worry about
the way that the certificates are stored/specified.
And also I'd like to see a more flexible way of processing key info.
Right now we are processing key information based on standard patterns,
those information can be appeared in a SOAP request. For example the
Subject Key Identifier(SKI).
But note that the specification allows having any information within key
info. For example I can use my NID number with a particular service to
reference my certificate, which is a non-standard way. If the service is
agreed upon a particluar identification that it's clients can abide by,
we should have a way to support it.
So what about having an optional callback for that in the service end?
The primary task of the callback is to process the SOAP header and load
the certificates/keys.
Cheers,
Kaushalye
Cheers,
Kaushalye
Regards,
Supun.
--
http://blog.kaushalye.org/
http://wso2.org/
--
http://blog.kaushalye.org/
http://wso2.org/
