logs not matching resolver test

[Cantor, Scott]

> * but somehow encoders for those attributes were not triggered - at least when
> running the resolver exerciser

Pretty much. That is the Occam's Razor answer before looking for more esoteric issues.

> I realize that in principle an attribute could be populated and released by policy
> but not be encoded, but I’m seeing even the most ‘basic’ of attributes with
> encoders in their definitions (ePPN, uid, …) show up in audit log by name, but
> not in the resolver exerciser (maybe related to the puzzle of no process log
> entries for the resolver exerciser).

I would think so. It runs all the same stuff and logs the same stuff.

> I’ve tried the resolver exerciser with an attribute reflector SP - for most users,
> lots of lines in the attribute statement saml, but for the problematic ones, no
> attribute statement at all. 

I can't really explain how it could be logging the attributes as released and nothing else. The only real reason for that is encoding no happening, that's the final step.

> I hadn’t noticed previously, but there’s no SAML at all: no issuer or subject as
> well as no attribute statement.

I don't recall what all gets included, I doubt resolvertest spits out an issuer. It includes a NameID if there is a configuration leading to its production, and not if there isn't, which is why it's now useful for diagnosing that part as well.

> Is there a specific logger I need to include in the logback config to see them?

No, it's standard IdP categories.

> I see no entry at all after invoking the resolver exerciser, whether for
> problematic user with no SAML output or my own id with 143 lines of SAML
> shown.

Then you are not looking at a log produced by the server actually responding to the request. That is really the only answer.

The audit log can be adjusted to, e.g., not log requests for admin flows like the resolvertest flow, but not the process log, that's just coming directly from the class loggers. No difference between the test and an SP making a login request.

-- Scott