OIF idp, ADFS sp: "MSIS7029: The SAML response has content that is not supported"

Question

Hello,
We're a team trying to get an Oracle Identity Federation server as idp to work with an ADFS 2.0 as sp with an http post binding.

We're closely following a microsoft guide on this topic (http://technet.microsoft.com/en-us/library/ff849212%28WS.10%29.aspx), just subsituting our own hosts and test user names.

We've come some of the way in that we get a saml response from the idp (see paste 1 below), encoded and inserted into an html post (see paste 2 below) which is then posted to the adfs. Here our luck ends though. We get an error in the event log for the ADFS host:

"Encountered error during federation passive request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.UnsupportedSamlResponseException: MSIS7029: The SAML response has content that is not supported.
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolResponse(FederationPassiveContext federationPassiveContext)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(SecurityToken securityToken). "

In the ADFS 2.0 Tracing->Debug event log we at the same time get a "Encoded context is null or empty." error.

Does anyone know either
1. how we get additional debug info from the ADFS host such that we can pinpoint more precisely what part of the content is not supported
2. What in the SAML response or http post the ADFS doesn't like?

Thanks beforehand for any and all help and info,

Yarc.
-----------------paste 1: saml response-----------
(I've changed sensitive url's and names in this response)

<samlp:Response xmlnS:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://mysp.com/adfs/ls/" ID="id-MbtPGI0KDoYTkXmyhhCzaO33qkI-" InResponseTo="id-6a9f996c-b885-4b61-b2e7-a115d50c7aa3" IssueInstant="2011-03-01T09:24:45Z" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://oif.com/fed/idp</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="id-dWJgdC4vrUMA8Jz6IsnnuaL0L3o-" IssueInstant="2011-03-01T09:24:45Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://oif.com/fed/idp</saml:Issuer>
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<dsig:Reference URI="#id-dWJgdC4vrUMA8Jz6IsnnuaL0L3o-">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>
hAW+09VlK9NjH9KGpQzYms7FyZY=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>
Fu0LPQ9z6grl/5p+VF6R89DYn1R72vhrouLcU8+u5o1bKyEC3WRH8gYFHwf11TU3Wj6UEQqnOJSIoUbCm0pOOph4AbJpWMSNmFNJgswNRYSnDjOzCnUz/eVbugJ9eZsH3tleCJyfVbZT00JR+EUsYl598tm8H0fHyzKwAWx+x2dv2z92JTlW75Xs5CSMS92DW8kZL6gPbqsmDVYrjZ5m+wtU2uq0AXkruLyCCRnndMxPa3kWgFnx7hedb/s7yZlBuYiA0mZxjT7c3AYJw5CFwNcktMyWh37tX3e4hvpUfCIx4mub3VnWqnI0Nh8+0v82aOkAaacJKsqbDe1yV2FMiw==</dsig:SignatureValue>
</dsig:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
testuser@localdomain</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="id-6a9f996c-b885-4b61-b2e7-a115d50c7aa3" NotOnOrAfter="2011-03-01T09:39:45Z" Recipient="https://mysp.com/adfs/ls/"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2011-03-01T09:14:45Z" NotOnOrAfter="2011-03-01T09:39:45Z">
<saml:AudienceRestriction>
<saml:Audience>
http://mysp.com/adfs/services/trust</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2011-03-01T08:41:17Z" SessionIndex="id-Y4CMFqCBVQrejZGlX48Uzjve0-o-" SessionNotOnOrAfter="2011-03-01T10:24:45Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saml:Attribute Name="http://schemas.xlmsoap.org/ws/2005/05/identity/claims/name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

---------------------paste 2: html post---------------------
(Since I've changed sensitive info in paste 1, I have reencoded the response in here (with https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php), so bear over with me if I've screwed up that part) .

<HTML>
<BODY onload="document.forms[0].submit();">
<FORM METHOD="POST" ACTION="https://mysp.com/adfs/ls/">
 
