Building a composite attribute from sets of attributes

[Cantor, Scott]

> I imagine this would need two separate attribute resolutions to fetch
> the two sets for 1234 at uniA.example.org and 5678 at uniB.example.org without
> mixing the attribute values together. We also want to filter those
> attributes according to the policy set for IdP A and IdP B,
> respectively, so two different filtering passes would be needed as well.

The resolver and filter are abstracted significantly from all of that by using contexts that pass in information about the the user, the issuer/recipient, etc. When people write scripts that punch out of that layer into other pieces of the request, they're breaking that abstraction and sometimes things become SAML specific but the core behavior isn't.

> Is there a way to realise this with the current (3.4) IdP API?

It's not a function of the APIs we have not being "enough", it's a matter of the orchestration of those APIs into profile actions to implement flows, and your flow wouldn't be anything we have implemented now.
 
Using our action bean objects to wire up new flows isn't really supported because all the objects are implementation classes (e.g. the actions that run the resolver and filter now). It's possible to do it and people do it all the time but they're going to find that it all breaks in V4 since all those classes will undergo all sorts of small changes internally since they were for our use.

Formally, you'd have to clone all that code where it's needed and clone all the touch points that aren't API. It's not meant to be a capability we have. I'm considering looking at moving some of the action beans into the API so that it would become more practical to author complex flows like this without doing all the copying or risking breakage.

One of the main requirements is also to create and stash context objects in the tree in various ways, or to wire up the actions to go looking for particular contexts in different places so that there's no contamination.

The actions that do resolver and filter execution now are in idp-profile-impl.

What to do after all that would depend on what the end result was supposed to be and how it would get used. I doubt this is about SAML, so something else would be in the mix.

If the data here is really coming in as part of authentication back to different systems, that's also a different use case that I've been working on extensively for the next release.

-- Scott