Solution working with WIF and not with ACS

Question

Hi,

 We are trying to integrate Siteminder with ACS using Ws-federation. We ran an initial test by integrating directly with applications deployed on Azure using WIF. The solution works fine. With the exact same token format, and the same metadata when I try to integrate with ACS, I just get ACS errors 200001, 500008: Saml token is invalid, with no further inner message.

There is one difference in the integration. When I integrated with with WIF, I disabled certificate chain validation. I do not have ability to specify that in ACS. But even when I tried using self signed certs for the ACS integration I got the same error, and so I believe this is not a certificate issue.

Without a log on ACS, I am at a loss.

The metadata looks like this....

<?xml version="1.0" encoding="utf-8" ?>
<EntityDescriptor ID="Amex_SSO" entityID="provider url" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

<RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
  <X509Certificate>
  MIIERzCCAy+gAwIBAgILAQAAAAABIX6aGX4wDQYJKoZIhvcNAQEFBQAwUDEX
  MBUGA1UEChMOQ3liZXJ0cnVzdCBJbmMxNTAzBgNVBAMTLEN5YmVydHJ1c3Qg
  U3VyZVNlcnZlciBTdGFuZGFyZCBWYWxpZGF0aW9uIENBMB4XDTA5MDUyNjE5
  MzAyM1oXDTEyMDUyNjE5MzAyM1owgfExFzAVBgNVBAMTDlNBUyBGZWRlcmF0
  aW9uMRwwGgYDVQQEExNJZGVudGl0eSBGZWRlcmF0aW9uMSAwHgYDVQQqExdT
  QVMgRmVkZXJhdGlvbiBQcm92aWRlcjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT
  AkFaMRAwDgYDVQQHEwdQaG9lbml4MRkwFwYDVQQKExBBbWVyaWNhbiBFeHBy
  ZXNzMSAwHgYDVQQLExdJbnRlci9JbnRyYW5ldCBTZWN1cml0eTEtMCsGCSqG
  SIb3DQEJARYedGVjaG5pY2FsLnNzby5zdXBwb3J0QGFleHAuY29tMIGfMA0G
  CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDig+SHwHzMj5bXwX/Zm3KXs0v0dnIr
  Jhtr2PJSpYh2/gvvDIVRh4wInE2RaTM5bDNc4wg1WxuCa4BKpqtfGvzZpPpL
  l3GXRA+8QjxWqBbsHXpE/zD6rC5BJbY5rkkgS7+KL+Lw8M4gJFzVBlHemusB
  KW+zO5Fs+viZnuFsDQIJowIDAQABo4IBAjCB/zAfBgNVHSMEGDAWgBTNOpaf
  rm4PQFwcSPhLLbhxAeuJ2jA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3Js
  Lm9tbmlyb290LmNvbS9TdXJlU2VydmVyRzIuY3JsMB0GA1UdDgQWBBSsICr0
  lE734pSba+oEiK9xYYgvujAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF
  oDATBgNVHSUEDDAKBggrBgEFBQcDAjBPBgNVHSAESDBGMEQGCSsGAQQBsT4B
  MjA3MDUGCCsGAQUFBwIBFilodHRwOi8vY3liZXJ0cnVzdC5vbW5pcm9vdC5j
  b20vcmVwb3NpdG9yeTANBgkqhkiG9w0BAQUFAAOCAQEAbHHbrP1SM8TVosWi
  cOuihB1BzJexdfbFGJPoSWhpz3nRcVm+G/q3tUOuTZfRVDTUVlu2MT0PU8YD
  k4KSI29GMQwXuEhDp5KKA5f2sgBrYJHS1bx0n42SVRpN6bbascFkpe4I8bGk
  atRk6j+GBleFozFCNiZeex64meBNX68Rvy+JtCTQVVxcZHj/I+aGw+ZknAeI
  0UL7J96xuE0IY6dcIK+36bWdE17Vsnxgwi39VijAbRBb41ZnKvs5lSf94qWE
  E2ikIOKD4ZHTSFWpcnbYaoiDDSFZJZpTD0RsijQu4pcnVYsoQGDNIEO/6EFh
