Hi all, In the case that supun mentioned, even clients private key and public key can be in any other format than files. So in this case we have to provide a way to specify them also. So it's just like exposing rampart configuration in policy file as a API.
I think if we are going to provide a way to specify the receiver certificate in the client side, we must expose other configuration parameters also. This will give some flexibility, but it will make web services clients more complicated by moving unnecessary configuration parameters to programming interface. Thanks Milinda.. On Mon, Jun 2, 2008 at 4:34 PM, Supun Kamburugamuva <[EMAIL PROTECTED]> 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. > > > > Cheers, > > Kaushalye > > > > Regards, > >> Supun. > >> > >> > >> > > > > > > -- > > http://blog.kaushalye.org/ > > http://wso2.org/ > > > > > -- http://mpathirage.com http://wso2.org "Oxygen for Web Service Developers" http://wsaxc.blogspot.com "Web Services With Axis2/C"
