Adding attributes in intercept flow

[Cantor, Scott]

On 8/21/19, 10:29 AM, "dev on behalf of Daniel Lutz" <dev-bounces at shibboleth.net on behalf of daniel.lutz at switch.ch> wrote:

> As far as I know, the IdP's regular attribute resolution stores the resolved attributes
> to the context "ProfileRequestContext -> RelyingPartyContext -> AttributeContext".

Yes, that's correct.

> Is the context "ProfileRequestContext -> RelyingPartyContext -> AttributeContext"
> considered part of the API? Can we safely add attributes there?

Yes, see https://wiki.shibboleth.net/confluence/display/IDP30/ProfileHandling under Post-Authentication Intercept Contract and you'll see an outline of at least some of the major bits including that one. And yes, since flows are all meant to be "single threaded", you have the ability to change the content safely.

Where you could run into bugs is if something unusual were created that we didn't handle correctly. I wrote the new Transcoder logic to be as defensive about values as possible, but it's conceivable there could be assumptions about not having IdPAttributes with no values or that sort of thing in the old code.

> I'm aware that we would need to take care of filtering ourselves.

Yes, though I'm going to add a quick/dirty way to run filtering like I did with the resolver earlier.

-- Scott