Using Windows CardSpace to Access a WCF Service


Windows CardSpace is a new technology incorporated into Windows Vista and is also available for Windows XP as part of the .NET Framework 3.0. Windows CardSpace is based on a number of WS-* standards, in particular WS-Trust, WS-MetadataExchange, and WS-SecurityPolicy. Consequently, the security mechanism that it implements is interoperable with Web services and client applications built using other technologies but that conform to these specifications.

Implementing Claims-Based Security

The world of claims-based security refers to three roles describing the participants involved in accessing a protected service:

  • The subject is the user or entity trying to access the service. The subject provides evidence of suitable rights (a claim) to gain access. This must be a claim that the service can accept. In the credit card scenario described earlier, it would be no good trying to use my football supporters’ club membership card when trying to pay for goods–the membership card might well be valid, but the vendor will not accept it.

  • The identity provider is the organization or entity that issues the rights to assert a particular claim (or set of claims) to the subject and verifies the authenticity of any claims to exercise these rights made by the subject. In the credit card example, the identity provider is the credit card company issuing the card.

  • The relying party is the organization or entity representing the protected service. The relying party asks the identity provider to verify that the claim made by the subject to the specified rights is valid. Again, in the credit card example, the relying party is the vendor selling me the goods that I am attempting to purchase.

Note 

From here on, I will refer to the information provided by a subject when attempting to prove its identity simply as a “claim.” Identity providers are said to issue claims, services can demand verified claims, and subjects can submit claims when attempting to access a service.

Windows CardSpace comprises a Windows service, a set of components, and a framework for enabling identity providers to issue claims to a user, allowing the user to store and retrieve information about these claims in an accessible manner and providing assurance to a service that any claims asserted by a user are genuine. Windows CardSpace stores information about the set of claims (called a “claimset”) issued by a provider as metadata in an Information Card. Windows CardSpace provides a graphical user interface enabling a user to manage and control her information cards.

A service that uses claims-based security specifies the claims it demands as part of its security policy. Windows CardSpace includes an identity selector component that can query this policy and then determine which of the user’s cards have claims that match the policy. In the real world, you could use several different forms of identity to prove a claim, such as your age–your driver’s license or your passport, for example. Similarly, when a service demands proof of one particular aspect of the user, there might be several information cards containing a corresponding claim from which the user can select. When a WCF client application attempts to access a service, the WCF runtime can invoke the identity selector component to determine and display the matching cards and the user can select which information card to use. The claims on the card then have to be verified by the identity provider before the client application can use them to access the service.

The complete sequence of operations that occur when a client application calls a Web service that uses Windows CardSpace to validate a user is as follows:

  1. The client application attempts to invoke an operation or access a resource in a Web service.

  2. The WCF runtime on the client invokes the identity selector component of Windows CardSpace. The identity selector queries the security policy of the Web service. The Web service returns information indicating the types of claims it can use to authenticate the user (for example, an email address or a pin number).

  3. The identity selector examines the user’s information cards and displays a list of cards that contain claims of the types specified by the Web service.

  4. The user selects the information card to use.

  5. The identity selector contacts the identity provider that issued the information card, passing it the metadata describing the claim on the user’s information card and the claims demanded by the service.

  6. The identity provider examines the metadata describing the claim and generates a token verifying that user’s claim is valid. The identity provider sends this token back to the identity selector running on the client computer.

  7. The identity selector asks the user to approve release of the token to the Web service.

  8. If the user approves release, the identity selector sends the token to the Web service. The Web service examines the token to verify that the user’s claim is valid. If the token is valid, the Web service can use the identity information in this token to determine whether the user is authorized to invoke the operation or access the resource.

All of this sounds quite complicated. Fortunately, WCF and Windows CardSpace shield you from much of this complexity, and it is actually quite straightforward to incorporate claims-based security into a WCF service. In the following set of exercises, you will configure the ShoppingCartService service to identify users by their email address.

Before we delve into the world of Windows CardSpace, I need to explain one more thing. In a real-world environment, you will most likely use information cards issued by commercial, trusted, third-party identity providers (such as credit card companies, banks, governments, or other organizations). Windows CardSpace also enables you to create self-issued cards. A self-issued card is a card that you create yourself by using the Windows CardSpace console, often for testing purposes (they have other uses as well). A self-issued card can contain a small but useful subset of claims, such as your name, home address, telephone number, and email address. In this case, you can think of the identity provider as the Windows CardSpace service running on your own computer. The exercises that follow make use of self-issued information cards, as I don’t want you to have to obtain a commercial information card just for learning purposes. However, the technique is very similar when you use an information card issued by a trusted third party, as I will explain afterwards.

Important 

A production Web service should not rely on claims asserted by self-issued information cards for authorizing access to sensitive data. It is very easy for a user to create a self-issued card with whatever values they want for the claims it contains.

Configure the ShoppingCartService service to use claims-based security

  1. Using Visual Studio 2005, open the solution file image from book ShoppingCartService.sln located in the Microsoft Press\WCF Step By Step\Chapter 15\ShoppingCartService folder under your \My Documents folder.

    This solution contains a completed version of the ShoppingCartService service, console host application, and test client application, from Chapter 9, “Implementing Reliable Sessions.”

  2. Edit the image from book App.config file in the ShoppingCartHost project by using the WCF Configuration Editor.

  3. In the left pane, add a new binding configuration to the Bindings folder. Select the wsFederationHttpBinding binding type. Change the name of the binding configuration to ShoppingCartServiceCardSpaceBindingConfig. The ShoppingCartService service uses reliable sessions and transactions, so set the TransactionFlow property to True and set the Enabled property in the ReliableSession Properties section to True.

    Note 

    You can also use claims-based security with the wsHttpBinding binding, but that binding supports only a limited set of claims. The wsFederationHttpBinding binding enables you to configure the service to specify a more extensive range.

  4. In the left pane, click the ClaimTypes folder under the Security node for the ShoppingCartServiceCardSpaceBindingConfig binding configuration. Click the New button at the bottom of the right pane.

    In the Claim Type Element Editor, set the ClaimType property to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. Verify that the IsOptional property is set to False, and then click OK.

    The claims specified in the ClaimTypes property of the binding configuration constitute the claims security policy for the service. Each type of claim is identified by a well-known URI–the URI you have specified here indicates an email address. You can add multiple claim types if you want to identify users based on more than one piece of information.

    Note 

    Apart from an email address, Windows CardSpace provides support for a number of other built-in claim types, such as a user’s name, address, telephone number, and date of birth. For a full list of the built-in claim types and the corresponding URIs that Windows CardSpace recognizes, see the properties of the ClaimTypes class in the Windows SDK documentation.

    However, you are not restricted to this set of claims. A key objective of the WCF claims-based security model is that it is extensible and interoperable with systems developed by using other technologies. You can make use of claim types supported by identity providers other than Windows CardSpace, you just need to know the URI that identifies the claim types you want to use.

  5. In the left pane, click the Security folder under the ShoppingCartServiceCardSpaceBindingConfig node. In the right pane, set the IssuedTokenType property to the value urn:oasis:names:tc:SAML:1.0:assertion.

    A WCF service uses the IssuedTokenType property to specify the type of token it expects to receive from the identity provider containing the claim information (identity providers can send tokens conforming to a number of different standard formats). In this case, the ShoppingCartService service expects a Secure Application Markup Language (SAML) 1.0 token.

  6. A fundamental requirement of solutions based on Windows CardSpace is that client applications must be able to verify the identity of the Web service requesting the claim and the Web service must be able to trust the identity provider verifying the claim. This means that you should configure the requesting Web service with a certificate and provide the client application with a reference to this certificate. If you are using a third-party identity provider, it must also supply a certificate that the client application and Web service can use to confirm its identity (the identity provider signs tokens with its private key, so the Web service must have access to its public key in order to verify their signatures). Additionally, all messages must be encrypted, either at the message level or at the transport level.

    More Info 

    For more information about how you can use certificates to encrypt and sign messages and verify the authenticity of a service, refer back to Chapter 5, “Protecting a WCF Service over the Internet.”

    To create a certificate for the ShoppingCartService, open a Microsoft Windows SDK CMD Shell prompt, and use the makecert utility to create a new certificate for the service, like this:

     makecert -sr LocalMachine -ss My -n CN=ShoppingCartService -sky exchange

  7. Leave the CMD shell open, and return to the WCF Service Configuration Editor. In the left pane, add a new service behavior to the Service Behaviors folder in the Advanced folder. Name this behavior ShoppingCartServiceBehavior.

  8. In the right pane, click Add, and add a <serviceCredentials> element to the behavior. In the left pane, expand the new serviceCredentials node, and click the serviceCertificate node. In the right pane, set the FindValue property to ShoppingCartService (this is the name of the certificate you have just created) and the X509FindType property to FindBySubjectName.

  9. In this exercise, you are using an unverifiable self-issued information card rather than a card issued by a third-party identity provider. At run time, the SAML token containing the claim token is provided by the Windows CardSpace service running on the client application computer. Therefore, you need to configure the Web service to accept SAML tokens from an untrusted source (the user running the client application and who has issued the card to herself).

    In the left pane, click the issuedTokenAuthentication node under the serviceCredentials node. In the right pane, set the AllowUntrustedRsaIssuers property to True.

  10. In the left pane, select the ShoppingCartService.ShoppingCartServiceImpl service in the Services folder. In the right pane, set the BehaviorConfiguration property to ShoppingCartServiceBehavior.

  11. In the left pane, add a new endpoint to the Endpoints folder under the ShoppingCartService.ShoppingCartServiceImpl service. Set the properties of this endpoint using the values in the following table:

    Open table as spreadsheet

    Property

    Value

    Name

    ShoppingCartServiceHttpFederationEndpoint

    Address

    http://localhost:9050/ShoppingCartService/ShoppingCartService.svc

    Binding

    wsFederationHttpBinding

    BindingConfiguration

    ShoppingCartServiceCardSpaceBindingConfig

    Contract

    ShoppingCartService.IShoppingCartService

  12. Save the configuration file, and close the WCF Service Configuration Editor.

