On Mon, Jun 2, 2008 at 4:32 AM, Manjula Peiris <[EMAIL PROTECTED]> wrote:
> > On Mon, 2008-06-02 at 04:15 -0700, Supun Kamburugamuva wrote: > > On Mon, Jun 2, 2008 at 2:51 AM, Manjula Peiris <[EMAIL PROTECTED]> wrote: > > > > > > > > On Mon, 2008-06-02 at 14:44 +0530, Kaushalye Kapuruge 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 this case do we really need to check the key store ? Because message > > > is signed using sender's private key and he is sending his certificate > > > to verify. So we need to verify using that and just need to be sure > that > > > the message is integrity protected by the way to the receiver. > > > > > > > Please consider this scenario. We have a service and we are accepting > > messages from different clients (We have fixed number of trusted clients > > that we need to serve). Most of these clients are not users and they are > > applications. They have a public/private key pair but do not have a user > > name. Now all of them are signing and sending there messages with their > > certificate inside the message. This scenario works as far as nobody > wants > > to cheat on us. Now if a unauthorized client wants to access the service > it > > can do that easily by sending a message with its certificate embedded in > the > > message. We don't differentiate between the authorized client and the > > unauthorized client since we are using whatever certificate embedded > inside > > the message. > > This is an authorization problem. So checking the authorization using > the public certificate is not the correct way. There are some other > means to handle this. I think if you really want to support this using > the key store you first need to look at the overhead of this key > comparison. AFAIK this is authentication. Authorization is a service specific thing that cannot be handled by Rampart/C and it has to be handled by the service. For example a particular client (axis2/C client) may be used by different user (i.e in a company application all the employees use the same client). But depending on the user (username/password) these users may have access to different resource levels. I think the other way that you are mentioning is username/password. But usernmae and password is not possible in all the scenarios. On the other hand in a policy you can specify whether to include the > certificate or not. So if you really want the authorization using this > what can be done is specifying not to include the token in your service > policy. Because people sends their certificates because it is easy for > receivers not to store each and every certificate. That's why there are > two mechanisms not to include your certificate and to include the > certificate in your message. > This is another strong reason why we should use this. Instead of sending the whole certificate we can send an unattached reference and the size of the message will be considerably reduced. > > > > > > > And if you are going to check whether the certificate is in the store > > > how are you going to do that? Because from the message you are getting > a > > > relatively big chunk of a string and finding that in the store may be a > > > time consuming operation. I mean even if you change it to a some other > > > format there is an unnecessary overhead. > > > > > > > AFAIK We don't have to parse the whole certificates to get a match. We > can > > use certain attributes of the certificate like issuer serial to check > > weather we have the certificate in the key store. > > > > > > > > > > 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. > > > Cheers, > > > Kaushalye > > > > > > > Regards, > > > > Supun. > > > > > > > > > > > > > > > >
