Backing a Managed Card with Alternate Credentials

When a Managed Card is used, the user must authenticate to the identity provider (IP), in order to get a token. The choices of authentication type are username/password, Kerberos, X509 certificate or a Self-Issued card. Each authentication type offers its own advantages and disadvantages.

· Usernames and passwords are easy to deploy, and users are familiar with them, but because they employ shared secrets they are also subject to social engineering attacks.

· Kerberos is great if your users are at work and using a card to access a federation partner’s site or web service, or accessing internal services that run on other platforms and usually can’t leverage their Windows identity. Since the user doesn’t need to enter extra credential info when they use the card, it requires little user interaction. The downside of Kerberos is that it doesn’t work well for many usage scenarios, such as when the user isn’t at work.

· X509 certificate backed cards can offer strong security, so are a good choice in high value scenarios. However the scenario needs to be of high enough value to justify the distributing and managing soft certificates or smart cards.

· Self-issued backed cards offer a streamlined experience since using them doesn’t require extra user interaction (though the user can choose to PIN protect their self-issued card). Of course, the self-issued card is stored on the machines it is used on, so it is probably not a good idea to use self-issued cards on a less trustworthy machine. (Does your friend really run an up-to-date virus scanner on his/her home machine?)

Those are the choices for picking a single authentication method. But what about cases where it could be useful to have a single card that can support different authentication methods? An example scenario is one where a user has a card on her laptop, which when she is at work and uses Kerberos, and when she is not at work uses X509 (or some other authentication method).

Specifying alternate authentication methods is fairly straightforward – at least as straightforward as a single authentication method. Alternate authentication methods are specified by including multiple <TokenService> elements in the Managed Card (.crd) file, were each token service can use a different authentication method. Details of this can be found the Identity Selector Interoperability Profile (Section 4.1.1.2).

 It is important to note that the Token Services appear in decreasing order of preference. CardSpace uses this order to determine the sequence with which it will attempt to use the token services. CardSpace will first try to retrieve the policy using the metadata location URL from the first token service endpoint in the .crd file. If policy cannot be retrieved from the metadata location, or if the policy does not contain an entry for the specified token service, CardSpace will fail over to the next token service defined in the .crd file.

<ic:TokenServiceList>

  <ic:TokenService>

    <EndpointReference >

      <Address>https://contoso.com/kerb/sts</Address>

      <Metadata>

        <Metadata>

          <wsx:MetadataSection>

            <wsx:MetadataReference>

              <Address>https://contoso.com/kerb/sts/Mex</Address>

            </wsx:MetadataReference>

          </wsx:MetadataSection>

        </Metadata>

      </Metadata>

    </EndpointReference>

    <ic:UserCredential>

      <ic:KerberosV5Credential/>

    </ic:UserCredential>

  </ic:TokenService>

  <ic:TokenService>

    <EndpointReference xmlns="https://www.w3.org/2005/08/addressing">

      <Address>https://fabrikam.com/X509/sts</Address>

      <Metadata>

        <Metadata>

          <wsx:MetadataSection Dialect="https://schemas.xmlsoap.org/ws/2004/09/mex" xmlns="">

            <wsx:MetadataReference>

              <Address>https://fabrikam.com/STS/mex</Address>

            </wsx:MetadataReference>

          </wsx:MetadataSection>

        </Metadata>

      </Metadata>

    </EndpointReference>

    <ic:UserCredential>

      <ic:X509V3Credential>

        <ds:X509Data>

          <wsse:KeyIdentifier

            ValueType="https://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.1#ThumbprintSHA1"

            EncodingType="https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"

            xmlns:wsse="https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

              OdiGsVrqbay3mn6BAjiHontnV1U=

            </wsse:KeyIdentifier>

        </ds:X509Data>

        </ic:X509V3Credential>

        </ic:UserCredential>

  </ic:TokenService>

(Figure 1)

 

CardSpace follows this same algorithm for each endpoint: first connect to the metadata endpoint, then retrieve policy for the specific token service endpoint.

For an example, suppose the metadata endpoint for the first service shown in Figure 1 is unavailable, and the metadata endpoint for the second token service does not contain policy for the STS endpoint. In that case, CardSpace will first try to retrieve the policy from the metadata location https://contoso.com/kerb/sts/Mex. Since that URL is unavailable, CardSpace will fail over to the next TokenService element, and retrieve the policy from https://fabrikam.com/STS/mex. However, since in this example, policy is returned, but does not contain information for the token service endpoint https://fabrikam.com/X509/sts, CardSpace will move to the next TokenService. This process continues until the policy is successfully retrieved for a token service, or there are no more token services to try. If the policy is retrieved for a token service, but the token service is not available, no fail-over occurs, at which point CardSpace will show an error to the user.

Now back to the example using Kerberos at work and X509 from home. This can be accomplished with CardSpace by specifying two token services in the .crd file. The first of the endpoints uses Kerberos authentication. The metadata endpoint for the Kerberos token service can be made available only from a machine using the corporate network. Fail over to the x509 endpoint will then occur when the user is not at work.

Let me know if there are questions or comments on how this works. Hopefully this is useful for some more advanced Managed Card scenarios. To learn more I recommend reading the Identity Selector Interoperability Profile, as well as chapter 3 of ‘Understanding Windows CardSpace’ . In the spirit of full disclosure, I’m co-author on the book so have been hesitant to self promote, but I’m mentioning it here as I really think it is relevant, and sincerely hope others find it useful.

Thanks,

Caleb

Comments

• Anonymous
  May 19, 2008
  Oh great, another piece of work for sharpsts :pSensible question, define unavailable. One presumes that's any error in attempting to reach the endpoint, be it (in a kerberos case) an access denied, or a time out, or what? How long will the selector wait before giving up in things like time out cases?
• Anonymous
  September 18, 2008
  Great post, really helped me understand.
• Anonymous
  October 20, 2008
  A really well explained article and has given me a nice idea for a project!
• Anonymous
  October 27, 2008
  Great to know that I can use more than one STS to provide failback in case of failures. I'm also interested in supporting more authentication methods with the Geneva server. For example, I want to use "RSA SecurID" authentication method. How can I extend my Geneva server so that Managed cards can be backed with this new auth method?
• Anonymous
  November 03, 2008
  Youcef, it's currently not possible to extend the server this way in the "Geneva" Server Beta, but we are looking at ways to support this type of scenario.  Do you have other authentication methods you would be interested in supporting?  
• Anonymous
  May 28, 2009
  Imagine this: you have been following this blog and have decided to try “Geneva” Beta 2. You have gone