FSQHRTW0sOo2ZbxeBpommEEDpg==
  </X509Certificate>
  <X509Certificate>
  MIIEMDCCA5mgAwIBAgIEBycURjANBgkqhkiG9w0BAQUFADB1MQswCQYDVQQGEwJV
  UzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMScwJQYDVQQLEx5HVEUgQ3liZXJU
  cnVzdCBTb2x1dGlvbnMsIEluYy4xIzAhBgNVBAMTGkdURSBDeWJlclRydXN0IEds
  b2JhbCBSb290MB4XDTA3MDQwNDE0MTgzN1oXDTE3MDQwNDE0MTgxMVowUDEXMBUG
  A1UEChMOQ3liZXJ0cnVzdCBJbmMxNTAzBgNVBAMTLEN5YmVydHJ1c3QgU3VyZVNl
  cnZlciBTdGFuZGFyZCBWYWxpZGF0aW9uIENBMIIBIjANBgkqhkiG9w0BAQEFAAOC
  AQ8AMIIBCgKCAQEAg0vZDrAbIL8dHlVdZTG1Lq6eqxCan9rkQ9jYsqapQAaJQ7MP
  SBMUkJpJdAR/N1rj7VbrSVZiYttuRffxAHlap6CuHMUr8H2PFL1KxsRaQlI/L7UU
  fTsTzZ3y0UuBca+rHM1AQZ9GyqUaFgL8SgmDJvlkBJHf84PgoLsOW6jVYH6WxUp8
  GlgQgT1q7jCIMUdwjrTJZTS13yLBFeBepklbxHOmpMnZT1kGABul55IusPyOacTK
  UALsFZGs6nAFBUSV9Po2KUczvMKF86L/b626F4gE/aEE2dvvgXDEd/958Ppwpg1O
  i6dXzWxJK0nMVS2b0O8MKhkLq7Cx1xrVZC8E1QIDAQABo4IBbDCCAWgwDwYDVR0T
  AQH/BAUwAwEB/zBTBgNVHSAETDBKMEgGCSsGAQQBsT4BMjA7MDkGCCsGAQUFBwIB
  Fi1odHRwOi8vY3liZXJ0cnVzdC5vbW5pcm9vdC5jb20vcmVwb3NpdG9yeS5jZm0w
  DgYDVR0PAQH/BAQDAgEGMIGJBgNVHSMEgYEwf6F5pHcwdTELMAkGA1UEBhMCVVMx
  GDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEnMCUGA1UECxMeR1RFIEN5YmVyVHJ1
  c3QgU29sdXRpb25zLCBJbmMuMSMwIQYDVQQDExpHVEUgQ3liZXJUcnVzdCBHbG9i
  YWwgUm9vdIICAaUwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3d3dy5wdWJsaWMt
  dHJ1c3QuY29tL2NnaS1iaW4vQ1JMLzIwMTgvY2RwLmNybDAdBgNVHQ4EFgQUzTqW
  n65uD0BcHEj4Sy24cQHridowDQYJKoZIhvcNAQEFBQADgYEAdxIyplp2LV+ulyp1
  W5iLQJ3YnSeHuBkF63DPSQNlA5pnGffb81Lim8BkccTyhqDgA60pTCSPOJvjgIQL
  35kCrnN5UpR+gww5h2dEkBQGZGBpTLcgKZDGM4+tNq/08R9lvOir+K7GI9YtxF+X
  ek5rOYuiM1zvKzH6iiW53IKvlMs=
  </X509Certificate>
  <X509Certificate>
  MIICWjCCAcMCAgGlMA0GCSqGSIb3DQEBBAUAMHUxCzAJBgNVBAYTAlVTMRgwFgYD
  VQQKEw9HVEUgQ29ycG9yYXRpb24xJzAlBgNVBAsTHkdURSBDeWJlclRydXN0IFNv
  bHV0aW9ucywgSW5jLjEjMCEGA1UEAxMaR1RFIEN5YmVyVHJ1c3QgR2xvYmFsIFJv
  b3QwHhcNOTgwODEzMDAyOTAwWhcNMTgwODEzMjM1OTAwWjB1MQswCQYDVQQGEwJV
  UzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMScwJQYDVQQLEx5HVEUgQ3liZXJU
  cnVzdCBTb2x1dGlvbnMsIEluYy4xIzAhBgNVBAMTGkdURSBDeWJlclRydXN0IEds
  b2JhbCBSb290MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCVD6C28FCc6HrH
  iM3dFw4usJTQGz0O9pTAipTHBsiQl8i4ZBp6fmw8U+E3KHNgf7KXUwefU/ltWJTS
  r41tiGeA5u2ylc9yMcqlHHK6XALnZELn+aks1joNrI1CqiQBOeacPwGFVw1Yh0X4
  04Wqk2kmhXBIgD8SFcd5tB8FLztimQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAG3r
  GwnpXtlR22ciYaQqPEh346B8pt5zohQDhT37qw4wxYMWM4ETCJ57NE7fQMh017l9
  3PR2VX2bY1QY6fDq81yx2YtCHrnAlU66+tXifPVoYb+O7AWXX1uw16OFNMQkpw0P
  lZPvy5TYnh+dXIVtx6quTx8itc2VrbqnzPmrC3p/
