(0) exportieren Drucken
Alle erweitern
EN
Dieser Inhalt ist in Ihrer Sprache leider nicht verfügbar. Im Folgenden finden Sie die englische Version.

Federated Single Sign-On Simplifies Access to Microsoft Library Electronic Resources

Article

Published: June 2013

The following content may no longer reflect Microsoft’s current position or infrastructure. This content should be viewed as reference documentation only, to inform IT business decisions within your own company or organization.

Microsoft Information Technology (Microsoft IT) provides user authentication and authorization through Active Directory Federation Services (AD FS) federation trusts with external partners who are using Microsoft and non-Microsoft technology. Microsoft Library worked with Microsoft IT to offer internal users federated single sign-on (SSO) access to non-Microsoft electronic resources, in order to reduce the need for separate user names and passwords to these resources, and improve resource utilization metrics.

Download

Intended Audience Products & Technologies

Download Article, 147 KB, Microsoft Word file

Organizations and personnel implementing federated single sign-on for electronic resources and needing a general background and introduction to the technology. OR Librarians, Systems Librarians, and Active Directory Administrators.

  • Active Directory Federation Server

Introduction

Upwards of 21,000 unique users a month use the more than 200 non-Microsoft electronic resources—including research databases, journals, and market research from all over the world—hosted by the Microsoft Library website. Many of these resources require the user to create unique user names and passwords to access their online information.

Having to create and recall separate user names and passwords for each resource decreased user satisfaction and usage of these valuable resources. Moreover, in the new world of work, users expect the same access to these resources at any time, from anywhere (inside or outside of the corporate network), from any device.

Microsoft Library management also needed to collect business intelligence about employee usage of Library resources, such as unique users and downloads – information that traditional IP authentication could not provide.

Solution

Microsoft Library turned to federated single sign-on (SSO) as the solution to improve the user experience and the ability to gather usage metrics. Federated SSO is the exchange of user identity information between organizations through the transfer of trusted and verified metadata such as names, email addresses, and other unique identifiers. SSO allows the user to use a single ID and password, in this case their corporate network credentials, to login to electronic resources, even when off corpnet.

Microsoft IT provides SSO user authentication and authorization through Active Directory federation trusts with external partners who use a wide variety of federated SSO products – whether or not they are Microsoft products, as well as federation metadata intermediaries such as InCommon. Microsoft IT is able to work with resource providers using solutions other than AD FS by using the WS-Federation component of AD FS to implement federated SSO.

An additional challenge with IP authentication is the growing prevalence of IPv6. In addition to the current exhaustion of existing IPv4 addresses, IPv6 vastly increases the number of IP addresses that must be exchanged and maintained between Microsoft and resource partners, and requires additional management and network equipment upgrades for both parties. Using federation for authentication eliminates the need for IP authentication and the costs associated with transitioning to IPv6.

Overview of Federated SSO

Figure 1: The exchange of information to authenticate a user with Active Directory Federation Services

Figure 1: The exchange of information to authenticate a user with Active Directory Federation Services

Microsoft employees accessing the resources of federated partners do so without knowledge of the almost instantaneous exchange of information.

First, the employee points their browser the resource partner's web page. For this example we're using Contoso Research as the Resource Partner. Then (2), the federation server at Contoso Research matches the request to an account partner. This may be done automatically or by asking the user to identify their organization; in this case Microsoft. Next (3), the client's (employee) identity is authenticated by asking for their corporate network credentials and (4) the user is authenticated using a domain account in Active Directory. While there are alternatives for authenticating the client (forms-based login or a client certificate, for example) integrated authentication is recommended for many reasons, not the least of which is single-sign on for the user.

In Step 5, the federation server issues a SAML token containing a set of claims that the resource partner's federation server will understand. The token is serialized into the URL as the employee's browser is redirected to the resource party's federation server.

Note SAML == Security Assertion Markup Language. A token consists of XML that includes a set of claims, signed by the issuer of the token. The Resource Partner's federation server reads the SAML token, verifies that it was signed by a valid partner, and issues a cookie containing a SAML token signed by the federation server. This token will contain a subset of the claims received from the Account Partner's federation server. The client's browser is now redirected back to the original Web application the employee was trying to access in the first place.

