Contexts and attribute operations

[Cantor, Scott]

On 1/6/14, 6:43 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>1) I propose we ditch all the Issuer-metadata related filters.  People can
>write scripts if they need it.  We really do not want to have even the
>suspicion of consuming our own metadata - the only use case I can
>construct
>in my head for this would involve needing to look at someone else's view
>of
>the IdP configuration which seems just plane broken.

I'm in favor. The only thing I think people may at times care about is the
entityID if you're multi-homing an IdP, but you don't need metadata for
that.

>2) At first blush it seems pretty simple to add a metadata context lookup
>strategy (for the SP) to the remaining filters, but as I started to code
>this I had second thoughts:  Are context hierarchies liable to ever change
>on a per-flow basis?  (so for instance for flow 1 the SAMLMetadataContext
>is
>a child of the profile context, but for flow 2 it is the child of the
>profile context's parent).

They'll never change for a given flow definition, but I thought the point
of the strategy function was to allow them to change across different
flows.

Also, by default, it's going to be the child of the incoming
MessageContext's SAMLPeerEntityContext child. So it's several layers down.

-- Scott