Currently IWeb allows you to encrypt the password, but it can be intercepted by a packet sniffer and “replayed”. To prevent this we have discussed it among the team and come up with two possible solutions. We would like to implement both of them and give developers a choice.

1) The client makes a call to IWeb and IWeb returns the current server time in minutes.
2) The client uses the pre-determined Security Key to encrypt the time and passes that value back to the IWeb when making a request
3) IWeb will attempt to unencrypted the value using the current time (and try one minute before and one minute after to account for slight differences).
4) The client can continue to make requests as it will change the value passed as each minute passes

Another method:

1) Client encrypts the user name/password pair using a shared encryption key
2) Client sends (possibly encrypted) user name/password to the IWeb
3) IWeb optionally decrypts the pair
4) IWeb validates the User, gets UserID and PortalID and generates a token containing UserID, PortalID, Timestamp of Token
Creation, Checksum and optionally some random data. IWeb encrypts this token using a key known ONLY to the server and returns it to the
client
5) Client sends token with each request
6) Server receives token, validates token, and checks if it has expired (is Current Time - Timestamp in Token > Timeout?). If expired, returns
a Session Timeout error, otherwise, continues

I envision expanding the current IWebAuthendicationHeader class (that is currently passed in the SOAP header) to contain additional properties such as:

SynchronizedEncryptionTiming (String) – This value if preset would indicate that the client is using an encrypted value based on the current time

EncryptionToken (String) – This value if preset would indicate that the client is using a Token