Adding attributes in intercept flow

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding attributes in intercept flow

Daniel Lutz
We consider implementing an intercept flow that adds another attribute
to the existing set of attributes (i.e. after the regular attribute resolution
took place). The source values for this attribute aren't known before the execution
of this intercept flow.

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

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

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

(BTW, this relates to Etienne's thread "Building a composite attribute from sets of attributes".)

  Daniel
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Adding attributes in intercept flow

Cantor, Scott E.
On 8/21/19, 10:29 AM, "dev on behalf of Daniel Lutz" <[hidden email] on behalf of [hidden email]> 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


--
To unsubscribe from this list send an email to [hidden email]