<INPUT TYPE="hidden" NAME="SAMLResponse" VALUE="PHNhbWxwOlJlc3BvbnNlIHhtbG5TOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIERlc3RpbmF0aW9uPSJodHRwczovL215c3AuY29tL2FkZnMvbHMvIiBJRD0iaWQtTWJ0UEdJMEtEb1lUa1hteWhoQ3phTzMzcWtJLSIgSW5SZXNwb25zZVRvPSJpZC02YTlmOTk2Yy1iODg1LTRiNjEtYjJlNy1hMTE1ZDUwYzdhYTMiIElzc3VlSW5zdGFudD0iMjAxMS0wMy0wMVQwOToyNDo0NVoiIFZlcnNpb249IjIuMCI+DQo8c2FtbDpJc3N1ZXIgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiIgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlkLWZvcm1hdDplbnRpdHkiPg0KaHR0cHM6Ly9vaWYuY29tL2ZlZC9pZHA8L3NhbWw6SXNzdWVyPg0KPHNhbWxwOlN0YXR1cz4NCjxzYW1scDpTdGF0dXNDb2RlIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6c3RhdHVzOlN1Y2Nlc3MiLz4NCjwvc2FtbHA6U3RhdHVzPg0KPHNhbWw6QXNzZXJ0aW9uIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iIElEPSJpZC1kV0pnZEM0dnJVTUE4Sno2SXNubnVhTDBMM28tIiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDMtMDFUMDk6MjQ6NDVaIiBWZXJzaW9uPSIyLjAiPg0KPHNhbWw6SXNzdWVyIEZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm5hbWVpZC1mb3JtYXQ6ZW50aXR5Ij4NCmh0dHBzOi8vb2lmLmNvbS9mZWQvaWRwPC9zYW1sOklzc3Vlcj4NCjxkc2lnOlNpZ25hdHVyZSB4bWxuczpkc2lnPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj4NCjxkc2lnOlNpZ25lZEluZm8+DQo8ZHNpZzpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+DQo8ZHNpZzpTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjcnNhLXNoYTEiLz4NCjxkc2lnOlJlZmVyZW5jZSBVUkk9IiNpZC1kV0pnZEM0dnJVTUE4Sno2SXNubnVhTDBMM28tIj4NCjxkc2lnOlRyYW5zZm9ybXM+DQo8ZHNpZzpUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZW52ZWxvcGVkLXNpZ25hdHVyZSIvPg0KPGRzaWc6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+DQo8L2RzaWc6VHJhbnNmb3Jtcz4NCjxkc2lnOkRpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNzaGExIi8+DQo8ZHNpZzpEaWdlc3RWYWx1ZT4NCmhBVyswOVZsSzlOakg5S0dwUXpZbXM3RnlaWT08L2RzaWc6RGlnZXN0VmFsdWU+DQo8L2RzaWc6UmVmZXJlbmNlPg0KPC9kc2lnOlNpZ25lZEluZm8+DQo8ZHNpZzpTaWduYXR1cmVWYWx1ZT4NCkZ1MExQUTl6NmdybC81cCtWRjZSODlEWW4xUjcydmhyb3VMY1U4K3U1bzFiS3lFQzNXUkg4Z1lGSHdmMTFUVTNXajZVRVFxbk9KU0lvVWJDbTBwT09waDRBYkpwV01TTm1GTkpnc3dOUllTbkRqT3pDblV6L2VWYnVnSjllWnNIM3RsZUNKeWZWYlpUMDBKUitFVXNZbDU5OHRtOEgwZkh5ekt3QVd4K3gyZHYyejkySlRsVzc1WHM1Q1NNUzkyRFc4a1pMNmdQYnFzbURWWXJqWjVtK3d0VTJ1cTBBWGtydUx5Q0NSbm5kTXhQYTNrV2dGbng3aGVkYi9zN3labEJ1WWlBMG1aeGpUN2MzQVlKdzVDRndOY2t0TXlXaDM3dFgzZTRodnBVZkNJeDRtdWIzVm5XcW5JME5oOCswdjgyYU9rQWFhY0pLc3FiRGUxeVYyRk1pdz09PC9kc2lnOlNpZ25hdHVyZVZhbHVlPg0KPC9kc2lnOlNpZ25hdHVyZT4NCjxzYW1sOlN1YmplY3Q+DQo8c2FtbDpOYW1lSUQgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoxLjE6bmFtZWlkLWZvcm1hdDplbWFpbEFkZHJlc3MiPg0KdGVzdHVzZXJAbG9jYWxkb21haW48L3NhbWw6TmFtZUlEPg0KPHNhbWw6U3ViamVjdENvbmZpcm1hdGlvbiBNZXRob2Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpjbTpiZWFyZXIiPg0KPHNhbWw6U3ViamVjdENvbmZpcm1hdGlvbkRhdGEgSW5SZXNwb25zZVRvPSJpZC02YTlmOTk2Yy1iODg1LTRiNjEtYjJlNy1hMTE1ZDUwYzdhYTMiIE5vdE9uT3JBZnRlcj0iMjAxMS0wMy0wMVQwOTozOTo0NVoiIFJlY2lwaWVudD0iaHR0cHM6Ly9teXNwLmNvbS9hZGZzL2xzLyIvPg0KPC9zYW1sOlN1YmplY3RDb25maXJtYXRpb24+DQo8L3NhbWw6U3ViamVjdD4NCjxzYW1sOkNvbmRpdGlvbnMgTm90QmVmb3JlPSIyMDExLTAzLTAxVDA5OjE0OjQ1WiIgTm90T25PckFmdGVyPSIyMDExLTAzLTAxVDA5OjM5OjQ1WiI+DQo8c2FtbDpBdWRpZW5jZVJlc3RyaWN0aW9uPg0KPHNhbWw6QXVkaWVuY2U+DQpodHRwOi8vbXlzcC5jb20vYWRmcy9zZXJ2aWNlcy90cnVzdDwvc2FtbDpBdWRpZW5jZT4NCjwvc2FtbDpBdWRpZW5jZVJlc3RyaWN0aW9uPg0KPC9zYW1sOkNvbmRpdGlvbnM+DQo8c2FtbDpBdXRoblN0YXRlbWVudCBBdXRobkluc3RhbnQ9IjIwMTEtMDMtMDFUMDg6NDE6MTdaIiBTZXNzaW9uSW5kZXg9ImlkLVk0Q01GcUNCVlFyZWpaR2xYNDhVemp2ZTAtby0iIFNlc3Npb25Ob3RPbk9yQWZ0ZXI9IjIwMTEtMDMtMDFUMTA6MjQ6NDVaIj4NCjxzYW1sOkF1dGhuQ29udGV4dD4NCjxzYW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPg0KdXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFjOmNsYXNzZXM6UGFzc3dvcmRQcm90ZWN0ZWRUcmFuc3BvcnQ8L3NhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY+DQo8L3NhbWw6QXV0aG5Db250ZXh0Pg0KPC9zYW1sOkF1dGhuU3RhdGVtZW50Pg0KPHNhbWw6QXR0cmlidXRlU3RhdGVtZW50IHhtbG5zOng1MDA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm9maWxlczphdHRyaWJ1dGU6WDUwMCIgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIj4NCjxzYW1sOkF0dHJpYnV0ZSBOYW1lPSJodHRwOi8vc2NoZW1hcy54bG1zb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIiBOYW1lRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXR0cm5hbWUtZm9ybWF0OmJhc2ljIi8+DQo8L3NhbWw6QXR0cmlidXRlU3RhdGVtZW50Pg0KPC9zYW1sOkFzc2VydGlvbj4NCjwvc2FtbHA6UmVzcG9uc2U+
"/>
 
