We Keep Coding

Modules Integration and Security in spring

I have several multi module spring web application each application like below, each of them differently develop no inter - connection.
war
|...webModule
|...coreModule
I want to integrate them with one admin module with security settings.
How can i do that?? is their any frameworks for that??
I go through the OSGI approach but it has lot migration work. What about component based (I never do that)... Can any one suggest some way to create my integration application which can handle common login & security for other sub application ? (need single sign on multiple war solution)

I strongly advise reading up on the Angular JS and Spring Security series, especially related is the https://spring.io/blog/2015/01/20/the-resource-server-angular-js-and-spring-security-part-iii
The approach that they describe seems completly viable for you. Key points
Spring Security uses the HttpSession to store authentication data by
default. It doesn’t interact directly with the session though: there’s
an abstraction layer (SecurityContextRepository) in between that you
can use to change the storage backend.
After authenticating through your admin module you should store your authentication data into a storage accessible to all your other modules, and using a session id as a key for the data. You can easily achieve this with a help of Spring Session where you can use an out-of-the-box supported Redis as your shared storage for authentication data.
Finally, the key will be set inside a custom header of the requests that target other modules, which will use this custom header and a changed session strategy to pull the authentication data from the storage and authenticated the user
There are quite a few details behind the approach, but the series come with the sample implementation so you should be able to find your way

where we use JAAS

I am learning Java Security JCE/JAAS. I am not able to get a example where we need to implement JAAS login module in real word webapplication.
Can any one please guide me where I can implement JAAS in my web application. as much i know this is authentication and authorization service.
///
If my understanding is correct now, it means if there is any service(Like LDAP) is running in our webserver or any other webserver, and if we want to consume that service then we need to implement JAAS to authenticate our application.

JAAS is one way of implementing login on a container. JAAS main benefits come from the facts that it is a standard framework integrated in the JRE - so you get plenty of information, samples, connectors, etc - and that it properly separates the various concerns of user authentication.
In particular, it clearly separates authentication (validating the supplied credentials) and authorization (role and permissions granted to the user).
While authentication is very often "generic" or "external", for instance using an LDAP server, authorization is often tightly coupled with you application: roles and permissions are usually specific to the business problem the application addresses.
Implementing your own JAAS module is a simple way of addressing this issue, while staying within the boundaries of a well-defined framework and without having to provide a low level implementation to inject the module with the login cycle and session management of the container.

You don't need to implement your own JAAS login module with standard servlet containers unless you want to modify its standard behaviour as they provide you with several standard means to achieve it.
Here you will find a tutorial showing how to use the form login with Tomcat (no need for rolling you own LoginModule):
http://www.avajava.com/tutorials/lessons/how-do-i-use-form-authentication-with-tomcat.html

Generally, you, as the application developer, do not implement JAAS modules. instead, you choose which JAAS module you need to use for your application from pre-existing modules included in the app server you are using. most application servers come with a variety of implementations which allow you to do common things like authenticate using info from a database, ldap, active directory, kerberos, etc. you would determine which authentication source you need to use and configure your application appropriately.

The main advantage of JAAS is that its pam that is pluggable authentication module.. thus if an application wants to be separated from the authentication and authorization system you can use JAAS. moreover JAAS unlike java general security not only verifies the code source but also the person using the code source to access.. so thus if a web app needs pam and the authorization should be of code source as well as code handler then JAAS is better.

jaas, authenticate application users on a database table

I want to know the simplest way to authenticate an application user on a database table using jaas.
Since a database table with username/hashed password is probably the most common solution, is there a "provided" LoginModule for this kind of auth?

The JDBCRealm support in Tomcat 6, comes out-of-the-box. This is probably sufficient for most needs. Note, that Tomcat also provides the DataSourceRealm to allow for authentication via a JNDI based JDBC datasource; this is better suited for applications that need a dedicated connection pool to access the authentication data source. Note that the realm implementations support the use of digested/hashed passwords; but not by default. This would require additional configuration via the digest attribute of each realm.
Glassfish also supports authentication of principals using a JDBC realm. Details for creating the realm can be found in the Glassfish Administration Guide. The guide might provide pitiful documentation on the allowed values for managing the realm - you'll these in a blog post.
If you are looking for ways to manage the underlying users in the realms, then most/all containers do not come with management tools for the same. You would have to write these tools on your own.
Also, if you wish to support digest algorithms not supported by these Realm implementation, or have the implementations work in a different manner (like adding a salt to the password, or locking out users based on a policy), then you'll need to roll out your own implementations.
Now, if you wish to use these in your application, this is usually done by specifying the realms in the appropriate deployment descriptor of your application. Assuming this is a web application, you can specify the realm used (for form, basic and digest authentication schemes) in the web.xml file.

JAAS / JAAC, DROOLS, or custom

