For ADFS I have explained in this blog post, from a process perspective, what you need to do when you need to replace any of the certificates in use by ADFS. Shibboleth is yet another federated identity solution and it is open source. You can read more about it here and here.
–
Like ADFS, Shibboleth (and any other federated identity solution) uses certificates for Token Signing and Token Encryption and you can either just use one certificate for both or use 2 individual certificates, one for each operation.
–
[Scenario 1] If you use just one certificate for both operations, your Shibboleth configuration (in ..\Shibboleth-SP\etc\shibboleth\shibboleth2.xml) regarding certificates may be similar to:
<CredentialResolver type="Chaining">
<CredentialResolver type="File" key="SHIBBOLETH.ADCORP.LAB_key_v1.key" certificate="SHIBBOLETH.ADCORP.LAB_cert_v1.pem" keyName="Current Token Signing/Encryption Cert"/>
</CredentialResolver>
–
[Scenario 2] If you use just one certificate for each operation, your Shibboleth configuration (in ..\Shibboleth-SP\etc\shibboleth\shibboleth2.xml) regarding certificates may be similar to:
<CredentialResolver type="Chaining">
<CredentialResolver type="File" key="SHIBBOLETH.ADCORP.LAB_signing_key_v1.key" certificate="SHIBBOLETH.ADCORP.LAB_signing_cert_v1.pem" use="signing" keyName="Current Token Signing Cert"/>
<CredentialResolver type="File" key="SHIBBOLETH.ADCORP.LAB_encryption_key_v1.key" certificate="SHIBBOLETH.ADCORP.LAB_encryption_cert_v1.pem" use="encryption" keyName="Current Token Encryption Cert"/>
</CredentialResolver>
–
REMARK: it is not mandatory to specify ‘use’ or keyname. When no ‘use’ is specified explicitly, it is both used for signing and encryption. When no ‘keyname’ is specified it uses the common name of the certificate as the keyname.
–
Based upon the configuration above in Shibboleth, you will the following in ADFS (or something similar)
Figure 1: The Federation Trust With A Token Encryption Certificate
–
Figure 2: The Federation Trust With One Token Signing Certificate
–
Shibboleth supports the publication of information regarding the federated identity solution into the federated identity solution metadata. ADFS in turn supports the consumption of automatic published metadata. So you are good to go and you have no worries when the federation partner using Shibboleth needs to replace the current certificates! Wrong!.
–
After the federation partner using Shibboleth configures Shibboleth using one of the following ways, or something similar:
[Scenario 1] If you use just one certificate for both operations, your Shibboleth configuration (in ..\Shibboleth-SP\etc\shibboleth\shibboleth2.xml) regarding certificates may be similar to:
<CredentialResolver type="Chaining">
<CredentialResolver type="File" key="SHIBBOLETH.ADCORP.LAB_key_v1.pem" certificate="SHIBBOLETH.ADCORP.LAB_cert_v1.pem" keyName="Current Token Signing/Encryption Cert"/>
<CredentialResolver type="File" key="SHIBBOLETH.ADCORP.LAB_key_v2.pem" certificate="SHIBBOLETH.ADCORP.LAB_cert_v2.pem" keyName="New Token Signing/Encryption Cert"/>
</CredentialResolver>
–
[Scenario 2] If you use just one certificate for each operation, your Shibboleth configuration (in ..\Shibboleth-SP\etc\shibboleth\shibboleth2.xml) regarding certificates may be similar to:
<CredentialResolver type="Chaining">
<CredentialResolver type="File" key="SHIBBOLETH.ADCORP.LAB_signing_key_v1.pem" certificate="SHIBBOLETH.ADCORP.LAB_signing_cert_v1.pem" use="signing" keyName="Current Token Signing Cert"/>
<CredentialResolver type="File" key="SHIBBOLETH.ADCORP.LAB_encryption_key_v1.pem" certificate="SHIBBOLETH.ADCORP.LAB_encryption_cert_v1.pem" use="encryption" keyName="Current Token Encryption Cert"/>
<CredentialResolver type="File" key="SHIBBOLETH.ADCORP.LAB_signing_key_v2.pem" certificate="SHIBBOLETH.ADCORP.LAB_signing_cert_v2.pem" use="signing" keyName="New Token Signing Cert"/>
<CredentialResolver type="File" key="SHIBBOLETH.ADCORP.LAB_encryption_key_v2.pem" certificate="SHIBBOLETH.ADCORP.LAB_encryption_cert_v2.pem" use="encryption" keyName="New Token Encryption Cert"/>
</CredentialResolver>
–
…you will start to see the following error in ADFS
[A] the federation trust with a red cross and not updating itself while automatic monitoring and updating is enabled
Figure 3: A Federation Trust In Error
–
Figure 4: An Outdated Federation Trust With Automatic Monitoring/Updating
–
[B] the next time you manually update the metadata through the GUI of the CP or RP Trust representing the Shibboleth federated identity solution
Figure 5: Manually Updating The Metadata Of A Shibboleth Based Federated Identity Solution Using The ADFS GUI Results In Error
–
An unexpected error occurred during an attempt to process the federation metadata. Verify that the federation metadata is correct and try again.
Error message: MSIS7508: The metadata contains unexpected data. Conflicting encryption certificates were found in the RoleDescriptors needed to represent a service provider role.
–
[C] the next time you manually update the metadata through PowerShell of the CP or RP Trust representing the Shibboleth federated identity solution
Figure 6: Manually Updating The Metadata Of A Shibboleth Based Federated Identity Solution Using The ADFS CMDlets Results In Error
–
Update-ADFSRelyingPartyTrust : MSIS7508: The metadata contains unexpected data. Conflicting encryption certificates were found in the RoleDescriptors needed to represent a service provider role.
At line:1 char:29
+ Update-ADFSRelyingPartyTrust <<<< -TargetName "Shibboleth Service Provider (R1FSMBSV4)"
+ CategoryInfo : NotSpecified: (Microsoft.Ident…lyingPartyTrust:RelyingPartyTrust) [Update-ADFSRelyingPartyTrust], MetadataProcessingException
+ FullyQualifiedErrorId : MSIS7508,Microsoft.IdentityServer.PowerShell.Commands.UpdateRelyingPartyTrustCommand
–
The reason this happens is that ADFS does not support (accept) the consumption of (automatic) metadata from another federated identity solution that publishes two Token Encryption certificates. Shibboleth publishes as many Token Encryption certificates as you have configured it with. This may also apply to other federated identity solutions. This is not a problem if multiple Token Signing certificates are published.
–
The first thing you need to do is download the metadata to a file using the federation metadata URL as specified in the federation trust (see figure 2). Save the metadata to a file called "METADATA_<TRUST NAME>_ORG.TXT". Then make a copy of that file and name it "METADATA_<TRUST NAME>_MODIFIED.TXT". Now open and edit the last file.
If "scenario 1" applies, 2 so called CredentialResolvers have been defined in Shibboleth and in the metadata you will find 2 "<md:KeyDescriptor>" sections. Depending on the way it has been configured you may not be able to distinguish between the current certificate(s) and the new certificate(s). For each "<md:KeyDescriptor>" section copy the data/value in the "<ds:X509Certificate>" section into the decoding window on a website such as http://www.sslshopper.com/certificate-decoder.html or http://redkestrel.co.uk/products/decoder/. After doing that for each certificate you will see something such as shown in the pictures below. Now you will be able to determine which certificate is the current certificate and which is the new certificate.
Figure 7: Decoded Data Of A Certificate (This Is The Current/Old Certificate)
–
Figure 8: Decoded Data Of A Certificate(This Is The New Certificate)
–
For the current/oldest certificate configure the <md:KeyDescriptor> (figure 9) as <md:KeyDescriptor use="signing"> (figure 10)
Figure 9: KeyDescriptor Without Use Specification – Old Certificate Used For Both Signing And Encryption (Before)
–
Figure 10: KeyDescriptor With Use Specification – Old Certificate Used For Signing Only (After)
–
For the newest certificate create a full copy of the <md:KeyDescriptor>
For the newest certificate configure the first <md:KeyDescriptor> (figure 11) as <md:KeyDescriptor use="signing"> (figure 12)
Figure 11: KeyDescriptor Without Use Specification – New Certificate Used For Both Signing And Encryption (Before)
–
Figure 12: KeyDescriptor With Use Specification – New Certificate Used For Signing Only (After)
–
For the newest certificate configure the second <md:KeyDescriptor> (figure 13) as <md:KeyDescriptor use="encryption"> (figure 14)
Figure 13: KeyDescriptor Without Use Specification – New Certificate Used For Both Signing And Encryption (Before)
–
Figure 14: KeyDescriptor With Use Specification – New Certificate Used For Encryption Only (After)
–
After performing the changes save "METADATA_<TRUST NAME>_MODIFIED.TXT"
–
Now it is time to manually update the CP or RP trust with the new metadata.
First execute: Add-PsSnapin microsoft.adfs.powershell (ADFS v2.0) OR Import-Module ADFS (ADFS v2.x and higher)
For CP Trusts execute: Update-ADFSClaimsProviderTrust -TargetName "<CP Trust Name>" -MetadataFile "<Path to file METADATA_<TRUST NAME>_MODIFIED.TXT>"
For RP Trusts execute: Update-ADFSRelyingPartyTrust -TargetName "<RP Trust Name>" -MetadataFile "<Path to file METADATA_<TRUST NAME>_MODIFIED.TXT>"
–
After executing the update command you most likely will see the following. The yellow errors can be ignored.
Figure 15: Manually Updating The Metadata Of The Federation Trust
–
When checking the federation trust you will that the certificates have been updated
Figure 16: The Federation Trust With A New Token Encryption Certificate
–
Figure 17: The Federation Trust With Two Token Signing Certificates (One Old And One New)
–
Be aware that the errors on figure 4, 5 and 6 will continue to occur until the Shibboleth administrator has removed the multiple definitions of a Token Encryption certificate. As soon as that happens, the metadata can be updated again automatically!
When updating the metadata manually you will again see:
Figure 18: Manually Updating The Metadata Of A Shibboleth Based Federated Identity Solution Using The ADFS GUI Results In Messaging Stating Incompatibilities
–
If "scenario 2" applies, 4 so called CredentialResolvers have been defined in Shibboleth and in the metadata you will find 4 "<md:KeyDescriptor>" sections. Depending on the way it has been configured you may not be able to distinguish between the current certificate(s) and the new certificate(s). For each "<md:KeyDescriptor>" section copy the data/value in the "<ds:X509Certificate>" section into the decoding window on a website such as http://www.sslshopper.com/certificate-decoder.html or http://redkestrel.co.uk/products/decoder/. After doing that for each certificate you will see something such as shown in the pictures 7 and 8. Now you will be able to determine which certificate is the current certificate and which is the new certificate.
–
For the current/oldest encryption certificate remove its <md:KeyDescriptor use="encryption"> section. You are now left with three <md:KeyDescriptor> sections where each already has a use defined. Save the file and update the federation trust accordingly as explained above. Be aware that the errors on figure 4, 5 and 6 will continue to occur until the Shibboleth administrator has removed the multiple definitions of a Token Encryption certificate. As soon as that happens, the metadata can be updated again automatically!
–
Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————
Jorge's Quest For Knowledge! 