Step 6 indicates the Web single-sign on agent reads the cookie, verifies the signature on the SAML token from the Microsoft's federation server, and makes the claims available to the Web application via a class called ‘SingleSignOnIdentity' (this class implements Identity and is available via the ‘HttpContext.User' and ‘Thread.CurrentPrincipal' properties). Finally (7), the user is now on the Contoso Research website as a signed in and recognized user.

For additional information about federation identity concepts, please see The .NET Developer's Guide to Identity.

For additional guidance on AD FS interoperability with other federation solutions, please see the AD FS 2.0 Step-by-Step and How To Guides.

For additional information about IPv6, see the IPv6 - Technology Overview.

Onboarding Process

Microsoft Library, in conjunction with Microsoft IT, created the following process for onboarding new Resource Partners:

  1. The Microsoft Library contract account managers work to identify which Resource Partners are technically ready to implement SSO. Microsoft Library then designates a program manager to collaborate with the contract managers and Microsoft IT, and identifies the proper technical contact at the vendor.
  2. Microsoft Library sends the Resource Partner technical contact an onboarding document with links to the Microsoft federation metadata, and requests the vendor's federation metadata and other needed information.
  3. A kickoff phone call occurs between Microsoft and the vendor, including the Microsoft Library account manager, Microsoft IT Identity and Access Management (IAM) contact, and vendor technical contact, in order to answer any questions.
  4. Microsoft IT and the Resource Partner create Pre-Production environments for testing purposes.
  5. When a vendor uses local accounts to secure its application, and the federation is a migration instead of a new implementation, the vendor sends a list of users to Microsoft IT so they can be reconciled against Microsoft's Active Directory user accounts. Account normalization happens by taking the vendors list of registered users and comparing their unique identifier for each user against the Microsoft AD record for each user. The process involves looking for and resolving discrepancies and ensuring that the unique identifier attributes match in the final list returned to the vendor. The Resource Partner then performs a final mapping on their end to ensure account continuity (bookmarks and saved alerts, for example) when Microsoft users begin to log on to the application with their federated corporate credentials.
  6. Microsoft Library coordinates user testing to ensure that saved account items, such as bookmarks and alerts, are still present in the federated access account. The testing includes various scenarios and access methods, such as on and off corpnet, mobile access, and apps.
  7. In preparation for federation, Microsoft Library identifies the sections of the website that will need updated links and messaging.
  8. The Resource Partner creates any needed redirects for previously bookmarked pages.
  9. Microsoft Library establishes customer service and escalation procedures for technical and other questions.
  10. The changeover to federated access occurs, usually after hours, with required messaging sent to registered users via email and a general announcement posted to relevant spots on the Library website.
  11. If IP authentication rules were in place to secure the application, the vendor removes these so Microsoft users can access resources when they are off the corporate network.

Best Practices

Planning considerations for implementing federated SSO include the following.

Map and preserve existing user accounts. If federating a resource partner where users have already created accounts and saved content like folders, bookmarks, and alerts, the non-Microsoft application provider should send a list of all active users to the federating party. You can use this list to normalize the vendor's accounts to Microsoft's user accounts. This process enables users to preserve any settings, favorites, and other customizations when they begin to use federated SSO.

Keep an issues and solutions log. This will assist with remembering problems unique to the application provider, as well as serve as a storehouse of issues (and their solutions) that other application federations may experience.

Simplify application migration with a standardized process. Create a checklist of all the steps involved in onboarding an application provider to a federated access model, and refer to it whenever you are implementing a new provider.

Establish scenario-based onboarding processes. Microsoft Library needed to consider federated access scenarios for on-corpnet, off-corpnet, mobile, and dedicated app experiences. Be sure to gather requirements and build scenarios for all licensed models of access and provision for them during the federation process.

Create custom error and access pages. Both Microsoft and the Resource Provider can do this when needed to help ensure an optimal user experience.

Establish post-launch customer support and escalation paths. Ensure that customer service channels have documented background information on the federated application providers, including how to troubleshoot and escalate possible technical issues that users encounter for each federated provider.

Conclusion

AD FS provides for implementation of federated single sign-on, with non-Microsoft application providers using a wide variety of federated SSO solutions. For Microsoft Library, the transition of existing user accounts to federated accounts has been seamless. Microsoft employees who have used Microsoft Library services appreciate the improved user experience, for both on-corpnet and off-corpnet scenarios. And Microsoft Library management can obtain metrics that provide better insight into resource usage.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

© 2013 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft