Metadata and trust in the UK Access Management Federation

From Guanxi

Jump to: navigation, search

Contents

Introduction

This paper describes the ways in which Shibboleth entities can trust each other when working within a federation that supports SAML2 Metadata, such as the UK Access Management Federation. These technical details are the result of lots of helpful discussion with Ian Young and they should be useful for anyone who wants to implement their own trust management for SAML entities. The scenario is slightly tongue in cheek, as Shibboleth requires a sense of humour to prevent oneself from going barmy while dealing with its many idiosyncracies. To that end, Scaramanga needs to login to Bond HQ in order to register a demand for ONE MEEELYON DOLLARS! The arch criminal and would-be destroyer of our hero Bond (shaken not stirred), fires up the golden laptop and points his browser at the Bond HQ website and clicks on the "Register Demands via Shibboleth" link. Scaramanga is then shown a list of known baddy hideouts, from which he chooses "Scaramanga, Den of Thieves" and is redirected to his IdP.

IdP trusting an SP

The initial contact between the Bond HQ SP and the Scaramanga, Den of Thieves IdP is a simple affair. The SP sends an HTTP GET request either directly or via the WAYF to the IdP's Single Sign On endpoint that handles Shibboleth profile interactions. As far as trust goes, there's not much in the request other than the providerId and shire of the SP: 

https://idp.scaramanga.ac.uk/SSO?shire=https://bond.ac.uk/Shibboleth.sso/SAML/POST&target=XXX&time=YYY&providerId=urn:bond:hq

To allow the Scaramanga, Den of Thieves IdP to trust the Bond HQ SP, it should follow the rules defined in Shibboleth Architecture Protocols and Profile, section 3.1.1.3. This basically means the IdP can use the providerId parameter as a lookup into the federation metadata it holds and verify that the shire parameter is the same as the AssertionConsumerService with a binding of urn:oasis:names:tc:SAML:1.0:profiles:browser-post. 

<EntityDescriptor ID="007" entityID="urn:bond:hq">
...
  <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
    ...
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://bond.ac.uk/Shibboleth.sso/SAML/POST" index="0"/>
    ...
  </SPSSODescriptor>
...
</EntityDescriptor>

If trust passes muster, the IdP is then free to send its AuthenticationStatement to the URL defined in the shire parameter.

SP trusting an IdP

Once the AuthenticationStatment arrives at the Bond HQ SP, the trust process is started. This can be vastly more complicated as it depends on what security information is held in the metadata for the IdP. There are three ways that the SP can verify the identity of the IdP:

  • PKIX Path Validation. When no security information is held in the metadata for the IdP. This is the most common scenario.
  • Direct signature validation via X509/X509Certificates in the metadata
  • Direct signature validation via RSAKeyValue in the metadata

Let's deal with the latter two first as they're less complicated than the main way of verifying an entity, PKIX path validation.

Loading the IdP's metadata

The issuer of the assertion should be used as a lookup into the metadata to find the IdP. In our case, Scaramanga, Den of Thieves has returned an AuthenticationStatement: 

<samlp:Response ... >
  ...
  <saml:Assertion ... Issuer="urn:scaramanga:den:of:theives">
     ...
  </saml:Assertion>
  ...
</samlp:Response>

The SP then uses the Issuer of the assertion as a lookup into its metadata to find the IdP: 

<EntityDescriptor ID="666" entityID="urn:scaramanga:den:of:theives">
  ...
</EntityDescriptor>

Direct signature validation via X509/X509Certificate

This method relies on the presence of an X509Data node in the metadata for the IdP's IDPSSODescriptor: 

