Skip to content

Supporting SAML2-P RPs with ADFS2 as a R-STS

May 23, 2012

In my previous post (related to ADFS2) I mentioned how my client was using ADFS2 not as an identity provider but rather as a broker between a Java RP which used SAML2-P and thinktecture’s IdentityServer IP-STS which uses WS-Fed:

This configuration wasn’t working out of the box and the RP was failing to accept the token response. To try to reproduce the error I setup a local RP that issued SAML2-P token requests. The test RP I used came from the CTP of WIF Extensions for SAML 2 Protocol and when I ran this SAML-P client the error I got was:

Error: ID4406: The SAML response does not correct status code. Expected: ‘urn:oasis:names:tc:SAML:2.0:status:Success’, actual: ‘urn:oasis:names:tc:SAML:2.0:status:Responder’.

Turns out the problem is some discrepancy between WIF and/or ADFS2 when the IP-STS issues a SAML 2 token over WS-Fed to ADFS2 and then ADFS2 returns the token over SAML2-P to the RP. There’s something about the Subject attribute that’s lost in translation so then ADFS2 issues a non-success status to the SAML2-P RP. This whole situation was discovered and then further explained to me by Dominick. Also, to help diagnose this problem I used the most excellent SAML and WS-Fed Troubleshooter.

Anyway, the solution was to change the token type IdSrv was issuing from a SAML 2 token to a SAML 1.1 token. Once I made this configuration change (and restarted IdSrv) it was working fine.

Also, after I got this working I wondered if the actual problem was a flaw in IdSrv’s implementation (and not an issue with WIF and/or ADFS2). To test this I setup a scenario where the SAML2-P RP connected to a R-STS ADFS2 which then connected to another instance of ADFS2 acting as the IP-STS. To my surprise this configuration worked out of the box (after I removed the SAML2-P configuration from the ADFS2->ADFS2 trust relationship in order to force WS-Fed). It turns out that in this configuration the IP-STS ADFS2 was issuing a SAML 1.1 token to the R-STS ADFS2! I really wanted to see this configuration fail (and thus proving it was not a problem in IdSrv) and so I searched and searched for a way to configure ADFS2 to only issue SAML 2 tokens but I could not. It seems that for WS-Fed ADFS2 only issues SAML 1.1 tokens but for SAML2-P it issues SAML 2 tokens. Go figure.

2 Comments leave one →
  1. Krzysztof permalink
    March 3, 2015 3:50 am

    Hi,
    I have similar scenario, only I’m using ADFS 3.0 with IdentityServer2. Can you explain more precisely how to change the token type IdSrv is issuing from a SAML 2 token to a SAML 1.1?
    Is it enough to change token type in relying party configuration from “non selected” to SAML11 or do I need to change also Default WS* Token in the General Configuration tab (currently the value is: urn:oasis:names:tc:SAML:2.0:assertion)?

    Thank you in advance for your answer.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: