Ok, so I've got so far as to be able to create non-cookie expiring sessions for a rest service.
One thing that has bothered me is that in order to authenticate, you need to "log on". In a rest-style service, then means that you have to pass the user name and password in a url.
This I don't like.
I see a couple of options :
1) encrypt the username + password before sending. This would require some js on the client side, which could be reverse-engineered to work out the encryption method
2) use a https connection to (supposedly) prevent man-in-the-middle attacks. This would not prevent the browser keeping a copy of the url (complete with url parameters such as your name and password)
3) use a https connection to (supposedly) prevent man-in-the-middle attacks, with hidden fields to stop the browser keeping a copy of the url (complete with url parameters such as your name and password)
4) use a POST https connection to (supposedly) prevent man-in-the-middle attacks, with the fields sent as data so it doesn't appear in the url
Q1) : Are there any other better options
Q2): Given that there is only the choice of 1-4, which choice is the best ? I am leaning towards 4
Thanks!
Julian
Sorry I missed your email. I am out of the office until Tuesday 2nd April with little access to email.
Thanks, Andrew
Doesn't the REST Adapter support http basic authentication? At least the OE Mobile docs say that http basic authentication is supported.
That way the encoded password is passed with the encoded username in the http header.
Jullan,
Web servers offer a number of peer reviewed authentication models that will work with the majority of HTTP clients. You appear to be very concerned about security, so I'm assuming you are using perimiter authentication security in the web server.
So you have the well known choices of:
HTTP Basic: (using either URL or header transport) no login-logout sessions, plus the level of obfuscation is pitiful
HTTP Digest: no login-logout sessions, but a good level of obscuring the credentials
FORM: login-logout sessions, but requires using HTTPS & POST to secure the credentials
SSL Client Authn: great security - but a pain in the a** to manage and distribute client certificates
Federated 3rd party: CAS, openid, siteminder, ... good security but is yet another moving part to configure and maintain
My opinion: never, ever, pass user credentials in the URL. Even with https that could expose the credentials.
My personal best choice is FORM over a HTTPS connection, just from a session management and simplicity standpoint. But the choice is really yours depending on the value of the data.
I do not know specifically what your security requirements are, but I hope this information is of some use.
Mike Jacobs
The REST adapter is tested with HTTP BASIC and FORM authentication models, today. The plans (such as plans go) is to also certify the HTTP Digest, SSL client, and some (?) level of Federated 3rd party over the next releases. But this is subject to change as more infromation comes in.
Mike Jacobs