[TRIPLESEC] JACC status

[David Jencks <da...@yahoo.com>]

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  
permission.

- 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.

- 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

Re: [TRIPLESEC] JACC status

[David Jencks <da...@yahoo.com>]

I talked with Alex a bit and he convinced me that a lot of the schema  
changes I made were a bad idea, in particular that its necessary to  
track the permissions under the application directly, and that for  
java permissions (at least from jacc) using an abstract identifier  
for the permissions together with  an objectClass specifying the java  
class, name, and actions for the permission will be simpler, clearer,  
and not conflict with non-java uses of the schema.

I'm still very unsure of how some of  the other data model bits need  
to work, in particular the idea of an application and a contextID and  
how they relate to users.

I'm quite sure that we should have multiple smaller login modules  
rather than one that tries to do it all.

I'm going to make a second sandbox copy from trunk and try again with  
the data model and see if I can merge in the stuff I still like.

thanks
david jencks

On Jan 2, 2007, at 5:34 PM, Alex Karasulu wrote:

> 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
> <akarasulu.vcf>

Re: [TRIPLESEC] JACC status

[Alex Karasulu <ak...@apache.org>]

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

Re: [TRIPLESEC] JACC status

[Ersin Er <er...@gmail.com>]

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 <da...@yahoo.com> 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