Accessing REST Services from a Windows Phone Device

The Premise | Goals and Requirements | Overview of the Solution - Passive Federation, Active Federation, Comparing the Solutions | Inside the Implementation - Active SAML Token Handling, Web Browser Control, Asynchronous Behavior | Setup and Physical Deployment | Questions | More Information

In Chapter 9, "Securing REST Services," you saw how Adatum exposed a REST-based web service that used federated authentication and SWT tokens. The scenario described there also included a rich desktop client application that obtained a Simple Web Token (SWT) token from Microsoft Azure™ AppFabric Access Control services (ACS) to present to the web service. The scenario that this chapter describes uses the same web service, but describes how to implement a client application on the Windows® Phone platform.

Creating a Windows Phone client raises some additional security concerns. You can't assume that the Windows Phone device is protected with a password; if the device is stolen or used without the owner's consent, a malicious user could access all of the applications and data on the device unless you introduce some additional security measures. Such security measures could include requiring the user to enter a password or PIN to access either your application, or a feature within your application. The problem here is that any of these security measures are likely to reduce the usability of the application and degrade the overall user experience.

This chapter describes two alternative implementations of the Windows Phone client: a passive federation approach and an active federation approach. The active federation implementation shows how the client application uses the OAuth protocol and contacts all of the issuers in the trust chain in turn to acquire a valid SWT token to access the a-Order Tracking application. The passive implementation shows how to use an embedded web browser control to handle the redirect messages that are used by the WS-Federation protocol to coordinate the exchange of messages with the issuers.

The active federation implementation described in this chapter differs from the implementation shown in Chapter 9, "Securing REST Services." Because there is no version of WIF available for Windows Phone to help with the token processing, the client code in the Windows Phone application is slightly more complex than you'd typically find in a Microsoft® Windows® operating system desktop application.

The sample client application demonstrates both active and passive federation approaches.

The Premise

Litware wants a mobile application that can read the status of its orders directly from Adatum. To satisfy this request, Adatum agrees to provide a web service called a-Order.OrderTracking.Services that users at Litware can use from a variety of client applications over the Internet.

Adatum and Litware have already done the work necessary to establish federated identity; Litware has an issuer that is capable of interacting with both active and passive clients, and Adatum has configured an ACS service namespace with the necessary relying parties (RPs) and identity providers (IdPs). The necessary communications infrastructure, including firewalls and proxies, is in place. To review these elements, see Chapter 5, "Federated Identity with Microsoft Azure Access Control Service."

Bharath Says:
	If ADFS 2.0 is used, support for federated identity with both active and passive clients is a standard feature.

Adatum also has a RESTful web service in place that exposes order-tracking data. This web service is claims-aware and expects to receive claims in an SWT token. For a description of how the web service handles SWT tokens, see Chapter 9, "Securing REST Services."

Goals and Requirements

Both Litware and Adatum see benefits in enabling mobile access to the a-Order tracking data, and Litware already has plans to adopt Windows Phone as its preferred mobile platform. Adatum originally decided to expose the a-Order tracking data using a RESTful web service in anticipation of developing client applications on mobile platforms.

Adatum wants to ensure that the Windows Phone client application follows best practices in terms of integration with the platform and design for optimal battery use. Adatum and Litware are concerned about addressing the possible security issues that arise from using a mobile platform—in particular, the risks associated with someone gaining unauthorized access to a device.

Adatum wants to simplify the process of configuring new identity providers for the Windows Phone application.

Overview of the Solution

The following sections describe two solutions: one that uses an active federated authentication approach, and one that uses a passive federated authentication approach. There is also a discussion of the advantages and disadvantages of each.

Passive Federation

Figure 1 gives an overview of the proposed solution that uses a passive federation model to obtain an SWT token from ACS.

Figure 1

Windows Phone using passive federation

The diagram presents an overview of the interactions and relationships among the different components. It is similar to the diagrams you saw in previous chapters.

Litware has a Windows Phone client application deployed on Litware employees' phones. Rick, a Litware employee, uses this application to track orders with Adatum.

Adatum exposes a RESTful web service on the Internet. The a-Order tracking web service expects to receive SWT tokens that contain the claims it will use for authorization. In order to access this service, the client must present an SWT token from the Adatum ACS instance.

Jana Says:
	Adatum has configured the a-Order tracking web service to trust the Adatum ACS instance.

The sequence shown in the diagram proceeds as follows:

1. The Windows Phone application connects to a service namespace in ACS. It obtains a list of configured identity providers for the relying party (RP) application (Adatum a-Order tracking) as a JavaScript Object Notation (JSON) formatted list. Each entry in this list includes the identity provider's name and the address of the sign-in page at the identity provider. You can find the URL for this list on the ACS Application Management page.

2. The Windows Phone application displays this list for Rick to select the identity provider he wants to use to authenticate.

   Note

   In the sample, there is only one identity provider (Litware), so Rick has only one choice.

3. When Rick selects an identity provider, the Windows Phone application uses an embedded web browser control to navigate to the identity provider's sign-in page (based on the information retrieved in step 1).

4. Because the client application initiates the sign-in passively, after the Litware identity provider authenticates Rick it automatically redirects the embedded web browser control back to ACS, passing it the Security Assertion Markup Language (SAML) token from the Litware identity provider.

5. ACS transforms the tokens based on the rules in the service namespace, and transitions the incoming SAML token to an SWT token. ACS returns the SWT token to the embedded browser.

6. The Windows Phone application retrieves the SWT token from the embedded web browser control and then caches it on the Windows Phone device.

7. The Windows Phone application then makes a REST call to the a-Order tracking web service, including the SWT token in the request header.

8. The a-Order tracking web service extracts the SWT token from the request. It uses the claims in the token to implement authorization rules in the a-Order tracking web service.

9. The service returns the order tracking data to the Windows Phone application.

This scenario uses the passive WS-Federation protocol; the interaction between the identity provider and ACS (the federation provider) is passive and uses an embedded web browser control on the phone to handle the redirects. The Windows Phone application invokes the RESTful web service directly, sending the SWT token to the web service (the relying party) along with the request for tracking data.

The only configuration data that the Windows Phone application needs is:

• The URL the phone uses to access the list of identity providers in JSON format from ACS. The Windows Phone application uses this URL in step 1 in the sequence shown in Figure 1.
• The URL the phone uses to access the a-Order tracking RESTful web service. This happens in step 7 in the sequence shown in Figure 1.

This scenario uses Secure Sockets Layer (SSL) to protect all the interactions from the Windows Phone device including accessing the Litware identity provider, the ACS instance, and calling the Adatum web service.

Markus Says:
	The sample application installs a self-issued certificate on the Windows Phone device so that it can use SSL when it communicates with the Litware identity provider and the a-Order tracking application. In a real-world scenario, the Litware identity provider and the a-Order tracking applications will be protected by certificates from a trusted third-party issuer.

To improve its usability, the Windows Phone application caches the SWT token so that for subsequent requests it can simply forward the cached SWT token instead of re-authenticating with the identity provider, and obtaining a new SWT token from ACS.

Active Federation

Figure 2 shows an alternative solution for the Windows Phone client application that uses a pure active federation approach.

Figure 2

Windows Phone using active federation

The diagram presents an overview of the interactions and relationships among the different components in the active federation solution.

Litware has a Windows Phone client application deployed on Litware employees' phones. Rick, a Litware employee, uses this application to track orders with Adatum.

Adatum exposes a RESTful web service on the Internet. This web service expects to receive Simple Web Token (SWT) tokens that it will use to implement authorization rules in the a-Order application. In order to access this service, the client application must present an SWT token from the Adatum ACS instance.

The sequence shown in the diagram proceeds as follows:

1. The Windows Phone application connects the Litware identity provider. It sends Rick's credentials and receives a SAML token in response. This SAML token includes the claims that the Litware identity provider issues for Rick.
2. The Windows Phone application sends the SAML token from the Litware issuer to ACS.
3. The ACS service instance applies the mapping rules for the Litware identity provider to the incoming claims and transitions the incoming SAML token to an SWT token. ACS returns the new SWT token to the Windows Phone client application.
4. The Windows Phone application caches the SWT token so it can use it for future requests. The Windows Phone application then makes a REST call to the a-Order tracking web service, including the SWT token in the request header.
5. The a-Order tracking web service extracts the SWT token from the request. It uses the claims in the token to implement authorization rules in the a-Order tracking web service.
6. The service returns the order tracking data to the Windows Phone application.

In this solution, the Windows Phone application controls the process of obtaining the SWT token and invoking the web service directly. The application code includes logic to visit all of the issuers in the trust chain in the correct order. It uses the WS-Trust protocol when it communicates with the Litware identity provider to obtain a SAML token, and the OAuth protocol to communicate with ACS and the a-Order tracking service.