<INPUT TYPE="hidden" NAME="RelayState" VALUE="ec0112ce-6fe5-40ec-82bc-0cd621f6b45a"/>
 
</FORM>
</BODY>
</HTML> 

Answer 1

You already seem to use the regular debug log etc. If that fails I usually generate symbols with Reflector and then go in single stepping with the debugger.

I cannot see an obvious error in the SAMLResponse (I have only looked at the XML, not the POST). The only thing obviously strange is that the (single) Attribute element does not have an AttributeValue element. Wouldn't be surprised if someone doesn't like that, but I haven't checked if that is illegal. This might be your next problem....

I cannot yet find the relation with:  "Encoded context is null or empty."
That is probably something different but could be related to the same request. It seems that ADFS2 is trying to forward the response to the RP, but it cannot find the "context" of that next RP. That would indicate that something is wrong with the context chain (incorrect wctx and/or RelayState, cookie content or the GUID glue to chain them....)

Let OIF fill the Attribute, just to exclude that point. Probably not an answer yet, but maybe it helps you one step further.

---

Paul Lemmers

Answer 2

One more thing, but I would be surprised if this is it.
The NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" for Name="http://schemas.xlmsoap.org/ws/2005/05/identity/claims/name"

I left it out because I think ADFS is a bit lax about this. But it would be painful (in the end) if it was this.

