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.
Related
We are using multiple datasources distributed across regions. Each datasource is meant to handle all data related to all users of the region including security related data such as roles, tokens etc. I can not have all security related information in one datasource.
Does Spring security rest plugin for Grails support this setup? From what I understand it always looks at the default datasource for all authentication related tables and stores all tokens in default datasource alone.
Could someone confirm this? If the plugin supports multiple datasources, how to make it work?
Our environment:
Grails 2.4.4
Spring security rest plugin 1.5.3
Spring security core 2.0-RC4
Postgresql 9.5
Grails supports multiple datasources:
http://docs.grails.org/2.4.4/guide/single.html#multipleDatasources
In order to adjust Spring security core, one relatively easy option, would be to provide an alternative userDetailsService. (method: loadUserByUsername(String username) could be customized to do that)
Which is in use by the DAOAuthenticationProvider to get user's details.
At that point, You would probably need to access more parameters from the request, to determine which datasource to access. So, the request object could be obtained using (for grails 2.x.x):
GrailsWebRequest webUtils = WebUtils.retrieveGrailsWebRequest()
def request = webUtils.getCurrentRequest()
I'm currently creating a new application that requires users to login. I want to use the Spring Security Core plugin for this, but the only problem is that the credentials of the users are stored in a centralized system, and not locally in the database. This system can only be accessed by an API, and will tell me whether the credentials are correct or not.
Is there any way to override the credentials check of the Spring Security Code plugin, so I can check the credentials myself? Or in case this is not possible, is there any other workaround?
It belongs on what your system looks like.
You can write your own Authentication Provider.
Here is answer.
You can create your own User class with datasource set on your centralized system database.
Or you can use Spring Security CAS Plugin
I am using Spring security for Authentication and Authorization in my application. I am using Neo4j database as backend and implemented userDetailsService for authentication.
However, whenever my application restarts, user is forced to login once again.
To overcome this, i am thinking to store session information in redis database and load the data to Spring security Context whenever application gets started.
Kindly pass on if there are any articles and pointers to implement the same.
I am thinking of following implementation for it,
1) For every successful authentication, store user details and session details in redis.
This must be implemented in loadUserByUsername() method of UserDetailsService implementation
2) Remove the data from redis, whenver user logs out, Where can i do this information? Is there any spring security function where i can call this
3) Load all the data from redis to spring security whenever application restarts, again where do i need to write this logic?
Please let me know if i have missed any information.
All you need to do is to implement a
SecurityContextRepository that handles security context storage to reds
Eventually a custom filter that retrieves/ stores session information (GenericFilterBean)
I think it is possible to just give the standard filter a different repository, but I am not sure, I needed my own implementation anyway...
Store session in a redis is out-of the box functionality now
http://docs.spring.io/spring-session/docs/current/reference/html5/guides/httpsession.html
You need to configure remember-me feature of Spring Security.
Remember-me or persistent-login authentication refers to web sites being able to remember the identity of a principal between sessions. This is typically accomplished by sending a cookie to the browser, with the cookie being detected during future sessions and causing automated login to take place. Spring Security provides the necessary hooks for these operations to take place, and has two concrete remember-me implementations. One uses hashing to preserve the security of cookie-based tokens and the other uses a database or other persistent storage mechanism to store the generated tokens.
More information available in Spring Security documentation:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/remember-me.html
You can use out of box implementations or inject your own (aforementioned redis).
As Luke Taylor said, Tomcat's default action is serialize/deserialize sessions on container restart.
Here
pathname attribute of standard manager is the name of the serialization file. If you dont specify a path name attirbute the default is SESSIONS.SER
If you dont want to have sesssions back when restarted, you need to specify it as empty string value..
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 currently working on a project running on JBoss AS 7 that requires authentication from a variety of sources. I'm trying to get an understanding of the various components that combine to provide authentication.
I have some assumptions / guesses as to how this all fits together, but I need to make sure that my understanding is correct. So below is what I understand to be the authentication process for JBoss AS7.
You have a security realm that defines how users are authenticated. This realm is then exposed to your application in order to secure some or all of it. In AS7 this is configured in the <subsystem xmlns="urn:jboss:domain:security:1.0"> element.
The realm can be configured to authenticate users against a variety of sources using login-modules, such as a database, LDAP, a local file or something else. Multiple login-modules can be defined, and you can specify some combination of login-modules must "succeed" in order for authentication to occur.
The actual username and passwords are passed in via a mechanism defined in the web.xml file (for servlets), defined in the <login-config> element.
Assuming that the above process is correct (and it may not be):
Does this whole authentication process fall under a specification like JAAS, or is JAAS just a small or optional part of this procedure?
Do all types of <auth-methods>'s (i.e. BASIC, DIGEST and FORM) work with all kinds of login-modules? This page would seem to suggest not, but I haven't seen any clear documentation matching <login-module> options <login-config> options.
The username and password flow from a login-config to a login-module seems straight forward enough, but what happens with systems like OpenID or OAuth where there are intermediary steps (like redirection to external login pages)?
How do projects like Seam 3 Security, Apache Shiro and Spring Security fit into this picture?
JavaEE security specification leaves a lot of space to container implementors so I will focus on JBoss implementation to answer.
JBoss security implementation
JBoss relies on JAAS authentication to implement JavaEE security. That way it takes benefits from a stable API and can use existing LoginModule implementations. Login modules are used to authenticate a subject but also to add roles to Subject. JAAS provides mechanisms for authorization, permission checking and JBoss uses it internally.
JAAS LoginModule does not only supports password-based authentication but also token-based authentication.
Token based authentications
A good example of what can be done in JBoss thanks to JAAS is the HTTP Negotiation support for Kerberos SPNEGO: an additional auth-method named SPNEGO is implemented thanks to a Tomcat Authenticator and token validation uses JavaSE standard Kerberos LoginModule.
By the way, the LoginModule API is not a requirement, it may even be too complex for some protocols. For instance, the implementation to support OpenID with PicketLink only uses Servlet API.
Third party security libraries
These libraries often provide security layers to an application running a JavaEE or pure Java context, even if it does not take benefits from JavaEE specifications for authentication or role-based authorization.
Spring Security provides other abstractions than JavaEE security for applications developers to implement authentication and authorization, mainly thanks to ServletFilter when a web application is concerned. A large panel of choices is available to secure his application: it is possible to mix multiple options like: JAAS usage, JavaEE container security usage or Spring Security specific implementations (the case of OpenID and OAuth). There is no dependency to JavaEE either so it may be use almost in any situation when running on JavaSE. Most architect choose to build application security on Spring Security to have the liberty to switch specific implementations in the future.
Apache Shiro is really similar to Spring Security but it is younger and probably easier to set up.
Seam security does not rely on JavaEE security or JBoss but only on Servlet and JSF APIs. It is obviously the easiest option for JSF/Seam-based web application. Behind the scene, it uses PicketLink implementations.
As a conclusion, the question to use third party libraries in addition or in replacement to JavaEE security depends on architectural choices: application complexity, vendor independence and portability, control on implementations for bug fixes or improvements. In your specific context, having multiple authentication sources requires a flexible solution like Spring Security which supports authentication provider chaining (or Shiro).