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
