My Metadata import is failing without giving me enough info

Question

Hi,

 I generated ws-federation metadata file and I tried to save that in ACS. ACS gave me ACS20009.

Here is what I am trying to do...

1. Setup an IDP which provides WS-Fed tokens, without any web services. So I put in only the IDPSSODescriptor element.

2. Provide a set of attributes in the WS-fed token so that authorization can happen smoothly.

Here is the xml I generated.

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="AmexSSOIDP" entityID="AmexSSOAZUREIDP">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MIIERzCCAy+gAwIBAgILAQAAAAABIX6aGX4wDQYJKoZIhvcNAQEFBQAwUDEXMBUGA1UEChMOQ3li&#13;
ZXJ0cnVzdCBJbmMxNTAzBgNVBAMTLEN5YmVydHJ1c3QgU3VyZVNlcnZlciBTdGFuZGFyZCBWYWxp&#13;
ZGF0aW9uIENBMB4XDTA5MDUyNjE5MzAyM1oXDTEyMDUyNjE5MzAyM1owgfExFzAVBgNVBAMTDlNB&#13;
UyBGZWRlcmF0aW9uMRwwGgYDVQQEExNJZGVudGl0eSBGZWRlcmF0aW9uMSAwHgYDVQQqExdTQVMg&#13;
RmVkZXJhdGlvbiBQcm92aWRlcjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkFaMRAwDgYDVQQHEwdQ&#13;
aG9lbml4MRkwFwYDVQQKExBBbWVyaWNhbiBFeHByZXNzMSAwHgYDVQQLExdJbnRlci9JbnRyYW5l&#13;
dCBTZWN1cml0eTEtMCsGCSqGSIb3DQEJARYedGVjaG5pY2FsLnNzby5zdXBwb3J0QGFleHAuY29t&#13;
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDig+SHwHzMj5bXwX/Zm3KXs0v0dnIrJhtr2PJS&#13;
pYh2/gvvDIVRh4wInE2RaTM5bDNc4wg1WxuCa4BKpqtfGvzZpPpLl3GXRA+8QjxWqBbsHXpE/zD6&#13;
rC5BJbY5rkkgS7+KL+Lw8M4gJFzVBlHemusBKW+zO5Fs+viZnuFsDQIJowIDAQABo4IBAjCB/zAf&#13;
BgNVHSMEGDAWgBTNOpafrm4PQFwcSPhLLbhxAeuJ2jA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8v&#13;
Y3JsLm9tbmlyb290LmNvbS9TdXJlU2VydmVyRzIuY3JsMB0GA1UdDgQWBBSsICr0lE734pSba+oE&#13;
iK9xYYgvujAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcD&#13;
AjBPBgNVHSAESDBGMEQGCSsGAQQBsT4BMjA3MDUGCCsGAQUFBwIBFilodHRwOi8vY3liZXJ0cnVz&#13;
dC5vbW5pcm9vdC5jb20vcmVwb3NpdG9yeTANBgkqhkiG9w0BAQUFAAOCAQEAbHHbrP1SM8TVosWi&#13;
cOuihB1BzJexdfbFGJPoSWhpz3nRcVm+G/q3tUOuTZfRVDTUVlu2MT0PU8YDk4KSI29GMQwXuEhD&#13;
p5KKA5f2sgBrYJHS1bx0n42SVRpN6bbascFkpe4I8bGkatRk6j+GBleFozFCNiZeex64meBNX68R&#13;
vy+JtCTQVVxcZHj/I+aGw+ZknAeI0UL7J96xuE0IY6dcIK+36bWdE17Vsnxgwi39VijAbRBb41Zn&#13;
Kvs5lSf94qWEE2ikIOKD4ZHTSFWpcnbYaoiDDSFZJZpTD0RsijQu4pcnVYsoQGDNIEO/6EFhFSQH&#13;
RTW0sOo2ZbxeBpommEEDpg==</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://ssointrad.dev.ipc.us.aexp.com/ssofedi /public/wsfedsignout"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://ssointrad.dev.ipc.us.aexp.com/ssofedi /public/wsfedsignout"/>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://ssointrad.dev.ipc.us.aexp.com/ssofedi/public/wsfedsso"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ssointrad.dev.ipc.us.aexp.com/ssofedi/public/wsfedsso"/>
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="E-Mail Address" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="Given Name" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="Name" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="UPN" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="Common Name" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/commonname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="Group" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/Group" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="SurName" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="PPID" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion" FriendlyName="Name ID" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
</IDPSSODescriptor>
</EntityDescriptor>

 

I want to know where I went wrong.

Thanks and Regards,

Kanduri

 

Answer 1

If you manually use WIF's MetadataSerializer.ReadMetadata to read the metadata, does it work? ACS only supports metadata that are supported by WIF.

---

Sining Oh Blue Star

Answer 2

This should be a standard FAQ topic.

Its caused by the default config of the STS wizard, when making an IDP SSO project. Its metadata has entity name equal to the registered audience (an http uri...), but the web.config uses a different value whe nconfiguring how the issuer field is treated, by the code controlling assertion content. THus ACS objects... (is my best guess) to assertions that do not tie to the registered entityID of the metadata for said IDP.

If you change the web.config issuer application parameter to have the same values as the entityID of the IDPs metadata, the problem goes away.

I also had to remove the signature from the signed metadata, for ACS to accept it. Ill guess that it may be possible to first upload a cert to ACS, that will verify the signed metadata (and the cert that said stream bears) subsequently assigned to an new IDP entry of ws-fedp type.

if someone has power... have visual studio 2011 template for claimsaware sites change how the STS wizard works, so the generated STS code does NOT not cause all this!

Answer 3

I forgot another default STS site (built by STS wizard) to Azure ACS interworking issue.

One must change how the scope.Audience is assigned in the STS callback GetScope(). Audience must be assigned the value of the request.ReplyTo - so that it the response bearing asserting is sent to the correct assertion consuming service endpoint path (and not to the default path of the namespace, which is what happens currently... inducing failure).