[opencms-dev] Authentication & Authorization the J2EE way
Sverker Abrahamsson
sverker at abrahamsson.com
Sun Dec 7 02:36:01 CET 2003
Hi,
I've just started to check out OpenCMS and I like it, a lot.
There is one major issue however. I am searching for a content management
tool that I can integrate with a JBoss backend and to do that I need to have
authentication and authorization done the J2EE way, and OpenCMS seams to
have it's own implementation of that. Unforturnatly that makes it very
difficult to integrate OpenCMS with any application which is a showstopper
in our case. Of course there is always the possibility to duplicate the
functionality but that is both cumbersome and errorprone, especially since
we have the rest of the system working fine the J2EE way. I've looked
through the mailinglist archive and found that many asked the same question.
I checked out the code from CVS to investigate if it would be a major issue
to change the way OpenCMS handles this but found that the project seams to
be in a major state of change since it was no longer possible to compile
eventhough I followed the instructions on the core build page. Btw, is there
any doc or forum where the current development is discussed?
Instead I used the src distribution of OpenCMS 5.0.0 and eventhough I
haven't figured out all about how things are connected together it doesn't
seam to be that hard.
In J2EE, security is handled by the container and the application declares
on deploy how it want security to be set up. With Tomcat a realm is defined
in the context of the application which e.g. can contain an implementation
that looks up the user to be authenticated with JDBC from a db, or by some
other method. A Subject is then created which can contain a number of
Principals where one is the main id of the authenticated user and another is
the roles that the user belongs to.
With a tool like OpenCMS it's hard to do declarative authorization since the
deployment descriptor doesn't know which pages should have which ACL's as
they are created dynamically from the VFS, so the system will have to
emulate that behaviour. Forturnatly that doesn't seam to be so hard to do,
eventhough some modifications are needed. Users are handled by a CmsUser
object but what is significant is the id of the user, which seams to be an
int. I assume that it is used as FK in all other tables that is refering to
the user object.
The HttpServletRequest instance that is given to the servlet contains two
methods that gives the information needed; getUserPrincipal(), which returns
the principal of the authenticated user, and isUserInRole() which returns
true if the authenticated user has the role indicated. A principal has a
name, which is a String. That id should be analogue to the id of the CmsUser
and in fact when I look at the class
com.opencms.file.genericSql.CmsResourceBroker I see that it is the id that
is used in the access methods. So it should be quite straightforward to just
change the id from an int to a String, eventhough that unforturnatly
requires a change of db schema as all the FK's would have to change as well.
It's not that hard to make a script that takes care of that though and with
proper indexing it shouldn't get any slower. Instead of a CmsUser object,
the access methods should be feed by a Principal object to work with.
For the group handling, I think that the OpenCms group handling should be
kept as is, more or less, and mapped directly to the roles of the J2EE
subject. In the resource broker, a vector is created with the groups that
the user belongs to. The implementation then iterates over this vector and
compare the id of the CmsGroup objects with the GroupId and ManagerGroupId
of the project, or in case of a resource it compare the group name of the
resource with the name of the CmsGroup. Instead isUserInRole() should be
called with the name of the group.
(Btw, isn't it wrong that the resource contains the group name directly?
That must complicate things if the name is changed on a group, instead
shouldn't it contain the FK to the group id?)
The CmsUser object contains a lot more information but it is just the id and
the groups (roles) that is significant when it is about authorization to a
resource. It is good that OpenCMS contains an integrated user handling but
that should be optional and pluggable so that e.g. I could write a module
that fits into the requirements of user handling in my application. I might
chose to not have user management visible in OpenCMS except that I can map
them to the OpenCMS groups.
I see that there are major changes in this area in the CVS version but
unforturnatly I can't see any integration into the J2EE security framework.
In either way, it is generally good for this kind of tools to try to stick
to the standards as much as possible since it helps in integration, give
better portability and overall functionality when it can take advantage of
advanced functionality of the container. That way it's easy to integrate
into whatever authentication mechanism that JAAS supports.
At the end I again want to say that I find this tool excellent. The
authentication & authorization is the only major flaw I've found so far and
if it can be solved we definitly start using it.
I offer to participate in this work, the changes I described above is quite
easy to make and I can take care of that, but I think I need to get in touch
with some of the developers to discuss how it should be done to not break
something else (and of course, if it should be done).
Best regards
Sverker
More information about the opencms-dev
mailing list