1 - Current situation
We've got a REST API (coded with the Play framework 2.5 in Java) and four front-end interacting with it (two web apps: a back office and our site coded with React, and two mobile apps: Android and iOS).
Everything is working correctly, but without user management.
2 - What we want to do
We would like to add user management with two roles: user (can sign up and log in to our site and our mobile apps) and admin (can do everything a user can do plus can log in to the back office). In other terms, administrators can use all web services whereas users can only use some of them.
Firstly, users have to be able to sign up with email and password.
In a second time (this is not part of our MVP), we would like to give the opportunity to register using a Google or a Facebook account.
3 - Technical choice
After reading a lot, we think that an authentication whose authorization step is taken care of by Oauth2 is a suitable choice.
But, during our research, we found articles that have made us hesitate, with sentences like theses ones:
"You should only use OAuth if you actually need it. If you are
building a service where you need to use a user’s private data that is
stored on another system — use OAuth. If not — you might want to
rethink your approach!"
"To be clear, OAuth 2.0 at the hand of a developer with deep
understanding of web security will likely result is a secure
implementation. However, at the hands of most developers — as has been
the experience from the past two years — 2.0 is likely to produce
insecure implementations."
We're not going to implement Google or Facebook authentication right away and don't have a "deep understanding of web security", so we question the relevance of choosing Oauth2.
4 - Implementation
We've understood the way Oauth2 works and are not afraid by the implementation of the client side, it seems straightforward (and many projects exist to facilitate its implementation).
On the contrary, for the server side, we will have to create an authorization server and it scares us a bit because we don't know how to do. Implement the whole by ourselves seems to be a fairly substantial and difficult job (and we didn't find any example using Play Java), we're scared to make a mistake that would create a security hole and don't want to reinvent the wheel. We've found some tools like Apache Oltu or Spring Security (that I've used in another project) but we're not sure if they're suitable for what we want to do.
5 - Questions
Is Oauth2 really a suitable choice for our needs?
If we choose Oauth2, what should we do about implementation? Trying to do it by ourselves? Using a tool like Apache Oltu or Spring Security?
Thank you in advance for your answers!
Related
We have two separate products, both including web app and server.
We want to implement Single Sign On for both of them, so when a user has logged into one product, he can automatically access resources in the other product belonging to him.
I have explored a little bit and find SAML is a good approach that we can take, but we are not sure how we want to proceed.
Is it a good idea to implement our own Service Provider? I have looked at Shib SP, but looks like if I want to integrate it into my products, it won't be that easy too.
So I am just looking for some suggestions from people who have encountered a similar problem before.
Another question is what resource that I can study if I need to implement a SP using OpenSaml? Looks like there is not a lot of tutorials or examples that I can refer to.
I would also be really appreciated if anybody can just point out some big procedures or components that my own SP need to contain.
EDIT 1:
Just try to provide more details about what I want. We have two separate products. Currently we are able to externalize user database. For example, our products can be configed to connect to LDAP server or any other external user DB as long as they implement a service properly.
Now our goal is we want SSO for both of our products. One scenario is we have our own SP component(either implement or integrate) in both products. Customer may have their own IdP. With some configuration, our SP can connect to their IdP, and do authentication from there, and user doesn't need to login twice to access both products. Of cause, we can provide an out of the box IdP if customer doesn't have it.
The biggest difficulty with Shibboleth is that it is, effectively, a reference implementation of the SAML v2.0 specification.
For most routine installations, though, you actually need very little of the SAML spec to enable a couple of web apps for SSO.
But since Shibboleth implements the whole thing, with all of its capability, it can be a bear to configure.
We did a project with Shibboleth (and it was admittedly an on the edge use case), and, for me, a SAML novice at the time, it was really a chore to get everything up and working.
For our next stab, I looked at the SAML spec for SSO via the Web Profile. If you read it, it's actually quite straightforward for this limited use case. And we decided that instead of using Shibboleth again, we'd write our own IdP and SP using the OpenSAML libraries.
Could we have got Shibboleth working faster? Probably. But I don't think we'd have the understanding of it that we do of our own. A bit of Not-Invented-Here, sure, but this stuff is confusing enough when you do understand the software and vocabulary, much less when you don't. And SAML is chock full of new vocabulary.
You can also consider using SimpleSAML as an IdP and writing your own SP for your web apps. SimpleSAML is in PHP, but it's a bit more user friendly. You can just treat it as a self contained apache service.
I will say that our SP weighs in at around 1000 lines of javadoc'd code, but it's mostly wiring OpenSAML stuff together and some utility stuff. In truth it's not that scary. Be prepared to really enjoy reading signed XML blobs though.
It is frustrating that this really isn't simpler, but it's a bit of a chicken/egg thing regarding adoption etc.
And if none of that suits you, you can look at OAuth2 and some of its profiles.
If you only want to implement SSO between 2 products, I think yes, building something from the scratch is easier. If it's Java, Shibboleth's OpenSaml is a very good lib.
As you begin to implement more stuff, and some complex scenarios, going for something already built is the best choice. You should also be aware of several stuff you'll be likely to write on a per-system basis (e. g. assertion generation, xml-dsig, validation, etc).
At a glance, it might seem like the already built products are way too complex or difficult to scale or adapt to your particular needs. But your dev effort writing connectors and implementations can be rewarded when you feel like exploding all of the SAML capabilities.
It'd be very helpful though, if you can explain with more detail what do you want to achieve; I feel your question is quite open...
I don't have personal experience with Shibboleth Service Provider, but I am currently developing architecture which uses Shibboleth IdP, Shibboleth Discovery Service and Guanxi Service Provider. Integrating lightweight Guard module from Guanxi Service Provider with Java webapp is a piece of cake and you can easily obtain Shibboleth based architecture without writing your own modules. There is localhost tutorial for setting up Guanxi SP, just skip the parts about Guanxi WAYF and IdP and use Shibboleth components in their place.
We are green fielding a mobile web app against an existing Java web app --the database of that app, at least.
We are only using the database of the original app because the original app is built on a custom ORM solution and Struts 1.1 that is showing its age. So this is going to be a bit of a proof of concept for what can be done with modern tools.
We have decided to utilize JQuery mobile on the front end to leverage device cross compatibility. On the back end we are going to go with JPA for now...maybe moving to Hibernate down the road. But we'd like to expose our model with a RESTful service to kill two birds with one stone (the original app interfaces with a number of third party's that we'd like to give access over a simple REST interface that happens to have a lot of overlap, data wise, with the mobile module.)
So, the question is which controller layer will best tie the JQuery mobile front end with the RESTful back end?
We'd like a controller framework that:
Is not too intrusive. i.e. we don't have to lock ourselves into that particular implementation because of hard set dependencies spread all over the code.
Is annotation based or heavy on convention over config. or both so we are not writing reams of XML glue
Doesn't bring along cruft that we won't be using... i.e. it sticks to the controller layer as much as possible
Can handle REST from one end and AJAX from the other without too much trouble
The larger the community the better
The simpler to get up an running without compromising any of the other points, the better.
We've begun exploring Struts2, SpringMVC, Stripes, Play! etc. but I am hoping for some sage advice from the erudite SO community to help narrow the field.
If you need anything clarified, I will be happy to do that.
It seems to me that you're searching in the wrong direction.
Your Java App is producing JSON/XML through REST web services.
Your jQuery client is consuming those web services to publish them to an interface
You seem to search a controller server side. Why? Producing REST web services is not the only goal of a REST server?
Take a look at BackboneJS — it's not the only one in the category, but the one I know better — it's a client-side controller. It fits perfectly with jQuery and allows to access REST resources with HTTP verb — GET, PUT, DELETE, POST — in a compact and generic way.
If you choose so, I'll help you further.
I have a GWT based app, which is deployed on Google App Engine for Java. The app uses Google Accounts based authentication. I'm maintaining basic user information such as email id (from Google Accounts), last login date etc. in the GAE datastore. The access to the website is free. Anyone can use it using his/her Google Account.
Going forward, I would like to make it a paid service. However, I have zero experience with setting up and operating an e-commerce website. So my question may be a bit vague. I need some guidance on how to go about it.
Here are some of my requirements (but I'm flexible on the exact implementation):
Offer 2 different types of account - free and premium.
I do not want to maintain any credit card related information in my system. I would also prefer to not maintain an elaborate user database.
When a user first logs in, he/she automatically gets a free account.
User has to "upgrade" to a premium account to access all features of the application.
User has to pay a one-time fee to upgrade.
Given this information, I have the following questions:
Is GAE suited for my requirements?
Which payment gateway (Paypal, Google Checkout etc.) would be most suitable for my requirements?
What level of integration is required between my app and the Payment gateway? I would like to maintain minimal user information in my app. I want to focus on my application development and want to spend minimal effort on user administration.
Would I need to implement a custom authentication mechanism or continue to use Google Accounts or another OpenID based authentication?
What other things do I need to consider?
I'll appreciate any help on this. Thanks.
Generally speaking, there's absolutely no reason why you wouldn't be able to keep the current application and its account management. You can extend your user account with an account type field that stores whether the user is a paying customer or not. If you need to send invoices, also store the users contact information (Paypal will send this to you together with payment receipts)
As far as specific payment providers is concerned. I only have practical hands-on experience with PayPal. I would not use them again for a few reasons:
Their APIs are not very well documented and some of the documentation is wrong (or out-of-date).
If you're a small player, support is mostly via the forums. So basically this means you're on your own.
Some of the APIs have serious gaping holes and missing functionality (for instance, you can create subscriptions, but not cancel them if you're using the standard payments APIs.
Outside of the US and a few lucky countries, the advanced APIs are not available. So you're stuck with implementing a IPN listener servlet, while it would much more preferable to pull the information when needed.
All existing PayPal Java libraries I have found use the Pro features that are not available to most of the users. Because I couldn't find it anywhere else, I have created and open sourced my own IPN servlet but it is very unfinished. If there is a demand for it, I'd be willing to improve it, just let me know.
What this IPN servlet does is listen to incoming PayPal messages. For instance, if a user subscribes, you'll get a message. If a user is billed (for instance on a monthly cycle), you'll get a message. If a user cancels his subscription you'll get a message. Those message allow you to maintain the account type of the user.
If I'd do it again, I would probably use a more advanced and higher level subscription API, such as Spreedly. I've heard some good things about the API and they are pretty affordable. I have no actual experience with Spreedly, so this is not an endorsement.
GAE supports this kind of applications without any particular problem; if your language of choice is Java, I would pick Paypal with this toolkit because Google Checkout Java API does not seem to work very well on GAE.
You would need an Authorization mechanism to check what your users are allowed to do based on their permissions.
Basically you would need the following things:
A flag membership status that indicates if a user is Premium or not; this should be set after the payment notification
An authorization system to check if, reading the membership flag value
, a given Web Handler can be consumed by the current user
Have a look to this great Spring Security tutorial; it covers:
Authentication using Google Accounts.
Setup access-control restrictions based on the roles assigned to users.
If you need subscription based billing with free trials, coupons, plan upgrades/downgrades, Dunning management and a whole lot more then take a look at Recurly.
You can choose to have customers maintain their billing information on pages hosted by Recurly, or use their Transparent POST API to post billing info to their servers from a page in your GAE app - both solutions avoid passing sensitive credit card data through your servers, which makes PCI compliance easy.
The Java API is not fully developed but it's easy to build out for your specific requirements using JAXB. I do not have my code wrapped into an open source project but would be willing to share snippets.
In our company, we have several rich Java applications that are used both by internal users and external users. We would like to begin migrating these systems to support a single sign on mechanism, and potentially allow our external clients to use their own authentication mechanisms to validate their users.
For instance, if we have a client who has a large number of users, and they would like to have their users only have to login using their company login information, we would like to support that behavior.
We have looked into using certificate based authentication systems (one of the common ones being Kerberos), and using that authentication mechanism to allow for external authentication services to be used in our system.
Is this doable? Are there specific implementation details we need to be aware of? I am not as concerned about specific technologies (although suggestions are certainly welcome), more about the core concepts and making sure we are doing the right thing wherever possible.
What about authorization - i.e. access to different services. Is there a standard or best practice to how this is handled when dealing with (potentially) disconnected authentication services?
As an additional note, our front end systems are made in Java, so specific information related to implementing this behavior in a Java framework is definitely appreciated (i.e. libraries that are useful, potential pitfalls specific to Java, etc).
Is it doable? Yes.
Are there specific implementation details we need to be aware of? Yes.
Each type of security implementation has its own implementation details that you're just going to have to figure out. Each one is different and has its own nuances.
You should be able to implement whatever type of security you chose. Kerberos is a fine choice. You might also look into Openid and CAS. There are many others though.
To handle the actual security itself you might consider looking into Spring Security. Spring Security is able to handle authentication/authorization fairly well. However, most of spring security is really focused towards security on the web and not client systems so you most likely will have to implement much of the authentication mechanisms yourself (using libraries available library whenever possible of course).
When designing your system, especially if you're going to have many different types of login types, try to build the login system as pluggable as you can. Which will take time and a lot of trial and error.
I would look into the Spring Security 3 book. It isn't a great book, but it does explain a lot about how to properly implement security. Leveraging springs work is highly recommend because trying to implement security all by yourself will be quite a daunting task.
Best of Luck.
How do I use OAuth within my Java GWT application?
In particular, I want to get a list of users in my Google Aps domain, using this API:
http://code.google.com/googleapps/domain/profiles/developers_guide_protocol.html
I know this sounds like a question, that probably has been asked many times before, but I couldn't find any Java code on how to realize the OAuth steps described in the API above.
I would be glad if someone could share some code, or point me to the right docs.
This tutorial by Matt Raible is easily the best one I've seen so far on OAuth and gwt. He also has a very good picture depicting the authentication flow, which I always find help. However, as Matt himself says, the solution is not 100% reliable, but it might still get you part of the way.
With this in mind, it might be better to just go with a pure javascript implementation of it. You'll find one such implementation right here. This SO thread might come in handy to you if you chose that path.
Best of luck to you.
What do you mean in your GWT application?
Do you mean client-side only?
Because on the server you can easily use the Scribe OAuth library.
It has a good documentation and is fairly simple to use.
For integrating OAuth and GWT, you should start with Scribe which handles the implementation of the OAuth:
https://github.com/fernandezpablo85/scribe-java
Next, you need to create a GWT widget that can handle the user's interactions to acquire permission to access their account. Then grab the response token, and make the API requests to the external site.
No point re-implementing OAuth when scribe already does it for you - you just need to. I'd probably aim to use a GWT Popup for doing the authentication:
http://gwt.google.com/samples/Showcase/Showcase.html#!CwBasicPopup