Hi Tom, Administrator configuration is liked off the config section in Admin guide. But the security descriptor document needs to have specific links to sections, we need to fix that). Look at section 3.1.5 in http://www.globus.org/toolkit/docs/development/4.2-drafts/security/wsaajava/ wsaajava-secdesc.html#wsaajava-secdesc-serverSide
If a PDP returns indeterminate, the processing is up to the combining algorithm. In default uses, the administrative authz chain uses deny override, so unless an explicit deny is returned that chain will return a permit. In the case of other authz chains (configured at resource, service or container level), the permit override algorithm attempts to construct a delegation chain. So indeterminate will imply that decision cannot be used for a permit chain. Rachana > -----Original Message----- > From: Tom Scavo [mailto:[EMAIL PROTECTED] > Sent: Monday, October 29, 2007 9:31 AM > To: Rachana Ananthakrishnan > Cc: gt-user > Subject: Re: [gt-user] authz chains at both the container and service > levels > > Hi Rachana, > > Thanks for the reply and the pointers. FYI, I read the documentation > before posting but obviously I wasn't able to find the relevant > material. I think this material should be in the Admin Guide, not the > Developer's Guide. Do you agree? If so, I'll create a bug. > > So if I'm understanding the docs correctly, a lower-level config > completely overrides a higher-level config. In other words, only one > authz chain is invoked (in 4.0, at least). > > The 4.1+ documentation is much clearer on this issue, thanks, but what > happens at any step if the authz chain returns indeterminate? Also, > where can I find more info on configuring administrative policy? I > don't see any reference to that in the Admin Guide or the Developer's > Guide. > > Thanks, > Tom > > On 10/29/07, Rachana Ananthakrishnan <[EMAIL PROTECTED]> wrote: > > For 4.0.x, look at section 3.1 in > > http://www.globus.org/toolkit/docs/4.0/security/authzframe/developer- > index.h > > tml#s-authzframe-developer-archdes. Pasting relevant piece here: > > > > "A chain of PDPs and PIPs, with relevant configuration information, can > be > > configured at resource, service or container level. If no chain is > specified > > at resource level, service level is used; if nothing is specified at > service > > level, the container level configuration is used. The engine evaluates > each > > PDP and PIP in the order specified and a deny-override mechanism is used > to > > render a decision. If one PDP returns a deny, the decision rendered is > > deny." > > > > For trunk, look at 1.1 in > > http://www.globus.org/toolkit/docs/development/4.2- > drafts/security/authzfram > > e/developer/authzframe-developer-archdes.html#id2467615 > > > > Rachana > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > > > Of Tom Scavo > > > Sent: Friday, October 26, 2007 12:15 PM > > > To: gt-user > > > Subject: [gt-user] authz chains at both the container and service > levels > > > > > > In GT 4.0, what happens if both the container and service security > > > descriptors have a configured authz chain? Does the authz chain > > > configured at the service level override the authz chain at the > > > container level? Is it possible to configure a PIP at the container > > > level such that this PIP is always invoked, regardless of whether or > > > not an authz chain is configured at the service level? > > > > > > Same question for GT 4.1+. > > > > > > Thanks, > > > Tom > > > >
