Hi Roland, I'm glad you got it to work, finally. But you've uncovered a bug since clearly the documentation says otherwise:
http://www.globus.org/toolkit/docs/4.2/4.2.1/security/wsaajava/descriptor/ Would you mind filing a bug and including a link to this thread in the bug report? Thanks, Tom On Tue, Mar 17, 2009 at 4:57 AM, Roland Kuebert <[email protected]> wrote: > Hi Tom, > > Tom Scavo wrote: >> >> Thanks, Roland. That was helpful. >> >> I think I see what's going on. Deny-overrides is configured in the >> security descriptor using the fully qualified classname, as indicated >> in Comment #1 of this bug report: >> >> http://bugzilla.globus.org/globus/show_bug.cgi?id=6033 >> >> Can you please try that and see if that works for you? > > that didn't work for me. As it is, fully qualified class names don't work > for any of the algorithms, even for the FirstApplicable and PermitOverride, > which I can use by specifying the short name. > > Anyway, I found that the file etc/globus_wsrf_core/authz-algorithm-config > contains the following lines: > PermitOverride org.globus.security.authorization.providers.PermitOverrideAlg > FirstApplicable > org.globus.security.authorization.providers.FirstApplicableAlg > > This looks like a mapping of the algorithm (short) name to the fully > qualified domain name, so I added > DenyOverride org.globus.security.authorization.providers.DenyOverrideAlg > > and now I can use the DenyOverrideAlg algorithm without getting an > exception! :) (I tried both - having my PDP once return a permit and once a > deny and the algorithm works as expected). > > I guess the mapping is just missing by default, should there be a bug fix > filed for that? Anyway, am glad that it works now, thanks for the support. > :) > > Regards, > > Roland >