---

Paul Lemmers

Answer 3

I'm impressed with the swiftness and precision of your replies. We will investigate today and I'll let you know how it went.

Thanks so far Paul,

:-)

Yarc.

Answer 4

We've had a look at your suggestions.

 

- We've added an AttributeValue tag, see paste 1. We simply edited the response from the OIF before it was posted to ADFS. This changed nothing. Same errors («MSIS7029: The SAML response has content that is not supported.» and «Encoded context is null or empty») and the correlation id's match between the two errors and the IIS request reference.

 

- We've looked at the RelayState. The ADFS 302 Found that redirects to the OIF contains a « RelayState=1a78c8ba-d2e0-406b-a287-3729c48125aa&amp» that matches the «<INPUT TYPE="hidden" NAME="RelayState" VALUE="1a78c8ba-d2e0-406b-a287-3729c48125aa"/> in the OIF postback to the ADFS. So that looks ok doesn't it?

 

- We've looked at the wctx argument. Here there are a couple of things to note;

 

- - The 302 Found that redirects from Sharepoint to the ADFS contains a «wctx=https%3a%2f%2fsharepoint.com%2fsites%2ftest%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252Fsites%252Ftest». I'm not an expert at decoding ascii hex, but isn't the latter part «%252Fsites%252Ftest» a bit strange in that %25 will resolve to '%', but %252f will not resolve to anything meaningful ('/' I guess would be the aim) ?

 

- - The http get from ADFS to OIF (GET https://oif.com/fed/idp/samlv20?SAMLRequest=<..>) contains a referer with the same wctx,but the reply from OIF that the user agent posts back to ADFS doesn't contain any mention of this wctx at all. Is that a problem?

 

- We've looked at the cookies. For the 302 Found that redirects from the ADFS to OIF we have a reply that sets cookies (see paste 2). When the OIF returns with a SAML response and it is posted back to the ADFS we find no cookies with the request. Is that a problem?

 

We use fiddler to follow the http traffic btw.

 

We again appreciate any and all help,

 

Yarc

 

--------------paste 1: an added AttributeValue---------

 

<saml:Attribute Name="http://schemas.xlmsoap.org/ws/2005/05/identity/claims/name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue>TestValue</saml:AttributeValue>

</saml:Attribute>

 

 

-----------paste 2: ADFS cookies set as we move to OIF------

 

 

 

Set-Cookie: MSISIPSelectionSession=<..>; path=/adfs/ls; secure; HttpOnly

Set-Cookie: MSISContext864cb091-a8bf-488e-a620-f307522571ae=<..>; path=/adfs/ls; secure; HttpOnly

Answer 5

> The NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" for Name="http://schemas.xlmsoap.org/ws/2005/05/identity/claims/name "

Tried that as well. Changed it to "<saml:Attribute Name="http://schemas.xlmsoap.org/ws/2005/05/identity/claims/name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">" an tested it with no luck with or without an AttributeValue. And tried AttributeValues with     <saml:AttributeValue xsi:type="xs:string"> explicit typing. To no avail.

Sigh.

:-O

Yarc.

Answer 6

I am going to take a look at your new test results now. Is there a way for us to get in touch of the list, so that (if necessary) you could send me the Fiddler trace? Because then I will be able to compare it with my fiddler traces of a working configuration, which I could send to you.

I am not so hard to find since you can find my company name (devcon in the Netherlands) in the paullem profile. And firstname.lastname will do the rest. Although Paul is a very respected lastname, it is my firstname :-).