The ShoppingCartService now expects the client application to provide the user’s email address whenever it invokes an operation. You can use the email address to authorize the user and grant or deny them access to specific operations. You can perform this task in a variety of ways. The most direct technique is to explicitly examine the value of the claim in the token passed to the service, which is what you will do in the next exercise.

Amend the ShoppingCartService service to authorize users based on their email address

  1. In Solution Explorer, edit the image from book ShoppingCartService.cs file in the ShoppingCartService project.

  2. Add the following using statements to the list at the top of the file:

     using System.Security; using System.IdentityModel.Claims; using System.IdentityModel.Policy;

  3. Add the following private array to the ShoppingCartServiceImpl class:

     // The list of authorized users private string[] authorizedUsers = { "Fred@Adventure-Works.com",                                      "Bert@Adventure-Works.com" };

    This array contains the email addresses of the users that the service will allow to access the service.

    Note 

    This code is for testing purposes only. In a production environment, you should consider storing the details of authorized users in a database rather than using a hard-coded array of strings.

  4. Add the following private method to the ShoppingCartServiceImpl class to determine whether the claimset in the token passed to the service contains an email claim with an email address that corresponds to one of the authorized users:

     // Authorize the user if their email address is in the authorizedUsers list private bool authorizeUser() {     bool authorized = false;     AuthorizationContext authContext =       OperationContext.Current.ServiceSecurityContext.AuthorizationContext;     foreach (ClaimSet claimSet in authContext.ClaimSets)     {         foreach (Claim emailClaim in             claimSet.FindClaims(ClaimTypes.Email, Rights.PossessProperty))         {             foreach (string validUser in authorizedUsers)             {                 if (String.Compare(emailClaim.Resource.ToString(),                                    validUser, true) == 0)                 {                     authorized = true;                     break;                 }             }         }     }     return authorized; }

    When the WCF runtime for the service receives the tokenized claims from the client application, it matches the values for these claims against the security policy that it implements. The AuthorizationContext property of the service security context contains the results of this match. In this case, AuthorizationContext property should contain an email address claim with the email address provided by the information card sent by the client application.

    Note 

    The AuthorizationContext property will also contain other claims resulting from the various WS-* protocols that Windows CardSpace uses, but the details are beyond the scope of this book.

    The AuthorizationContext property comprises a collection of claimsets, and each claimset contains a collection of claims. This method iterates through each claimset looking for an email claim. If it finds one, it examines the value of the claim and compares it to each email address in the list of authorized users. Notice that the value of a claim is available through the Resource property. The type of this property is Object, and its contents are dependent on the type of the claim. An email claim is a string containing the authenticated email address of the user, so this method simply performs a case-insensitive string comparison. If the email address in the claim matches one of the authorized users, the authorizeUser method returns true, otherwise it returns false.

  5. Locate the AddItemToCart method in the ShoppingCartServiceImpl class. At the start of the method, add a block of code that calls the authorizeUser method and throws a security exception if the user is not an authorized user, like this:

     public bool AddItemToCart(string productNumber) {     // Check that the user is authorized     // Throw a SecurityException if they are not     if (!authorizeUser())     {         throw new SecurityException("Access denied");     }      }

  6. Add the same statements to the start of the RemoveItemFromCart, GetShoppingCart, and Checkout methods.

  7. Build the ShoppingCartService project.

    You can now configure the client application to enable the user to select an information card and send the SAML token containing the user’s email address to the ShoppingCartService service.

    image from book
    Implementing Custom Authorization

    If you need to perform more extensive authorization checks than those shown in the exercise, the .NET Framework 3.0 provides the ServiceAuthorizationManager class in the System.ServiceModel namespace. The WCF runtime on the service calls the methods of this class to perform authorization checks whenever it processes a client request. However, this class is just a placeholder, which by default allows users to invoke all operations without restriction. To implement a more secure policy, extend this class by using inheritance and override its methods to perform your own custom authorization. You then register your implementation of the class with the WCF runtime by setting the Authorization.ServiceAuthorizationManager property of the service host object to an instance of your class, or by creating a service behavior in the service configuration file and specifying the name of your class in the <serviceAuthorization> element.

    For a complete example, see the topic “How To: Create a Custom AuthorizationManager for a Service” in the Microsoft Windows SDK documentation.

    image from book

Configure the ShoppingCartClient application to use Windows CardSpace to send a token identifying the user

  1. Edit the image from book App.config file in the ShoppingCartClient project by using the WCF Configuration Editor.

  2. In the left pane, add a new binding configuration to the Bindings folder. Select the wsFederationHttpBinding binding type. Change the name of the binding configuration to ShoppingCartClientCardSpaceBindingConfig. Set the TransactionFlow property to True, and set the Enabled property in the ReliableSession Properties section to True.

  3. Add the claim type http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress to the ClaimTypes collection under the Security node in the left pane. Verify that the IsOptional property is set to False.

    Note 

    Hardcoding the claim type in this way removes the need for WCF runtime on the client computer to query the security policy of the service. This is acceptable if you know that the types of claims demanded by the service are not going to change very often. However, if the security policy of the service does change and it requires different claims, you must make corresponding updates to this configuration.

  4. Set the IssuedTokenType property of the Security node to urn:oasis:names:tc:SAML:1.0:assertion.

  5. Return to the CMD Shell window and type the following command:

     certmgr -put -c -n ShoppingCartService -r LocalMachine -s My ShoppingCartService.cer

    This command retrieves a copy of the ShoppingCartService certificate used by the WCF service to authenticate itself and creates a file called ShoppingCartService.cer. This file contains a copy of the certificate including its public key but not the private key.

    Type the following command to import this certificate into the trusted people certificate store for the current user:

     certmgr -add ShoppingCartService.cer -c -r CurrentUser -s TrustedPeople

  6. Close the CMD Shell window and return to the WCF Service Configuration Editor. In the left pane, add a new endpoint behavior to the Endpoint Behaviors folder under the Advanced folder. Name this behavior ShoppingCartClientEndpointBehavior.

  7. In the right pane, click Add, and add a <clientCredentials> element to the behavior. In the left pane, expand the clientCredentials node, expand the serviceCertificate node, and then click the authentication node. In the right pane, set the CertificateValidationMode property to PeerTrust and the RevocationMode property to NoCheck.

    Note 

    You are using a test certificate issued by the certmgr tool rather than a recognized certification authority. You placed the certificate in the TrustedPeople store, and setting the validation mode to PeerTrust bypasses validation for certificates placed in this store.

  8. In the left pane, add a new client endpoint to the Endpoints folder under the Client folder. Set the properties of this endpoint using the values in the following table:

    Open table as spreadsheet

    Property

    Value

    Name

    HttpFederationBinding_ShoppingCartService

    Address

    http://localhost:9050/ShoppingCartService/ShoppingCartService.svc

    BehaviorConfiguration

    ShoppingCartClientEnpointBehavior

    Binding

    wsFederationHttpBinding

    BindingConfiguration

    ShoppingCartClientCardSpaceBindingConfig

    Contract

    ShoppingCartClient.ShoppingCartService.ShoppingCartService

  9. In the right pane, click the Identity tab. In the CertificateReference Properties section, set the FindValue property to ShoppingCartService and the X509FindType property to FindBySubjectName.

  10. Save the configuration file, and close the WCF Service Configuration Editor.

  11. In Solution Explorer, edit the image from book Program.cs file in the ShoppingCartClient project. In the Main method in the Program class, change the statement that creates the proxy to use the HttpFederationBinding_ShoppingCartService endpoint, as follows:

     // Connect to the ShoppingCartService service ShoppingCartServiceClient proxy = new     ShoppingCartServiceClient("HttpFederationBinding_ShoppingCartService");

The next stage is to create some information cards that you can use to test the ShoppingCartService service. You can do this using the Windows CardSpace application in the Control Panel.

Create information cards for testing the ShoppingCartService service

  1. In Windows Control Panel, select the User Accounts category, and then start the Windows CardSpace application.

    The Windows CardSpace console starts and displays the Windows CardSpace–Welcome dialog box. Click Don’t show me this page again, and then click OK.

  2. If you have not yet created or installed any cards, the list of information cards will be empty apart from the Add a card icon. Click the Add a card icon, and then click the Add button that appears at the bottom of the console window.

  3. In the Add a card window, click Create a Personal card.

  4. In the Edit a new card window, specify Valid ShoppingCartService Test Card for the Card Name property, Fred@Adventure-Works.com for the Email Address property, and then click Save. The following image shows the details for the information card:

    image from book

    The new information card should appear in the list of cards in the Windows CardSpace console. The email address for this card represents a user that is authorized to access the operations in the ShoppingCartService service.

  5. Add another personal card. In the Edit a new card window, specify Invalid ShoppingCartService Test Card for the Card Name property, Sid@Adventure-Works.com for the Email Address property, and then click Save. The email address for this card represents a user that is not authorized to invoke the operations in the ShoppingCartService service.

  6. Close the Windows CardSpace console.

Test the ShoppingCartService service

  1. In Visual Studio 2005, start the solution without debugging. Wait for the service to start and display the message “Service running.” In the client application console window displaying the message “Press ENTER when the service has started,” press Enter.

    When the client application invokes the first operation in the ShoppingCartService service, the Windows CardSpace service intervenes and displays the Windows CardSpace console.

    Note 

    The Windows CardSpace identity selector runs in a separate desktop session from the user to prevent other applications being able to interfere with it. For this reason, whenever the Windows CardSpace console appears, the user’s desktop is dimmed and inaccessible.

    Notice that Windows CardSpace recognizes that the certificate used by the ShoppingCartService service is not verified and displays the following warning:

    image from book

    Click Yes, choose a card to send.

    Important 

    If Windows CardSpace displays this message when you access a commercial Web service, you should be very careful, as it indicates that the Web service’s certificate might not have originated from a recognized certification authority. In this situation, you should probably click No and not send your credentials to the site.

  2. Windows CardSpace displays a list of cards that contain email addresses and so match the claims required by the service. Select the Valid ShoppingCartService Test Card, and then click Send.

  3. Windows CardSpace displays the details of the card that it will send to the ShoppingCartService service:

    image from book

    Click Send to confirm that this is the correct card.

    The client application resumes and runs as it has done in previous chapters. The selected card contains an email address identifying a user that the ShoppingCartService service allows to invoke the various operations it implements. Notice that although the client application makes several calls to the service, Windows CardSpace intervenes only on the first call in the session.

    Note 

    If you take more than one minute to select and send the card, the client application stops with the exception “The operation is not valid for the state of the transaction.” This is because the AddItemToCart operation is part of a transaction initiated by the client application, and the transaction timeout specified by the client application is one minute. If this happens, stop the client application and service, restart the solution, and select the Valid ShoppingCartService Test Card when prompted by Windows CardSpace.

    Generally, it is not good practice to gather user input during a transaction. For situations such as this, you can programmatically request a token for a specific card in advance of the transaction starting and then supply this token when the first operation occurs. Note that the API that Windows CardSpace currently provides for performing these tasks is unmanaged and requires that you are familiar with C++.

  4. Press Enter to close the client application console window, but leave the service running.

  5. In Visual Studio 2005, in Solution Explorer, right-click the ShoppingCartClient project, point to Debug, and then click Start new instance. This action starts a new instance of the client application.

  6. In the client application console window, press Enter. The Windows CardSpace appears again. This time, however, you don’t get the warning that the Web service is using a suspect certificate–this warning only appears the first time you access the service. Windows CardSpace also organizes the list of matching cards and informs you which cards you have previously sent to the Web service:

    image from book

  7. Select the Invalid ShoppingCartService Test Card, and then click Send. Click Send again to confirm that this is the card you want to use.

    This time the client application stops and reports the exception “Access is denied.” The email address in this card identifies a user to which the ShoppingCartService service has not granted access.

  8. Press Enter to close the client application console. Press Enter to close the service application console.

Using a Third-Party Identity Provider

In the previous exercises, Windows CardSpace acted as its own identity provider, verifying the claim made by the user before sending a SAML token containing the claim information to the service. I mentioned earlier that you might not want to rely on the veracity of self-issued cards in a commercial environment. Instead, you should use information cards issued by trusted third-party identity providers, such as banks, credit card companies, government agencies, and so forth. It is important to realize that the claims on an information card are simply a representation of a set of rights. The rights themselves are retained by the identity provider, and the identity provider can withdraw these rights at any time, rendering the user’s information card invalid.

A user can request an information card from a third party as an out-of-band operation. If the third party approves the request, it can create an information card file and send it to the user. This file is a signed XML file, containing data in a format that Windows CardSpace recognizes. The user can then install this file into Windows CardSpace using the “Install a Managed card” feature of the Windows CardSpace console (this is on the same page in the Windows CardSpace console that you use to create self-issued cards). If the user tries to create a card with a forged set of claims, the third party will not be able to verify those claims and will consequently not issue a token when the user attempts to use the card.

More Info 

Remember that Windows CardSpace is built on accepted WS-* protocols. Microsoft provides documentation on how Windows CardSpace uses these protocols and how to build non-WCF services that can interact with Windows CardSpace for issuing cards and verifying claims. For more information, see the document “A Guide to Integrating with Windows CardSpace v1.0,” available at http://download.microsoft.com/download/6/c/3//infocard-guide-beta2-published.pdf.

The Microsoft Windows SDK also includes the sample “Creating Managed Cards,” which shows how to build an application that can create a signed XML file containing claims that a user can import into Windows CardSpace. This sample is available online at http://msdn2.microsoft.com/en-us/library/aa967567.aspx.

Configuring a WCF Client Application and Service to use a Third-Party Identity Provider

You have seen that an identity provider actually has to perform two related tasks: it issues claims, and it verifies that the claims submitted by a client application are genuine and issues a security token. The component of the identity provider that performs claims verification and issues tokens is usually referred to as a Security Token Service, or STS. In the exercises you performed earlier, Windows CardSpace provided the STS itself. You can also build your own STS. The details are outside the scope of this book, but the Microsoft Windows SDK includes a description of the process in the topic “How To: Create a Security Token Service.” You can find this document online at http://msdn2.microsoft.com/en-us/library/ms733095.aspx.

When you use an STS other than that provided with Windows CardSpace, you must configure the client application with the address of this STS. The identity selector on the client computer uses this information to contact the STS and obtain a security token. You can provide this information programmatically or in the application configuration file. If you use the WCF Configuration Editor to edit the application configuration file, the key properties are in the Issuer page of the wsFederationHttpBinding configuration, shown in Figure 15-1.

image from book
Figure 15-1: Configuring the Issuer properties for a WCF client application.

Specify the URI of the STS in the Address property. You can optionally provide a binding configuration if the STS has particular communications requirements, such as reliable sessions. The Identity tab enables you to indicate a certificate in the local certificate store to use for validating the identity of the STS.

The token issued by an STS can be in one of several formats. By default, the client application requests a token that conforms to the SAML 1.1 specification. However, if the WCF service expects a token in a different format, you can specify the token type in the IssuedTokenType property on the Security page. The STS should respond with a token of this type.

More Info 

For more information about these properties and how to set them programmatically rather than using an application configuration file, see the topic “How To: Create a WSFederationHttpBinding” in the Microsoft Windows SDK documentation. This information is also available online at http://msdn2.microsoft.com/en-us/library/aa347982.aspx.

Claims-Based Authentication in a Federated Environment

Claims-based authentication is an extremely powerful and flexible mechanism that you can use in a variety of scenarios. For example, suppose the Fabrikam organization wants to make one of its Web services available to users belonging to other partner companies, such as Adventure-Works, but not to the general public. One way to authenticate users from Adventure-Works attempting to access the Fabrikam service would be for Fabrikam to implement an STS and issue information cards for each employee of Adventure-Works. However, if Adventure-Works has a large number of employees, then maintaining a list of valid users in the Fabrikam system can quickly become an unmanageable task. Furthermore, should Fabrikam really be concerned with the details of who works for Adventure-Works? All the Fabrikam service requires is that the user is a verified employee of Adventure-Works but not any other details. If Fabrikam has several other partner organizations besides Adventure-Works, whose employees should also be able to access the Fabrikam service, then the scope of the problem multiplies.

To solve this problem, it can help to think of an STS as a service that converts claims of one type into claims of another. The WS-Trust specification on which the concept of an STS is based defines a “language” for requesting and issuing claims. An organization can implement an STS that verifies its employees’ claims, and outputs tokens that can be used as claims for another STS belonging to another organization (the exact details of the WS-Trust specification are beyond the scope of this book). What does this mean, and how does it help? Look at the following possible solution to the problem of Fabrikam authenticating Adventure-Works employees.

The Fabrikam organization has an STS that issues a single claim to Adventure-Works, effectively stating that it recognizes any employee that Adventure-Works authenticates as an employee as being a valid user of the Fabrikam Web service. Adventure-Works implements its own STS. Users inside Adventure-Works have information cards issued by the Adventure-Works STS containing a claim asserting that they are valid employees of Adventure-Works (the “employee claim”). An application run by a user within Adventure-Works that requires access to the Fabrikam Web service actually sends the “employee claim” of the user to the Adventure-Works STS. This STS verifies that the user really is an employee and returns a token containing a verified “the user is an employee of Adventure-Works” claim. The application then sends this new claim to the STS inside the Fabrikam organization. The Fabrikam STS verifies the authenticity of this claim to establish that it is genuine and was issued by a recognized partner organization, and then issues another token containing an authenticated claim that the client application uses to access the Fabrikam Web service. Figure 15-2 depicts the flow of claims and security tokens.

image from book
Figure 15-2: Cooperating Security Token Services.

The Fabrikam organization can issue similar claims to other partner companies, enabling their employees to access the Fabrikam service. If Fabrikam wishes to withdraw the rights of a partner company, it only needs to rescind a single claim. Of course, Fabrikam can issue individual claims to its own employees as well.

Note 

This is a somewhat simplified view of the process, and there other security aspects that a scheme like this requires you to implement, such as authenticating and protecting the physical communications between organizations.

This mechanism is generally referred to as federated security. Each user is authenticated, but the authentication is the responsibility of the individual organizations to which they belong. Internally, each organization operates in an autonomous manner, implementing its own security policies and authenticating users in its own way.

A key aspect of federated security is the confidence that different organizations have with each other’s authentication mechanisms. As long as an organization implements a strong security policy, partner organizations can trust that if it says “user x is valid” then that user is genuinely valid. Security is always a matter of confidence and trust. In the past, different organizations have tried to protect their systems from unauthorized access by using a wide variety of techniques, often based on proprietary protocols. This frequently becomes a problem as soon as organizations need to share information with each other, with ad hoc solutions that often open holes in the security infrastructure of these organizations. The increasing use of STSs and the adoption of the various WS-* protocols can help to standardize the way in which organizations protect their communications and their users, making their security mechanisms more interoperable. Windows CardSpace and WCF provide an important set of tools for helping to implement these mechanisms in a simple-to-use but robust manner.




Microsoft Windows Communication Foundation Step by Step
Microsoft Windows Communication Foundation Step by Step (Step By Step Developer Series)
ISBN: 0735623368
EAN: 2147483647
Year: 2007
Pages: 105
Authors: John Sharp

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net