title: Azure Access Control Service (ACS) - ACS50001: Relying party with identifier 'https://[namespace].accesscontrol.windows.net/' was not found
body: <p>I have an ACS namespace with a WS-Federation identity provider set up. Since I'm using Visual Studio 2012, I used the Identity and Access Tool to create the relying party. The tool uses the realm and return url values that I give it when it creates the relying party (I use the Azure cloud service url where I'm deploying my project - i.e. <a href="http://myapp.cloudapp.net" rel="nofollow">http://myapp.cloudapp.net</a>). There is only one rule in the rule group for my relying party after I run the tool - Pass through all claims for [Relying Party]. I tested the ACS for my app with just that one rule, and also after generating all the rules for the WS-Federation identity provider. </p>
  
  <p>Regardless of the rules in the rule group, I get the error in the title of my question. My browser is redirected to ACS, however for some reason it can't find the correct relying party. I have created an ACS namespace, identity provider, and relying party in two different Azure accounts, with exactly the same result. </p>
  
  <p>I've also tried publishing my project to the Azure cloud service with both http and https endpoints, and both endpoints yield the same result. </p>
  
  <p>The WS-Federation identity provider's federation metadata is coming from Windows Azure Active Directory.</p>
  
  <p>UPDATE
  FederationConfiguration section from web.config: </p>
  
  <pre><code>&lt;federationConfiguration&gt;
        &lt;cookieHandler requireSsl="false" /&gt;
        &lt;wsFederation passiveRedirectEnabled="true" issuer="https://[MyNamespace].accesscontrol.windows.net/v2/wsfederation" realm="http://[MyApp].cloudapp.net/" requireHttps="false" /&gt;
  &lt;/federationConfiguration&gt;
  </code></pre>
  
  <p>UPDATE 2: 
  Still no solution. It looks like the issue stems from the fact that I set up my own ACS identity provider, and downloaded the federation metadata from Windows Azure Active Directory (WAAD) for that identity provider. That essentially chains 2 ACS instances together. When my app redirects to my ACS, it passes my app's url as the realm. Then, my ACS redirects to the identity provider, WAAD, and passes its own url as the realm. That's why the error I get back has the strange characteristic of a relying party identifier = the url of my own ACS admin portal. I'm not sure why it's not passing the realm all the way through from my app to WAAD.</p>