David Jencks 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.
So now permissions are now LDAP entries that subordinate to roles and
profiles?
This is way different from the original model we were using.
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.
I don't know if I explained completely what we were trying to do with
the concept of profiles. A user was to be able to have multiple
security profiles WRT an application context. This is why a profile
refers to a user instead of the other way around.
Anyway this is interesting to see what is emerging. However we still
need to reconcile these differences in understanding. At this point I
don't know if there is a right an a wrong.
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.
There was a kind of dual authentication taking place. LDAP was being
used for simple static passwords while kerberos was being used for
2-factor authentication.
There's some wacky stuff here.
- 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.
That's cool considering so much has changes wrt your jacc based branch.
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.
Neat so it sounds like JACC interfaces will do most of what this admin
API does.
- 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.
This was an experiment with a design new pattern. I've tried making jdo
like patterns map to LDAP but with little success. The end result was
not to pretty.
This admin API was an attempt to merge the modifier pattern with the DAO
pattern. It does make for a useful API from the user's side especially
when implementing a GUI.
You basically take a model object like a User object and can ask for a
modifier of it. You do updates to the modifier object then perform an
update which returns the modified User object.
- 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.
I think I used eclipse for this. (I switch back and forth between
eclipse and idea btw)
- I have no idea about the state of the wicket apps nor the "server"
:) well we need to make it all work.
- 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.
Hmmm ok. I'll have to investigate this.
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.
Yeah we can change this. So long as we don't change the trunk before a
merge we're ok.
- There are now 3 java data models: in admin-api, guardian-api, and
jacc. This is too many, one or 2 should be plenty :-)
Yep it's not well organized at all.
- 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.
Ok looks like we have lots to talk about. I don't know the impact of
such things on tsec as it stands now or in your branch. I'm very
worried about the changes to the LDAP data model as well. I have some
catching up to do and will comment more on this email a little later.
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!
Happy New Year to you to David.
Regards,
Alex
begin:vcard
fn:Alex Karasulu
n:Karasulu;Alex
org:Apache Software Foundation;Apache Directory
adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA
email;internet:[EMAIL PROTECTED]
title:Member, V.P.
tel;work:(904) 791-2766
tel;fax:(904) 808-4789
tel;home:(904) 808-4789
tel;cell:(904) 315-4901
note;quoted-printable:AIM: alexokarasulu=0D=0A=
MSN: [EMAIL PROTECTED]
Yahoo!: alexkarasulu=0D=0A=
IRC: aok=0D=0A=
PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A=
x-mozilla-html:FALSE
url:http://people.apache.org/~akarasulu
version:2.1
end:vcard
