I'm using spring-security-core and spring-security-ui plugins.
I'd like to use annotation-driven access management.
After I installed ui plugin for managing users I faced with the problem when those pages are unsecured. I know how to restrict access to those pages only with UrlMap. But if I use map then annotations don't get taken into account.
So actually there are 2 questions:
1) How to restrict access to spring-security-ui pages/controller?
2) Is it possible to use both annotation based and UrlMap security configuration?
See section "5.1 Defining Secured Annotations" in the docs where it describes the controllerAnnotations.staticRules property. This is very similar to the URL map approach and lets you define access rules on static resources, controllers from other plugins, and other URLs that you can't (or shouldn't) annotate.
Related
My problem:
I would love to use the Spring Security plugin's access control/authorization mechanism with my Grails application without having to use the plugin's authentication mechanism. The various Grails Spring Security plugin examples (like this one) I've found combine these two functions. Is there an easy way to just do access control?
Background:
I would like to add roles-based access control to my existing app. I would love to either just annotate my controllers or use the Config.groovy map approach for setting up the access control.
My app already has a user domain class.
The user domain class already handles encrypting passwords using BCrypt.
The app does not have a "role" domain class.
I already have controller actions, views and business logic for handling logging in and logging out. I have no interest in replacing this with the plugin's implementation.
On the right track, but not quite helpful:
I know this is possible to do, as explained in this other question: BUT, that questions and its answers explains how to do it in a Java app using the raw Spring Security framework. I would love for someone to lay out how to do this in a way that is compatible with the latest version (1.2.7.3 as of this writing) of the Grails Spring Security plugin. I don't want to reinvent wheels that have already been taken care of by the plugin.
In addition, this example explains how to do some of this, but it appears to be outdated because it is based on an older version of the plugin that uses Spring Security 2.x. It also only uses custom authentication for one piece of the app, while it looks like it still uses the Spring Security plugin's domain classes elsewhere.
How to do it?
Can someone lay out an approach for me?
I assume I need to create my Role domain class.
After that I assume it will involve custom Authentication objects and the like. But how do I hook them into use the plugin's existing code?
You could go with a custom authentication provider and I have an updated version that I did as part of a recent talk. See this blog post which has a sample app and link to a video of the talk: http://burtbeckwith.com/blog/?p=1090
It would be simple to use a custom UserDetailsService - this is the most common customization done for the plugin and it so has its own chapter in the docs: http://grails-plugins.github.com/grails-spring-security-core/docs/manual/guide/11%20Custom%20UserDetailsService.html
Basically you need to create a Spring Security User instance and Spring Security (and the plugin) doesn't care how you get the data. So your custom UserDetailsService just needs to be a bridge between your current auth scheme and Spring Security.
I ended up creating my own access control/authorization mechanism rather than using the Spring Security plugin. I never could figure out how to separate the plugin's authentication mechanism from the authorization mechanism. Doing the work myself was very easy.
I did the following:
Created a new Role domain class.
Added a Set property and hasMany relationship to my User domain class.
Created a new AuthorizationFilters filter. This is where I put in my authorization rules. In this filter I can check to see if a user has the role necessary to access the given URL and redirect to a login page, redirect to a "not authorized page" or allow them to pass.
This doesn't have the nice syntactic sugar of the plugin and isn't quite as concise either, but it was very easy to implement and understand.
I'm replacing the service tier in an existing older Struts2 project with Spring service beans developed for another project.
I'd like to just #Inject these service beans into my Action classes.
Is it required to use Struts' Spring Plugin? Or can I add Spring into my Struts web application like I would any other (ContextLoaderListener, applicationContext.xml, context:component-scan)?
Am I missing some reason why the Struts Spring plugin helps me in another way?
Many thanks!
Well you can do the most of the things what you have described in your question as Services layer is completely out of view for the S2 and Struts2 do not care how you are creating your Service layer instances and other things.
Benefits i am seeing of using Struts2-Spring plugin is to delegate creation of Struts2 related things to Spring like Action classes creation,Interceptors,Results etc.
My Suggestion is to use the plugin as you are going to use the Spring in your application so its very good and flexible as well powerful to use the power of Spring DI to create required objects needed by S2 else S2 will use its own data creation factory to create framework component.
Why wouldn't you use the Spring plugin?
It's essentially invisible, uses Spring to create your actions (including injecting other Spring beans), etc.
Guice's #Inject doesn't know anything about Spring beans, AFAIK, so you'd be naming classes manually, they'd be instantiated via normal Java/Guice mechanisms, wouldn't be injected with their own Spring dependencies (unless you did it manually, or via AOP, or whatever).
You'd also need to use non-Spring mechanisms for doing injection in testing, which is fine, but unless you provide more details regarding your usecase, I don't really see a reason to bypass the functionality the Spring plugin provides out-of-the-box.
I want to implement role-based access control for each button and function in my application that can be modified onrRuntime. I'm implementing JSF 2.0, and EJB on Glassfish and currently using JSecurity with JDBCRealm to restrict access to the pages. But the problem is my client has requested runtime modification on the roles and access control, which cannot be performed with my current techniques without modifying the web.xml file and redeploy the application. I read through many post regarding Spring security. I want to check if this is possible with spring security, and whether such mechanism to control access control dynamically (can be edited at runtime) to pages + (button and fields level access) are available in spring.
I'm using JSF 2.0, glassfish 3.1, EJB 3.0, and J_Security_check for authentication.
Yes, it is possible with Spring Security. Spring Security allows runtime manipulation of Access Control List (ACL) fields through the MutableAcl interface. It allows creating, updating and deleting of access control entries (ACEs) and also provides the JdbcMutableAclService to persist these changes to the JDBC datastore.
See also:
domain-acls-getting-started
You can see the sample application available here
Instructions to run Spring Security sample applications.
You need to have your database ready with the acl tables before you can try these samples. Here is the schema for Spring ACL tables
I think best bet would be to partition the roles. E.g. the button "submit" may be clicked by user with role "Submitter" and the button "filter" by role "Filterer" and so on.
I mean need different:
Login URL
Login out url
session time url
authentication provider
error page
css
for different entry point.
Is this possible?
From 3.1.0 (which is currently beta) it will support multiple <http> elements in the namespace.
So short answer:
In 3.1.x yes.
In 3.0.5.RELEASE no.
Longer aswer:
Here is additional info, check the links in the comments also.
I had a similar problem once, since I had multiple entry points.
A good way IMO would be to make a new login page which decides which login page to redirect to or even calls the logic of the other entry points. Then you can point spring to the new page.
I'm pretty sure this can be done inside the filter chain, but I wouldn't recommend it since you will need a lot of manual coding and bean definitions. Generally I don't think 3.0.5 was designed for multiple entry points.
With multiple <http../> elements, you can achieve most of what you want but the authentication manager is going to be common and that means authentication providers are going to be common. See the issue faced by #David Parks in the post Spring Security 3.1.0.RC1: With multiple elements why can I only register one authentication manager?.
You can see my answers to similar questions such as Configuring Spring Security 3.x to have multiple entry points and Authenticate user using external webservice in grails to develop custom code to execute entry point specific authentication providers. This can be implemented in 3.0.5 as well.
You can implement solution in 3.0.5 without multiple <http../> elements but you will be need to develop custom code to handle logout and error pages.
There is org.springframework.security.web.authentication.DelegatingAuthenticationEntryPoint
since 3.0.2.
It might help.
Is it possible for two different Grails project, also having different domains, to share a session/cookie?
Let's say I have 2 sites: www.mycompany.com, and, www.othercompany.com. Assume that both sites are having same domains, and same database and records too. What I want to know is if this code:
authenticateService.userDomain()
or even the
authenticateService.isLoggedIn()
will behave and return exactly the same object/result whether it is called in either of the site.
Basically, what we need is a solution for sharing/identifying logged in user between two different sites. Need more details on how to implement this using acegi 0.5.2 and grails 1.2.1.
Hoping for any leads on this. Thank you.
Regarding cross-domain authentication the only thing that comes into my mind is using a single-sign-on service. There are a few open-source SSO implementations available, among them:
CAS
OpenSSO
Josso
Tomcat also has a SingleSingOn valve
This list is by far not complete. Speaking of CAS it definitly works with Grails and Acegi.