I'm currently developing a Vaadin 8 app with spring boot and as I've read on many posts, the correct way of securing a view is to annotate the class with PreAuthorize. I'm doing that to protect views like this:
#SpringView(name="arinteractions")
#PreAuthorize("hasAuthority('OWNER') or hasAuthority('ADMIN')")
public class ARInteractionsView extends SideMenuViewBase {
The first problem I encountered was that my roles didn't have the ROLE_ prefix so I added that.
Still, spring was allowing the user to enter any view just by typing its URL (which in vaadin is a hashbang like #!interactionview).
Adding this allows the user with access to enter the view, but also users without access. When a user without the roles tries to enter the views he they open. The logs show:
Found view ARStorageBanksView annotated with #PreAuthorize but no access decision manager. Granting access.
And also an exception is thrown:
org.springframework.security.access.AccessDeniedException
at org.springframework.security.access.vote.AffirmativeBased.decide(AffirmativeBased.java:84) ~[spring-security-core-5.0.4.RELEASE.jar:5.0.4.RELEASE]
I tried adding an access decision manager by adding a bean maker method in the security config, but I didn't found any documentation on how to implement this correctly.
Also, adding the access decision manager only made it worse. All views became blocked and the logs showed that the views 'didn't exist'.
What I did to solve was to use the old #Secured annotation. That for some reason is working flawlessly.
Spring security Roles, Authorities, are very confusing. Some of its objects are strings, some are plain objects, the auth scripts are hard to debug, the convetions aren't obvious that are required.
So the question is, what is the correct way of setting up security so that I can use the newer pre-authorize?
I think there is nothing wrong using #Secured, especially if it works. The Vaadin reference application (Bakery) has been implemented using that as well. See more at: https://vaadin.com/start/v8-full-stack-spring
Related
I am trying to secure my Webapplication which is based on a Spring MVC project containing REST controllers and Angular JS pages that get all their data from these controllers.
I am not at all familiar with Spring boot, just with 'classic spring'. I'd like to use the token based authentication which JHipster creates a skeleton for.
What needs to be done to get that security part and migrate it to my current Spring project? I tried copying relevant classes and the Token generation and such works, but the SecurityConfiguration seems to do nothing (no URL's are authenticated while I do say they need to be in the config, the tokenfilter never gets called etc.)
There's possibly some structural/ configurational differences between Spring and Spring boot which cause this?
What needs to be done to get the security mechanism working in a regular Spring application?
What is working:
- token generation
What is not working:
- every REST call goes through no matter if it's behind an .authenticated() URL
- the token filter never checks if there's a token and thus doesn't validate the token
Everything token-wise is okay, everything url-security wise is not at all okay.
(I've been trying to solve this for 3 days now and I just don't see where I'm going wrong.)
All help/ insights/ tips much appreciated as always.
I am working on an application using Spring Security 3.1.0. A piece of functionality that I need to modify is being driven by SPRING_SECURITY_LAST_EXCEPTION being set as an certain type of attribute. I do not see any code from my organization that is setting an attribute by this name, so I have guessed that this is being set by Spring Security.
My suspicion that it was not a name we made up was confirmed when I found many forum messages and 'how-to' blog posts referencing SPRING_SECURITY_LAST_EXCEPTION that don't address my actual issue.
I still can't say what kind of attribute it is, because I have not found any documentation of how this attribute gets set and what is properties are.
Please show me where I have failed to look in order to find the documentation explaining how this property gets set and what its attributes are.
The class WebAttributes contains a constant named AUTHENTICATION_EXCEPTION. This is used to set a request attribute or session attribute (depending if forwarding or redirecting is used) with the name of SPRING_SECURITY_LAST_EXCEPTION and value of the last AuthenticationException in SimpleUrlAuthenticationFailureHandler.
NOTES
It is generally not a good idea to use SPRING_SECURITY_LAST_EXCEPTION for error messages since it displays information an attacker can use.
I would recommend updating to Spring Security 3.2.7.RELEASE. This should be passive and will fix any vulnerabilities that are present in older versions. Eventually you should spend the time to update to Spring Security 4, but this is a little more involved since it includes some non passive changes.
Is there a way using the latest verions of Spring Roo to having this RequestMapping URL/value in this manner(s):
localhost/application/[generated-code]/menu
localhost/application/[generated-code]/settings
localhost/application/admin
generated-code is supplied to a column in the accounts table.
menu, settings and admin are Controllers having the class names MenuController, SettingController and AdminController respectively.
OPTIONAL: Since both menu and settings to share the same URL mapping, is there a way to have such validation on an abstract controller to implement the abstraction OOP concept.
The idea was to put additional security feature to end-user by supplying them them their login URL and login account. The plan was in the application named: application both the admin users and end users share the same application build.
Is this feature possible using Spring-Roo, Spring MVC, and Spring Security? How can such be implemented?
UPDATED
#CodeChip comment to use #PathVariable can be a solution. But as stated in the question and on comment to #CodeChip suggestion, creating an abstract controller is a optimal approach.
I tried using Basic Authentication by changing the server.xml config of Tomcat 6.0 but it did not worked: BASIC authentication in jersey JAX-RS service and Tomcat 6.0 getting failed
Hence I am opting a way where no server specific config is needed and I can add up the roles directly in my code (either client or server; not sure about theavailable options).
Please provide me some ideas about the possible options for setting the user roles so that I can authenticate my Web Service methods using the #RolesAllowed annotation.
You need to go back and figure out why your security constraints weren't working. Maybe start with the default file realm before moving on to JDBC realms. #RolesAllowed in an annotation that triggers behavior in the container.
If you really want to do it yourself (a bad idea) they you'd probably start by creating a custom servlet filter that implemented the entire basic http challenge mechanism. Next you'd have to replace the SecurityContext provider in Jersey.
They "thing" that enables #RolesAllowed in jersey is this: http://java.net/projects/jersey/sources/svn/content/trunk/jersey/jersey-server/src/main/java/com/sun/jersey/api/container/filter/RolesAllowedResourceFilterFactory.java Which, by the way, don't forget to add as an init-param to your jersey servlet. The RolesAllowedResourceFilterFactory gets its security info from an injected SecurityContext which I'm sure at some point just delegates off to the Servlet API for credential info.
So basically if you don't want to take the time to get security constraints working you are going to end up replacing most of the chain...like I said, a bad idea.
The features on application servers are there to keep you from having to spend time creating infrastructure code, if you write your own infrastructure code you're going to have a bad time.
I'm facing a problem with Spring dependency injection. I have an application that once deployed checks if it's previously configured, if not then it launches configuration manager and asks the user for db host, port, admin login and pass etc.
Now I can't find a way to inject those configured values. I assume that I would have to use lazy init beans but when i add the annotation #Lazy, Spring is still trying to inject them at the runtime and I'm getting an error since the host and port are not yet configured.
What am I missing :/?
You need a lookup method, a feature accessible only through XML configuration. There is an almost ancient JIRA issue still open on this, still unresolved.
Please do check this comment on the mentioned issue, it describes a workaround that may be an option for you.