As in the passive solution, all the interactions from the Windows Phone device are secured using SSL.

Comparing the Solutions

The passive federation solution that leverages an embedded browser control offers a simpler approach to obtaining an SWT token because the embedded web browser control in combination with the WS-Federation protocol handles most of the logic to visit the issuers and obtain the SWT token that the application needs to access the a-Order tracking service. In the active federation solution, the Windows Phone application must include code to control the interactions with the issuers explicitly. Furthermore, the active solution must include code to handle the request for a SAML token from the Litware issuer; this is more complex on the Windows Phone platform than on the desktop because there is not currently a version of WIF for Windows Phone. The sample described in Chapter 9, "Securing REST Services," shows you how to do this in a Windows Presentation Foundation (WPF) application.

Jana Says:
	In a WPF application, you can use Windows Identity Foundation (WIF) to perform some of the token handling, even though WIF does not provide full support for RESTful web services.

However, there is some complexity in the passive solution in the way that the application must interact with an embedded web browser control to initiate the sign-in with the Litware identity provider and retrieve the SWT token issued by ACS from the browser control.

For some scenarios, an advantage of the passive federation approach is that it enables the Windows Phone application to dynamically build the list of identity providers for the user to choose from. If you add an additional identity provider to your ACS configuration, the Windows Phone client application will detect this the next time it requests the list of identity providers from ACS. You could use this to quickly and easily add support for additional social identity providers to an already deployed Windows Phone application. In the active federation solution, the application is responsible for choosing the identity provider to use, and although you could design the application to dynamically build a list of identity providers, this would add considerably to the complexity of the solution. The active federation solution is much better suited to scenarios where you have a fixed, known identity provider for the Windows Phone application to use.

If you compare Figures 1 and 2, you can see that the passive solution requires more round trips to obtain an SWT token, which will make this approach slower than the active approach. You should bear in mind that this applies only to the initial federated authentication. If the application caches the SWT token, it can reuse it for subsequent requests to the a-Order tracking web service.

Another potential disadvantage of the active solution is that it only works with a WS-Trust compliant Security Token Service (STS). If the Windows Phone device needs to authenticate with a different protocol, then you'll have to implement that protocol on the phone.

You must explicitly add any SWT token caching behavior to the Windows Phone application for both the active or passive federation solutions; there is no automatic caching provided in either solution. However, in the passive federation solution, the embedded web browser control will automatically cache the SAML token it receives from the Litware identity provider; after the initial authentication with the Litware identity provider, the application will not prompt the user will to re-enter their credentials for as long as the cached SAML token remains valid.

Bharath Says:
	The lifetime of the SAML token is determined by the token issuer.

Inside the Implementation

Now is a good time to walk through some of the details of the solution. As you go through this section, you may want to download the Microsoft Visual Studio® development system solution called 9WindowsPhoneClientFederation from https://claimsid.codeplex.com. The following sections describe some of the key parts of the implementation; some of these are specific to either the active or passive federation solution.

Note

For details about the implementation of the a-Order tracking web service, see Chapter 9, "Securing REST Services."

Active SAML Token Handling

The active federation solution must handle the request for a SAML token that the Windows Phone application sends to the Litware identity provider. There is no version of WIF available for the Windows Phone platform, so the application must create the SAML sign-in request programmatically. In the sample application, the GetSamlTokenRequest method in the HttpWebRequestExtensions class, illustrates a technique for requesting a SAML token when WIF is not available to perform this task for you.

Bharath Says:
	ADFS 2 does not support the OAuth protocol, so the Windows Phone application must use the WS-Trust protocol to obtain a SAML token.

Note

See chapter 9, "Securing REST Services," for an example of an active client that can use WIF to request a SAML token.

The following code sample from the HttpWebRequestExtensions class shows how the Windows Phone application creates the SAML token request to send to the identity provider.

private static string GetSamlTokenRequest(string samlEndpoint, string realm)
{
  var tokenRequest =
    string.Format(
    CultureInfo.InvariantCulture,
    samlSignInRequestFormat,
    Guid.NewGuid().ToString(),
    samlEndpoint,
    DateTime.UtcNow.ToString("yyyy'-'MM'-'ddTHH':'mm':'ss'.'fff'Z'"),
    DateTime.UtcNow.AddMinutes(15).ToString("yyyy'-'MM'-'ddTHH':'mm':'ss'.'fff'Z'"),
    "LITWARE\\rick",
    "PasswordIsNotChecked",
    "https://aorderphone-dev.accesscontrol.windows.net/");

    return tokenRequest;
}

