IdPXMLSigEnc Behavior unclear

[Chad La Joie]

No, but that's not the channel determining whether the assertion is
encrypted.  As I said, *everything* about the generation of the
assertion occurs within the scope of the SSO profile handler.  The
artifact resolver does not, in any way, touch the assertion, it just
looks it up from an internal map and sticks it in the response.

I think what you're getting at is that the XML encryption is
potentially wasted effort when the assertion is actually being fetched
by means of an artifact, and thats true.  There is an RFE for the IdP
to address this already.  But for right now, everything is working as
designed.

On Fri, Aug 19, 2011 at 08:50, Rainer Hoerbe <rainer at hoerbe.at> wrote:
> Is it the correct and expected default behavior with encryptAssertions="conditional" that the assertion is encrypted over the TLS-secured SOAP channel?
>
>
> Am 19.08.2011 um 13:41 schrieb Chad La Joie:
>
>> Yeah, the assertion is actually generated by the profile handler that
>> sends the artifact and the conditional is based on the current request
>> not some future request.  So, the SSO profile handler is what is
>> making the determination, thats why its configuration option takes
>> effect, and it's the transport used by the SSO profile handler that is
>> used when computing the "conditional" aspect of that setting.
>>
>> On Fri, Aug 19, 2011 at 07:30, Rainer Hoerbe <rainer at hoerbe.at> wrote:
>>> I expected that artifact resolution over TLS would not encrypt the assertion, but the  Shib IDP does with the default profile configuration in the default relying party:
>>> encryptAssertions="conditional" in SAML2SSOProfile, SAML2AttributeQueryProfile and SAML2ArtifactResolutionProfile.
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered