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
begin:vcard
fn:Alex Karasulu
n:Karasulu;Alex
org:Apache Software Foundation;Apache Directory
adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA
email;internet:[EMAIL PROTECTED]
title:Member, V.P.
tel;work:(904) 791-2766
tel;fax:(904) 808-4789
tel;home:(904) 808-4789
tel;cell:(904) 315-4901
note;quoted-printable:AIM: alexokarasulu=0D=0A=
MSN: [EMAIL PROTECTED]
Yahoo!: alexkarasulu=0D=0A=
IRC: aok=0D=0A=
PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A=
x-mozilla-html:FALSE
url:http://people.apache.org/~akarasulu
version:2.1
end:vcard
