WIF Programming Model
Claims-based
identity simplifies authentication, authorization and customization of
applications and services. WIF provides a claims-based programming model
that includes the following:
integration with the .NET identity API
unified API for ASP.NET and WCF
unified programming model for
on-premises and cloud
configuration-driven (allowing changes to be made at
runtime without development effort or recompilation)
UI tooling for automatic application configuration
(including WS-Trust and WS-Federation)
classes that allow for custom STS development
(not recommended when already using ADFS)
Visual Studio 2010 integration (including
tools for establishing and maintaining trust, templates for claims-aware
Web sites and services, and ASP.NET controls)
WCF Integration
WIF introduces several new
built-in bindings that are designed to leverage ADFS 2.0. The following
bindings simplify the process for obtaining and using tokens when ADFS
is the identity provider:
Programming Windows
Cardspace
To further enhance
security, Windows Cardspace does not include an API to enumerate, edit, delete, or
create InfoCards. It also does not support the importing or exporting of
InfoCards. The primary programming model for Windows Cardspace is WCF,
which requires that services be constructed using System.ServiceModel. The service is then enabled to use Windows Cardspace by
changing security settings in the application configuration file. This
also makes it simple to switch between security bindings, such as X509
certificates, UserName, Kerberos, and InfoCard.
WCF supports all the WS-*
standards used by Windows Cardspace, including WS-MetadataExchange,
WS-Security, WS-SecurityPolicy, WS-Trust, as well as the Identity
Metasystem itself.
WCF supports
developing an identity provider and relying party by conforming to
requirements listed in the following sections. WCF includes a special
binding to indicate that a service uses Cardspace for authentication. If
the service consumer specifies this binding, Windows Cardspace will be
automatically invoked when a security token is required, and the card
selection screen will appear allowing the user to select a digital
identity. Behind the scenes, Windows Cardspace will contact the identity
provider, acquire a security token, and send the acquired security
token to the relying party.
Developing a Relying
Party
Provided in this section is a
three-step process for building a relying party service with WCF:
1. | Set Up a Certificate
The public key from the certificate made available is used to encrypt
the security token. The certificate is also used by the Windows
Cardspace container on the subject’s machine.
|
2. | Ensure that the Relying Party
Accepts Security Tokens from Identity Providers
Specify the security token the relying party accepts using
WS-SecurityPolicy—in WCF this is done by modifying the configuration
file. The following example shows the various attributes used to enable
Windows Cardspace to use wsFederationBinding:
Example
1.
<wsFederationBinding>
<binding configurationName="FedBinding">
<security mode="Message">
<message issuedTokenType=
"urn:oasis:names:tc:SAML:1.0:assertion">
<requiredClaimTypes>
<add claimType=
"http://schemas.example.org/.../EmailAddress"/>
<add claimType=
"http://schemas.example.org/.../FirstName"/>
</requiredClaimTypes>
<tokenRequestParameters>
<xmlElement>
...
</xmlElement>
</tokenRequestParameters>
<issuer address=
"http://schemas.example.org/.../issuer#self"/>
</message>
</security>
</binding>
</wsFederationBinding>
|
The example shows that the
security token type is defined as SAML. The requiredClaimTypes
attribute is used to specify the claim types or statements required by
the relying party. In such a case we specify that the security token
must include EmailAddress and ZipCode. The issuer
attribute is used to establish valid issuers of the security token. If
the attribute is omitted, it indicates that all identity providers are
valid. In this example, only self-issued cards are permitted.
|
3. | Implement Authorization Logic
When a security token arrives, the relying party should have the ability
to process the claims and make authorization decisions.
|
Developing an Identity
Provider
With WCF you can also
build an identity provider. Provided here are two primary steps:
1. | Create InfoCards
The identity provider must be able to create InfoCards in the .crd file
format and the card must be signed and delivered to the user. The .crd
file includes the issuer name, policy, image, security tokens supported,
and the STS server location.
|
2. | Implement STS Specification
The identity provider must implement the STS, as defined by the WS-Trust
standard. The core functions a reliable STS must be capable of
performing include:
accepting a request for a security token from the
card issued by the user or subject authenticating
the request creating security tokens sending security tokens to users
|
Windows Cardspace
includes a local implementation of STS. If the relying party specified
the identity provider as self, then Windows Cardspace will use the local
implementation of STS.
