JSecurity

Hello,

JPA is good stuff - all of the JSecurity core uses it in our own projects that also use JSecurity (well, Hibernate directly via Spring, but you get the idea).

Concerning the JpaRealm: this makes perfect sense, but you may or may not need to extend AuthorizingRealm. AuthorizingRealm does caching of Account data, but this is not necessary if you're using a Hibernate 2nd-level cache to cache your JPA-aware User objects. You can subclass AuthenticatingRealm and call your DAO methods for each realm method call. If the DAO layer implements caching, you don't have to worry about EIS round-trips when doing a User lookup for an authc/authz check. I also find it beneficial to have my User class implement the Account interface, and JSecurity can just use my User objects directly - your choice if you want to do that or not, but it usually simplifies things. If you choose not to use JSecurity in the future, all that is usually required is to remove that interface from the User class's implements clause, so given the simplicity benefits, its usually an acceptable thing to do that.

As far as the DefaultSecurityManager - this is the one you should be using in non-web environments. It internally uses the org.jsecurity.util.ThreadContext class which is the only part of JSecurity core that has a dependency on the servlet .jar. It will not use any of the Servlet classes during runtime, but the class has a classloader dependency on the API. This isn't ideal, to say the least, so I've created a new issue to remove that dependency on the next release. For now though, it won't hurt including servlet-api.jar in the runtime classpath.

For the null value errors in doGetAccount() that is because your Realm implementation must return an org.jsecurity.authc.Account (or org.jsecurity.authz.AuthorizingAccount) instance that represents your User class. If you implement the Account/AuthorizingAccount interface in your User class and return the user instance directly as that method's return value, you shouldn't see any null problems anymore. If you don't want to implement the Account/AuthorizingAccount interface in your User class, you can manually instantiate, say org.jsecurity.authc.SimpleAccount or org.jsecurity.authz.SimpleAuthorizingAccount, copy over the relevant properties from your User instance into it, and return it instead. Not as 'clean' as implementing the interface in my opinion, but of course its your choice.

Sessions are exactly as you think them to be - a time-based context for holding data. You can use them in any application, web or non web if you need them, for whatever you desire. Some apps don't need them at all, and its perfectly acceptable not to use them. The apps that do use them find them useful in a number of ways, but the most popular seem to be 1) Storing sessions in a relational database so they can be accessed later, say, for reporting purposes - JSecurity makes this trivial with its SessionDAO or 2) Sharing session state between your business tier (no HTTP dependencies) and your client tiers (Web MVC, Flex, Swing, etc). In this set-up, the business tier can set Session state without ever referencing the Servlet API (as it should be) and that state can then be accessed simultaneously in a web MVC page, a Flex application, Swing app, etc, etc.

So, if you want to use them, you don't really have to do anything to access them. Just SecurityUtils.getSubject().getSession() is good enough to create one if one does not yet exist for the current subject/user.

Finally, in a web environment, you should use the JSecurityFilter, which automatically creates a DefaultWebSecurityManager. If for some reason you can't use the JSecurityFilter or choose not to, the DefaultWebSecurityManager is definitely the instance you should use. If you feel that you need to subclass one of our default SecurityManager implementations, we're probably not doing something right since they are extremely flexible. If you still can't get either to work depending on your web/non-web environments, let me know and I'll work with you to resolve it because that shouldn't happen ;)

I really need to make a Spring/Hibernate example application that shows how I implement my realm. Here's how I set my domain model up - maybe it will give you some ideas:

A User has a collection of Role objects. A Role object has a collection of Permission objects (or permission Strings, either is ok).

My User implements the JSecurity AuthorizingAccount interface and is returned from my HibernateRealm implementation's doGetAccount() call.

Because it implements AuthorizingAccount, I let my User class do its own authorization - in the hasRole("rolename") call, it basically does the following:

for( Role role : getRoles() ) {
if ( role.getName().equals( rolenameMethodArg ) ) {
return true;
}
}
return false;

I.e. this is pure OO delegation, and I rely on JPA to lazily pull in the Set<Role> collection for me, either via an SQL query or a 2nd-level cache hit.

The hasPermission* methods are similar - I iterate over the Role collection, and for each one, check if ( role.hasPermission( permString) ) ) return true;

I hope this gives some insight as to how you might go about your app.

Let me know if you have any other questions!

Cheers,

Les