Our team has a REST server and a web application developed using Jersey. Currently we support only authentication in our application using OpenID [1]. We're planning to introduce authorization. In my research I found that role based authorization is one way we can implement this. This approach is to have our own tables like user, privileges and user_privileges and we assign users the required privileges (one to many mapping).
I have the following questions:
Since we have a web application and a REST server. Should the authorization be implemented “inside” the REST server, or in the Web Application Server.
Would like to understand the benefit of using Java's security frameworks like JAAS, Apache Shiro, OACC, Java security annotations [2] (#RolesAllowed) apart from code reuse ability, easy implementation.
Would also like to receive recommendations on which framework to choose from the above mentioned (JAAS, Apache Shiro, OACC, Java security annotations) if suggested.
Thank you.
[1] https://en.wikipedia.org/wiki/OpenID
[2] https://docs.oracle.com/javaee/7/tutorial/security-javaee002.htm
As to your question: "Should the authorization be implemented “inside” the REST server, or in the Web Application Server": My recommendation is to implement it in neither! Instead, implement security inside the services that are called by your REST layer. In other words security is implemented in the very heart of your services, and is enforced regardless of how the service is called.
As for the security frameworks you mentioned, I am biased/partial to OACC. OACC provides a fully implemented API, uses an innovative design to seamlessly integrate with your application, supports a number of database back-ends to persist the security data, and is extensively tested with 1000+ integration tests.
This is a good article that discusses the OACC security model: https://dzone.com/articles/a-different-kind-of-java-security-framework
(Disclosure: I am the creator/chief architect of the OACC framework)
Related
I am about to start developing a REST service and security is an important aspect of this project but I can't find some definitive information on how to implement it. My service will be consumed by an Android App at first, but could be used by other platforms later. Controlling user access is critical, so Authorization and Authentication control of the REST services is very important.
Although I can find topics on how to make a secure REST API, like here, here and this big one here, to my surprise, all of them fail to point to a famous standard or framework or time tested solution, which usually is the "way to go" in securing software applications, where we avoid as much as we can to "roll your own security solution".
So far on my research I think OAUTH 2.0 (or even OAUTH 1.0) is the best way to go, it's a public widely used protocol and supports Authorization and Authentication and we can control the lifetime of keys and even have a special refresh key allowing the client to not store password information for acquiring a new key if needed.
I also think Apache Shiro is the best framework for Security, Authorization and Authentication in java, so it comes to a surprize for me when I can't find any integrations between Shiro and OAUTH 2.0...ok there is one that's 5 years old, and doesn't inspire much trust to me.
Even more curious is the fact that Les Hazlewood, the Apache Shiro PMC Chair, owns (ok, owned, he just sold it to Okta) Stormpath, a company made for Identity and User Management, so I would expect him to have provided some easy integrations between OAUTH 2.0 and Shiro, unless this would disrupt Stormpath business plan too much I guess (which I don't believe, since the Apache Foundation won't allow this kind of behavior).
So the final questions are:
1 - Are there any easy integrations between Shiro and OAUTH 2.0 or will I have to code my own?
2 - Does everyone implement their own OAUTH 2.0 solution for dealing with REST APIs access control or am I missing something?
I know the Buji project uses Shiro and supports Oauth2. I haven't used it, but you can check it out.
You definately don't need to code your own. There's some great java libraries and apps that you can use for oauth2 and you can choose from a low level library that you use to build your own oauth2 server up to a full featured standalone openid connect server.
Spring security provides oauth2 that you can use to embed an oauth2 server in your application. A tutorial is available at http://www.baeldung.com/rest-api-spring-oauth2-angularjs.
There's mitreid openid connect https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server, which has a war overlay that you can use to add a user and client admin app into your webapp.
Keycloak (https://www.keycloak.org/) provides a full featured standalone openid connect server.
I have a Jersey based server that I want to secure with OAuth 2.0. There are two paths that I've seen as common:
Oltu - Is compatible with Jersey and seems to be supported, although not as well as Spring Security. This 2012 question seems to suggest this is the way to go, but I want confirmation on a 2016 context so I son't implement something not as well supported anymore.
Spring Security - It seems to be very popular, but this path implies changing the server into a Spring based MVC. I don't know if that is something recommendable based on the benefits of using something as widely supported as Spring and the cost of the refactoring.
With support I mean a project that is in continous development, well established community with tutorials, materials and some libraries for clients (web, mobile, server) already available.
Which one is a stronger option? Is there another option or options?
In any case. Is there a good reference material or tutorial to start implementing this?
UPDATE
After few hours of reading and understanding about both the OAuth Providers I had mentioned, I feel Apache Oltu's documentation did not guide me much as there are key components that aren't documented yet, but an example gave me a better picture on how Oltu must be implemented. On the other hand, going through Spring Security's material I got to know that it can still be built on a non-Spring MVC based java project. But there is a limited exposure of implementations/tutorials on Spring Security on a non-Spring based project.
Another approach:
I came up with an architecture that might be more stable and would not care about the implementation details of the inner server(the one already implemented using Jersey). Having a server that is dedicated for security purpose (authorizing, authenticating, storing tokens in its own database, etc) in the middle that acts like a gateway between the outside world and the inner server. It essentially acts a relay and routes the calls, back and forth and ensures that the client knows nothing about the inner server and both the entities communicate with the security server only. I feel this would be the path to move forward as
Replacing with another security provider just means plugging out the security server implemetation and adding the new one.
The security server cares nothing about the inner server implementation and the calls would still follow the RESTful standards.
I appreciate your suggestions or feedbacks on this approach.
Apache Oltu supports OpenID Connect but its architecture is bad. For example, OpenIdConnectResponse should not be a descendant of OAuthAccessTokenResponse because an OpenID Connect response does not always contain an access token. In addition, the library weirdly contains a GitHub-specific class, GitHubTokenResponse.
Spring Security is famous, but I'm afraid it will never be able to support OpenID Connect. See Issue 619 about the big hurdle for OpenID Connect support.
java-oauth-server and java-resource-server are good examples of Jersey + OAuth 2.0, but they use a commercial backend service, Authlete. (I'm the author of them.)
OpenAM, MITREid Connect, Gluu, Connect2id, and other OAuth 2.0 + OpenID Connect solutions are listed in Libraries, Products, and Tools page of OpenID Foundation.
**UPDATE** for the update of the question
RFC 6749 (The OAuth 2.0 Authorization Framework) distinguishes an authorization server from a resource server. In short, an authorization server is a server that issues an access token, and a resource server is a server that responds to requests which come along with an access token.
For a resource server, API Gateway is one of the recent design patterns. Amazon, CA Technologies, IBM, Oracle and other companies provide API Gateway solutions. API Gateway architecture may be close to your idea. Some API Gateway solutions verify access tokens in their own ways (because the solutions issue access tokens by themselves) and other solutions just delegate access token verification to an external server (because the solutions don't have a mechanism to issue access tokens). For example, Amazon API Gateway is an example that delegates access token verification to an external server, which Amazon has named custom authorizer. See the following for further information about custom authorizer.
Introducing custom authorizers in Amazon API Gateway (AWS Blog)
Enable Amazon API Gateway Custom Authorization (AWS Document)
Amazon API Gateway Custom Authorizer + OAuth (Authlete article)
If an authorization server provides an introspection API (such as RFC 7662) that you can use query information about an access token, your resource server implementation may be able to replace (plug-out and add) an authorization server to refer to comparatively easily.
For an athorization server, gateway-style solutions are rare. It's because such a solution must expose all the functionalities required to implement an authorization server as Web APIs. Authlete is such a solution but I don't know others.
I think, it's far simplier to use the oauth connectors that are implemented inside jersey itself!
Have you considered using jersey own OAuth (already linked inside jersey) server / client ?
https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/security.html#d0e13146
Please take a look to :
16.3.2. OAuth 2 Support
hope helped. :)
I am trying to design a JAAS microservice which handles user authentication for multiple J2EE applications. Currently we have multiple applications which authenticate against our LDAP and have seperate role-systems.
Now I am stuck at designing the interface between the application and the authentication backend.
Via custom LoginModule: Design a custom login module which uses a nonsecured EJB interface from our LoginService to authenticate and authorize, but i remembered reading that login modules can't be injected with EJBs / use EJBs.
Is this the right starting point, or do i have other possibilities to refactor JAAS security out of our applications? Has somebody done something like that before?
I had been curious about Java security some time before. I have found nice framework Picketlink.
Despite it needs quite high threshold to entry, it is much more flexible than JAAS and handles most typical needs.
We are currently evaluating building a new web-application which consists of the following technology:
Back-end:
ee6 jax-rs restful web service
Front-end:
html5 UI using backbone.js (and various other libraries)
The question is, what is the best way to implement a secure session? Limitations are we cannot use oAuth (due to legacy login service we will be consuming). We need a financial industry level of security.
We are thinking about using HTTPS basic authentication with the rest server (back-end), and use backbone.js's session to elegantly handle the front end.
What are the security implications of adopting this strategy?
When you approach security issues, you must remember that your security is as strong as your weakest link. I hope you fully realize you need to secure all your communication, and not just the login.
Also, what key length are you going to use? 128bit?
I would recommend you to check about SPEGNO .. I think this might assist you.
Was just wondering at the current point in time, what is a good combination of tools/frameworks/libraries for implementing a REST API on top of J2EE that integrates to a backend RDB and using OpenID for authentication.
What I am looking to implement is a server component that provides a set of services, all of which will utilise OpenID authentication, and the services will retrieve or update information to/from a backend relational database environment.
What I'm interested in are:
* application server options available (e.g. Tomcat, Glassfish etc.)
* IDE's (e.g. Eclipse, Netbeans, IntelliJ etc.)
* additional components useful for implementing REST (and JSON payloads)
* what is best practice/good technique/options available for database integration from the services (hibernate via spring, hibernate directly, raw jdbc connections ... )
* for integrating authentication via OpenID - what is an appropriate integration point for any custom authentication mechanism within the J2EE environment - are there any commonly used solutions/plug-ins available for OpenId etc.
Also any pointers to good, current tutorials, books etc.
Edit:
Unfortunately I haven't had as much time to research the results to this question as I'd have liked.
At this stage I've found that installing/setting up REST with Jersey was very quick and I believe I can use a ContainerRequestFilter to provide the OpenID support as per the article here: http://plaincode.blogspot.com/2011/07/openid-authentication-example-in-jersey.html
I intend on using OpenId4Java for the OpenId support, with the PAPE extensions to get users email address returned. I don't need OAuth as I don't need to access any of the users other OpenID details or info on their OpenID site from my server app.
I've had a look at the latest Spring, it looks very good and if I were needing to build a web client with my solution, or had more time to look at both, I could easily have ended up leaning that way.
Thanks for the good answers and replies, hard to pick a single correct answer. I've accepted yves answer because it is correct and the way I'm going at the moment with minimal time to research properly, but awarded the bounty to cfontes answer, as it is also correct, and he's replied with additional information and justification.
Make it simple and modern (Spring is neither one nor the other for RESTful web-services):
Jersey – the JAX-RS reference – defines resources and supports OAuth; its code is compact, easy to use & to plug to libraries (backends, etc...).
Take a look at this project on GitHub, it produces JSON from static data. Its web.xml and ProductResource are good places to start.
Every server will do the job, Jetty is my favorite, Tomcat, the standard
The choice of an IDE is up to you, the 3 you're giving are great, well integrated with Maven and source control tools. I use Eclipse from habit
I would go for
Spring 3: this can be useful to wire things up with Dependency
injection and other things.
Spring MVC: Restful support and Request mapping, a request based
framework that integrates very well with Spring
Apache Tiles: to make the HTML templates easier to make.
Spring Security: it's a JAAS implementation and for me it's better and
easier than Standard JAAS.( doesn't need a full web server, tomcat will do fine)
This can help you decide which Persistence provider you want : Persistence Provider comparison I would go for Hibernate, because it have a lot of great features like Criteria API, hibernate Search and it's widely used.
Of course your app should be using JPA 2 for the sake of interchangeability instead of using a Persistence provider directly ( it's not easy to chance from one to another but with JPA2 it's possible, also should be giving you a lot of trouble but it's possible)
I would go with NetBeans 7.0.1 and GlassFish as explained here
From the linked tutorial:
The IDE supports rapid development of RESTful web services using JSR 311 - Java API for RESTful Web Services (JAX-RS) and Jersey, the reference implementation for JAX-RS.
For authentication, I would use the GlassFish JDBC Realm (have a look at this tutorial) but I have never worked with OpenID, so I don't know if this approach can be used together with OpenID.