Looking at the Google App Engine API, it seems that despite all its great features, the User API is extremely limiting. It seems you can only authenticate people who have a Google account, or use an OpenID account, or via some OAuth kung fu (handshaking with a Facebook account etc).
This appears to be a major stumbling block for anyone who wants a proprietary user base by creating user accounts within the application. In short, I don't want my users to have to use or create a Google account to access my app.
Has anyone else come across this limitation and has it been a deal breaker for using the GAE? Am I missing something? It is possible to deploy my own Spring based security etc within the app and use my own User API? Comments on this issue greatly appreciated. Thanks.
You're free to completely ignore the Users API and implement your own authentication system, as you would in any other hosting environment. Nothing about App Engine prevents you from doing so.
The Users API is just there as a convenience, in case you'd like to spare yourself the effort of re-implementing everything, and spare your users the inconvenience of filling out another sign up form and remembering another set of credentials.
You can always implement your own user management system.
In my application I have used spring-security for this purpose. spring security 3.0.1 works perfectly fine with app engine 1.3.5. There may occur some issues integrating other versions of both. I found below links extremely useful :
http://www.google-app-engine.com/blog/post/Spring-security-fix-for-google-app-engine.aspx.
http://www.dotnetguru2.org/bmarchesson/index.php?p=1100
http://groups.google.com/group/google-appengine-java/browse_thread/thread/964e7f5e42840d9c
Related
I am in process of designing a SaaS application over PaaS (Google App Engine).
My SaaS will have two user interfaces:
Web Based
Mobile App based
Web based would be feature-rich whereas Mobile app would have essential and/or frequently used features.
Mobile app would invoke RESTful services to perform business logic.
This SaaS would target mainly individuals using Mobile Apps; however, there could a use-case wherein these individuals could form a group and operate as a company.
So with that in mind, I am considering two entities: Account (Tenant) and User.
I am considering having many-to-many relationship between these two entities as one user could be part of multiple Accounts (unlikely but can’t be ruled out) and of course, one account can have multiple users.
I would like to know the best practices for authentication under such scenario:
Should I use Google's provided Authentication or should I implement my own authentication? (I am still exploring OAuth and Google's authentication offering.)
I think, for web-based interface, username/password over SSL would suffice. But, not sure, can this be applied to mobile app?
Can I avoid a situation wherein I have to store credentials in mobile app?
Thanks in advance for any help you can provide on this.
A
Having just completed my first project using Google App Engine, I can say that I ran into alot of the questions that you have. I'll try to explain my approach to each point and also approach it from your perspective as well.
Authentication - Generally using Google's auth would be the easiest route, but you would still have to implement a custom adaptation in order to work with the "company"/"group" concept. Implement in the datastore/whatever database you prefer to use an entity called "Groups" which have a list of google users... this way users can belong to many groups.. then you just search by property (user) to get all groups they belong to. I implemented my own authentication system for unrelated reasons.
Google App Engine comes with SSL/HTTPS support for its own domains. You can add in your own custom domain with SSL support as well. You can use SSL through native apps or mobile web apps additionally. I simply used the native support that came with it.
Yes and no. You will always have to store the credentials somewhere. Maybe it wont be in your apps code/directly connected to your app (Google auth would be an example). But somewhere, on your phone, the credentials WILL reside. They may be encrypted/obfuscated, but they will be there. So either have your user enter them in everytime, or save them/use the ones provided by the phone. For myself, .NET provided a nice way of storing credentials in a secure fashion (non-plain-text) for each user's machine.
I just got an Android phone, and of course I am itching to make an app for the platform.
I have an idea in mind, but it requires that I have a server that will offer REST-style services to the client phones. I have neither the skills on server security nor the money for a verified SSL certificate. I also wouldn't feel that great having people's login information (username, password) on my server, as I could get easily hacked.
So in a nutshell, will App Engine help out with these aspects? Basically, I do not trust myself in coding security-critical code, such as logins, and account creation/deletion. Maybe I'm making it seem more difficult than it really is, but I rather have that stuff taken care of already.
App Engine supports integrating with Android apps for authentication, as described here. In that respect, it's an excellent choice for a backend for an Android app.
It's good to not have unwarranted faith in your ability to write secure apps - but bear in mind that no platform is a silver bullet, and there's always possible avenues for security vulnerabilities.
Oauth in GAE works quite well, companies like Facebook and Dropbox and Twitter are using it. Access_token is send to the app (or browser) and with this access_token, the app can access the user's account without needed the username + password.
With GAE, you can use encryption (pycrypto) when storing the access_token on the user app, only to be decrypted by GAE when user logs in.
I'm using Google's user api on Google App Engine for authentification. As nearly everyone have a Google Account and api is easy to implement, that solution is convenient.
The problem is, though, with user who do not have a Google Account (or have no idea what a Google Account is). Where the api provides a nice interface to log in/log out and redirect immediately and easily to the app, nothing is said to developers about potential new users.
So here are a couple of things worth noticing:
Google' new Google Account page (https://www.google.com/accounts/NewAccount) is pretty straightforward, but not convenient at all for new users of a GAE app: no mention of anything not Google (users who don't really know what authentification is won't have any clue of why they need to open an account with Google), dead end (won't lead anywhere in the end), ugly.
GAE Log In screen includes a link to the New Google Account page. This link is of the form:
https://www.google.com/accounts/NewAccount?continue=http%3A%2F%2Fexample.com%2F_ah%2Flogin%3Fcontinue%3Dhttp%3A%2F%2Fexample.com%2Fprofile%2F&service=ah<mpl=gm&sig=0aa0a000aa000a00000aa0000a000aa
(Where example.com is the return url provided to the API). Great! But the situation is in no way different than it was: still a dead end, still no mention of any non-Google app, still ugly).
So, I'm asking, is there any imaginative way to provide a nicer interface for new users? Have anyone have ideas of how to present the process to the new users (a video for how to create a new account? some kind of tutorial page? etc.)? Just trying to think outside of the technical box here...
Regarding the various authentication options you can check out the Java or Python docs on OpenID (http://openid.net/)
Basically this allows supporting authentication by different agents, which includes Google accounts or even your own GAE application's custom implementation.
Furthermore you can check out User Experience summary for Federated Login for more information regarding UX considerations and best practices - with user authentication.
I am still trying to wrap my mind around the workings of OAuth/OpenID, as such...
I am developing an "installed app" that will run on computers and iPhone. A given user may install the client app on multiple machines, and all of the user's installed clients will synchronize via a centralized Google App Engine service. The GAE service will also allow multiple users to collaborate on the data produced by the installed app, via a web app.
I don't want to roll my own authentication system, for my own ease and also to spare users from yet another set of credentials. As such I was initially thinking of using Google's clientlogin service, but then I thought OAuth/OpenID would be better because it would allow users to use not just Google credentials but also credentials from the other OpenID providers. Also, avoiding asking the user for a login/password seems more secure.
My question is... I'm not sure if this is the right use case for OAuth/OpenID. I am not accessing data from any other service, I am just looking for an authentication solution. Also, how difficult is this scenario to accomplish using Google App Engine (java)?
Any advice and/or starting points would be much appreciated!
My question is... I'm not sure if this is the right use case for OAuth/OpenID.
The "use case" for oAuth is: App X requires access to App Y. App X "asks" permission for access to App Y through your credentials. App X received an "authorized access token".
In your case, assuming I understood correctly, you could have the App on GAE implement an OpenID consumer and have your mobile app access the GAE app through oAuth.
In other words, your approach seems like a sensible one.
I've been fooling around with the Google App Engine for a few days and I have a little hobby application that I want to write and deploy.
However I'd like to set it up so that users are not directly accessing the app via appspot.com.
Is hosting it through Google Apps and then pointing it at my own domain the only way to go? I looked at that a little bit and it seemed like a pain to implement but maybe I'm just missing something.
My other thought was to write the app-engine piece as a more generic web-service.
Then I could have the user-facing piece be hosted anywhere, written in any language, and have it query the appspot.com url.
Anyone have any luck with the web-service approach?
The reason Google Apps is required is because you need somewhere to a) verify you own the domain (otherwise, you might point it at app engine, then I might hijack it by adding it to my account) and b) set up domain mappings (which subdomains point to which of your appengine apps).
Since this stuff already exists in Apps, it seems silly to duplicate it in AppEngine.
As has been pointed out, it doesn't cost anything, and you do not need to "move" anything to Google. You simple created a cname record with a random name to verify you own the domain, and a cname for the subdomain you wish to point at App Engine. This only takes a few minutes, and once it's done, it's done forever.
Note: If you host your site elsewhere and use webservices, you need to scale the site/frontend. If you host on app engine, you get this for free :-)
I wrote an article on my blog about redirecting *.appspot.com domains to your custom domain to keep your branding:
http://blog.dantup.com/2009/12/redirecting-requests-from-appid-appspot-com-to-a-custom-domain
To do this, I believe you need to be using Google Apps and have a custom domain setup for Google Apps. Then, you deploy your app into your Google Apps domain.
Here is google's official instructions on how to do that:
http://code.google.com/appengine/docs/domain.html
I have used this process for a couple of sites and it is easy and painless, provided you have control on the DNS records for your domain (you should).
OK, we're now at the end of 2017 and things are a lot different regarding App Engine and custom domains. It's easy now!
Go to the app engine dashboard for your app and choose Settings, then go to the Custom Domains tab. From there, choose Add custom domain.
The tricky part is that Google needs to verify that you control the domain, so they ask you to put a TXT record in the DNS for your domain. Once you do that and Google it, you become "verified" as the owner of the domain.
After that, Google will give you a bunch of A and AAAA (for IP6) records to put in your DNS. Once you've done that, you should be good to go.
It can be easily done using request.getRequestURI() method. If the URL doesn't include your domain, just redirect it to the desired URL using
resp.sendRedirect("<your domain>")
Otherwise load a error page using
request.getRequestDispatcher("<error-page>").forward(request, response);