Nandana Mihindukulasooriya wrote:
Hi Devs,
Currently only way that a user provide a X509 certificate is through a
java key store. Sometimes a client may
only want to interact with only one particular service but even then it has
to create a key store and import the
certificate to it and specify it in the Rampart configuration. This may take
some effort specially if the service is
is .NET service. But if we can extend the Rampart configuration to specify
the certificate used for encryption as
a binary-encoded certificate, then we can remove all the hassle of creating
key stores.
For example, WCF has an extension by which they provide the certificate
of the service in the WSDL.
</wsdl:definitions>
</wsdl:service>
<wsdl:port >
<wsa:EndpointReference>
<Identity>
<KeyInfo>
<X509Data>
<X509Certificate>
......
</X509Certificate>
</X509Data>
</KeyInfo>
</Identity>
<wsa:EndpointReference>
<wsdl:port >
</wsdl:service>
</wsdl:definitions>
In this case, Rampart user who interact with this service only have to
extract the binary certificate from from the WSDL and
specify it in the Rampart Configuration. And almost every certificate tool
will allow to export the certificates in binary-encoded
format. So this will increase ease of interacting with non-java web
services.
Thoughts ?
+1.
Not only for encryption, but also for signature verification too.
So this means the Base64 encoded DERs (Or PEM format excluding the BEGIN
and END tags in a certificate) right?
I agree with the fact that creating, importing certificates is a messy
thing. User need to know "how Java key stores work" in order to use
Ramaprt. This is a problem with the PKCS#12 format in Rampart/C too.
Once we have the WSDL parsing, I'd like to see this feature in Rampart/C
as well. :)
Cheers,
Kau
Nandana
--
http://blog.kaushalye.org/
http://wso2.org/