<EntityDescriptor ID="666" entityID="urn:scaramanga:den:of:theives">
  ...
  <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
    ...
     <KeyDescriptor use="signing">
       <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
         <ds:X509Data>
           <ds:X509Certificate>
             MIIC5jCCAk8CAgZOMA0GCSqGSIb3DQEBBAUAMIHNMQswCQYDVQQGEwJHQjERMA8G
             A1UECBMIU2NvdGxhbmQxEjAQBgNVBAcTCUVkaW5idXJnaDEkMCIGA1UEChMbVGhl
             IFVuaXZlcnNpdHkgb2YgRWRpbmJ1cmdoMSQwIgYDVQQLExtUaGUgVW5pdmVyc2l0
             eSBvZiBFZGluYnVyZ2gxJzAlBgNVBAMTHlRoZSBVbml2ZXJzaXR5IG9mIEVkaW5i
             dXJnaCBDQTEiMCAGCSqGSIb3DQEJARYTcG9zdG1hc3RlckBlZC5hYy51azAeFw0w
             NzExMTUxNTQ4MjVaFw0wODExMTQxNTQ4MjVaMIGnMQswCQYDVQQGEwJHQjERMA8G
             A1UECBMIU2NvdGxhbmQxEjAQBgNVBAcTCUVkaW5idXJnaDEgMB4GA1UEChMXVW5p
             dmVyc2l0eSBvZiBFZGluYnVyZ2gxDTALBgNVBAsTBEVVQ1MxHTAbBgNVBAMTFGph
             Y2ludG8udWNzLmVkLmFjLnVrMSEwHwYJKoZIhvcNAQkBFhJKLk1hZGRvY2tAZWQu
             YWMudWswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOYxZHynoEEC+v9jK7CB
             Y4s6bum0BWQZDXFMAq3dRIBH0o0pYOf0FHkx6Sf6nktEo/PPNBMDb3Fu3VCnmEVi
             00OYosaVRmAY8UCJr7oUPKOg0YyZZiZcYxTLN48RBYTeVAoQ57g1QcBD3GpQEGel
             q76y5e6wdgWG3GYbCaIX7WjHAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAiQ7nKt7i
             hPl1iTPJnQsx6xo68IaFzvcTJ9GBnLindNxWPFA5sl3fVuEwXp8Y/swfZqjMdEnH
             umI8WF5Ys+hgAvjSSDBBwYCXLy+8wXoTGc5Bz9bXVwzSER0DtmXGCBaMktVo5IcL
             UlDCJNglzNrMSaBBxzb4Yo0p0IjoZCu/DM4=
          </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    ...
  </IDPSSODescriptor>
  ...
</EntityDescriptor>

In this case, the SP verifies the signature on the SAML Response from the IdP and compares the public key in the signature with the public key contained in the certificate in the metadata. If no certificate is present in the signature the public key from the certificate in the metadata is used to verify the signature. The trust process is now complete.

Direct signature validation via RSAKeyValue

This method is more or less the same as the X509Data method above, except the metadata must contain a raw RSAKeyValue node. Again, the SP uses the public key in the metadata to verify the signature on the IdP's assertion. Again, the trust process is complete if the signature validates.

PKIX Path Validation

This is the most commmon method for verifying an IdP and is also the most complicated, defined by RFC3280. The SP should use this method if both of the above methods fail or if there is no X509Data or RSAKeyValue in the metadata for the IdP. In this case, the IdP will have included the certificate in its SAML Response: 

<samlp:Response>
  <ds:Signature>
    <ds:SignatureValue>
      ...
    <ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIIDfjCCAuegAwIBAgIQLkN8T6BY84qOPNGjF4Gb1TANBgkqhkiG9w0BAQUFADCBzjELMAkGA1UE
          BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYDVQQK
          ExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE
          aXZpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkB
          FhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29tMB4XDTA4MDIxMzAwMDAwMFoXDTA5MDQxNTIzNTk1
          OVowgYMxCzAJBgNVBAYTAkdCMREwDwYDVQQIEwhTY290bGFuZDEVMBMGA1UEBxMMSXNsZSBvZiBT
          a3llMSEwHwYDVQQKExhVSEkgTWlsbGVubml1bSBJbnN0aXR1dGUxDDAKBgNVBAsTA1dXVzEZMBcG
          A1UEAxMQZ3VhbnhpLnVoaS5hYy51azCBnjANBgkqhkiG9w0BAQEFAAOBjAAwgYgCgYBtfcq6E1eO
          tHCeiqImxPGcqMwvuBLMbjQdBK+cQSl0ia8BsBM3r8C4Yh8DRS/qFED3hlSVgp8emTtZjgLYOzLG
          SGJmHsEeo/WomQNxkfoEC/eCprPInxNRMRdMtFYu337oKzLuW4R2Nae42YfgvxLr5SRjeMhvRQrD
          b9G2Ktx4SQIDAQABo4GmMIGjMAwGA1UdEwEB/wQCMAAwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cDov
          L2NybC50aGF3dGUuY29tL1RoYXd0ZVNlcnZlclByZW1pdW1DQS5jcmwwHQYDVR0lBBYwFAYIKwYB
          BQUHAwEGCCsGAQUFBwMCMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3Au
          dGhhd3RlLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCfj9PeSPUBdY+L0rWJIJ0cCXyRE3pgXEFGmtLa
          yK1c31vm1ZpajCnWdFxNYHJ8Yp5iI4oMY5yrB92HmG0vop0ewAJ2v8Jt8fbogVZ4RxhVAKtag8iQ
          nIATollQ1BU/ZJ0v5Hv96yD4G+i0siEhpLZXeemk+Q3sgg1jrJH0pM8xfg==
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
</samlp:Response>

