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
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
1. I think the IP idea is a bad one, because, as you said, they can be
spoofed. Plus what if they're using a dynamic IP?
2. I think you can use a combination of 2 and 3; Use public key
authentication to establish identity at the start of the session (you
can bind that to an IP if you wish), an
On 4/10/06, Angus Johnson <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Can anyone tell me whether I am right by making the following assumptions;
>
> To make sure the proper client is talking to our server over **HTTPS** with
> XML I can do the following to authenticate them:
> - validate their remote I
