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), and them use a token for the rest of the session. As you are using SSL, and the token is set up per session, it's not going to be of use to anyone by the time they crack the encryption. That said, my gut feeling says the most elegant solution would be to use SSL with client certificates, and be done with it, but I have no idea how CF would support that. Angus Johnson 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 IP (apparently can be spoofed??) to the one we > have on file > - work with public keys > - have them include a password in the XML packet (obviously this could > be guessed by brute force) > > Can't think of anything else, and I am assuming that the public key > method would be the way to go? > > The scenario is: the clients are posting XML and we are returning XML > but want to make sure they are subscribed to our services and are who > they say they are. > > Thanks for any help > Angus > > > -- Haikal Saadh, Applications Programmer Teaching and Learning Support Services K405, Queensland University of Technology, Kelvin Grove Campus [EMAIL PROTECTED], 3864 8633 CRICOS No. 00213J --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