---

Paul Lemmers

Answer 7

 

- We've added an AttributeValue tag, see paste 1. We simply edited the response from the OIF before it was posted to ADFS. This changed nothing. Same errors («MSIS7029: The SAML response has content that is not supported.» and «Encoded context is null or empty») and the correlation id's match between the two errors and the IIS request reference.

Not surprisin, but ADFS somtimes does thing in an unexpected order. Away that seem OK. Also the NameFormat change.

- We've looked at the RelayState. The ADFS 302 Found that redirects to the OIF contains a « RelayState=1a78c8ba-d2e0-406b-a287-3729c48125aa&amp» that matches the «<INPUT TYPE="hidden" NAME="RelayState" VALUE="1a78c8ba-d2e0-406b-a287-3729c48125aa"/> in the OIF postback to the ADFS. So that looks ok doesn't it?

 Indeed echoed correctly. BUT I would expect the MSISContext cookie to have this RelayState in its name....... See below 

The 302 Found that redirects from Sharepoint to the ADFS contains a «wctx=https%3a%2f%2fsharepoint.com%2fsites%2ftest%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252Fsites%252Ftest». I'm not an expert at decoding ascii hex, but isn't the latter part «%252Fsites%252Ftest» a bit strange in that %25 will resolve to '%', but %252f will not resolve to anything meaningful ('/' I guess would be the aim) ?

 Not unusual. Probably because there are several nested encodings/decodings

The http get from ADFS to OIF (GET https://oif.com/fed/idp/samlv20?SAMLRequest=<..>) contains a referer with the same wctx,but the reply from OIF that the user agent posts back to ADFS doesn't contain any mention of this wctx at all. Is that a problem?

No that is OK. wctx is part of the WS-fed spec, and your ADFS "talks" SAML2 with OIF.

We've looked at the cookies. For the 302 Found that redirects from the ADFS to OIF we have a reply that sets cookies (see paste 2). When the OIF returns with a SAML response and it is posted back to the ADFS we find no cookies with the request. Is that a problem?

Yes it seems as if something weird is going on there.... In my own trace the cookies are of course returned to the ADFS server. As said above the RelayState is part of the name of the MSISContext cookie. This looks like the way ADFS is "remembering" the original request from your Sharepoint server. If it is missing then I would expect the "Encoded context is null or empty" error. So two deviations from my trace: 1) should be returned, 2) non-matching name.

Looks like we are getting closer! 

---

Paul Lemmers

Answer 8

Any Luck on this?

 

I am stuck on EXACTLY the same problem but with Shibboleth as Idp.

Below is the SAML response (decoded, but changed some URLs for making it cryptic):

