incubator-shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <...@hazlewood.com>
Subject Re: Problematic first steps with JSecurity
Date Fri, 10 Oct 2008 20:21:42 GMT
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
<grzegorzborkowski@o2.pl> 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

Mime
View raw message