The SP then uses the subject of the X509Certificate as a lookup within the metadata for the IdP, looking for a KeyName that matches, to verify it should be talking to this IdP. If it can't find a KeyName corresponding to the IdP's certificate subject it should not proceed further with the verification process. 

TBSCertificate  ::=  SEQUENCE  {
  issuer baddy.hq,
  subject idp.scaramanga.ac.uk
}

<EntityDescriptor ID="666" entityID="urn:scaramanga:den:of:theives">
  ...
  <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
    ...
    <KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:KeyName>idp.scaramanga.ac.uk</ds:KeyName>
      </ds:KeyInfo>
    </KeyDescriptor>
    ...
  </IDPSSODescriptor>

Once the SP has made the subject/KeyName match it then uses the public key within the IdP's certificate, which is embedded in the SAML Response, to verify the signature on the Response.

The final step is for the SP to recognise the Certificate Authority (CA) that issued the certificate to the IdP. As we can see above, baddy.hq is the IdP's CA in this case. To verify the CA as a trusted entity, the SP uses the Shibboleth SAML2 Metadata extensions block in the federation metadata. This is a list of CA certificates which are used to indicate whether an entity should trust the identity claims made by another entity. The Shibboleth extensions are a legacy remnant of Apache/OpenSSL/Tomcat mis-interactions and over time they should eventually disappear, to be replaced by the X509Data/RSAKeyValue methods of verification. We're stuck with them at the moment however, so the SP must iterate though them, looking for the baddy.hq CA: 

<EntitiesDescriptor>
  ...
  <Extensions>
    <shibmeta:KeyAuthority>
      ...
      <ds:KeyInfo>
        <!-- baddy.hq CA -->
        <ds:X509Data>
          <ds:X509Certificate>
            MIICvDCCAiWgAwIBAgIBADANBgkqhkiG9w0BAQUFADBIMQswCQYDVQQGEwJHQjEn
            MCUGA1UEChMeSklTQyBDb3JlIE1pZGRsZXdhcmUgUHJvZ3JhbW1lMRAwDgYDVQQD
            EwdTRFNTIENBMB4XDTA0MDgyNDEzMzQ1MFoXDTA4MTIzMTEzMzQ1MFowSDELMAkG
            A1UEBhMCR0IxJzAlBgNVBAoTHkpJU0MgQ29yZSBNaWRkbGV3YXJlIFByb2dyYW1t
            ZTEQMA4GA1UEAxMHU0RTUyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
            nG0nCHnged5EI4vKLU5ate5WzjJd39Zv7PZLuJIBN8M7RM3AfOqhXfcF1xGYs5oM
            GRytf672Fo3UffTn0wjOPRv+ZpK5YMjc1i1I44lWY/zHS3smT5gl7ZinRqyjBhTZ
            1WB0rHIiVJtBU10BmC/Gu96xV4331/CIAyoVbQNIn+cCAwEAAaOBtTCBsjAdBgNV
            HQ4EFgQUvq0gh0kHZ3Eez9e6q0CKdxYdK8AwcAYDVR0jBGkwZ4AUvq0gh0kHZ3Ee
            z9e6q0CKdxYdK8ChTKRKMEgxCzAJBgNVBAYTAkdCMScwJQYDVQQKEx5KSVNDIENv
            cmUgTWlkZGxld2FyZSBQcm9ncmFtbWUxEDAOBgNVBAMTB1NEU1MgQ0GCAQAwDwYD
            VR0TBAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADgYEA
            aImnqqpFtvuPayuSPSoH4gTaW0t3GOnN2stnRPrcP0FzfmQOA1BruKA4JsrRhBOs
            KyAs/351HF4hkBivFp2BXb4qQDP45l9YUJwTSfZT4oBLem5UWIZ/gzgYISz6G5eH
            0SOjzJxojpTWKe0eLkp9qUAdTgFKerXB9p+V84Uzgng=
          </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
      ...
    </shibmeta:KeyAuthority>
  </Extensions>
</EntitiesDescriptor>

As we can see, baddy.hq is a trusted CA so the trust process succeeds and Scaramanga is now free to enter his demand for ONE MEEELYON DOLLARS! But what about attributes? In this case, the Bond HQ SP can be sure that no-one would dare impersonate the arch baddy Scaramanga. His XML Signature alone is enough to gain entry to Bond HQ.

Retrieved from "http://www.guanxi.uhi.ac.uk/index.php/Metadata_and_trust_in_the_UK_Access_Management_Federation"
Personal tools