<?xml version="1.0" encoding="UTF-8"?>
-<saml2p:Response Version="2.0" IssueInstant="2011-09-16T19:29:43.338Z" InResponseTo="id-87041017-8767-4408-a3f0-bca5530b98b2" ID="_fdfd013a69634893b913bf7ed83081fb" Destination="https://xyz/adfs/ls/" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"><saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">urn:mace:incommon:xyz</saml2:Issuer>-<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> -<ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> -<ds:Reference URI="#_fdfd013a69634893b913bf7ed83081fb"> -<ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> -<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces PrefixList="ds saml2 saml2p xs" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>i7mnx6OfMaErQs0ENIQZG/qlY2A=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> LUJDP8oRU8ENak21cS5vtH3Njw1Jbdy4GfwvZaRmPhwdW7JbbXhBp9SaTCdYzrOVnC/o7Oy6qSIH JI4zjWW5Mm3QxDM5Hd0MZwuSZrV+m6R91yaGAwnmUfZ99CkYqfCtpTUYl/5wDn33yOdCXTk+bSnK emv/Mov0Jd2q4BG/dAymfyPjib2QOEYj+42BITTF+uMbaBxhsReT+nI8fXeoN0VyBcqVlS3rGRov 8zQqUvzyv9WTwVaRWsyQTigs90fO7wS78FeOSLhFRTW2R8hXOVFO+9b3rzCh0lQqNEOsLDVWfQxK Cz2VK/VmE4SqeufCvz/kP0IOMBQ0IlmYaZICrA== </ds:SignatureValue> -<ds:KeyInfo>-<ds:X509Data><ds:X509Certificate>MIID/TCCAuWgAwIBAgIJAMoYJbDt9lKKMA0GCSqGSIb3DQEBBQUAMFwxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJXQTEhMB8GA1UEChMYVW5pdmVyc2l0eSBvZiBXYXNoaW5ndG9uMR0wGwYDVQQDExRp ZHAudS53YXNoaW5ndG9uLmVkdTAeFw0xMTA0MjYxOTEwMzlaFw0yMTA0MjMxOTEwMzlaMFwxCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJXQTEhMB8GA1UEChMYVW5pdmVyc2l0eSBvZiBXYXNoaW5ndG9u MR0wGwYDVQQDExRpZHAudS53YXNoaW5ndG9uLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMH9G8m68L0Hf9bmf4/7c+ERxgDQrbq50NfSi2YTQWc1veUIPYbZy1agSNuc4dwn3RtC 0uOQbdNTYUAiVTcYgaYceJVB7syWf9QyGIrglZPMu98c5hWb7vqwvs6d3s2Sm7tBib2v6xQDDiZ4 KJxpdAvsoPQlmGdgpFfmAsiYrnYFXLTHgbgCc/YhV8lubTakUdI3bMYWfh9dkj+DVGUmt2gLtQUz buH8EU44vnXgrQYSXNQkmRcyoE3rj4Rhhbu/p5D3P+nuOukLYFOLRaNeiiGyTu3P7gtc/dy/UjUr f+pH75UUU7Lb369dGEfZwvVtITXsdyp0pBfun4CP808H9N0CAwEAAaOBwTCBvjAdBgNVHQ4EFgQU P5smx3ZYKODMkDglkTbduvLcGYAwgY4GA1UdIwSBhjCBg4AUP5smx3ZYKODMkDglkTbduvLcGYCh YKReMFwxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEhMB8GA1UEChMYVW5pdmVyc2l0eSBvZiBX YXNoaW5ndG9uMR0wGwYDVQQDExRpZHAudS53YXNoaW5ndG9uLmVkdYIJAMoYJbDt9lKKMAwGA1Ud EwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAEo7c2CNHEI+Fvz5DhwumU+WHXqwSOK47MxXwNJV pFQ9GPR2ZGDAq6hzLJLAVWcY4kB3ECDkRtysAWSFHm1roOU7xsU9f0C17QokoXfLNC0d7KoivPM6 ctl8aRftU5moyFJkkJX3qSExXrl053uxTOQVPms4ypkYv1A/FBZWgSC8eNoYnBnv1Mhy4m8bfeEN 7qT9rFoxh4cVjMH1Ykq7JWyFXLEB4ifzH4KHyplt5Ryv61eh6J1YPFa2RurVTyGpHJZeOLUIBvJu 15GzcexuDDXe0kg7sHD6PbK0xzEF/QeXP/hXzMxR9kQXB/IR/b2k4ien+EM3eY/ueBcTZ95dgVM=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>-<saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></saml2p:Status>-<saml2:Assertion Version="2.0" IssueInstant="2011-09-16T19:29:43.338Z" ID="_dc53eba020254f139bcc06c378bb9934" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"><saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">urn:mace:incommon:washington.edu</saml2:Issuer>-<saml2:Subject><saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_3e977ad0b4a062b04c43cf246fd15439</saml2:NameID>-<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData InResponseTo="id-87041017-8767-4408-a3f0-bca5530b98b2" Recipient="https://xyz/adfs/ls/" NotOnOrAfter="2011-09-16T19:34:43.338Z" Address="128.95.254.6"/></saml2:SubjectConfirmation></saml2:Subject>-<saml2:Conditions NotOnOrAfter="2011-09-16T19:34:43.338Z" NotBefore="2011-09-16T19:29:43.338Z">-<saml2:AudienceRestriction><saml2:Audience>httpxyz/adfs/services/trust</saml2:Audience></saml2:AudienceRestriction></saml2:Conditions>-<saml2:AuthnStatement SessionIndex="1533a99c3ae2fb17784d40c20056a830024d3b8e4277d7f94a4ca5fa849760d2" AuthnInstant="2011-09-16T19:29:43.324Z"><saml2:SubjectLocality Address="128.95.254.6"/>-<saml2:AuthnContext><saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef></saml2:AuthnContext></saml2:AuthnStatement>-<saml2:AttributeStatement>-<saml2:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:0.9.2342.19200300.100.1.3" FriendlyName="mail"><saml2:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema">[e-mail]</saml2:AttributeValue></saml2:Attribute></saml2:AttributeStatement></saml2:Assertion></saml2p:Response>

