Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=tX5uJm5Zbo3ZX3kzofY+qivocpWfuZdyosjIcOCH0Dr0UAZhGOC5yIcV1ZRfI4iL3Y3pX4lU7Exc628lSC1doNLyD89PzESzjX1Ot4IjQMVlvMSHQrH/QrrUeW09gDkkUx/R0c4P7pGuJsib5cUErDGwOP02A27t3m0mTBIWJao=
  ;
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <45A1E13A.2030407@apache.org>
References: <C265D81C-9FF0-464D-B425-9B9BE4B20278@yahoo.com>
 <45A1DC64.4020307@apache.org>
 <E0EDE2EC-7B0B-435E-9D56-BD78E3A56898@yahoo.com>
 <45A1E13A.2030407@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F102B25D-278F-485F-8986-6C26EC9AE9DA@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: [TRIPLESEC]  JACC context id in an application
Date: Mon, 8 Jan 2007 01:35:58 -0500
To: "Apache Directory Developers List" <dev@directory.apache.org>


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.


>
>> 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=myAp 
>> p,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.

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

>
>> 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 :-)

thanks
david jencks

>
> Alex
> <akarasulu.vcf>