I think Haikal is onto it - HTTPS with client certificates. Traffic is encrypted with HTTPS & idenitifcation is ensured by the cetificates at both ends.
If you are talking client (i.e. browser) / server I don't think CF would really need to be involved at all - the browser and web server should be able to take care of all that. Have a look at http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#accesscontrol and http://www.garex.net/apache/#CACreation If you are talking about web services I guess your CF "client" would need to know how to pass through cert information, but at the other end it would still be Apache receiving the request and handling the HTTPS end of things. CF on the server end might see some extra CGI variables, but that's about it. On 4/10/06, Angus Johnson <[EMAIL PROTECTED]> wrote: > > Thanks guys! > > Gavin, I think I follow what you're saying with the port forwarding. Sounds > like a pretty cool idea but relies on the customer having control over port > allocations/routing? I don't know whether we could count on that... > certainly something our enterprise clients could implement for that "feel > secure" factor :) > > Looks like public keys is the way to go. If I am not mistaken the only way > to get public keys into the CF picture will be to work with Java directly. > Is this correct? > We want to really keep things as simple as possible. > > Cheers > Angus > > > > > -- Mark Stanton Gruden Pty Ltd http://www.gruden.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie -~----------~----~----~----~------~----~------~--~---