---

http://blogs.msdn.com/rahul/

Answer 9

Yes we have fixed this one in the past, through private communication by email.

The problem had to do with the different names that were used for the ADFS server or Sharepoint Server. Some (incorrect mix of)  Fully Qualified Domain Name and some single label NetBIOS names, which led to missing cookies. Putting that straight was their solution.

If this doesn't help then please send me a Fiddler2 trace directly by email. Then I'll take a look at it. So please don't edit the SAML response or anything else in the Fiddler trace because that hides exactly the problem........... :-)

---

Paul Lemmers

Answer 10

Hi Paul,

could you please let me know how you resolved that with the cookies?

I have the exact same problem. We run MS Dynamics CRM 2011 with ADFS2.0 and PingFederate Authentication.
Since now the app is behind some reverse proxies the client browser doesn't see the actual server anymore but only the name in the demilitarized zone (DMZ).

But this leads to the error message on the ADFS2.0-Server:

Encountered error during federation passive request. The SAML response has content that is not supported.

In IE this shows:
Error There was a problem accessing the site. Try to browse to the site again. If the problem persists, contact the administrator of this site and provide the reference number to identify the problem. Reference number:  75133f4e-1da24b7b-ad7e-c392faa4f2cd

What are these strange reference numbers all about? They seem to come from the adfs2.0 server.

Thank you for any hints

Andreas

---

Andreas

Answer 11

I cannot solve these problems without a Fiddler2 trace. In cases like this we exchange that trace directly (not through the forum) through email.

---

Paul Lemmers

Answer 12

Hi Paul,

I Understand.

But could you give a hint how to remedy the missing cookies because of mixed URLs (some netbios and some FQDN)?

Perhaps that alone could really help me.

Thank you.

Andreas

---

Andreas

Answer 13

Hi All,

We’re trying to get an Shibboleth as Idp to work with an ADFS 2.0 as sp with an http post binding. We’re closely following a microsoft guide on this topic (AD FS 2.0 Step-by-Step Guide:

Federation with Shibboleth 2 and the InCommon Federation), just subsituting our own hosts and test user names.

