Securing a WCF service w/ wsFederationBinding and STS

May 13, 2008 at 7:16 PM

One of the benefits of federated security is the delegation and normalization of authentication to an external source.

 As a service developer, I only care about the claims available to me.  I do not need to concern myself with how the user was authenicted.  Only the claims and the ability to verify the claims.

 As as STS developer, I must care about how users authenticate themselves.  The STS is responsible for receiving authentication creds, validating them and returning a normalized set of claims about the authenticated caller.

 The STS can support any number of authentication methods, username password, self-issued cards, certficiates, etc. Each authentication method has its own endpoint on the STS ( including mex):

http://sts.sharpsts.com:9000/sts/usernamepassword/sts
https://sts.sharpsts.com:9001/sts/usernamepassword/mex
http://sts.sharpsts.com:9000/sts/usernamepassword
https://sts.sharpsts.com:9001/sts/usernamepassword
http://sts.sharpsts.com:9000/sts/selfissuedsaml/sts
https://sts.sharpsts.com:9001/sts/selfissuedsaml/mex
http://sts.sharpsts.com:9000/sts/selfissuedsaml
https://sts.sharpsts.com:9001/sts/selfissuedsaml 

each endpoint has an authorization poicies and validators to ensure the provided creds are valid.

 Here's my question.

 I want to secure a service using a wsFederationHttpBinding.  When defining the configuration for the service, What should I be setting the as address the address of the issuer?  Each endpoint on the STS Issue operation is tied to a specific crediential type (u/p, certificate, self-issued, etc), but the service should have no knowledge of the cred types supported by the sts.

 if my service configuration looks like this:

      <wsFederationHttpBinding>       
       <binding name="stsbindingconfig">
          <security mode="Message">
            <message>
              <issuer address="http://sts.sharpsts.com:9000/sts/usernamepassword/sts"
                      binding="wsFederationHttpBinding"
                      bindingConfiguration="MyServerSTS" >
                <identity>
                  <certificateReference storeLocation ="CurrentUser"
                                        storeName="TrustedPeople"
                                        x509FindType="FindBySubjectName"
                                        findValue="sts.sharpsts.com" />
                </identity>
              </issuer>
            </message>
          </security>
        </binding>
      </wsFederationHttpBinding>

 

then I've "hard coded" the sts reference to the endpoint that supports only username and password.  What do I do if the caller has a different set of creds?

 After all my services are up and running, if I decide I want to support biometric tokens as cred type on the STS, I need to create a new endpoint on my STS (myserver.com/auth/biometric/sts), but shouldn't need to change the business services at all.

 

 

Coordinator
May 13, 2008 at 8:55 PM
This is the same problem in limiting a web site to a particular type of card. If you look at the object tag parameters we have an issuer parameter which accepts an address. My first thought was the same as yours; it's the endpoint address. A couple of "What on earth?" emails back and forth and all became clear; it's not. It's the issuer address.

In the STS configuration settings there's an issuer parameter which accepts at URI; the web sample has it as http://www.woodgrovebank.com/ and you can use this as the issuing parameter in the object tag. I tried it in a federation sample I have and it's the same; so rather than use the endpoint for the STS use the address you specified as the issuer. Of course you then need to check the signing certificate very very carefully to make sure it's the one you expect, as anyone can set an issuer parameter.
May 13, 2008 at 11:21 PM
I'm confused.

If the issuer uri isn't the endpoint address of the sts endpoint, how is the correct sts endpoint discovered?  If all the STS requests go to the same endpoint, what does the routing to ensure that RST's with u/p creds go to the u/p endpoint, and RST's with self-issued tokens go to the SelfIssuedSamlToken endpoint?

Coordinator
May 14, 2008 at 4:29 AM
Issuer != Endpoint.

Issuer is part of the card metadata, the selector will allow use of the cards which match the specified issuer URI. When a card is selected which matches that issuer the selector then reads the endpoint information from the card and goes off to ask for a token from the endpoint embedded in the card.
May 14, 2008 at 1:13 PM
How does this work when I'm not using infocards?  The issuer uri is specified as part of the binding configuration of the service being secured.  When the client proxy is generated for that service, where will it get the uri for the sts?  and assuming we have multiple endpoints for different auth. mechanisms (u/p, cert, biometric, etc) which endpoint for the Issue operation will it generate?

Am I conceptually misunderstanding something here?



Coordinator
May 14, 2008 at 2:57 PM
Pass. The selector takes care of it in an infocard scenario; and that's all I'm catering to here *grin* You could ask on the WCF forums I guess, it's not an infocard issue as far as I can see.
May 14, 2008 at 5:11 PM
chicken <g>.

I've posted to the WCF forum on MSDN, but I never seem to get responses to my posts, so I thought I'd try here as well.

May Dominick can offer some insight.