</X509Certificate>
  </X509Data>
  </KeyInfo>
  </KeyDescriptor>
 <fed:ClaimTypesOffered>
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706">
  <auth:DisplayName>Name Identifier</auth:DisplayName>
  <auth:Description>A unique identifier for the user</auth:Description>
  </auth:ClaimType>
<auth:ClaimType Uri="http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706">
  <auth:DisplayName>Identity Provider</auth:DisplayName>
  <auth:Description>The original identity provider used to authenticate the user</auth:Description>
  </auth:ClaimType>
  </fed:ClaimTypesOffered>
 
 
 <fed:PassiveRequestorEndpoint>
 <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
  <Address>provider url</Address>
  </EndpointReference>
  </fed:PassiveRequestorEndpoint>
  </RoleDescriptor>
 
  </EntityDescriptor>

Thanks and Regards,

Kanduri

Answer 1

Make sure you're using the correct SAML version. If Siteminder uses SAML 1.1, you need to configure ACS to support SAML 1.1 on the portal. The same for SAML 2.0 case.

Answer 2

Can you post the full error details, including TraceID, Timestamp, and all error codes and messages?

Answer 3

Thanks for the response Oren. This is resolved.

Thanks andRegards,

Kanduri

---

Thanks and Regards, Kanduri

Answer 4

Do you mind posting what the issue was, for the benefit of others on the forum?

Answer 5

I dont know what the issue was, but I can make some guesses from the evidence presented publicly.

The metadata of the IDP imported into ACS v2 have one entityID, while the assertions have an issuer that is not the same as the entityID. The characteristic constellation of symptom is: ACS errors 200001, 500008, and be concerned that what works with an RP built by the Visual Studio ClaimsAware wizard does not then work with a (well-configured) ACS FP.

ACS seems to do what Id expect of a well engineered solution - and insist that the assertion's issuer matches the metadata, identified by entityID. The imported metadata is acting essentially as the cert store in effect - expressing whether the cert is authoritative for that issuer name.

One might feel stupid at having induced this to occur. But...dont feel so. Probably, one setup Siteminder to emulate how the IP-STS built by Visual Studio's STS wizard also works (when talking succesfully to a ClaimsAware website built using the Visual Studio template). Then, as I did earlier today, one might that those auto-generated code sets are "sound" - and are models for then interworking with ACS as a WIF FP. This is not correct: they work (but dont intework out of the box with ACS). We must remember WIF is a technology, and several concepts for IDP/FP/SPs exist - with different interworking properties.

There are good reasons why the ClaimsAware templates in the WIF SDK do what they do (and should stay that way). I do recommend Microsoft product another Visual Studio template for the WIF SDK, one which specifically produces an IP-STS and associated metadata with the STS wizard that then works without issue, with ACS v2.

1. setup the code generator to have Scope.Audience property suitably for the ACS endpoints

2. similarly have it set the Issuer web.config app property to the same value used in populating the EntityID in the metadata

3. Dont sign the metadata.