directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [TRIPLESEC] JACC context id in an application
Date Mon, 08 Jan 2007 06:14:18 GMT
David Jencks wrote:
> 
> On Jan 8, 2007, at 12:53 AM, Alex Karasulu wrote:
> 
>> David Jencks wrote:
>>> Alex explained to me that for various legal scenarios its very 
>>> desirable to have triplesec guardian bind to a single application and 
>>> use ldap security to prevent it seeing anything outside that 
>>> application.  On the other hand jacc requires you to deal with a set 
>>> of application components, called policy contexts, within a single 
>>> application.  My original idea was to say application == policy 
>>> context, but this requires triplesec to have access to the entire 
>>> realm in ldap, which includes the users, so that won't work.
>>> So, currently the dn structure is hardcoded to be
>>> appName=foo,ou=applications,<realm dn>
>>> with profiles, permissions, roles, etc right below this rdn.  In 
>>> particular there's code all over the place to take "foo" and turn it 
>>> into "appName=foo,ou=applications".
>>> I think we can simplify the code a bit, satisfy the "log into a 
>>> single application", and make the jacc stuff work by generalizing 
>>> this rdn.  As far as existing code goes I want to pass in a rdn 
>>> string wherever the rdn is currently constructed (e.g. as above from 
>>> "foo").  This will let people set up the same kind of structure as 
>>> they do now if desired, or for jacc introduce another level
>>> contextID=myWar,appName=foo,ou=applications,....
>>> and perhaps for other purposes add even more levels.
>>> Of course there may well be reasons this won't work, and in 
>>> particular I haven't tried to figure out yet if more or different 
>>> objectClasses are needed.  Any comments would be more than welcome.
>>
>>
>> David I'm still trying to understand what you mean.  So you want to 
>> create different policy contexts (JACC jargon) underneath an 
>> application?  What would be contained under these contexts?
> 
> we're playing tag here.... I just committed this stuff.

Yeah I just saw it now.  I got online late this weekend and just saw 
your email.  I read it and let it sit a while in my head.

> Basically the idea is to make the concept of applications hierarchical, 
> so you can run triplesec the way it is now with one layer:

Yeah this is odd to me.  I'm trying to understand how this fits with the 
way Tsec was intended to operate as well as JACC.  I guess I need a 
little more time to think about it.

> appName=myApp, ou=applications,....
> 
> or for jacc with sub-applications:
> 
> appName=myWar,appName=myApp,ou=applications,...
> 
> or for some purpose I haven't thought of yet
> 
> appName=mySubSubThingy,appName=mySubThingy,appName=myWar,appName=myApp,appName=myAppCollection,ou=applications,....


Yeah I just don't understand the utility of this and what the impact is 
in terms of structure and permission evaluation.  Are for example 
permissions in the top application inherited by the children and further 
down descendants?

> The main change is that generally instead of supplying "myApp" you 
> supply the name segment that identifies your app, such as the strings 
> shown above.  I had to change the PolicyProtectionInterceptor to let me 
> do this, and I think I found a problem in the aci list maintenance, see 
> DIRTSEC-3.
> 
> I tested the new code with the original server.ldif and everything 
> worked, then changed it to have 2 levels and fixed the resulting 
> bugs.... haven't checked that the original 1 level still works but I 
> can't see why it wouldn't.  Checking that would require further 
> parameterization of the integration tests.

Hmmm perhaps we need to get together and have another solid discussion 
about this then report back to the list?

Alex

Mime
View raw message