[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-dev
Subject:    Re: Building a composite attribute from sets of attributes
From:       "Cantor, Scott" <cantor.2 () osu ! edu>
Date:       2019-07-25 17:46:30
Message-ID: A0F611B6-2BDD-4429-83C1-08FC16A0833E () osu ! edu
[Download RAW message or body]

> I imagine this would need two separate attribute resolutions to fetch
> the two sets for 1234@uniA.example.org and 5678@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


-- 
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net


[prev in list] [next in list] [prev in thread] [next in thread]