Modifying attributes to release in post-authentication intercept

[Cantor, Scott]

I wil say that, generally speaking, if you replace the contents of the AttributeContext that early, you're going to change what gets encoded for a response. The impersonation flow does a more invasive removal of the contexts because it re-runs a number of steps internally to resolve them again (and it's our code so we have freedoms that deployer code doesn't), but actually changing the content is relatively safe provided you understand that anything that cared what they were before that happens obviously doesn't get informed, and since everything in the IdP can be attribute-influenced, that can certainly be lots of stuff.

You said that it didn't work when you replaced the context's content via setIdPAttributes(), but there's no reason that wouldn't work. Of course that setter doesn't take a map, it takes a Collection. The map is built on the fly for access after.

Also note that the unfiltered collection is equally accessible by code. So if you diverge the two sets wildly without any regard for that, you could have odd outcomes where some components see the original unfiltered data but other steps operate on the now-unrelated map. Filtering isn't meant to make that sort of change, it removes things but never adds anything. So it's in some sense a violation of expectations to make the two collections that distinct.

If that helps, great, otherwise I'd have to defer to a support ticket.

-- Scott