I'm developing an application in Spring which has numerous methods in the controller, and are mapped to various URL using #RequestMapping.
Some of these methods (and hence url) are accessible to some user roles, and not to others. Can I create annotations, and annotate these methods so that only privileged users have access to right methods, while not to the others?
Thanks in advance.
I am not sure if creating new annotations is what you really need. You could probably use Spring Security and its annotations. Please take a look here to see if it is what you are looking for.
You can use Spring Security and its annotations, restrict access to some methods. This Blog post show some features of annotations used with Spring Security 3.
Have a look at this question and answer, to see how you build your own annotations on top of spring security.
See also the documentation of Spring Security 3.1, Chapter Expression-Based Access Control.
Related
I'm attempting to integrate Spring's default access control list implementation into a Jersey contained Restful API. I successfully was able to implement Basic Authentication using the Spring Security Filter Chain and setting up an authentication manager in my securityContext.xml.
My problem in a nutshell is, after adding the acl-context.xml and making adjustments to other parts of the project, my project seems to not recognize the #pre and #post annotations. It doesn't throw an error, but it doesn't make queries to the database according to the mysql log. Is there something about the default implementation of Spring's ACL that relies on Spring MVC classes like #controller, #transactional, #resource, or #service?
Here is the repo with the code as it is now (I appologize for the extra classes laying about. It is a maven project.
https://github.com/DataAnalyticsinStudentHands/RESTFUL-WS/tree/secure
web.xml:
https://github.com/DataAnalyticsinStudentHands/RESTFUL-WS/blob/secure/src/main/webapp/WEB-INF/web.xml
webSecurityConfig.xml:
https://github.com/DataAnalyticsinStudentHands/RESTFUL-WS/blob/secure/src/main/resources/webSecurityConfig.xml
acl-context.xml:
https://github.com/DataAnalyticsinStudentHands/RESTFUL-WS/blob/secure/src/main/resources/acl-context.xml
pom.xml:
https://github.com/DataAnalyticsinStudentHands/RESTFUL-WS/blob/secure/pom.xml
I'm sorry I would love to paste the .xmls here but I can't seem to get the formatting to work and its deleting characters. Please let me know if there is anything else I can do to clarify the situation. If I'm doing anything overtly stupid in regards to anything else, please let me know. I welcome the criticism. I'm the only person on our team working on network security and I don't have anyone here to give me feedback.
I am no fan of gross over abstractions, And i think Spring has committed a major felony.
But I'm willing to overlook it this time if someone can explain the algorithm behind the 'auto' configuration.
Having a look at spring's own javadocs, It doesn't give much away other than saying that it will intelligently guess what you need and something to do about conditional beans.
Does someone know what algorithm is used to determine what needs to be loaded?
In my experience as a Spring Boot user the basic factors for Spring Boot to decide on what auto-configurations will be enabled are:
1) The classes present on the classpath. For example if RabbitMQ and Spring AMQP classes are present, then the RabbitAutoConfiguration will be enabled. The corresponding annotation is #ConditionalOnClass,
2) The presence or not of user defined beans. For example, if all the Spring Data JPA is present on the classpath, Spring Boot will register a LocalContainerEntityManagerFactoryBean bean only if the user has not already done so. The beans registered by the user will 'override' the default ones. The relevant annotation is #ConditionalOnMissingBean
As #DaveSyer mentions, you can of course use Spring Boot without #EnableAutoConfiguration if you want to include the relevant configuration on your own. Or you could use the less drastic solution of the exclude field of #EnableAutoConfiguration. If for example you want Spring Boot to autoconfigure everything except ActiveMQ, you would use #EnableAutoConfiguration(exclude=ActiveMQAutoConfiguration.class)
In my opinion, there is absolutely no felony here! You can use what you want from Spring Boot. When you don't want something it has to offer, you can easily opt out partially or completely!
Also if you want to get a look under the covers, you can add the property
logging.level.org.springframework.boot=DEBUG
to application.properties and Spring Boot will gladly give a detailed report of what was auto-configured and what wasn't
There is some documentation in the Spring Boot Reference Guide. It's not terribly complicated, and I hardly think it's a felony to just include a bunch of #Configuration that you might have written anyway (because that's all it does). Feel free not to use #EnableAutoConfiguration if you prefer to include the individual configurations individually.
Can I use Spring Security annotations in my ZKGrails composers to secure the ajax-callbacks, or can/do i have to inject springSecurityService (and check the principal's authorities, in every method manually)?
Update: According to http://felipecypriano.com/2009/10/26/tweak-zk-to-make-event-processing-call-groovys-invokemethod/ , the annotations should work, and I found the modification mentioned in this post in the current ZKGrails plugin version (1.0.4). Still, when I try to secure methods in my composer, they remain fully accessible.
Because "#Secured" annotation is not supported by spring security plug-in. I think you should implement your own method interceptor according http://felipecypriano.com/2009/10/19/enable-secured-annotation-with-grails-spring-security-plugin/ to enable it.
I'm developing a web application using Spring MVC 3.0 and looking for a ready-made solution, if any, or a "best practices" reference for a url/action mapping and routing system that can achieve the following:
REST-friendly controller / method name to view mapping. The current mapping implementation translates the request to a view name, which may be problematic when using several parameters and is incompatible with REST urls
A service that accepts the name of a controller, a method and arguments values and renders the URL that's represented by them
Integration with Spring Security that can allow me to check for a given URL whether the current user is allowed to access it, so that I can decide whether or not to render a URL
A menuing system based on the above that can define menues composed of these actions and render them to page
Basically what I need is the ability to define URLs in one centralized place, so that changing a URL (during development; I'm aware of the don't-change-live-urls idea :) ) does not mean looking up and changing that URL in a zillion pages.
Any directions to such an existing solution / tutorial / guide would be great.
Thanjs
This is a feature I really miss in Spring MVC.
That's why I created the springmcv-router project, basically a port of PlayFramework's Router implementation in Spring MVC (HandlerMapping + HandlerAdapter).
I'm heavily using it in several real-world projects and the Router implementation itself is reliable.
Try using Spring Roo. It utilizes many best practices for spring MVC, and it has a scaffolding feature that automatically maintains a menu, jsp's and all the CRUD methods of a controller.
Setting up Spring Security with Roo is as simple as typing "security setup".
Hope this is helpful.
In a banking or similar application there are usually several roles defined and associated privileges required (for example a normal user could only do transactions but not post it while a supervisor can verify and post them, sort of maker/checker). We also need to add new roles and privileges in the system (not sure about the latter).
How do you achieve this Role Based access in a Spring/Hibernate application? Especially in terms of scaling up to add new roles/privileges. Can Acegi (I never used it) help? Any other idea would be appreciated that can help me achieve the above.
Thanks,
As duffymo mentioned, Acegi has been renamed to "Spring Security" and it's what I would recommend if you're already working with Spring.
There's more documentation online for Acegi than Spring Security, so if in doubt you can find useful information in the Acegi docs/tutorials as well as the more recent Spring stuff.
If you can design your user table to fit with Spring Security's concept (user name, password, roles, each with certain specified types and names) then you can use Spring Security's DAO classes right out of the box; if not, you build a tiny adapter class to hook up Spring Security to your database for the user query.
You can specify required roles per servlet/URL or even at the method level. It took me a day or two to wrap my head around the concepts involved, but after that configuring it was reasonably easy, and I was happy that they've already solved most of the kinds of problems that arise in connection with Web security.
Yes, Spring Security (formerly known as ACEGI) can do it.