/// Format:
/// {0}: Message Id - Guid
/// {1}: To - https://localhost/Litware.SimulatedIssuer.9/Issuer.svc
/// {2}: Created - 2011-03-11T01:49:29.395Z
/// {3}: Expires - 2011-03-11T01:54:29.395Z
/// {4}: Username - LITWARE\rick
/// {5}: Password - password
/// {6}: Applies To - https://{project}.accesscontrol.windows.net/
private const string samlSignInRequestFormat =
  @"<s:Envelope xmlns:s=""http://www.w3.org/2003/05/soap-envelope""  
  xmlns:a=""http://www.w3.org/2005/08/addressing"" xmlns:u=""http://docs.oasis-
  open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility- 
  1.0.xsd""> … </s:Envelope>";

The following code example shows how the client posts the SAML token request to the identity provider and retrieves the SAML token from the response.

public static IObservable<string> PostSamlTokenRequest(this HttpWebRequest request, string tokenRequest)
{
  request.Method = "POST";
  request.ContentType = "application/soap+xml; charset=utf-8";

  return
    Observable
      .FromAsyncPattern<Stream>(request.BeginGetRequestStream, 
      request.EndGetRequestStream)()
      .SelectMany(
        requestStream =>
        {
          using (requestStream)
          {
            var buffer = System.Text.Encoding.UTF8.GetBytes(tokenRequest);
            requestStream.Write(buffer, 0, buffer.Length);
            requestStream.Close();
          }

          return
            Observable.FromAsyncPattern<WebResponse>(
              request.BeginGetResponse,
              request.EndGetResponse)();
        },
        (requestStream, webResponse) =>
        {
          string res = new StreamReader(webResponse.GetResponseStream(), 
            Encoding.UTF8).ReadToEnd();
          var startIndex = res.IndexOf("<Assertion ");
          var endIndex = res.IndexOf("</Assertion>");
          var token = res.Substring(
            startIndex, endIndex + "</Assertion>".Length - startIndex);
          return token;
        });
}

Web Browser Control

The passive federation solution uses an embedded web browser control to handle the passive WS-Federation interactions between the client application and the issuers. The application wraps the web browser control in a custom control that you can find in the SL.Phone.Federation project. The Windows Phone application passes the address of the JSON-encoded list of identity providers into this control, and then retrieves the SAML token from the control when the federated authentication process is complete. The following code sample from the MainPage.xaml.cs file shows how the application interacts with the custom sign-in control.

private void OnGetMyOrdersPassiveButtonClicked(object sender, RoutedEventArgs e)
{
  …

  var acsJsonEndpoint = "https://aorderphone-dev.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm=https%3A%2F%2Flocalhost%2Fa-Order.OrderTracking.Services.9&context=&version=1.0";
  SignInControl.RequestSecurityTokenResponseCompleted += 
    new EventHandler<SL.Phone.Federation.Controls
    .RequestSecurityTokenResponseCompletedEventArgs>(
    SignInControl_RequestSecurityTokenResponseCompleted);
  SignInControl.GetSecurityToken(new Uri(acsJsonEndpoint));
}

