Shibboleth Developers

["Scott Cantor" <>]

Lukas Haemmerle wrote on 2010-01-13:
> However, I would have assumed that resolvertest just queries the
> attribute authority and therefore would need only the
> AttributeAuthorityDescriptor in an EntityDescriptor. I'm I wrong here?

The program isn't doing much of anything itself, it just calls into a method
implemented on the AssertionConsumerService base class that extracts data
from a pushed assertion and then runs the AttributeResolver code. That
method normally takes an IDPSSODescriptor on input from earlier in the SSO
process, and resolvertest obtains one as the first step of preparing to call
the method.

The method itself probably doesn't actually that role, the parameter is just
typed as a RoleDescriptor. It shouldn't break if an AA descriptor was passed
in instead. But the problem is that the code is trying to simulate the
effect of the attribute extraction process as a whole, and that code
typically would run using an IDP descriptor.

For example, you can pass in an Assertion on stdin, and it will consume that
instead of manually taking a NameID value to use. If it changed roles, that
could (in theory) change the result of the process due to differences in
role content (e.g., Scope extensions). Obviously that's not going to be very
likely, but it's just a question of correctness.

Fixing it to allow only an AA role would probably need to be a new option
for the -i/-n/-f code path to control which kind of role it goes after.

-- Scott