directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject [TRIPLESEC] JACC status
Date Tue, 02 Jan 2007 03:51:53 GMT
Here's a brief summary of progress on modifying Triplesec to be a  
JACC provider in sandbox/triplesec-jacc

- I'm modified the data model and schema so that permissions  
correspond pretty well to java permissions and are organized below  
roles and profiles.  Each of these can grant or deny permissions.   
The only disagreement I have with the current data model is that  
profiles point to users rather than users pointing to profiles.  I  
think it will be more useful fore each user to have one profile, but  
allow many users to uses the same profile.  Also I can't see any  
point in tracking all known permissions under the application so I  
removed that.

- I'm modelling the set of "applications" (current triplesec term)  
that are managed together with a realm.  This could correspond to one  
or several j2ee applications.  The SafehausPrincipal now basically  
has an application >> profile map in it rather than a single profile.

- I've modified the login module to work better :-) but need advice  
on what part kerberos is playing compared to just binding to ldap  
using the supplied credentials.

- I've imported and fixed the start of a jacc implementation I did at  
geronimo.  Some simple tests show that it at least partly works.   
This means that the guardian ldap and api stuff pretty much  
completely works and the admin-api works at least to some extent.   
One test adds a permission to a role using the JACC interfaces, then  
demonstrates that a user with a profile with that role then has the  

- The admin-api is not completely modified for the changes in the  
data model.  The permissions under roles and profiles are not really  
dealt with in the admin-api data model.  There's quite a bit of  
disabled test code here.   I'm not very happy with how the code is  
structured now with data objects and "modifiers".  Maybe I don't  
quite get it but I wonder if something more similar to jpa or jdo  
would be easier to deal with -- I'm thinking some kind of state  
manager object for each data object instance and a persistence  
broker.  It's also possible that if I understood the existing code  
better I'd realize this is what it's doing.

- The swing admin program has a lot of stuff disabled so it will  
compile.  This shows some signs of having been written using an IDE  
that generates skeleton code for you..... knowing which one might be  
useful.  It would be even better if the original developers wanted to  
update for the data model changes :-) given my near-total swing  

- I have no idea about the state of the wicket apps nor the "server"

- AFAICT the integration tests all pass when run individually in my  
IDE but almost all fail when run through maven.  I think that the  
ldap server is not being shut down or restarted properly so the  
second and following tests can connect to it.  I wonder if it would  
be practical to actually turn these into more of integration tests  
where a server is started, all the tests are run, then the server is  
shut down.  I have no idea how to start investigating this problem  
and I hope that someone who understands how the ldap server is being  
started and stopped can take a look at it.

- The packages are still at safehaus.  I'd prefer they get changed to  
apache sooner rather than later in case there are problems, so we can  
start finding them.

- There are now 3 java data models: in admin-api, guardian-api, and  
jacc.  This is too many, one or 2 should be plenty :-)

- There are a bunch of unresolved problems that may or may not be  
important.  For instance, jacc has sets of unchecked and excluded  
permissions.  I've modelled these as roles..... I should actually  
model them as one role :-), but it has to be assigned to every user.   
Perhaps this could be done with a trigger?  Also, j2ee expects a set  
of roles to apply to an entire j2ee application, which is in the  
current triplesec model a set of applications in a realm.  It would  
be convenient to have something like assigning a role to a profile in  
all apps in a realm rather than doing it one app at a time.   
(renaming "app" to "context" would make this sentence a little  
clearer :-).  Also there may be some lifecycle issues since jacc  
expects that whenever you redeploy a j2ee app all the existing  
security info will be removed and you'll start over.  I think we can  
model this by removing all the permissions from all the roles but not  
deleting the roles (thus not breaking existing profiles) but I need  
to think about this some more.

So, I think I might be at the point where I can try integrating with  
geronimo and seeing if it can work in practice.  On the other hand I  
may well find I need more of an administrative interface to manage  
the users and their profiles.  Perhaps I can get around this with an  
appropriate ldif file.  Maybe an xml file format adapted to this  
stuff would be handy.

It would be great if the other triplesec developers could review my  
changes before there are any significant changes in triplesec trunk.   
I'm hoping that we can all agree that something like what I've come  
up with is the way forward, fix the problems, and move it back to  
trunk.  I'm already worried about how long the sandbox branch has  
existed :-)

Happy New Year!

many thanks
david jencks

View raw message