Relying Party context shenanigans

[Cantor, Scott]

So, what I'm doing at the moment is trying to rethink and generalize some
of the code we have that's using the RP context. I'm not really shooting
for a multi-RP use case implementation necessarily, but I'm trying to see
how satisfied I am with the idea of building more of the profile behavior
around hanging things off the RP context, which is where the
AttributeContext currently lives, and probably where some of the Security
parameter context material would live.

These are some things I don't like right now:

- we manually create the context in a way that just assumes it's "about"
the inbound msg issuer
- we manually set the RP ID based on the BasicMessageMetadataContext in
the inbound msg context
- we don't really have access to the SAML-specific information like
metadata using the RP context because that's all in the inbound or
outbound message context tree

My insight this morning is that we could generalize this on the one hand,
but also make it more profile aware on the other, by creating the RP
context not in a general action in idp-profile-impl but in a SAML-aware
action in idp-saml-impl that understands (as Brent said) what the hell
we're doing.

So the SSO profile action knows that it's creating this around the inbound
msg issuer, and further, it can actually populate something in the RP
context based on the SAML messaging contexts, eliminating a dependency on
that one we don't want.

Secondly, I came up with the idea that the RP context could contain a
pointer to another portion of the context tree that contains
protocol-specific identifying material. And we could inject a function
that understands that material in order to dynamically obtain the name of
the RP. This is more like Brent's other SAML-aware contexts, but it's done
with a functor so it's not baked into the context.

So in addition to the above, the SSO profile action would inject the
SAMLPeerEntityContext-aware functor and a reference to the
SAMLPeerEntityContext on the inbound msg ctx so the RP context would be
sort of a wrapper around that information for use by the flow.

I also like the idea of creating the outbound msg context tree based on
the RP context's access to that material rather than via copying inbound
to outbound, because that also breaks the assumption that they are one and
the same.

Thoughts, if this isn't making zero sense?

-- Scott