Hi Grzegorz, First, let me thank you for your comments and the time you put into writing the email. I certainly appreciate this level of feedback and it is extremely helpful in guiding our efforts. Now I'll try to address your points as best as I can.
On Fri, Oct 10, 2008 at 8:58 AM, Grzegorz Borkowski <[EMAIL PROTECTED]> wrote: > > Hi all, > I'm evaluating Java security libraries at this moment. As a Spring user, I > started with Spring Security, and found it very powerful, but extremely > difficult to understand and follow. I am especially interested in > authorization capabilities which goes beyond standard JEE role-based > approach. I want to be able to declare access rules on per-object, > per-method, and per-user level. Spring Security allows it with its ACL > package, but it took me several days to figure out how to use it. > Then I found JSecurity. First impression is very good: it seems much simpler > to use, configure and understand than Spring Security, and possibly > comparable with functionality, and it is not so much web-centric, which is > also advantage. So i wanted to port my test application to JSecurity, but I > got stuck almost at the beginning. > Those are my problems - maybe you can help me with at least some of them: > > 1. On the project page, there is almost no decumentation. Only very simple > quick-start, and some slides. This is too little to start doing anything > real. In Spring Security there is user manual - not perfect, but it gives > good background to start. Here I have completely nothing. You're absolutely right - we don't have a user manual yet, and that is no doubt the biggest challenge we need to overcome. That is part of the reason why we're not at 1.0 yet - I would like to have at least a semblance of a user manual before we hit 1.0 - we're currently about to release 0.9. That being said, we've tried extremely hard to make the JavaDoc quite usuable and easy to read - more so than a large majority of open source projects out there. We're currently about 85% complete and I wanted to get to 100% JavaDoc by the 0.9 final release. Ohloh.net ranks us as one of the best (code) documented projects in the open source world, and we're trying to get even better. For now, as you've seen, we're relying on the sample applications to supplement the JavaDoc until we have time to put into a full user manual - it is no small task to say the least ;) > 2. Because of this, I tried to learn somehthing from sample applications > bundled with jsecurity distribution. I would expect to see Maven pom.xml > file in each sample, so that I can open it in Eclipse or NetBeans as > separate projects, analyse them, build and run (I believe especially > community projects should not be tied to any IDE - and Maven pom.xml file is > the perfect way to provide you with necessary metadata to open it in any > IDE). But there is no Maven config in sample appplications. I spent long > time to figure out how to open those projects, how to build them, etc. The JSecurity team does not (currently) use Maven to build its projects - it uses Ant. All you have to do is run 'ant' from the command line, or if you import the build.xml file into any IDE, you'll instantly see all the tasks available, with the descriptions of what they do. But that being said, if you'd like to contribute pom's to the sample apps, we'd be extremely happy to receive them. Naturally the most effort in build configuration is done by the people that regularly build the project - the developers. Since most of our developers do not prefer Maven, you can see why we haven't spent any effort writing poms. But that's not to say that we wouldn't be extremely happy should you wish to contribute some :) > 3. After looking at quickstart, I looked at web sample. The most > interesting section is JSecurity filter configuration in web.xml. I looked > at filter JavaDoc too, but still don't know how it works: > - in section [filters] you have "jsecurity.loginUrl = /login.jsp" - what is > this "jsecurity.loginUrl"? where it comes from? In JSecurityFilter JavaDoc > there is no phrase "jsecurity.loginUrl". is the "jsecurity" the name of > filter? but still, there is no "loginUrl" property. The [filters] section in > javadoc does not mention such option. Ah, this is a good catch, and you're right - it is not documented yet because it is a very new feature. Basically any properties prefixed with 'jsecurity.' means they are 'global'. 'Global' in this context means that any filter object that has a property with that name (e.g. aFilterInstance.setLoginUrl(String url)) will be automatically called with the value specified. So, if you have jsecurity.loginUrl = blah, then every Filter instance with a setLoginUrl method will be automatically called with value "blah". This also means you can define your own globals - just prefix it with 'jsecurity.' and it will be injected into any filter that has that setter defined. This was created as a convenience mechanism so you didn't have to keep redefining the same property over and over again on multiple filters, i.e.: filterA.loginUrl = /blah.jsp filterB.loginUrl = /blah.jsp ... But to be honest with you, 0.9 RC2 introduced '$' variable substitution, so there is an alternative that is a little more explicit (a few more lines of config), but it might be a little more self documenting and easier to understand. For example: loginUrl = /blah.jsp filterA.loginUrl = $loginUrl filterB.loginUrl = $loginUrl A little more to write, but may feel more natural to you. In any case, sorry about the confusion - the 'jsecurity.' prefix stuff was added just prior to 0.9 RC2 release, and wasn't documented like it should have been. Thanks for the pointer! > - after building war and deploying it, the most suprising fact is that > authentication works. How can it be? There is nowhere the list of > users/passwords/specified! How the system knows the names of users, their > passwords and roles??? Ah, that's because of JSecurity's minimalistic configuration - one of the project's goals is to 'just work' out of the box and you can tweak it as your requirements (and knowledge of the framework) increase. Out of the box, there is a failsafe jsecurity.properties file (in the jsecurity.jar) that is read if you don't configure any security Realms. It is really only meant to be used in demo scenarios and serves as an example for people to configure their own PropertiesRealm if they want to use a file-based Realm (usually very simple deployments). > 4. I really like the WildcardPermission concept: specifying permission with > "newsletter:edit:12,13,18" seems much simpler and powerful than Spring > Security solution. Not only WildcardPermission, but our configuration mechanism and Filter and FilterChain definitions - much easier, more powerful and more succinct/easy-to-read. That, and it is usable in any environment - web or not. But this is only declaration - how do I really grant such > permissions? How do I bind the "12,13,18" ids to real objects? is there some > example anywhere? In Spring Security there is a JDBC-based implementation of > ACL, used to store ACLs for object. There is also > ObjectIdentityRetrievalStrategy interface for defining binding between class > instances IDs and ACL IDs. How it is done in JSecurity? This is done in any way that you see fit for your application. The Realm implementation ultimately knows how to find roles and permissions and return them to JSecurity in the form of an AuthorizationInfo instance (see: http://www.jsecurity.org/api/org/jsecurity/authz/AuthorizationInfo.html and our default implementation: http://www.jsecurity.org/api/org/jsecurity/authz/SimpleAuthorizationInfo.html). This is what abstracts JSecurity's internals away from domain models, which can vary greatly across projects and companies. So, really, it is up to you. Here are some paradigms that most people tend to follow: At the database level, most applications have a roles table. Each Role would have an application-unique name. A User would have one or more Roles and a Role could be assigned to more than one user - implying a many-to-many relationship with a simple mapping table. If you're using Permissions for finer grained control, a Role usually has a one to many relationship with Permissions, in a separate table (i.e. an id column and the wildcard string) People sometimes take that further depending on their application's requirements. For example, A Group is usually a higher level 'convenience' mechanism: It usually has an application unique name and two collections: Collection<User> for the users that are members of the group and Collection<Role> for all the Roles that are globally assigned across only those users in the Group. This is a convenience mechanism because without Groups, you have to add or remove Roles _per_ user, and that might not be convenient depending on your application requirements. Most people are fine with Users, Roles and Permissions though, but it is ultimately up to you. So, you write your data model however you want, in whatever way you want. Your Realm is responsible for 'translating' how your data model is represented into AuthenticationInfo instances that are then used by JSecurity internals. Check out the Spring/Hibernate sample application for real examples of how objects are queried from the database and then returned to JSecurity in the form of AuthorizationInfo objects. You'll probably want to subclass AuthorizingRealm (http://www.jsecurity.org/api/org/jsecurity/realm/AuthorizingRealm.html) to make your life easier as a starting point, or look at the out-of-the-box subclasses that exist already (LDAP, JDBC) for ideas. > > > My current impression is that JSecurty is a nice and promising project, but > complete lack of any documentation gives the impression that it is not used > in any real-world solutions. But I know that it is not true - at least, I > know Nexus project is based on JSecurity. You're absolutely right - Nexus certainly uses it, so does Grails.org as well as a decent number of other public websites and quite few very large commercial installations. I've personally installed it into high-security government applications, so it is definitely 'production proven'. So I think that if you really want > to make JSecurity popular, you should work on some UserGuide, with better > instroduction for new users. Perhaps I can help you a bit with JSecurity if > I find it useful and primising enough. I'm sure we would be extremely grateful for any help you could offer - documentation, code, suggestions, whatever. We're certainly open! We have a Wiki space at Apache (http://cwiki.apache.org/JSEC/) if you want to contribute to that. > But it is hard to evaluate a tool > when I'm stuck at the very beginning. Can you help me with it? I'm certainly happy to help. What would you like assistance with? Lemme know and I'll be happy to fill in the gaps! Thanks again for the great email! Regards, Les
