using cert in SP metadata for encryption

[IAM David Bantz]

Closing the loop:

Replacing the SP metadata with the vendor-corrected version that includes
proper KeyDescriptors for both signing and encrypting enabled our IdP to
respond with encrypted assertion to nextgen (there are 3 distinctly
different X509 certs in the metadata -  for signing, for encryption, and
used to sign metadata).
A couple quick additional tweaks at the vendor end completed the
integration.

[So Craig, you might re-visit and hope to encrypt assertions.]

David Bantz


On Fri, Nov 18, 2016 at 9:22 AM, IAM David Bantz <dabantz at alaska.edu> wrote:

> Just received totally different metadata from the SP with appropriate
> keyDesriptors for both signing and encryption;
> many other enhancements as well such as reflecting properly named
> requested attributes.
> Clearly I previously received incomplete/bogus metadata.
>
> db
>
> On Fri, Nov 18, 2016 at 9:13 AM, Peter Schober <peter.schober at univie.ac.at
> > wrote:
>
>> * IAM David Bantz <dabantz at alaska.edu> [2016-11-18 19:08]:
>> > yes, extended discussion with their technical team, who told me
>> > they'd "turned on" encryption and re-generated the metadata...
>>
>> Well, then they should be able to give you a copy of the certificate
>> you should use for encryption of data to them, either via SAML 2.0
>> Metadata or out of band. Doesn't really matter at this point.
>>
>> (That would make the suggestion moot to try using the cert they signed
>> their metadata with.)
>>
>> You can always find examples of how to mint/assemble metadata in the
>> Shib wiki and verify with the tools documented on the
>> MetadataCorrectness wiki page.
>>
>> Cheers,
>> -peter
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161118/f3f52020/attachment.html>