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 Wed, 10 Jan 2007 20:39:08 GMT

On Jan 10, 2007, at 1:14 PM, Alex Karasulu wrote:

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

Yes, exactly.
>>>> 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=my 
>>>> App,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?

JACC thinks that permissions go with the contextID, i.e. the war.  I  
can't really make anything else make sense in my feeble mind :-).  If  
we stick with this, the change I made/am proposing basically means  
you can bind/log in to a group of applications rather than just a  
single application, but you still administer each application  
(contextID) individually just like before.

hope this is a little clearer.... maybe that phone call is due :-)

david jencks

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

View raw message