I am studying for the Spring core certification and I have some doubts related how REST web service and I am studying it to apply to Spring framework.
So I have some doubt related to this question founded on my study material but I can't find an answer.
So the questions are (I don't know it these questiona are related each other):
Is REST secure? What can you do to secure it?
Does REST work with transport layer security (TLS)?
I have understand how a REST webservice works and I know that it use the Http method to access resources and implement CRUD operation but what means asking if REST is secure? What is meant by secure in this specific case?
And what exactly is a TSL in REST?
1. Is REST secure? What can you do to secure it?
REST is a paradigm. It's not a finished protocol or an implementation.
There are mechanisms to secure RESTful webservices (one would be TLS), but by default REST doesn't say anything about it.
The OWASP gives a good overview over REST security topics and how to secure a RESTful webservice:
https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
What is security?:
Please note that there are different security objectives in information security:
confidentiality
integrity
availability
All would need different security measures. Some can not be handled by the webservice (REST) alone. (e.g. availability would mean that the server itself is secured and you have security measure agains dDoS attacks.)
It's not really well defined what REST is in detail, it's not a official standard or a specification. I would say that REST per se is not secure. There are mechanisms you can build around it to secure it (like TLS, token authentication). Many of these measure have nothing to do with REST directly.
2. Does REST work with transport layer security (TLS)?
Yes. Transport Layer Security can encrypt the communication to a RESTful Webservice and authenticate the server to a client. (confidentiality and to some extend integrity)
1. It depends. Security is about tradeoffs, not a simple yes/no question. REST is not inherently secure or insecure; it depends on how you implement it. One example is SQL injection attacks: the use of REST has no bearing on whether the system prevents them. Another example is authorizing access: REST does not inherently limit access to the resources it exposes. If you need a guarantee that those resources can only be accessed locally, using REST will make it harder to ensure that.
2. Generally yes. Off-the-shelf servers support TLS, but a completely written-from-scratch program using REST to communicate might not implement TLS code (this is a rather unrealistic scenario, but I'm including it for the sake of completeness).
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'm pretty new to REST and am currently developing an API with JAX-RS Jersey. I am curious on what is the easiest way to implement a user Management. I.e. users must log in and have restricted access to different resources depending on their role. From what I understand, using OAuth 2.0 is the current standard. Can I implement that with Jersey? Does anyone have a few links for me to get me started (examples, tutorials)? Or would you suggest another approach?
Thanks a lot
There are multiple ways to achieve that, let me point few of them:
HTTP Basic authentication (BA) implementation is the simplest technique for enforcing access controls to web resources because it doesn't require cookies, session identifier and login pages. Rather, HTTP Basic authentication uses static, standard HTTP headers which means that no handshakes have to be done in anticipation.
Role based access control for J2EE applications using realm
OAuth with REST:
There's an OAuth 1.0 contrib for Jersey # https://wikis.oracle.com/display/Jersey/OAuth
Works great for me. OAuth 2 is not really a standard yet as it's not finished and there's still a lot of debate and interoperability issues around it.
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.
Found this article on Java-based SSO systems and was wondering if it is in any way at all applicable to secure web services.
With secure web services, you need:
A secure transport
Authentication
Digital signage
Encrypted payloads
Usually this can be accomplished with some OASIS-compliant secure framework (CXF, WSS4J, XWSS, etc.) over SSL for the transport.
I'm not familiar at all with Kerberos, JAAS or GSS, but it seems to me that if they can be used to keep secure connections between a client and multiple Java EE apps, why couldn't they be used in tangent with one of those frameworks (like WSS4J) to provide WSS.
Instead of SSL, I could use Kerberos, then let WSS4J handle all the WS-specific stuff.
This way, I could make reusable Kerberos components that could be used both in SSO and for transport layer security in web services.
Am I completely off my rocker here?
Eugie,
The requirements stated are typical. But the details vary to a large degree.
Hence it is not practical to conclude on a single approach or solution.
The requirements need to be further broken down and analysed seperately.
for eg : SSO broadly has two requriments a)Authentication b) Authorization.
You could use single solution for both or multiple solutions for each. An eloborate system could be using multiple authentications at the same time like .. form-based, certifcate based , token based , remote-auth.
In case of authorization we could have a centeralized solution using LDAP/ActiveDirectory/Domino
or a decentralized with all above co-ordinating.
Each of these solutions have limitations , for eg,Kerberos is not effective against password guessing attacks
The choice of security solutions depends on many parameters like
persived threat, cost, prrformace etc..
WS-Security project tries to address many such architectural concerns.
To answer your question -- No you cannot use kerberos for both SSO and transport layer encryption
--Kiran.Kumar