509 Certificate in Idp-sp communication

[Rod Widdowson]

> We have the lines in relying-party.xml which are commented out like below.
> 
> <!-- security:Credential id="IdPCredential" xsi:type="security:X509Filesystem" --
> >
>         <!-- security:PrivateKey>d:\IdP/credentials/idp.key</security:PrivateKey-->
>         <!-- security:Certificate>d:\IdP/credentials/idp.crt</security:Certificate-->
>     <!-- /security:Credential-->

So you (probably) have *no* *signing* on your IdP.  I'd assume that your <DefaultRelyingParty> does *not* does not have a defaultSigningCredential and all the profiles specify
signAssertions="never" and signResponses="never".

This is weird, and almost certainly insecure against many threat models, but quite possible.

If any of these are not true then you need to find the security:Credential with the id the same as the value for defaultSigningCredential (on DefaultRelyingParty) or signingCredentialRef (on the <ProfileConfiguration>)

 Note that this does not preclude your IdP from encrypting (because it uses the SP certificate)

> It seems we are not using the above lines in our configuration. but in "idp-
> metadata.xml" we have the certificate copied like below:
>  <IDPSSODescriptor protocolSupportEnumeration="urn:mace:shibboleth:1.0
> urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">

That is quite feasible.  The metadata is generated during the installation from information that is gathered then and it is *NEVER UPDATED*.

Rod