views:

296

answers:

3

Hi,

We are starting a very large web based service project. We are trying to decide what hosting environment to use. We would really like to use Google App Engine for scalability reasons and to eliminate the need to deal with servers ourselves.

Secure logins/registrations is very important to us, as well as using our own domain. Our target audience is not very computer savvy. For this reason, we don't want to have the users have to sign up with OpenID as this can't be done within our site. We also do not want to force our customers to sign up with Google.

As far as I can see, I am out of luck. I am hoping to have a definite answer to this question. Can I have an encrypted login to our site accessed via our domain, without having to send the customers to another site for the login (OpenID/Google).

Thanks.

+2  A: 

There is nothing stopping you from creating your own authentication/registration mechanism with Google App Engine. The only problem is that Google App Engine currently only supports HTTPS via https://yourid.appspot.com and not your Google Apps Domain (i.e. https://www.foobar.com). However, this is on the product roadmap for future support (SSL for third-party domains). Note, also on the product roadmap is built-in support for OAuth & OpenID.

Update: Another option may be to use a proxy server (like Apache with mod_proxy) and map your domain to the proxy server and then the proxy server can proxy the HTTP and HTTPS requests to Google App Engine. The requests could be proxied to the appspot.com domain behind the scenes. I haven't actually done this, but I believe it should work. However, this would give you a single point of failure at the proxy server which basically defeats the purpose of Google App Engine's high-availability and scalability. This would definitely just be a short-term solution until Google supports SSL for third-party domains or OpenID.

Taylor Leese
Yeah I am aware about that which is why I am hoping to find another solution. As far as I am aware, the plan is to implement TLS SNI which doesn't work on Windows XP (any browser) which in my opinion is not an acceptable solution for a public site where you don't control your customers' environments.
mhost
Another option that may or may not work for you is to post to the HTTPS URL's from an HTTP page. This way the users would never actually see the https://yourid.appspot.com domain unless they look at the HTML. I know this is a hack, but it might be good enough for some scenarios.
Taylor Leese
The built in support for OpenID (on the product roadmap) will probably be a better solution than the TLS SNI in the short-term. There are still way too many people with Windows XP to not support those users, I agree.
Taylor Leese
This is the related Google App Engine issue: http://code.google.com/p/googleappengine/issues/detail?id=792
Taylor Leese
@Taylor L - Posting to https from a http form is NOT secure. The browser won't show the padlock/URL won't read https, and this in itself is a deterrent. Besides, it is easy to do a man-in-the-middle attack.
sri
Actually, it is reasonably secure. The only issues are the man in the middle attack and not showing the padlock. However, if you look at facebook.com you'll notice they do this exact thing. They post to https from http for a simple login. Doing this is still pretty secure, but it's just not as secure as going from https to https. Also, as far as GAE goes, I think it's a better user experience than showing the appspot.com domain. It all really depends on how secure the site needs to be. However, if you need the site to be totally secure then GAE is probably not where you want to be right now.
Taylor Leese
+3  A: 

The hardest part is getting around the cookie issue. While you can do secure and custom logins against https://yourdomain.appspot.com, you cannot set a cookie there that will work on http://yourdomain.com.

Here is what I propose:

When you need to log the user in, send them to https://yourdomain.appspot.com. If they enter the credentials properly, create a one-time token and place it either in the datastore or in memcache. Give it a lifetime of a few seconds.

Then redirect the user back to http://yourdomain.com/authenticate?token=mytoken (obviously substitute the names as appropriate), check to make sure that the token is valid and has not expired, and if all is clear, set the appropriate cookies and expire the token.

I think that'd work just fine. Hope it helps!

Michael Gorsuch
+1  A: 

Here you go: http://www.tophatmonocle.com/blog/2010/4/22/secure-login-app-engine/

Mike
This is a nice solution except it won't work for users with JavaScript disabled. Thanks.
mhost