Getting error "Invalid Attribute resolver configuration"

[Cantor, Scott]

> > The canonicalized principal name resulting from authentication is what's in
> it.
> 
> So what, in practice, is that?

Out of the box, some of the login methods have beans that can do some transforming of the value before it comes out, but outside of that the final process that canonicalizes the principal is basically the identity function.

For the password flow, regardless of the back-end, the value that is assumed to be the "correct" result is the one the user enters. If that's not good enough, then there are additional features that have to be used to get it into the form desired.

>  If the user logs in as
> "Joe.Bloggs at domain.com", what will it be?  If the user logs in as "Joe
> Bloggs", what will it be?  If the user logs in as "xyz\Joe Bloggs", what
> will it be?

"Logs in as" doesn't technically get at the detail I'd have to have to answer that. If you mean "enters into the form presented by the Password login flow", then the answer is that it should be exactly those strings.

> I need to know how to match it up with my AD users, whose objects are in
> the form "CN=User Name".  And again, is there some way I can see log
> output of how Shibboleth is trying to match stuff up?  All I know so far
> is that it doesn't seem to be bringing back any attributes, but I don't
> know why.

On DEBUG you should get plenty of that information.

> > Lots of other data reachable from the requestContext object, but it
> virtually never matters.
> 
> Again, not documented?

The detailed spec of the request contexts in the resolver hasn't been documented (outside of Javadoc) in the entire history of the project, because almost everybody is using the principal name or some other resolved attribute as the input to the LDAP search. It just boils down to $requestContext.principalName or $attributeId.

-- Scott