directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [TRIPLESEC] JACC context id in an application
Date Mon, 08 Jan 2007 05:57:31 GMT

On Jan 7, 2007, at 6:00 PM, 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.

AFAICT I made this work and committed the result in rev 493959.

the string of app names have to all be like

I modified the PolicyProtectionInterceptor to allow one connected  
sequence of applicationPolicy objectClasses in the dn but no gaps.

There seems to be a bug in that renaming applications doesn't rename  
the corresponding admin groups or admin ACI.  I'm not quite sure how  
to fix this: there's some commented out code in ApplicationAciManager  
about modifying app names.  See DIRTSEC-3.

I'd really appreciate quick review of this work,  if it's going to be  
a problem to bring to trunk I'd rather know before I get much further.

david jencks

> many thanks
> david jencks

View raw message