Answers to Questions
Chapter 1, An Introduction to Claims
- Under what circumstances should your application or service accept a token that contains claims about the user or requesting service?
- The claims include an email address.
- The token was sent over an HTTPS channel.
- Your application or service trusts the token issuer.
- The token is encrypted.
Answer: Only (c) is strictly correct. While it is good practice to use encrypted tokens and send them over a secure channel, an application should only accept a token if it is configured to trust the issuer. The presence of an email address alone does not signify that the token is valid. - What can an application or service do with a valid token from a trusted issuer?
- Find out the user's password.
- Log in to the website of the user's identity provider.
- Send emails to the user.
- Use the claims it contains to authorize the user for access to appropriate resources.
Answer: Only (d) is true in all cases. The claims do not include the user's password or other credentials. They only include the information the user and the identity provider choose to expose. This may or may not include an email address, depending on the identity provider. - What is the meaning of the term identity federation?
- It is the name of a company that issues claims about Internet users.
- It is a mechanism for authenticating users so that they can access different applications without signing on every time.
- It is a mechanism for passing users' credentials to another application.
- It is a mechanism for finding out which sites a user has visited.
Answer: Only (b) is correct. Each application must query the original issuer to determine if the token a user obtained when they originally authenticated is valid. The token does not include the users' credentials or other information about users' browsing history or activity. - When would you choose to use Microsoft Azure™ AppFabric Access Control Service (ACS) as an issuer for an application or service?
- When the application must allow users to sign on using a range of well-known social identity credentials.
- When the application is hosted on the Azure platform.
- When the application must support single sign-on (SSO).
- When the application does not have access to an alternative identity provider or token issuer.
Answer: Only (a) and (d) are correct. Applications running on Azure can use ACS if they must support federated identity, but it is not mandatory. SSO can be implemented using a range of mechanisms other than ACS, such as a Microsoft Active Directory® domain server and Active Directory Federation Services. - What are the benefits of using claims to manage authorization in applications and services?
- It avoids the need to write code specific to any one type of authentication mechanism.
- It decouples authentication logic from authorization logic, making changes to authentication mechanisms much easier.
- It allows the use of more fine-grained permissions based on specific claims compared to the granularity achieved just using roles.
- It allows secure access for users that are in a different domain or realm from the application or service.
Answer: All of the answers are correct, which shows just how powerful claims can be!
Chapter 2, Claims Based Architectures
- Which of the following protocols or types of claims token are typically used for single sign-on across applications in different domains and geographical locations?
- Simple web Token (SWT)
- Kerberos ticket
- Security Assertion Markup Language (SAML) token
- Windows Identity
Answer: Only (a) and (c) are typically used across domains and applications outside a corporate network. Kerberos tickets cannot contain claims, and they are confined within a domain or Active Directory forest. Windows Identities may contain role information, but cannot carry claims between applications. - In a browser-based application, which of the following is the typical order for browser requests during authentication?
- Identity provider, token issuer, relying party
- Token issuer, identity provider, token issuer, relying party
- Relying party, token issuer, identity provider, token issuer, relying party
- Relying party, identity provider, token issuer, relying party
Answer: Only (c) is correct. The claims-aware application (the relying party) redirects the browser to the token issuer, which either redirects the browser to the appropriate identity provider for the user to enter credentials (ACS) or obtains a token on the user's behalf using their correct credentials (ADFS). It then redirects the browser back to the claims-aware application. - In a service request from a non-browser-based application, which of the following is the typical order of requests during authentication?
- Identity provider, token issuer, relying party
- Token issuer, identity provider, token issuer, relying party
- Relying party, token issuer, identity provider, token issuer, relying party
- Relying party, identity provider, token issuer, relying party
Answer: When authenticating using ADFS and Active Directory (or a similar technology), only (b) is correct. ADFS obtains a token on the application's behalf using credentials provided in the request. When authenticating using ACS, (a) and (b) are correct. - What are the main benefits of federated identity?
- It avoids the requirement to maintain a list of valid users, manage passwords and security, and store and maintain lists of roles for users in the application.
- It delegates user and role management to the trusted organization responsible for the user, instead of it being the responsibility of your application.
- It allows users to log onto applications using the same credentials, and choose an identity provider that is appropriate for the user and the application to validate these credentials.
- It means that your applications do not need to include authorization code.
Answer: Only (a), (b), and (c) are correct. Even if you completely delegate the validation of users to an external federated system, you must still use the claims (such as role membership) in your applications to limit access to resources to only the appropriate users. - How can home realm discovery be achieved?
- The token issuer can display a list of realms based on the configured identity providers and allow the user to select his home realm.
- The token issuer can ask for the user's email address and use the domain to establish the home realm.
- The application can use the IP address to establish the home realm based on the user's country/region of residence.
- The application can send a hint to the token issuer in the form of a special request parameter that indicates the user's home realm.
Answer: Only (a), (b), and (d) are correct. Home realms are not directly related to geographical location (although this may have some influence). The home realm is the domain that is authoritative for the user's identity. It is the identity provider that the user must be redirected to when logging in.
Chapter 3, Claims-Based Single Sign-On for the Web and Microsoft Azure
- Before Adatum updated the a-Expense and a-Order applications, why was it not possible to use single sign-on?
- The applications used different sets of roles to manage authorization.
- a-Order used Windows authentication and a-Expense used ASP.NET forms authentication.
- In the a-Expense application, the access rules were intermixed with the application's business logic.
- You cannot implement single sign-on when user profile data is stored in multiple locations.
Answer: Only (b) is correct. The key factor blocking the implementation of single sign-on is that the applications use different authentication mechanisms. Once users authenticate with a claims issuer, you can configure the applications to trust the issuer. The applications can use the claims from the issuer to implement any authorization rules they need. - How does the use of claims facilitate remote web-based access to the Adatum applications?
- Using Active Directory for authentication makes it difficult to avoid having to use VPN to access the applications.
- Using claims means that you no longer need to use Active Directory.
- Protocols such as WS-Federation transport claims in tokens as part of standard HTTP messages.
- Using claims means that you can use ASP.NET forms-based authentication for all your applications.
Answer: Only (a) and (c) are correct. Protocols that use claims such as WS-Federation make it easy to provide web-based access to your applications. ADFS makes it easy to continue to use Active Directory in a claims-based environment, while using just Active Directory on its own with the Kerberos protocol is not well suited to providing web-based access. - In a claims enabled ASP.NET web application, you typically find that the authentication mode is set to None in the Web.config file. Why is this?
- The WSFederationAuthenticationModule is now responsible for authenticating the user.
- The user must have already been authenticated by an external system before they visit the application.
- Authentication is handled in the On_Authenticate event in the global.asax file.
- The WSFederationAuthenticationModule is now responsible for managing the authentication process.
Answer: Only (d) is correct. The WSFederationAuthenticationModule is responsible for managing the authentication process. It intercepts requests in the HTTP pipeline before they reach the application and coordinates with an external claims issuer to authenticate the user. - Claims issuers always sign the tokens they send to a relying party. However, although it is considered best practice, they might not always encrypt the tokens. Why is this?
- Relying parties must be sure that the claims come from a trusted issuer.
- Tokens may be transferred using SSL.
- The claims issuer may not be able to encrypt the token because it does not have access to the encryption key.
- It's up to the relying party to state whether or not it accepts encrypted tokens.
Answer: Only (a) and (b) are correct. A key feature of claims-based authentication is that relying parties can trust the claims that they receive from an issuer. A signature proves that the claim came from a particular issuer. Using SSL helps to secure the tokens that the issuer transmits to the relying party if the issuer does not encrypt them. - The FederatedPassiveSignInStatus control automatically signs a user out of all the applications she signed into in the single sign-on domain.
- True.
- False. You must add code to the application to perform the sign-out process.
- It depends on the capabilities of the claims issuer. The issuer is responsible for sending sign-out messages to all relying parties.
- If your relying party uses HTTP sessions, you must add code to explicitly abandon the session.
Answer: Only (c) and (d) are correct. It is the responsibility of the claims issuer to notify all relying parties that the user is signing out. Additionally, you must add any necessary code to abandon any HTTP sessions.
Chapter 4, Federated Identity for Web Applications
- Federated identity is best described as:
- Two or more applications that share the same set of users.
- Two or more organizations that share the same set of users.
- Two or more organizations that share an identity provider.
- One organization trusting users from one or more other organizations to access its applications.
Answer: Only (d) is correct. Federation is about trusting the users from another organization. Instead of creating special accounts for external users, you trust another organization to authenticate users on your behalf before you give them access to your applications. - In a federated security environment, claims mapping is necessary because:
- Claims issued by one organization are not necessarily the claims recognized by another organization.
- Claims issued by one organization can never be trusted by another organization.
- Claims must always be mapped to the roles used in authorization.
- Claims must be transferred to a new ClaimsPrincipal object.
Answer: Only (a) is correct. The claims used by one organization may not be the same as the claims used by another. For example, one organization may use a claim called role while another organization uses a claim called group for a similar purpose. Mapping enables you to map the claims used by one organization to the claims used in another. Although role claims are often used for authorization, the authorization scheme could depend on other claims such as organization or cost center. - The roles of a federation provider can include:
- Mapping claims from an identity provider to claims that the relying party understands.
- Authenticating users.
- Redirecting users to their identity provider.
- Verifying that the claims were issued by the expected identity provider.
Answer: Only (a),(c) and (d) are correct. A federation provider can map claims, redirect users to the correct identity provider, and verify that the claims were issued by the correct identity provider. - Must an identity provider issue claims that are specific to a relying party?
- Yes
- No
- It depends.
Answer: Only (b) is correct. It is the job of the federation provider to map the claims issued by the identity provider to claims recognized by the relying party. Therefore, the identity provider's issuer should not issue claims specific to the relying party. Using a federation provider helps to decouple the identity provider from the relying party. - Which of the following best summarizes the trust relationships between the various parties described in the federated identity scenario in this chapter?
- The relying party trusts the identity provider, which in turn trusts the federation provider.
- The identity provider trusts the federation provider, which in turn trusts the relying party.
- The relying party trusts the federation provider, which in turn trusts the identity provider.
- The federation provider trusts both the identity provider and the relying party.
Answer: Only (c) is correct. The trust relationships described in this chapter have the relying party trusting the federation provider that trusts the identity provider.
Chapter 5, Federated Identity with Microsoft Azure Access Control Service
- Which of the following issues must you address if you want to allow users of your application to authenticate with a social identity provider such as Google or Windows Live® network of Internet services?
- Social identity providers may use protocols other than WS-Federation to exchange claims tokens.
- You must register your application with the social identity provider.
- Different social identity providers issue different claim types.
- You must provide a mechanism to enroll users using social identities with your application.
Answer: Only (a),(c) and (d) are correct. Your solution must be able to transition protocols; the solution described in this chapter uses ACS to perform this task. The scenario described in this chapter also uses ACS to map the different claim types issued by the social identity providers to claim types that Adatum understands. You must provide a mechanism to enroll users with social identities. - What are the advantages of allowing users to authenticate to use your application with a social identity?
- The user doesn't need to remember yet another username and password.
- It reduces the features that you must implement in your application.
- Social identity providers all use the same protocol to transfer tokens and claims.
- It puts the user in control of their password management. For example, a user can recover a forgotten password without calling your helpdesk.
Answer: Only (a),(b), and (d) are correct. Reusing a social identity does mean that the user doesn't need to remember a new set of credentials. Also, the authentication and user account management is now handled by the social identity provider. - What are the potential disadvantages of using ACS as your federation provider?
- It adds to the complexity of your relying party application.
- It adds an extra step to the authentication process, which negatively impacts the user experience.
- It is a metered service, so you must pay for each token that it issues.
- Your application now relies on an external service that is outside of its control.
Answer: Only (c) and (d) are correct. Although ACS is a metered service, you should compare its running costs to the costs of implementing and running your own federation provider. ACS is a third-party application outside of your control; again, you should evaluate the SLA associated with ACS against the service-level agreement (SLA) your IT department offers for on-premises services. - How can your federation provider determine which identity provider to use (perform home realm discovery) when an unauthenticated user accesses the application?
- Present the user with a list of identity providers to choose from.
- Analyze the IP address of the originating request.
- Prompt the user for an email address, and then parse it to determine the user's security domain.
- Examine the ClaimsPrincipal object for the user's current session.
Answer: Only (a) and (c) are correct. The scenario described in this chapter lets the user select from a list of identity providers. It's also possible to analyze the user's email address; for example, if the email address were paul@gmail.com, the federation provider would determine that the user has a Google identity. - In the scenario described in this chapter, the Adatum federation provider trusts ACS, which in turn trusts the social identity providers such as Windows Live and Google. Why does the Adatum federation provider not trust the social identity providers directly?
- It's not possible to configure the Adatum federation provider to trust the social identity providers because the social identity providers do not make the certificates required for a trust relationship available.
- ACS automatically performs the protocol transition.
- ACS is necessary to perform the claims mapping.
- Without ACS, it's not possible to allow Adatum employees to access the application over the web.
Answer: Only (b) is correct. Using ACS simplifies the Adatum federation provider, especially because ACS performs any protocol transitioning automatically. It is possible to configure the Adatum federation provider to trust the social identity providers directly and perform the claims mapping; however, this is likely to be complex to implement.
Chapter 6, Federated Identity with Multiple Partners
- In the scenario described in this chapter, who should take what action when an employee leaves one of the partner organizations such as Litware?
- Fabrikam Shipping must remove the user from its user database.
- Litware must remove the user from its user database.
- Fabrikam must amend the claims-mapping rules in its federation provider.
- Litware must ensure that its identity provider no longer issues any of the claims that get mapped to Fabrikam Shipping claims.
Answer: Only (b) is correct. If the employee leaves Litware, the simplest and safest action is to remove the employee from its user database. This means that the ex-employee can no longer authenticate with Litware or be issued any claims. - In the scenario described in this chapter, how does Fabrikam Shipping perform home realm discovery?
- Fabrikam Shipping presents unauthenticated users with a list of federation partners to choose from.
- Fabrikam Shipping prompts unauthenticated users for their email addresses. It parses this address to determine which organization the user belongs to.
- Fabrikam Shipping does not need to perform home realm discovery because users will have already authenticated with their organizations' identity providers.
- Each partner organization has its own landing page in Fabrikam Shipping. Visiting that page will automatically redirect unauthenticated users to that organization's identity provider.
Answer: Only (d) is correct. Each organization has its own landing page in Fabrikam Shipping. For example, Adatum employees should navigate to https://{fabrikam host}/f-shipping/adatum. - Fabrikam Shipping provides an identity provider for its smaller customers who do not have their own identity provider. What are the disadvantages of this?
- Fabrikam must bear the costs of providing this service.
- Users at smaller customers will need to remember another username and password.
- Smaller customers must rely on Fabrikam to manage their user's access to Fabrikam Shipping.
- Fabrikam Shipping must set up a trust relationship with all of its smaller customers.
Answer: Only (a), (b) and (c) are correct. Unless Fabrikam Shipping charges for the service, they must bear the costs. It does mean that users will have to remember a new set of credentials. All of the user management takes place at Fabrikam, unless Fabrikam implements a web interface for smaller customers to manage their users. - How does Fabrikam Shipping ensure that only users at a particular partner can view that partner's shipping data?
- The Fabrikam Shipping application examines the email address of the user to determine the organization they belong to.
- Fabrikam Shipping uses separate databases for each partner. Each database uses different credentials to control access.
- Fabrikam shipping uses the role claim from the partner's identity provider to determine whether the user should be able to access the data.
- Fabrikam shipping uses the organization claim from its federation provider to determine whether the user should be able to access the data.
Answer: Only (d) is correct. It's the organization claim that Fabrikam Shipping uses to control access. - The developers at Fabrikam set the wsFederationpassiveRedirectEnabled attribute to false. Why?
- This scenario uses active redirection, not passive redirection.
- They wanted more control over the redirection process.
- Fabrikam Shipping is an MVC application.
- They needed to be able to redirect to external identity providers.
Answer: Only (b) is correct. For this scenario, they needed more control over the passive redirection process.
Chapter 7, Federated Identity with Multiple Partners and Microsoft Azure Access Control Service
- Why does Fabrikam want to use ACS in the scenario described in this chapter?
- Because it will simplify Fabrikam's own internal infrastructure requirements.
- Because it’s the only way Fabrikam can support users who want to use a social identity provider for authentication.
- Because it enables users with social identities to access the Fabrikam Shipping application more easily.
- Because ACS can authenticate users with social identities.
Answer: Only (a) and (c) are correct. Using ACS means that Fabrikam Shipping no longer requires its own federation provider. Also, ACS handles all of the necessary protocol transition for the tokens that the social identity providers issue. ACS does not perform the authentication; this task is handled by the social identity provider. - In the scenario described in this chapter, why is it necessary for Fabrikam to configure ACS to trust issuers at partners such Adatum and Litware?
- Because Fabrikam does not have its own on-premises federation provider.
- Because Fabrikam uses ACS for all the claims-mapping rules that convert claims to a format that Fabrikam Shipping understands.
- Because partners such as Adatum have some users who use social identities as their primary method of authentication.
- Because a relying party such as Fabrikam Shipping can only use a single federation provider.
Answer: Only (a) and (b) are correct. In this scenario, Fabrikam decided to use ACS as its federation provider, so ACS holds all of its claims-mapping rules. - How does Fabrikam Shipping manage home realm discovery in the scenario described in this chapter?
- Fabrikam Shipping presents unauthenticated users with a list of federation partners to choose from.
- Fabrikam Shipping prompts unauthenticated users for their email addresses. It parses each address to determine which organization the user belongs to.
- ACS manages home realm discovery; Fabrikam Shipping does not.
- Each partner organization has its own landing page in Fabrikam Shipping. Visiting that page will automatically redirect unauthenticated users to that organization's identity provider.
Answer: Only (d) is correct. Although the sample application does have a page that displays a list of partners, this is just to simplify the use of the sample. In practice, each partner would use its own landing page that would redirect the use to ACS, passing the correct value in the whr parameter. - Enrolling a new partner without its own identity provider requires which of the following steps?
- Updating the list of registered partners stored by Fabrikam Shipping. This list includes the home realm of the partner.
- Adding a new identity provider to ACS.
- Adding a new relying party to ACS.
- Adding a new set of claims-mapping rules to ACS.
Answer: Only (a), (c) and (d) are correct. A partner without its own identity provider will use one of the pre-configured social identity providers in ACS. - Why does Fabrikam use a separate web application to handle the enrollment process?
- Because the expected usage patterns of the enrollment functionality are very different from the expected usage patterns of the main Fabrikam Shipping web site.
- Because using the enrollment functionality does not require a user to authenticate.
- Because the site that handles enrolling new partners must also act as a federation provider.
- Because the site that updates ACS with new relying parties and claims-mapping rules must have a different identity from sites that only read data from ACS.
Answer: Only (a) is correct. The number of new enrolments may be only one or two a day, while Fabrikam expects thousands of visits to the Shipping application. Using separate web sites enables Fabrikam to tune the two sites differently.
Chapter 8, Claims Enabling Web Services
- Which statements describe the difference between the way federated identity works for an active client as compared to a passive client:
- An active client uses HTTP redirects to ask each token issuer in turn to process a set of claims.
- A passive client receives HTTP redirects from a web application that redirect it to each issuer in turn to obtain a set of claims.
- An active client generates tokens to send to claims issuers.
- A passive client generates tokens to send to claims issuers.
Answer: Only (b) is correct. The relying party, federation provider, and identity provider communicate with each other through the client browser by using HTTP redirects that send the browser with any tokens to the next step in the process. - A difference in behavior between an active client and a passive client is:
- An active client visits the relying party first; a passive client visits the identity provider first.
- An active client does not need to visit a federation provider because it can perform any necessary claims transformations by itself.
- A passive client visits the relying party first; an active client visits the identity provider first.
- An active client must visit a federation provider first to determine the identity provider it should use. Passive clients rely on home realm discovery to determine the identity provider to use.
Answer: Only (c) is correct. A passive client visits the relying party first; the relying party redirects the client to an issuer. Active clients know how to obtain the necessary claims so they can visit the identity provider first. - The active scenario described in this chapter uses which protocol to handle the exchange of tokens between the various parties?
- WS-Trust
- WS-Transactions
- WS-Federation
- ADFS
Answer: Only (c) is correct. WS-Trust is the protocol that WIF and Windows Communication Foundation (WCF) use for active clients. - In the scenario described in this chapter, it's necessary to edit the client application's configuration file manually, because the Svcutil.exe tool only adds a binding for a single issuer. Why do you need to configure multiple issuers?
- The metadata from the relying party only includes details of the Adatum identity provider.
- The metadata from the relying party only includes details of the client application's identity provider.
- The metadata from the relying party only includes details of the client application's federation provider.
- The metadata from the relying party only includes details of the Adatum federation provider.
Answer: Only (c) is correct. The metadata from the relying party only includes details of the Adatum federation provider and the client application also needs the metadata from its identity provider. - The WCF service at Adatum performs authorization checks on the requests that it receives from client applications. How does it implement the checks?
- The WCF service uses the IsInRole method to verify that the caller is a member of the OrderTracker role.
- The Adatum federation provider transforms claims from other identity providers into Role type claims with a value of OrderTracker.
- The WCF service queries the Adatum federation provider to determine whether a user is in the OrderTracker role.
- It does not need to implement any authorization checks. The application automatically grants access to anyone who has successfully authenticated.
Answer: Only (a) and (b) are correct. The WCF service checks the role membership of the caller. The role value is created from the claims received from the federation provider.
Chapter 9, Securing REST Services
- In the scenario described in this chapter, which of the following statements best describes what happens the first time that the smart client application tries to use the RESTful a-Order web service?
- It connects first to the ACS instance, then to the Litware IP, and then to the a-Order web service.
- It connects first to the Litware IP, then to the ACS instance, and then to the a-Order web service.
- It connects first to the a-Order web service, then to the ACS instance, and then to the Litware IP.
- It connects first to the a-Order web service, then to the Litware IP, and then to the ACS instance.
Answer: Only (b) is correct. The Active client first obtains a SAML token from the Litware IP, it then sends the SAML token to ACS where it is transitioned to an SWT token, it then attaches the SWT token to the request that it sends to the web service. - In the scenario described in this chapter, which of the following tasks does ACS perform?
- ACS authenticates the user.
- ACS redirects the client application to the relying party.
- ACS transforms incoming claims to claims that the relying party will understand.
- ACS transitions the incoming token format from SAML to SWT.
Answer: Only (c) and (d) are correct. The only tasks that ACS performs in this scenario are claims transformation and claims transitioning. - In the scenario described in this chapter, the Web.config file in the a-Order web service does not contain a <microsoft.identity> section. Why?
- Because it configures a custom ServiceAuthorizationManager class to handle the incoming SWT token in code.
- Because it is not authenticating requests.
- Because it is not authorizing requests.
- Because it is using a routing table.
Answer: Only (a) is correct. The incoming tokens are handled by the custom SWTAuthorizationManager class that is instantiated in the CustomServiceHostFactory class. - ACS expects to receive bearer tokens. What does this suggest about the security of a solution that uses ACS?
- You do not need to use SSL to secure the connection between the client and the identity provider.
- You should use SSL to secure the connection between the client and the identity provider.
- The client application must use a password to authenticate with ACS.
- The use of bearer tokens has no security implications for your solution.
Answer: Only (b) is correct. A solution that uses bearer tokens is susceptible to man-in-the-middle attacks; using SSL mitigates this risk. - You should use a custom ClaimsAuthorizationManager class for which of the following tasks.
- To attach incoming claims to the IClaimsPrincipal object.
- To verify that the claims were issued by a trusted issuer.
- To query ACS and check that the current request is authorized.
- To implement custom rules that can authorize access to web service methods.
Answer: Only (d) is correct. The CheckAccess method in a custom ClaimsAuthorizationManager class has access to the IClaimsPrincipal object and URL associated with the current request. It can use this information to implement authorization rules.
Chapter 10, Accessing REST Services from a Windows Phone 7 Device
- Which of the following are issues in developing a claims-aware application that access a web service for the Windows Phone® 7 platform?
- It's not possible to implement a solution that uses SAML tokens on the phone.
- You cannot install custom SSL certificates on the phone.
- There is no secure storage on the phone.
- There is no implementation of WIF available for the phone.
Answer: Only (c) and (d) are correct. Because there is no secure storage on the phone, you cannot securely store any credentials on the phone; either the user enters his credentials whenever he uses the application, or you accept the risk of the phone being used by an unauthorized person who will be able to use any cached credentials. There is no version of WIF available for the phone, so you must manually implement any token handling that your application requires. - Why does the sample application use an embedded web browser control?
- To handle the passive federated authentication process.
- To handle the active federated authentication process.
- To access the RESTful web service.
- To enable the client application to use SSL.
Answer: Only (a) is correct. The embedded web browser control handles the passive federated authentication process, enabling redirects between ACS and the Litware IP. - 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?
- They both require the same number.
- The passive solution requires fewer than the active solution.
- The active solution requires fewer than the passive solution.
- It depends on the number of claims configured for the relying party in ACS.
Answer: Only (c) is correct. For the initial request to the web service, the active solution requires fewer round trips: the active solution first calls the Litware identity provider, then ACS, and finally the web service; the passive solution first calls ACS, the Litware identity provider, then goes back to ACS, and finally calls the web service. - Which of the following are advantages of the passive solution over the active solution?
- The passive solution can easily build a dynamic list of identity providers.
- It's simpler to create code to handle SWT tokens in the passive solution.
- It's simpler to create code to handle SAML tokens in the passive solution.
- Better performance.
Answer: Only (a) and (c) are correct. The passive solution can retrieve a list of configured identity providers from ACS to display to the user. In the passive solution, the embedded web browser manages the SAML token as part of the automatic redirects between the identity provider and the federation provider. - In the sample solution for this chapter, how does the Windows Phone 7 client application add the SWT token to the outgoing request?
- It uses a Windows Communication Foundation (WCF) behavior.
- It uses Rx to orchestrate the acquisition of the SWT token and add it to the header.
- It uses the embedded web browser control to add the header.
- It uses WIF.
Answer: Only (b) is correct. The sample solution makes extensive use of Rx to orchestrate asynchronous operations. Both the active and passive solutions use Rx to add the authorization header at the right time.
Chapter 11, Claims-Based Single Sign-On for Microsoft SharePoint 2010
- Which of the following roles can the embedded STS in SharePoint perform?
- Authenticating users.
- Issuing FedAuth tokens that contain the claims associated with a user.
- Requesting claims from an external STS such as ADFS.
- Requesting claims from Active Directory through Windows Authentication.
Answer: Only (b),(c) and (d) are correct. The embedded STS does not perform any authentication itself, but it can request that external token issuers such as ADFS or Windows Authentication issue tokens. The claims are then added to the user's FedAuth token. - Custom claim providers use claims augmentation to perform which function?
- Enhancing claims by verifying them against an external provider.
- Enhancing claims by adding additional metadata to them.
- Adding claims data to the identity information in the SPUser object if the SharePoint web application is in "legacy" authentication mode.
- Adding additional claims to the set of claims from the identity provider.
Answer: Only (d) is correct. Claims augmentation is the function of a custom claims provider that adds to the set of claims from an identity provider. - Which of the following statements about the FedAuth cookie in SharePoint are correct?
- The FedAuth cookie contains the user's claim data.
- Each SharePoint web application has its own FedAuth cookie.
- Each site collection has its own FedAuth cookie.
- The FedAuth cookie is always a persistent cookie.
Answer: Only (a) and (b) are correct. Each SharePoint web application has its own FedAuth token because you can configure each SharePoint web application to have a different token provider. By default, the FedAuth cookie is persistent, but you can configure it to be a session cookie. - In the scenario described in this chapter, why did Adatum choose to customize the people picker?
- Adatum wanted the people picker to resolve role and organization claims.
- Adatum wanted the people picker to resolve name and emailaddress claims from ADFS.
- Adatum wanted to use claims augmentation.
- Adatum wanted to make it easier for site administrators to set permissions reliably.
Answer: Only (a) and (d) are correct. Adatum wanted the people picker to correctly resolve role and organization claims so that site administrators could assign permissions based on these values. - In order to implement single sign-out behavior in SharePoint, which of the following changes did Adatum make?
- Adatum modified the standard signout.aspx page to send a wsignoutcleanup message to ADFS.
- Adatum uses the SessionAuthenticationModule SigningOut event to customize the standard sign-out process.
- Adatum added custom code to invalidate the FedAuth cookie.
- Adatum configured SharePoint to use a session-based FedAuth cookie.
Answer: Only (b) and (d) are correct. The relying party must send a wsignout message to its identity provider; the identity provider sends wsignoutcleanup messages to all of the currently logged-in relying parties. If the FedAuth cookie is session-based, SharePoint will automatically invalidate it.
Chapter 12, Federated Identity for SharePoint Applications
- In the scenario described in this chapter, Adatum prefers to maintain a single trust relationship between SharePoint and ADFS, and to maintain the trust relationships with the multiple partners in ADFS. Which of the following are valid reasons for adopting this model?
- It enables Adatum to collect audit data relating to external sign-ins from ADFS.
- It allows for the potential reuse of the trust relationships with partners in other Adatum applications.
- It allows Adatum to implement automatic home realm discovery.
- It makes it easier for Adatum to ensure that SharePoint receives a consistent set of claim types.
Answer: Only (a),(c) and (d) are correct. There is nothing in the model chosen by Adatum that specifically enables home realm discovery, though it may be easier to implement by customizing the pages in ADFS. It is easier for Adatum to manage the authentication and claims issuing in ADFS. - When must a SharePoint user reauthenticate with the claims issuer (ADFS in the Adatum scenario)?
- Whenever the user closes and then reopens the browser.
- Whenever the ADFS web SSO cookie expires.
- Whenever the SharePoint FedAuth cookie that contains the SAML token expires.
- Every ten minutes.
Answer: Only (a) and (c) are correct. Whether or not a user must re-authenticate after closing and re-opening the browser depends on whether the SAML token is stored in a persistent cookie; the Adatum single sign-out implementation requires session cookies to be enabled. The ADFS web SSO cookie determines when a user must reauthenticate with ADFS, not with SharePoint. The time period between authentications will depend on the lifetime of the SAML token as specified by ADFS and whether sliding sessions are in use. - Which of the following statements are true with regard to the Adatum sliding session implementation?
- SharePoint tries to renew the session cookie before it expires.
- SharePoint waits for the session cookie to expire and then creates a new one.
- When SharePoint renews the session cookie, it always requests a new SAML token from ADFS.
- SharePoint relies on sliding sessions in ADFS.
Answer: Only (a) and (c) are correct. SharePoint tries to renew the session cookie before it expires. If the cookie expires, then SharePoint will request a new SAML token from ADFS. - Where is the organization claim that SharePoint uses to authorize access to certain documents in the a-Portal web application generated?
- In the SharePoint STS.
- In the identity provider's STS; for example in the Litware issuer.
- In ADFS.
- Any of the above.
Answer: Only (c) is correct. The solution relies on ADFS to generate the organization claim. It's important not to rely on the partner's identity provider because a malicious administrator could spoof another partner's identity. - Why does Adatum rely on ADFS to perform home realm discovery?
- It's easier to implement in ADFS than in SharePoint.
- You can customize the list of identity providers for each SharePoint web application in ADFS.
- You cannot perform home realm discovery in SharePoint.
- You can configure ADFS to remember a user's choice of identity provider.
Answer: Only (a), (b), and (d) are correct. (a), (b), and (d) are all reasons for Adatum to implement home realm discovery in ADFS. It is possible to implement it SharePoint.