[java-identity-provider COMMIT] in /trunk/idp-saml-impl/src: main/java/net/shibboleth/idp/saml/impl/profile/saml1/Sig...

[Cantor, Scott]

On 2/6/14, 8:02 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Yes, although my existing model might work for at least 2 of those.  The
>params for attributes could live under the attribute resolution context
>(presumably they are encrypted before leaving that "subsystem") and the
>params for assertion could live, as you said, directly under the PRC or
>wherever general profile response intermediate data lives.  Params for
>NameID, I'm not sure, maybe there is a different and natural
>place/subsystem for that, but I'm not familiar with all of that in the
>IdP at the moment.

The problem is all that stuff happens in the SAML steps that occur fairly
late in the flow, not in the various subsystems that operate more
generally, and I was hoping the encrypt actions would actually run after
the plaintext versions are already "in place" in the response, so that
they just replace those with the encrypted versions.

So I think I prefer the idea of having separate named slots for params for
the three cases but not necessarily putting them in different locations in
the tree.

-- Scott