+1 Good idea! ... this will help a lot of our users in getting most of the scenarios to interop easily.
Thanks, Ruchith 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 ? > > Nandana >
signature.asc
Description: OpenPGP digital signature