We are getting SAMLResponse and RelayState but event viewer show error message : MSIS7029: The SAML response has content that is not supported.

SAMLResponse :

<?xml version="1.0" encoding="UTF-8"?><saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://**********.com/adfs/ls/" ID="_ac8b58376964c4fc77d3e22b9e184c95" InResponseTo="9603efef-6783-407d-be74-c269ed12bd89" IssueInstant="2012-03-13T08:41:18.454Z" Version="2.0"><saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp-*******.net/idp/shibboleth</saml2:Issuer><ds:Signaturexmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds:Reference URI="#_ac8b58376964c4fc77d3e22b9e184c95">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml2 saml2p xs xsi"/></ds:Transform>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>GrENAW10yPXe4Ducl3GFWvJlnZ0=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>

***********************

</ds:SignatureValue>

<ds:KeyInfo><ds:X509Data><ds:X509Certificate>

****************************

</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></saml2p:Status><saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_505da718bfd8a1ed4c1640e180919bc6" IssueInstant="2012-03-13T08:41:18.454Z" Version="2.0"><saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp-*************.net/idp/shibboleth</saml2:Issuer><ds:Signaturexmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds:Reference URI="#_505da718bfd8a1ed4c1640e180919bc6">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml2 xs"/></ds:Transform>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>D3LqyG1JkbFoCaOn4hY61nWsL34=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>

SFGWC85rkNpuD5TCu9OCWomK8G2SdUASfOhxep3Hu9unDAJNXC4yquzBNuoZCaL6MPtxh3Vujjha

pbkiJ3p2DrUvsxlX2/p8WTjA04febErHEMKgx3h99x4vyFiklCI09v2543910VXhA+iSMZbfhpyL

mGAmlTYezUr6JRPIQiA1k1DywXi+IAvK1ZhE+Rj0IYwcbtsFbHIEJGmEW9JE7FDY+H57BycV4n9/

wtKMn6sZLluKyuRZrCKosUgbprvT1RruPltY2o9Vzc9QvtZIIFHc4aRYmn9HDlKJQcuN0vjbCH9o

/h79hgGoG6SdUivxlV21bKfvvltAWhy3sdQvIA==

</ds:SignatureValue>

<ds:KeyInfo><ds:X509Data><ds:X509Certificate>

************************************

</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:Subject><saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData Address="172.16.14.9" InResponseTo="9603efef-6783-407d-be74-c269ed12bd89" NotOnOrAfter="2012-03-13T08:46:18.454Z" Recipient="https://*************.com/adfs/ls/"/></saml2:SubjectConfirmation></saml2:Subject><saml2:Conditions NotBefore="2012-03-13T08:41:18.454Z" NotOnOrAfter="2012-03-13T08:46:18.454Z"><saml2:AudienceRestriction><saml2:Audience>http://**************.com/adfs/services/trust</saml2:Audience></saml2:AudienceRestriction></saml2:Conditions><saml2:AuthnStatementAuthnInstant="2012-03-13T08:41:18.424Z" SessionIndex="a8327372b88b95f578c92592507217ca93de6fd7762c43664403a28865b821a1"><saml2:SubjectLocality Address="172.16.14.9"/><saml2:AuthnContext><saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef></saml2:AuthnContext></saml2:AuthnStatement><saml2:AttributeStatement><saml2:Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">https://idp-************.net/idp/shibboleth</saml2:AttributeValue></saml2:Attribute><saml2:AttributeFriendlyName="RapUserID" Name="RapUserID" NameFormat="string"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">test </saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="http://schemas.xmlsoap.org/claims/CommonName" NameFormat="string"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">test</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">C</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Security</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="MLS" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">hh</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="http://schemas.xmlsoap.org/claims/EmailAddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">*****.com</saml2:AttributeValue></saml2:Attribute></saml2:AttributeStatement></saml2:Assertion></saml2p:Response>

Please any one can help me to resolve this issue.

Thanks in Advance.