6

We have an ADFS 2.0 installation that's working well for our MVC apps in our various environments. I believe it uses "passive authentication" (I'm still getting used to the proper terminology) - it definitely is where it redirects the user to our adfs proxy if the user is not logged in and adfs redirects the user back to our MVC app once they are logged in.

We are now beginning to expose some secured web services and want to tap into this same authentication system. My understanding is that I want to use ws2007FederationHttpBinding as my binding to do this. I believe I have my WCF's web.config all setup for this but my struggle is now centered around the FederationMetadata.xml file.

Looking at this file, I see some things that obviously need to change, such as entityID="http://localhost/UserServices" and the certificate. Then there are some things that I have no clue what they are and if they need to change or not, such as EntityDescriptor ID="_2b510fe8-98b8...... and <ds:SignatureValue>CZe5mEu19/bDNoZrY8f6C559CJ........

Where can I get a better understanding on how I should be managing this file for my various environments? I have the following environments hosting these services that we'll be deploying to one way or another:

  1. Individual developer workstations (3x for now, more later)
  2. A shared Dev environment for people writing apps against these services but not necessarily modifying the services
  3. QA
  4. Staging
  5. Production (3 different environments with different certs/domains/etc.)

As such, we have a fairly streamlined process in place managing our web.config files in the different environments using transforms and finding/replacing certain tokens, so I'd like to do the same thing with this xml file. So ultimately, all I'm looking for is some understanding in what changes are necessary when managing this FederationMetadata.xml file for my various environments.

My current FederationMetadata.base.xml file is below and I BELIEVE this is about right (I just need names/roles) and I just need to intelligently replace the various tokens, such as ~RootServiceUrlTokenToReplace~, in here:

<?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor ID="~EntityDescriptorIdTokenToReplace~" entityID="http://~RootServiceUrlTokenToReplace~" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
  <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/2001/04/xmldsig-more#rsa-sha256" />
      <ds:Reference URI="#~ReferenceURITokenToReplace~">
        <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#" />
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
        <ds:DigestValue>~DigestValueTokenToReplace~</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>~SignatureValueTokenToReplace~</ds:SignatureValue>
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <X509Data>
        <X509Certificate>~CertificateTokenToReplace~</X509Certificate>
      </X509Data>
    </KeyInfo>
  </ds:Signature>
  <RoleDescriptor xsi:type="fed:ApplicationServiceType" protocolSupportEnumeration="http://schemas.xmlsoap.org/ws/2005/02/trust http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
    <KeyDescriptor use="encryption">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>~CertificateTokenToReplace~</X509Certificate>
        </X509Data>
      </KeyInfo>
    </KeyDescriptor>
    <fed:ClaimTypesRequested>
      <auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
      <auth:ClaimType Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
    </fed:ClaimTypesRequested>
    <fed:TargetScopes>
      <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
        <Address>http://~RootServiceUrlTokenToReplace~</Address>
      </EndpointReference>
    </fed:TargetScopes>
    <fed:ApplicationServiceEndpoint>
      <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
        <Address>http://~RootServiceUrlTokenToReplace~</Address>
      </EndpointReference>
    </fed:ApplicationServiceEndpoint>
  </RoleDescriptor>
</EntityDescriptor>
Jaxidian
  • 13,081
  • 8
  • 83
  • 125

2 Answers2

1

A WIF-based application's FederationMetadata.xml is not related to the claims-based web services it offers.

(A URL pointing to) FederationMetadata.xml is used by AD FS, to automatically update the information to be used in a Relying Party Trust. AD FS can for example regularly query this URL, and update the Relying Party Trust information accordingly.

The information about a web service (claims-based or otherwise), i.e., its metadata, is published as a WSDL document. In a WCF-based service this is a URL that often looks like this: http://myhost.example.com/appName/serviceName.svc?wsdl. That WSDL document often does not exist as a physical file, but is automatically generated by WCF.

MarnixKlooster ReinstateMonica
  • 9,640
  • 14
  • 54
  • 108
  • Yeah, I know this has nothing to do with the WSDLs. However, this has a lot to do with the environment. The originally-rendered FederationMetadata.xml had "http://localhost/" in it several times which is clearly wrong and needs to change for each different deployment location. I don't know what to change some of these to, such as the EntityDescriptor ID or the SignatureValue. THAT's what I need help understanding. – Jaxidian Oct 08 '11 at 05:00
  • You seem to want to secure WCF web services using WIF and AD FS. My point is simply that you don't need `FederationMetadata.xml` for that: that file is not used in any web service communication. You might as well remove this file from your application, and everything still works. – MarnixKlooster ReinstateMonica Oct 08 '11 at 16:44
  • Doing it this way means I'll have to manually configure everything with ADFS 2.0 instead of having the XML configure it, correct? And it will still work fine as an RP? If so, well, that really only projects the same problem elsewhere. So now, I guess, I need to know how exactly to configure the RP manually within the ADFS management tool. – Jaxidian Oct 10 '11 at 01:36
  • Correct. And you already have an RPT in AD FS 2.0 for your webapp's UI, right? Now, the configuration in AD FS 2.0 does not change if you start using WCF, if the UI part of your application already works. In web.config, just point the WCF binding (service? don't remember off-hand) to the same AD FS 2.0 instance with the same Relying Party Identifier, and then both your web service and your webapp UI will use the same RPT. – MarnixKlooster ReinstateMonica Oct 10 '11 at 04:10
  • But with ASP.NET, it's Passive Federation whereas with WCF, it's Active Federation. Don't I need to configure the RP differently? Or am I misunderstanding something there... – Jaxidian Oct 10 '11 at 13:56
  • Correct, passive vs. active doesn't influence the RPT in AD FS. – MarnixKlooster ReinstateMonica Oct 10 '11 at 14:20
0

I have found a partial answer to my question in this blog post. I'm looking into it more to discover whether or not this answers all of my questions. I just found it. Apparently I do need to change my EntityID (that contains the URL) as I redeploy this to different environments but the SignatureValue contains a hash of that URL (among other things?) so by modifying the URL, I invalidate the SignatureValue and it needs to be regenereated. Apparently this FederationMetadata Generator can help me with this.

Jaxidian
  • 13,081
  • 8
  • 83
  • 125