509 Certificate in Idp-sp communication

[Surinaidu Majji]

Thank you Rod, as you mentioned that we don't have "defaultSigningCredential"
and we have the profiles with signAssertions="never" signResponses="never".

Please look into the following our defaultRelyingPatry configuration, it
hink which is not secure:



<DefaultRelyingParty provider="https://idp.example.org/idp/shibboleth">

   <!-- defaultSigningCredentialRef="IdPCredential"-->

        <ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile"
                              includeAttributeStatement="false"
                              assertionLifetime="1800000"
                              signResponses="never"

                              signAssertions="never" />

        <ProfileConfiguration xsi:type="saml:SAML1AttributeQueryProfile"
                              assertionLifetime="1800000"

  signResponses="never"
                              signAssertions="never" />

        <ProfileConfiguration xsi:type="saml:SAML1ArtifactResolutionProfile"
                              signResponses="never"
                              signAssertions="never" />

        <ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
                              includeAttributeStatement="true"
                              assertionLifetime="1800000"
                              assertionProxyCount="0"
                              signResponses="never"
                              signAssertions="never"
encryptAssertions="never"
                              encryptNameIds="never" />

        <ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile"
                              assertionLifetime="1800000"
                              assertionProxyCount="0"
                              signResponses="never"
                              signAssertions="never"
                              encryptAssertions="never"
                              encryptNameIds="never" />

        <ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile"
                              signResponses="never"
                              signAssertions="never"
                              encryptAssertions="never"
                              encryptNameIds="never"/>
    </DefaultRelyingParty>

In the above code we are not using 'signing' and 'encryption' for saml
transmission. Even though we are not using any of the 'signing' and
'encryption' seen above, we use <X:509 certificate>in idp-meatadata.xml.
1) What might be the purpose of <X:509-Certificate> in the idp-metadata.xml?

 2) Are we done improper configuration or Is it because of using own SP not
from Shibboleth?

Thanks for your valuable time.


On Mon, Mar 30, 2015 at 1:10 PM, Rod Widdowson <rdw at steadingsoftware.com>
wrote:

> > 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
>
> --
> 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/20150330/8511de4f/attachment-0001.html