The other day, I was working on a proof of concept for a customer who wanted to do some identity federation testing between Oracle, IBM, and ADFS version 2. In this configuration, we were working with an architecture that resembled the following:
Going into this, I thought this was a no-brainer - after all, ADFS v2 passed IdP Lite, SP Lite, and eGov SAML profile testing. The ADFS v2 configuration went smoothly. I got the metadata file from Oracle and imported with no issues. There were no problems whatsoever setting up the RP trust on my end. Here's a screen capture of my endpoint configuration:
However, when it came time for Oracle to import the ADFS v2 metadata file, we ran into issues. When Oracle tried to import our FederationMetadata.xml file, they were getting the following error:
org.xml.sax.SAXException: Could not locate translation scheme associated with "http://docs.oasis-open.org/wsfed/federation/200706":ApplicationServiceType, child of "urn:oasis:names:tc:SAML:2.0:metadata"
As it turns out, the Oracle SP doesn't support harmonized data in the SAML metadata format. By default in ADFS v2, we expose both the SAML and WS-Federation endpoints in our FederationMetadata.xml file. In the screen capture below, you can see that the RoleDescriptor elements contain the data for our WS-Fed endpoints. The SAML 2.0 metadata spec does allow this. It’s defined in section 2.4.1 of the SAML Metadata 2.0 format specification.
So I manually removed the RoleDescriptor elements and re-sent the FederationMetadata.xml file back over to Oracle. So now, the file only had the SPSSODescriptor and IDPSSODescriptor elements, which are used to define only the SAML endpoints. The below screen capture shows the edited file:
So I sent this file back to Oracle and voila… a different error:
javax.management.RuntimeMBeanException: javax.management.RuntimeMBeanException: The Signing Certificate could not be validated. Could not add metadata at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:205)
As anyone reading the above error would assume, I read this and thought they were having issues with our token signing cert. So I sent them over a copy of the .cer file and they imported it into their certificate store, but it still didn't work. I wasn't sure what else we could do on the Microsoft side, so I tabled this for a few days, waiting for Oracle to come up with an answer as to why they couldn't import the file.
A few days later, I was sitting at Panera Bread having lunch and working (as is my usual fare) when I suddenly realized that I never regenerated the signature on the metadata file! Doh! So after consulting with the trusty (pun intended) ADFS product group on the best way to regenerate that signature, I took their advice to try removing it altogether. I opened the FederationMetadata.xml file, deleted the signature element (the ds element) and sent it back over to my new buddy Matt at Oracle.
I tell you, I heard the church bells ringing that day - the file worked and the world gasped in silence for a nanosecond as Microsoft and Oracle came together in harmony. Here's a screen capture of the metadata file with the signature removed:
So here are the lessons learned when federating ADFS v2 with Oracle Identity Federation:
- Don't use the FederationMetadata.xml file unless you want to modify it
- If you do use the FederationMetadata.xml file, remove the WS-Fed RoleDescriptor elements and don't forget to remove or regenerate the signature on the file
- Don't take java error messages at face value … I know, I know - we're guilty of that too, sometimes :)
I swear I could hear Laura Hunter across the US… "So it was both PKI AND a typo" Special thanks to Matt @ Oracle!