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 Wed, 10 Jan 2007 18:14:46 GMT
David Jencks wrote:
> 
> On Jan 8, 2007, at 1:14 AM, Alex Karasulu wrote:
> 
>> 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.
> 
> The thing with jacc is you need not only applications corresponding to 
> e.g. ears but also sub-applications corresponding to e.g. wars and 
> ejb-jars inside the ear.  You want to be able to (bind? login?) to the 
> entire application so you can see all its parts at once, so it wouldn't 
> be so good to just use the contextId (which is a unique identifier) as 
> the appname since then you'd need to log into each contextId separately.

According to JEE and JACC a context Id exists for each war right?

>>> 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?
> 
> ahh, maybe more constraints are in order.  My idea is a tsec 
> installation would decide "I'm going to have a 2 level app hierarchy" so 
> the only things that can have permissions, roles, etc are the ones like
> 
> appName=myWar,appName=myApp.
> 
> In such an installation you would never have permissions, roles, etc 
> directly under appName=myApp.
> 
> To get the old behavior you'd specify 1 level.

Would it make sense to have permissions global to the entire app or 
would each war need it's own permissions.  Meaning is permission scope 
wrt the web app?

> This was definitely not clear in my previous explanation :-)

I'm still in a bit of a haze.

>>
>>> 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?
> 
> ok but maybe not tonight :-)

NP just as long as it happens.

Alex

Mime
View raw message