Wednesday, March 23, 2011 10:31 AM
IDP = My company (using ADFS 2.0)
SP = Third party (using Ping Federate)
I am extremely close to establishing a SSO connection to a third party. In a previous thread the setup we had was an IDP initiated SSO connection to the third party using the SAML 2.0 protocol. We managed to get the connection started and succesfully passed SAML tokens containing the various claims we selected. Our connection string to the third party looked something like this:
However after authenicating the browser then displayed a blank "Page cannot be displayed" error.
I went on to learn that this is a known issue in that ADFS 2.0 does not support the passing of relay state data in an IDP initiated scenario. Therefore my browser did not know where to go/what to do after authenicating. To be honest I'm a little surprised this scenario is not supported in ADFS 2.0
The third party mentioned they also support the WS Federation protocol so quickly setup a SP initiated WS Federation connection for us.
The connection string created for us is something like:
I manually created a relying party trust on our ADFS 2.0 server to use WS Federation ensuring that there was a WS Federation end point URL. I'm fairly confident the setup on the ADFS 2.0 server is correct.
Once again we are close to making a succesful connection but have hit a few problems. The above link produces a "Single Sign failed error message". My contact at the third party checked the Ping logs and found this:
2011-03-22 10:49:35,884 tid:e23925deb DEBUG [org.sourceid.util.log.TrackingIdSupport] [cross-reference-message] entityid:null subject:null
2011-03-22 10:49:35,884 tid:e23925deb ERROR [org.sourceid.wsfed.profiles.sp.HandleRSTR] Unexpected exception occurred in Response Handling: Unable to lookup idp connection metadata for entityid=http://OUR-ADFS-2.0-SERVER/adfs/services/trust
So my questions are:
1) Should our entity ID in Ping be http://OUR-ADFS-2.0-SERVER/adfs/services/trust or something else?
2) Our WS federation end point url entered into Ping is https://OUR-ADFS-2.0-Server/adfs/ls - I believe this is correct but would appreciate confirmation.
3) Are there any benefits or risks in using WSF over SAML 2.0 when you have a choice of both?
4) What other connection scenarios/options do we have? IDP iniated WSF connection? SAML 2.0 SP initiated connection?
Time has become crucial and I need this SSO working ASAP.
ps; sorry for the poor text formatting, haven't worked out how to change it.
Thursday, March 24, 2011 10:15 AM
Just an update...
Third party changed our enitity ID to the correct name after we used a fiddler trace to see where the problem was occuring.
Now the logs show:
INVALID commentary: [Not checking signature with configured verification cert **CERT NUMBER**because it does not match the embeded certificate in the signature.] signature on assertion (ID=_AN-ID-NUMBER). All assertions must have valid signatures.
So I checked over our token signing certificate and it seems the ADFS has created a new one as the "automatic certificate rollover" option is enabled. To remove it and install the correct certificate I had to disable it in Powershell using the command below:
set-ADFSProperties -AutoCertificateRollover $false
Anyone had to do this before?
Tried connecting again to the third party again, same error.
Restarted the ADFS service - same error.
Recreated the relying party trust - same error.
I've sent the third party my signature cert again to see if reimporting it helps and asked them to check the logs again after I tried conencting in again.
Friday, March 25, 2011 12:55 PM
Just updating to share experience:
Turns out the CRL Distribution point for the cert we sent our third party was not reachable for them to check the signature.
After some further checking we found the server in the CRL distribution check was taken down ages ago - no server!
This explains why the connection is still failing.
Looking into options to make it visible again.
Tuesday, March 29, 2011 9:07 AM
CRL point was made accessible externally but SSO is still failing - same error in logs.
I've sent our token signing certificate to support for further analysis.
I'm wondering if the cert is somehow corrupt? Strangely when we tried using a self signed cert it also failed.
Tuesday, March 29, 2011 2:07 PM
This is part of the error log from PING when I try connecting, I've changed some parts:
2011-03-28 09:03:36,905 tid:75827065c WARN [org.apache.xml.security.signature.Reference] Verification failed for URI "#_A-WHOLE-BUNCH-OF-NUMBERS
2011-03-28 09:03:36,905 tid:75827065c WARN [org.apache.xml.security.signature.Reference] Expected Digest: ALPHA-NUMERIC-CODE=
2011-03-28 09:03:36,905 tid:75827065c WARN [org.apache.xml.security.signature.Reference] Actual Digest: DIFFERENT-ALPHA-NUMERIC-CODE=
So it seems it was expecting "ABC" but got "XYZ" to put it plainly.
The certificate we are using for token signing was issued by our RootCA. I sent it to my thirdparty who added it to their trusted store
ADFS and the Relying Party setup are using the certificate we created and sent to the third party.
I'm at a loss as to why SSO is not working?
Would appreciate any suggestions.
Tuesday, March 29, 2011 8:56 PM
Sharing information in the (un)likley event someone else gets this issue.
We use ISA to pass external traffic to our ADFS box.
A setting in ISA rules had to be disabled (Link Translation).
It now works and we have a SSO connection to our third party. A few things need changing/fixing for when we move to our production envirnonment but for now its working!
- Marked As Answer by Piley Tuesday, March 29, 2011 8:57 PM
Friday, April 01, 2011 11:42 AM
Have you been able to fix this problem (with different expected and actual digests)? We are using ComponentSpace SAML 2.0 Component to build the response manually and experiencing exactly the same error.
Any help appreciated,
Friday, April 01, 2011 12:17 PM
Yes we did fix this problem by disabling link translation on our ISA server.The article below explains the similar situation we were in.
What hardware and software are using between ADFS and your third party? It seems like one of the components is "changing" something.
I hope this helps.
During a federation passive request to a WIF-protected web application, WIF throws an exception on the web server. When WIF tracing is enabled, the following exception is found in the service trace:
<ExceptionType>System.Security.Cryptography.CryptographicException, mscorlib, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType>
<Message>ID6018: Digest verification failed for reference '#_1d261dc4-e81e-47d0-abd3-a0c737939e55'.</Message>
at Microsoft.IdentityModel.Protocols.XmlSignature.Reference.EnsureDigestValidityIfIdMatches(String id, Object resolvedXmlSource)
at Microsoft.IdentityModel.Protocols.XmlSignature.SignedInfo.EnsureDigestValidityIfIdMatches(String id, Object resolvedXmlSource)
at Microsoft.IdentityModel.Protocols.XmlSignature.SignedInfo.EnsureDigestValidity(String id, Object resolvedXmlSource)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ReadAssertion(XmlReader reader)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ReadToken(XmlReader reader)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ReadToken(XmlReader reader)
at Microsoft.IdentityModel.Web.TokenReceiver.ReadToken(String tokenXml, XmlDictionaryReaderQuotas readerQuotas)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error)
at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)
at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)
at System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr ecb, Int32 iWRType)
<ExceptionString>System.Security.Cryptography.CryptographicException: ID6018: Digest verification failed for reference '#_1d261dc4-e81e-47d0-abd3-a0c737939e55'.</ExceptionString>
Note: The reference number will change each time the exception is thrown. The reference number changes because it correlates with the SAML assertion ID coming from the STS. The SAML assertion ID is unique to each assertion.
Something is happening to the SAML assertion in transit. When WIF receives a signed SAML assertion, it computes a digest of the assertion and compares its digest to the digest that was sent with the assertion. In this case, the digests do not match because something about the assertion changed after the STS signed it and before WIF parsed it.
In my specific case, the WIF-protected web application was published via ISA Server. The ISA publishing rule was configured to "Apply Link Translation to this rule" located on the Link Translation tab of the publishing rule.
1. Eliminate the entity in the middle who is modifying the assertion
2. Modify the actions performed by the entity in the middle
Monday, April 04, 2011 11:26 AM
Fixed! My bad! :)
Just so simple it was I can't believe it! I had my code adding things to the SAMLResponse after signing it! So embarassing! :)