I have been using my own internal custom authorization model which evaluates whether a user has permission to view, edit, delete, or create an item. For instance, one place I use this is to determine if a user has permission to view a resource. I have some restrictions such as whether the item is published, whether the user belongs to the necessary group / role, etc.
I store all of that information in a database where I audit the permissions and who changed them for a given entity. To evaluate whether a user has permission, I have a Hibernate Event Listener that takes the current user and other contextual information and evaluates that against the entity.
Is this a good security model, would JAAS / JAAC or DROOLS work better here?

Spring Security and Shiro are probably the most widely used security frameworks and I would probably use them for a project right now. However, it seems a shame to have a layer on top of an application server when and app server has fully tested and integrated security built in (JAAS). I am looking forward to seeing what PicketBox has to offer, Seam Security 3.0 is built on it, it seems to more naturally fit with what an app server already offers, just with some nice features such as open id support.

Instead of JAAS or a rule engine based solution, I'd consider Apache Shiro (formerly JSecurity) for pluggable and flexible Authentication and Authorization. Have a look at What is Shiro?.
But if you have a working solution, why not stick with it if it gets the job done.

I realize I'm a little late to the party, but Spring Security is a pretty robust option as well, specifically it's ACL module can do a lot of what you're looking for.

Permissions checking in server-side API

our product is built on a client-server architecture, with the server implemented in Java (we are using POJO's with Spring framework). We have two API levels on the server:
the external API, which uses REST web services - useful for external clients and integrations with other servers.
the internal API, which uses pure Java classes - useful for the actual code inside (as many times the business logic invokes an API call) and for integration with plusins developed inside out company and deployed as parts of our product. The external REST API also uses the internal API.
We implemented permission checking (using Spring security) in the internal API because we wanted to control access at the lowest API level.
But here comes the problem: there are some operations defined on the API level that are regarded as forbidden for a currently logged user, but which should be performed smoothly by the server itself. For example, deleting some entity could be forbidden for the user, but the server might want to delete this entity as a side effect of some other operation performed by the user and we want this to be allowed.
So what is the best approach for allowing the server to perform an operation (in some kind of super-user mode) that might be forbidden for the actual logged-in user?
As I see it we have several options each of which have its pros and cons:
Implement permission checking in external level API (REST) - bad because plugins will bypass permissions checks.
Turn off permission checking for the current thread after the request was granted - too dangerous, we might allow too many server actions that should be forbidden.
Explicitly ask the internal API level to perform the operation in the privileged mode (just like PrivilegedAction in java security framework) - too verbose.
As none of the above approaches is ideal, I wonder what is the best-practice approach for this problem?
Thanks.

Security is applied at the bounds of a module. If I understand you, your system applies security on two levels of abstraction of the (roughly) same API. It sounds complex, as you have to make a double security check on the whole two APIs.
Consider migrating the REST needed methods from the internal API to the external one, and deleting security stuff in the internal API.
external API will manage security for external clients (at the boundaries of your app)
internal API will be strictly reserved for internal app and plugin use (and you would happy hack it, as no external clients are bounded to it)
Do you really need to control the plugin's permissions to your application logic ? Is there a good reason for it ? Plugins are developped by your company, after all. Maybe a formal document explaining to plugin's developpers what should not be done, or a safety test suite validation for the plugin (e.g. assert plugin does not call "this" method) will do the job either.
If you still need to consider these plugins as "untrusted", add the methods they need to your external API (on your app boundary) and create specific security profile for each use: "restProfile", "clientProfile" & "pluginProfile". Each will have specific rights on your external API methods.

It sounds like you need two levels of internal API, one exposed to plugins and one not.
The best way of enabling that would be using OSGi (or Spring Modules). It allows you to explicitly state which packages and classes can be accessed by other modules (ie REST modules and plugin modules). Those would be the exposed level of your new internal API and you would use Spring Security to further restrict access selectively. The internal packages and classes would contain the methods which did all the low level stuff (like deleting entities) and you wouldn't be able to call them directly. Some of the exposed API would just duplicate the internal API with a security check, but that would be ok.
The problem with the best way is that Spring Modules strikes me as still a bit too immature even to put into a new webapp project. There's no way I'd want to shoehorn it into an old project.
You could probably achieve something similar using Spring Security and AspectJ, but it strikes me that the performance overhead would be prohibitive.
One solution that would be quite cool if you could re-architect your system would be to take tasks requiring security elevation offline, or rather make them asynchronous. Using Quartz and/or Apache Camel (or a proper ESB) you could make the "delete my account" method create an offline task that can at a future date be executed as an atomic unit of work with admin priveliges. That means you can cleanly do your security checks for the user requesting account deletion in a completely separate thread to where the deletion actually takes place. This would have the advantage of making the web thread more responsive, although you'd still want to do somethings immediately to preserve the illusion that the requested action had been completed.

If you're using Spring, you may as well utilize it fully. Spring offers AOP that allows you to use interceptors and perform these cross-system checks, and in the event of an unauthorized action, prevent the action.
You can read more about this in Spring's online documentation here.
Hope this helps...
Yuval =8-)