Develop Reference

Webservice - how can I drop unwanted requests? (Dropwizard/Spring Boot)

Suppose I am running a REST webservice built in Dropwizard or Spring Boot. It has one or a few resources (paths) configured which provide some services to clients.
Now, ocassionally, there are requests on other paths that are not configured, in other words they are invalid for this service.
I can't tell if these are malicious or simply mistakes. They might just be erronous, but there is always a risk that they are attempts to probe my service for weakpoints.
My desire is to imediately drop such requests so that they take up no resources in my service, while providing absolutely no feedback to the client.
So my questions are:
Is this a good idea in the first place?
If yes, how can this best be achieved in Dropwizard or Spring Boot?
If no, what would be a good approach?
Edit:
To clarify the third point, if the idea of simply dropping the request and leave the poor client hanging is not a good idea, what other way of handling such requests is advisable instead?

How can secure a REST web service?

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).

Easy way for Authentication and Authorization with JAX-RS Jersey

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.

Spring security securing the service layer, the web-service layer or both?

I have an API which I'm exposing via REST and I'm deliberating about where to place the authorities restrictions.
I've read that there is a best practice about securing the service layer as it is the one doing the work and you don't know where it's going to get called but I'm not sure what's the best practice with respect to the WS layer.
One thought I have is that I need to have a very fine grained model of authorization on the service layer and a very coarse grained model of authorization on the WS layer as to minimize breaking the DRY principle on the one hand but still have some notion of defence in depth.
Example:
For the Users resource there is a UserWS and a UserService. Admins can create/update/delete users and Users can read about other users.
Assuming the UserWS is bound to %root%/users I will define an intercept-url for that url with the ROLE_USER authority which just says that you have to be a user to get there but the service layer itself will specify the specific authorities for the relevant methods.
Other options are:
Place the same authorization requirements on both the service and the WS-
Pro- You'll filter out as early as possible intruders (and save for example the conversion of parameters if you're using spring mvc)
Con- Duplication of configuration is a maintenance issue and is error prone => security issue
Place the authorization requirements only on the WS-
Pro- Filter as soon as possible if comming from the WS
Con- The service layer might be used from different contexts
Plate the authorization requirements only on the service-
Pro- No Duplication
Con- Overhead of allowing "bluntly" inept request to arrive to the service layer
Would really appreciate any feedback about the options

Ittai,
Using the very same security mechanism at both the WS and Service layer is considered as repeating yourself - and it requires maintenance at these two levels.
Not having any security at the WS layer is a bad thing - since you actually let anyone to get into your system ( even if you'll block them later on - many see that as a bad thing ).
In short, I think that you should mix up these two - use a very rough mechanism at the WS layer and a very strong one at the service layer, That's how you wont repeat yourself and wont have to maintain the code in both places (as it not the SAME security level ); and you'll be able to filter out undersized users as soon as possible but still have a very high security level where it should be placed.

I'd say both if you have the time, only service layer if not.
Its always good to secure presentation and services because if you ever expose your services to something else other than the presentation (you expose a web service for instance), you'll have your security in place and already done.
Also if someone finds a way to bypass your presentation layer (say you have tiers and your services run on a remote machine), you'll still have your security in place.

What are the alternatives for Java authentication?

Preferably something that integrates well with a Flex front end. Yes the Spring Security guys say this is possible, but all examples seem to use legacy jsp tag libraries making them half useless as examples. I don't want to spend a month setting up and learning how to use a security tool. I would like a tool which supports using annotations (#RolesAllowed etc), MINIMAL XML, and 'remember-me' features (not cookie based).
Apache Shiro seems to support Flex/Silverlight/Swing as well but I'd like to know if there are any other alternatives that are NOT container specific.

Turns out Apache Shiro is actually a simpler and easier to learn solution than Spring security. And no stupid xml configuration is nice.

Spring Security is by far the best tool out there.
BlazeDS is no magic. It is ultimately just a call to the server over HTTP. The Blaze application is just a war file, and has traditional urls. So, to protect the services, you have to protect the urls in your web.xml / spring configuration files.
Essentially, read the documentation of Spring Security/JAAS, and substitute the jsps with the urls of your blaze services.
Spring Security also has support for Roles and authorization. It also has a remember-me functionality, but that absolutely uses cookies. You cannot have a remember-me functionality without cookies.
Regarding authentication, it is possible to pass the authentication token as a request parameter instead of a cookie. But cookies are recommended, and are a lot easier to get right.
And finally, security is pointless without using https. You absolutely must use https throughout your application if you care about security.

I don't see why Flex should authenticate anything, after all that is the client side. Whats stopping someone from decompiling your flash/flex?
For most people Apache Shiro is overkill and they just roll their own. Which isn't the best idea to be honest. I have seen a lot of horrible authentication systems over the years. Cookies are meant to keep track of the session for the client, why use anything else?
Edit:
Use spring secuirty for authentication.