SAML proxy authentication against something like Azure AD

[Cantor, Scott]

> Why in IdP v4.0.1 are messages like this at the INFO level?

To avoid people needing to drop to DEBUG to "find" stuff that wasn't being mapped in as expected, the same reason the SP does it.

> Azure AD is going to send back attributes with Microsoft-specific  names, and
> ones that one does not really want to map into being able to accept and release
> back out. (And that you cannot stop it from sending.)

If Azure AD can't be stopped from sending something, that seems a bit crazy to me, but that doesn't really mean this code should or shouldn't log something. It seems to me that if you want to proxy this thing, it would make the most sense to just map in their names. I woudn't expect anybody to do the work of forcing it to behave correctly. The design was meant to allow for easy crafting of shared rules that people could post and drop into the registries.
 
> So if you don't care about
> some attribute in the response, why does the IdP appear to "require one" to do
> all the config for accepting it --- at least if one doesn't want to have that
> message logged? (To be fair, the IdP operates fine, its just having that annoying
> message in the log.  I can see that message at the DEBUG level, but not the
> INFO level. Or have a property/setting that says "consider it ok to have
> unmapped attributes when the proxied-ti IdP returns a SAML response".

You could also just adjust the level of that category, so that amounts to the same thing as having a property for it.

But to be frank, the reason it's not on DEBUG is that the experience with the SP is that people constantly screwed up attribute mappings or had trouble identifying the rules to define, and we didn't feel requiring DEBUG logging to find that out was warranted, and since the logging is already tuneable, that always seemed to be the best compromise.

-- Scott