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