Hi David, First off thank you very much for your great affords and apologize us for not getting involved into this process enough. Although we are dying to work on Triplesec this is I think a bad/busy time period for most of us.
On 1/2/07, David Jencks <[EMAIL PROTECTED]> wrote:
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.
The point of such a scheme is that a user is a real entity and represented by a single entry on the system. For different applications the user can be assigned to different profiles is desired. Your suggestion of multiple-users-per-profile looked more like what is Roles for to me.As you may already read these concepts are explained here: http://cwiki.apache.org/DIRxTRIPLESEC/guardian-api-users-guide.html OK, it is not a perfect model (well far from it maybe) but has some intentions. BTW, I think I am one of the last guys here to support these intentions as I am one of the least involved in Triplesec. But synergy is a good thing ;-)
Also I can't see any point in tracking all known permissions under the application so I removed that.
Hmm, it may be just used for demonstration purposes. One more tracking capability does not hurt :-)
- 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 permission.
Cool!
- 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 ignorance.
The swing admin tool is just a toy written for again demonstration purposes. Of we need a much better, probably web gui. In fact Timothy had started writing a web (wicket) based tool but I do not know its current state.
- I have no idea about the state of the wicket apps nor the "server"
Oh, I hadn't seen the line above. :-)
- 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?
We can do it with Triggers or with an Interceptor. Triplesec already uses an interceptor for most of its integrity/automation requirements. It may be extended or a new one for JACC can be written.
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.
As Triplesec is intented to be a generic AAA solution we need to develop a stable core and then provide extra features for different model requirements on layers above the core. For example, if Application needs to be named as Context, JACC api can do the conversion by using a Triplesec Application when it needs a Context. (Well, I think Appplication needs to be renamed to Service :-) )
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.
You may want to check the cool DSML thing we have at: http://cwiki.apache.org/confluence/display/DIRxSTUDIO/DSML+Execution+Plugin
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 :-)
Alex is the man to do the main reviewing and I hope we'll get involved in improving Triplesec soon!
Happy New Year! many thanks david jencks
Cheers, -- Ersin