void SignInControl_RequestSecurityTokenResponseCompleted(object sender, 
  SL.Phone.Federation.Controls.RequestSecurityTokenResponseCompletedEventArgs e)
{
  this.GetOrdersWithToken(e.RequestSecurityTokenResponse.TokenString)
    .ObserveOnDispatcher()
    .Catch((WebException ex) =>
      {
        …
      }
    .Subscribe(orders =>
      {
        …
      });
}

The catch block in the SignInControl_RequestSecurityTokenResponseCompleted method enables the client to trap errors such as "401 Unauthorized" errors from the REST service.

The custom control that contains the embedded web browser control must raise the RequestSecurityTokenResponseCompleted event after the control receives the SWT token from ACS. The control recognizes when it has received the SWT token because ACS sends a redirect message to a special URL: https://break_here. The ACS configuration for the aOrderService RP includes this value for the "Return URL" setting. The following code sample shows how the Navigating event in the custom control traps this navigation request, extracts the SWT token, and raises the RequestSecurityTokenResponseCompleted event to notify the Windows Phone application that the SWT token is now available.

private void SignInWebBrowserControl_Navigating(object sender, NavigatingEventArgs e)
{
  if (e.Uri == new Uri("https://break_here"))
  {
    e.Cancel = true;

    var acsReply = this.BrowserSigninControl.SaveToString();

    Regex tagRegex = CreateRegexForHtmlTag("BinarySecurityToken");
    var acsBinaryToken = tagRegex.Match(acsReply).Groups[1].Value;
    var acsTokenBytes = Convert.FromBase64String(acsBinaryToken);
    var acsToken = System.Text.Encoding.UTF8.GetString(
      acsTokenBytes, 0, acsTokenBytes.Length);

    tagRegex = CreateRegexForHtmlTag("Expires");
    var expires = DateTime.Parse(tagRegex.Match(acsReply).Groups[1].Value);
                
    tagRegex = CreateRegexForHtmlTag("TokenType");
    var tokenType = tagRegex.Match(acsReply).Groups[1].Value;

    if (null != RequestSecurityTokenResponseCompleted)
    {
      var rstr = new RequestSecurityTokenResponse();
      rstr.TokenString = acsToken;
      rstr.Expiration = expires;
      rstr.TokenType = tokenType;
      RequestSecurityTokenResponseCompleted(this,
        new RequestSecurityTokenResponseCompletedEventArgs(rstr, null));
    }
  }
  …
}

You must also explicitly enable JavaScript in the embedded web browser control on the phone; otherwise the automatic redirections will fail. The following snippet from the AccessControlServiceSignIn.xaml file shows how to do this.

<phone:WebBrowser x:Name="BrowserSigninControl" 
IsScriptEnabled="True" Visibility="Collapsed"  />

Asynchronous Behavior

Both the active and passive scenarios make extensive use of the Reactive Extensions (Rx) for the Windows Phone platform to interact with issuers and the a-Order tracking web service asynchronously. For example, the active federation solution uses Rx to orchestrate the interactions with the issuers and ensure that they are visited in the correct sequence. The GetOrders method in the MainPage.xaml.cs file shows how the client application adds the SWT token to the request header that it sends to the a-Order tracking web service, sends the request, and traps any errors such as "401 Unauthorized" messages, all asynchronously.

public IObservable<Order[]> GetOrders()
{
  var stsEndpoint = "https://localhost/Litware.SimulatedIssuer.9/Issue.svc";
  var acsEndpoint =
    "https://aorderphone-dev.accesscontrol.windows.net/v2/OAuth2-13";

  var serviceEnpoint = "https://localhost/a-Order.OrderTracking.Services.9";
  var ordersServiceUri = new Uri(serviceEnpoint + "/orders/frommyorganization");

  return
    HttpClient.RequestTo(ordersServiceUri)
      .AddAuthorizationHeader(stsEndpoint, acsEndpoint, serviceEnpoint)
      .SelectMany(request =>
        {
          return request.Get<Order[]>();
        },
        (request, orders) =>
        {
          return orders;
        })
        .ObserveOnDispatcher()
        .Catch((WebException ex) =>
        {
          var message = GetMessageForException(ex);
          MessageBox.Show(message);
          return Observable.Return(default(Order[]));
        });
}

Note

This example uses the SelectMany method instead of the simple Select method because the call to the Get method itself returns an IObservable<Orders[]> instance; using Select would then return an IObservable<IObservable<Orders[]> instance. The SelectMany method flattens the IObservable<IObservable<Orders[]> instance to an <IObservable<Orders[]> instance.

The following list outlines the nested sequence of calls in the active federated authentication scenario. The process starts when the application calls the MainPage.GetMyOrdersButton_Click method, and uses Rx to manage the nested sequence of asynchronous calls.

1. Call the MainPage.GetOrders method asynchronously on a background thread.
   1. Create an HttpWebRequest object to send to the a-Orders tracking web service.
   2. Call the HttpWebRequestExtensions.AddAuthorizationHeader method to add the SWT token to the HttpWebRequest object asynchronously.
      1. Create a SAML token request.
      2. Call the HttpWebExtensions.PostSamlTokenRequest to send the SAML request asynchronously to the Litware identity provider.
      3. Send the SAML request to the Litware identity provider.
      4. Extract the SAML token in the response from the Litware identity provider.
      5. Return the SAML token.
      6. Call the HttpWebExtensions.PostSwtTokenRequest method to send the SAML token to ACS asynchronously.
      7. Create an SWT token request that contains the SAML token.
      8. Send the SWT token request to ACS.
      9. Extract the SWT token in the response from ACS.
      10. Return the SWT token.
      11. Add the SWT token to the HttpWebRequest object.
      12. Return the HttpWebRequest object.
   3. Invoke the a-Orders tracking web service by calling the HttpWebRequest.Get method asynchronously.
      1. Send the web request to the a-Orders tracking web service.
      2. Use the BeginGetResponse and EndGetResponse methods to capture the response data.
      3. Deserialize the response data to an Order[] instance.
      4. Return the Order[] instance.
   4. Return the results as an Order[] instance.
2. Update the UI with the result of the call to MainPage.GetOrders.

The following list outlines the nested sequence of calls in the passive federated authentication scenario. The process starts when the application calls the MainPage.OnGetMyOrdersPassiveButton_Click method, and uses Rx to manage the nested sequence of asynchronous calls.

1. Call the AccessControlServiceSignIn.GetSecurityToken method to obtain an SWT token.
2. Handle the AccessControlServiceSignIn.RequestSecurityTokenResponseCompleted event.
   1. Call the MainPage.GetOrdersWithToken method asynchronously. The SWT token is available in the EventArgs parameter.
      1. Create an HTTP request to send to the a-Order tracking web service.
      2. Call the HttpWebRequestExtensions.AddAuthorizationHeader method asynchronously to add the SWT token to the request.
      3. Invoke the a-Orders tracking web service by calling the HttpWebRequest.Get method asynchronously.
      4. Send the web request to the a-Orders tracking web service.
      5. Use the BeginGetResponse and EndGetResponse methods to capture the response data.
      6. Deserialize the response data to an Order[] instance.
      7. Return the Order[] instance.
      8. Return the Order[] instance.
   2. From the background thread, update the UI with the Order[] instance data by calling the UpdateOrders method.

Setup and Physical Deployment

For the sample Windows Phone application to be able to use SSL when it communicates with the sample Litware issuer and Adatum a-Order tracking applications on localhost, it's necessary to install the localhost root certificate on the Windows Phone device. To do this, the Litware sample issuer includes a page that has a link to the required certificate: https://localhost/Litware.SimulatedIssuer.9/RootCert/Default.aspx. If you navigate to this address on the Windows Phone device, you can install the root certificate that enables SSL. In a production environment, you should secure your web service and issuer with a certificate from a trusted third-party certificate provider rather than a self-issued certificate; if you do this, it won't be necessary to install a certificate on the Windows Phone device in order to access your issuer and web service using SSL.

In the passive federation scenario, the Windows Phone application uses an embedded web browser control to navigate to the Litware identity provider so that the user can enter her credentials. It's important that the sign-in page at the issuer is "mobile friendly" and displays clearly on the Windows Phone device. You should verify that your issuer renders a suitable sign-in page if you are planning to use a Windows Phone client in a passive federated authentication scenario.

Questions

1. Which of the following are issues in developing a claims-aware application that access a web service for the Windows Phone 7™ platform?
   1. It's not possible to implement a solution that uses SAML tokens on the phone.
   2. You cannot install custom SSL certificates on the phone.
   3. There is no secure storage on the phone.
   4. There is no implementation of WIF available for the phone.
2. Why does the sample application use an embedded web browser control?
   1. To handle the passive federated authentication process.
   2. To handle the active federated authentication process.
   3. To access the RESTful web service.
   4. To enable the client application to use SSL.
3. Of the two solutions (active and passive) described in the chapter, which requires the most round trips for the initial request to the web service?
   1. They both require the same number.
   2. The passive solution requires fewer than the active solution.
   3. The active solution requires fewer than the passive solution.
   4. It depends on the number of claims configured for the relying party in ACS.
4. Which of the following are advantages of the passive solution over the active solution?
   1. The passive solution can easily build a dynamic list of identity providers.
   2. It's simpler to create code to handle SWT tokens in the passive solution.
   3. It's simpler to create code to handle SAML tokens in the passive solution.
   4. Better performance.
5. In the sample solution for this chapter, how does the Windows Phone 7 client application add the SWT token to the outgoing request?
   1. It uses a Windows Communication Foundation (WCF) behavior.
   2. It uses Rx to orchestrate the acquisition of the SWT token and add it to the header.
   3. It uses the embedded web browser control to add the header.
   4. It uses WIF.

More Information

To learn more about developing for Windows Phone 7, see the "Windows Phone 7 Developer Guide" at: https://msdn.microsoft.com/en-us/library/gg490765.aspx.

Next | Home