Step-by-Step Guide: Federated
Collaboration with Shibboleth 2.0 and
SharePoint 2010 technologies
Microsoft France
Published: December 2010
Version: 1.0
Authors: Jean-Marie Thia (UPMC), Philippe Beraud (Microsoft France), Benjamin Guinebertière
(Microsoft France), Stéphane Goudeau (Microsoft France)
Copyright
© 2010 Microsoft Corporation. All right reserved.
Abstract
Through its native support for Claims Authentication and the WS-Federation protocol, Microsoft
SharePoint 2010 allows interoperability with major IDA market solutions. Through its support for the
WS-Federation and Security Assertion Markup Language (SAML) 2.0 protocols along with its ability to
act as a protocol bridge, Microsoft Active Directory Federation Services 2.0 (AD FS 2.0) provides
claims-based, cross-domain Web Single Sign-On (SSO) interoperability with non-Microsoft federation
solutions. Internet2 Shibboleth 2, through its support for SAML 2.0, enables cross-domain federated
SSO between environments that are running Microsoft and Internet2 federation infrastructures.
Building on existing documentation from both companies, this step-by-step guide walks you through
the setup of a basic lab deployment of Shibboleth 2, AD FS 2.0 and SharePoint 2010 that performs
cross-product, browser-based, federated collaboration. This document is intended for developers and
system architects who are interested in understanding the basic modes of interoperability between
Shibboleth 2, AD FS 2.0 and SharePoint 2010.
This document is provided “as-is”. Information and views expressed in this document, including URL
and other Internet Web site references, may change without notice. You bear the risk of using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real
association or connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any
Microsoft product. You may copy and use this document for your internal, reference purposes. You
may modify this document for your internal, reference purposes.
© 2010 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Internet Explorer, SQL Server, Windows, Windows PowerShell, and
Windows Server are trademarks of the Microsoft group of companies. All other trademarks are
property of their respective owners
Content
1
INTRODUCTION ........................................................................................................................1
1.1
OBJECTIVES OF THIS GUIDE ................................................................................................1
1.2
ORGANIZATION OF THIS GUIDE ............................................................................................1
1.3
ABOUT THIS GUIDE .............................................................................................................2
1.4
ABOUT THE AUDIENCE ........................................................................................................2
1.5
ABOUT THE LIVE DEMO AT THE MTC PARIS .........................................................................3
1.6
TERMINOLOGY USED IN THIS GUIDE .....................................................................................4
2
SHIBBOLETH 2 SYSTEM..........................................................................................................5
2.1
LOGICAL ARCHITECTURE OF THE SYSTEM COMPONENTS ......................................................6
2.2
INTERACTION PRINCIPLES AND ASSOCIATED PROFILES .........................................................8
2.3
FEDERATION METADATA DEFINED .................................................................................... 10
3
SHAREPOINT 2010 PLATFORM ........................................................................................... 12
3.1
A BRIEF OVERVIEW OF SHAREPOINT 2010 ....................................................................... 12
3.2
OFFICE W EB APPS COMPANION....................................................................................... 13
3.3
OVERVIEW OF AUTHENTICATION IN SHAREPOINT 2010 ..................................................... 14
3.4
FEDERATED SHAREPOINT 2010 SAML-CLAIMS AUTHENTICATION WITH THE SAML 2.0
PROTOCOL ................................................................................................................................. 19
4
ABOUT THE TESTING ENVIRONMENT ............................................................................... 23
4.1
PREPARE THE VIRTUAL MACHINES ................................................................................... 23
4.2
PERFORM THE PRECONFIGURATION TASKS....................................................................... 24
5
CONFIGURE SHIBBOLETH 2 AS A CLAIMS PROVIDER FOR AD FS 2.0 ......................... 27
5.1
PREREQUISITES AND REQUIREMENTS .............................................................................. 27
5.2
INSTALL SHIBBOLETH 2 ................................................................................................... 28
5.3
CONFIGURE SERVLET CONTAINER FOR SSL AND SHIBBOLETH.......................................... 28
5.4
CONFIGURE SHIBBOLETH 2 ............................................................................................. 29
5.5
CONFIGURE AD FS 2.0 .................................................................................................. 43
5.6
TEST SHIBBOLETH AS THE IDENTITY PROVIDER AND AD FS 2.0 AS THE RELYING PARTY .... 46
5.7
OTHER ISSUES? ............................................................................................................. 47
6
CONFIGURE SHAREPOINT 2010 AS A RELYING PARTY FOR AD FS 2.0 ....................... 48
6.1
PREREQUISITES AND REQUIREMENTS .............................................................................. 48
6.2
CONFIGURE SHAREPOINT 2010 AS RELYING PARTY IN AD FS 2.0 .................................... 48
6.3
CREATE A SHAREPOINT 2010 W EB APPLICATION ............................................................. 61
6.4
CREATE A TRUSTED IDENTITY PROVIDER CORRESPONDING TO THE AD FS 2.0 INSTANCE .. 63
6.5
DECLARE THE TRUSTED IDENTITY PROVIDER FOR THE W EB APPLICATION.......................... 65
6.6
TEST THE W EB APPLICATION AS A CORPORATE USER....................................................... 67
6.7
TEST THE W EB APPLICATION AS A SHIBBOLETH EXTERNAL USER ....................................... 69
6.8
USE OFFICE 2010 WITH THE W EB APPLICATION A SHIBBOLETH EXTERNAL USER ................ 71
APPENDIX A. USE AD FS 2.0 IN THE RENATER FEDERATION................................................. 81
APPENDIX B. OTHER POSSIBILITIES OUTSIDE THE SCOPE OF THIS GUIDE ....................... 84
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
i
1 Introduction
1.1 Objectives of this guide
Through its newly introduced support for the WS-Federation protocol, the Microsoft SharePoint
2010 platform enables interoperability with Web single sign-on (SSO) and federation solutions.
With the support of both the WS-Federation and Security Assertion Markup Language (SAML) 2.01
protocols, Microsoft Active Directory Federation Services 2.0 (AD FS) 2.0 provides claims-based,
cross-domain, Web single sign-on (SSO) interoperability with non-Microsoft federation solutions.
Furthermore, Shibboleth 2, through its support for SAML 2.0, enables cross-domain, federated
SSO between environments that are running Microsoft and Shibboleth 2 federation infrastructures.
On that basis, after a short introduction of the aforementioned technologies and platforms, this
guide walks you through the setup of a SharePoint 2010-based basic federated document
collaboration between organizations via Shibboleth 2 and AD FS 2.0 that performs cross-product,
browser-based identity federation.
In this guide, Shibboleth 2 product performs the Claims Provider/Identity Provider role (see section
§ 1.6 TERMINOLOGY USED IN THIS GUIDE) on top of SAML 2.0 protocol (with the SAML 2.0 HTTP
POST binding) whereas AD FS 2.0 performs the Relying Party/Service Provider role vis-à-vis
Shibboleth on top of SAML 2.0 protocol and the Claims Provider role vis-à-vis SharePoint 2010 on
top of WS-Federation protocol and while finally SharePoint 2010 performs the Relying Party role on
top of WS-Federation.
In other words, AD FS 2.0 acts as a protocol gateway between Shibboleth 2 and SharePoint 2010.
In addition, this guide provides additional details in Appendix A about the steps that are necessary
for/the considerations related to interoperability between AD FS 2.0 and the Education-Recherche
RENATER Federation2, in which Shibboleth (1.3 and 2) software is used. We expect that
interoperability with other federations in the Research and Education sector would be achieved
similarly.
1.2 Organization of this guide
To cover the whole set of considerations relating to the implementation of federated collaboration
with the SharePoint 2010 technologies in the context of a Shibboleth 2-based Identity Provider, this
document adopts an organization according to the following themes, each of them being addressed
as part of an eponymous section:

SHIBBOLETH 2 SYSTEM;

SHAREPOINT 2010 PLATFORM;

ABOUT THE TESTING ENVIRONMENT;

CONFIGURE SHIBBOLETH 2 AS A CLAIMS PROVIDER FOR AD FS 2.0;

CONFIGURE SHAREPOINT 2010 AS A RELYING PARTY FOR AD FS 2.0.
Finally, references provided in the appendixes enable to easily search the Web for additional
information.
1
Security Assertion Markup Language (SAML) 2.0: http://go.microsoft.com/fwlink/?LinkId=193996
2
Education-Recherche RENATER Federation: https://federation.renater.fr/
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
1
1.3 About this guide
This guide has been developed in collaboration with the French
University Pierre and Marie Curie (UPMC) in Paris and, more specifically Jean-Marie Thia.
More than one year ago, Jean-Marie Thia announced the release of shib4moss 1.0 (Shibboleth for
SharePoint 2007). This starter kit developed in partnership with Microsoft France allows a
SharePoint 2007 Web site to use the Shibboleth Service Provider (SP) software package (see
Shibboleth download site3) for Microsoft Internet Information Services (IIS) as an authentication
provider and Shibboleth attributes for authorization.
The project is hosted at https://sourcesup.cru.fr/projects/shib4net, the subversion repository is in
the shib4moss subproject. There is also a zip file4 with the source code, help files and
documentation in French and partially in English (installation documentation).
This guide, as its title indicates, aims at describing how to expose a SharePoint 2010 Web site to a
Shibboleth-based federation. This time, the SharePoint application is exposed via its native
federation capabilities (along with the AD FS 2.0 protocol gateway).
In many ways, this guide can be seen as the counterpart of the aforementioned shib4moss 1.0
project/starter kit for SharePoint 2010.
Building on existing documentations, this step-by-step guide walks you through the setup of a basic
lab deployment of Shibboleth 2.0, SharePoint 2010, and AD FS 2.0 that performs cross-product,
browser-based federated collaboration.
Microsoft has recently published, thanks to author Dave Martinez, the AD FS 2.0 STEP-BY-STEP
GUIDE: FEDERATION WITH SHIBBOLETH 2 AND THE INCOMMON FEDERATION5 in a series of step-by-step
guides6 on configuring AD FS 2.0 to interoperate with partner products. This guide describes how
to configure AD FS 2.0 and Shibboleth to federate using the SAML 2.0 protocol with the SAML2.0
HTTP POST binding. The current guide leverages some of the information contain in this guide.
This guide also leverages the weblog Share-n-dipity7 from the Microsoft employee Steve Peschka
and the various really good posts that are published on it. Thanks again to Steve Peschka. This
guide especially leverages the post CONFIGURING SHAREPOINT 2010 AND ADFS V2 END TO END8. It
also refers whenever relevant in the context to other posts from this weblog.
1.4 About the audience
(Federated) Identity (and delegation) in SharePoint 2010 technologies is a broad topic, with many
facets and depths of understanding. This paper addresses this topic only from the federated
collaboration perspective and from both conceptual and technical levels.
More especially, this document covers the SharePoint 2010 federated collaboration scenario in the
context of Shibboleth-based federation. This scenario is covered in detail, including a configuration
checklist and step by step instructions to help you successfully configure such a scenario in your
environment.
3
Shibboleth download site: http://go.microsoft.com/fwlink/?LinkId=204016
4
Shib4moss project package: https://sourcesup.cru.fr/frs/download.php/2625/Shib4MOSS.zip
5
AD FS 2.0 STEP-BY-STEP GUIDE: FEDERATION WITH SHIBBOLETH 2 AND THE INCOMMON FEDERATION:
http://go.microsoft.com/fwlink/?LinkId=204784
6
AD FS 2.0 Step-by-Step and How To guides: http://technet.microsoft.com/en-us/library/dd727938(WS.10).aspx
7
Weblog Share-n-dipity: http://blogs.technet.com/b/speschka/
8
CONFIGURING SHAREPOINT 2010 AND ADFS V2 END TO END:
http://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx
2
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
This document is intended for developers and system architects who are interested in
understanding the basic modes of interoperability between Shibboleth 2 and SharePoint 2010 and
who would like to get a deeper view on ADFS 2.0 capacities.
1.5 About the live demo at the MTC Paris
Microsoft Technology Centers9 (MTC) are
collaborative environments that provide access to innovative technologies and world-class
expertise, enabling our customers and partners to envision, design, and deploy solutions that meet
their needs.
Since 2004, MTC Paris, is part of these global centers designed to provide our customers with an
actionable set of steps on how a Microsoft solution can assist them in achieving their key business
objectives. Inside this facility, MTC architects and Microsoft technologies Experts, through a
discovery process and scenario-based demonstrations running in MTC datacenter, play a critical
role in addressing our customers’ challenges.
Interestingly enough, MTC Paris is hosting and running Microsoft France Interop Lab in order to
allow customers to see and understand how Microsoft solutions and action can interoperate with
other technologies or products around several topics such as : advanced Web services, PHP,
Java, SAP, application lifecycle management and last but not least security & identity.
In this lab, customers and partners test multi-vendor technical configurations in order to adapt
solutions to their needs in terms of operational interoperability. MTC Paris hosts more than 20
competing players’ solutions. These solutions are deployed on MTC Paris datacenter infrastructure
which is built upon more than 300 servers and 200 terabytes storage. Working with many
competing publishers, we facilitate the integration of heterogeneous systems. Thus interoperability
becomes a guarantee of integration for our customers and enables them to create value by
maximizing the investment in innovation.
In order to ensure both identity portability and security in a loosely coupled environment, it is
fundamental to master the identity management part in each involved security realm for the
considered scenario. As aforementioned, the Microsoft platform natively offers a series of products
and technologies to sustain the notion of claim-based identity: ready to use enterprise-class Claims
Provider Security Token Service (STS), Framework for building claims-aware applications and
services (including authentication, access control, auditing, etc.), etc. In “real world” heterogeneous
environments, these components haven’t no choice rather than being truly interoperable.
To illustrate this interoperability, the MTC Paris Security and Identity Management Interop Lab
proposes a permanent dedicated platform offering multiple identity management scenarios, and
more especially the one describes in this paper, i.e. the federated collaboration scenario based on
SharePoint 2010, Outlook Web Access 2010/Exchange 2010 from within Shibboleth communities.
Beyond it, in terms of technology integration, it also features the Azure platform Access Control
Service (ACS) 2.0.
ACS is a resource STS in the cloud to handle authentication and help with authorization). ACS
directly authenticates simple clients using a symmetric key (similar to the familiar user name and
password), brokers authentication for enterprise clients that use ADFS 2.0, and also offers a cloudbased identity management framework for all types of clients, applications, and services. For
example it accepts security tokens from many other identity frameworks such as Facebook, Google
Accounts, Windows Live ID, and others. Finally, ACS provides basic identity services for RESTful
Web services.
9
Microsoft Technology Centers: http://microsoft.com/mtc
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
3
1.6 Terminology used in this guide
Throughout the rest of this document, there are numerous references to federation concepts that
are called by different names in the Microsoft and Internet2 products and/or technologies. The
following table assists in drawing parallels between the two.
Concept
Microsoft name
Shibboleth name
XML document describing a user sent
during an access request from the
federation party that is handling users to
the federation party that is managing an
application
Security Token
Assertion
Partner in a federation that creates security
tokens for users
Claims Provider
Identity Provider
Partner in a federation that consumes
security tokens for providing access to
applications
Relying Party
Service Provider
Data about users that is sent inside
security tokens
Claims
Assertion attributes
In this guide, Shibboleth 2 software performs Claims Provider/Identity Provider role, AD FS 2.0
both the Claims Provider/Identity Provider role and the Relying Party/Service Provider role, and
finally SharePoint 2010 the Relying Party/Service Provider role.
4
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
2 Shibboleth 2 System
This section quickly describes the Shibboleth system so that it is
simpler to understand how SharePoint 2.0 can be exposed in a Shibboleth identity federation from
a technology perspective, as well a protocol perspective with SAML 2.0.
Shibboleth (, as a reference to the Hebrew word "shibbóleth” and the related Biblical use, i.e. to
discover hiding members of the opposing group,) was designed to fill higher education needs in
terms of identity federation and attributes propagation for a number of partners. The Shibboleth
project was initiated by the Internet2/MACE (Middleware Architecture Committee for Education) 10.
The project (http://shibboleth.internet2.edu) refers to both a specification and an open source
project that implements them as a distributed system.
As a specification, Shibboleth is an extension of the SAML (Security Assertion Markup Language)
1.1 standard which comes from the OASIS Security Services (SAML) TC11; this technical
committee defined a protocol to exchange security information in order to implement Web Single
Sign-On.
SAML 1.1 standard defines 2 main components in a federated environment:
1. Service provider (SP) - The service provider, or SP as we call it in the rest of the
document, provides (or does not provide) Web resources depending on the trusted user
attributes it received in order to feed it access control;
2. Identity Provider (IdP) - The identity provider, or IdP as stated in the rest of the document,
is in charge of authenticating users and providing attributes based on that authentication.
SAML 1.1 profiles assume the user starts with the IdP. In order to take into account scenarios
where a user first connects to an SP, Shibboleth extended the SAML browser/POST and
browser/Artifact profiles.
For that, Shibboleth:
1. Defines the notion of an authentication request which allows an SP to require some
authentication from a browser
2. Introduces the notion of WAYF (Where Are You From?) which allows a browser to select
its IdP.
In other terms, the WAYF service is an optional service that can redirect a user towards a
security domain where his identity is declared as an account, and more precisely towards
an IdP of this security domain.
3. Also specifies how attributes exchanges take place (this is not the case in SAML 1.1).
Beyond these elements, which are available as part of Shibboleth 1.x system as SAML 1.1
extensions, version 2.x of Shibboleth12 provides SAML 2.0 support as well backward compatibility
with Shibboleth 1.x.
10
Internet2/MACE (Middleware Architecture Committee for Education): http://middleware.internet2.edu/MACE
11
OASIS Security Services (SAML) TC: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
12
Shibboleth 2.0: http://shibboleth.internet2.edu/shib-v2.0.html
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
5
2.1 Logical architecture of the system components
This description of the components as well as the interaction between them is how the authors of
this document see the system provided by the Internet2’s Shibboleth project.
The
SHIBBOLETH
ARCHITECTURE
TECHNICAL
OVERVIEW
document,
available
at
http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-overview-latest.pdf, describes the
system and precisely defines the Shibboleth project terminology. While the document is about the
version 1.x of Shibboleth, the main elements are still valid in the context of Shibboleth 2.x, which
this guide is about.
In the context of a French speaking community, as well as for planning considerations in your
specific environment, you are encouraged to read resources made available in the context of the
Education & Research federation (fédération Education-Recherche13), a service provided by “GIP
RENATER”. Those resources are available
online at the following address:
https://federation.renater.fr/. As a first step, you can read the document called FÉDÉRATION
D’IDENTITÉS ET PROPAGATION D’ATTRIBUTS AVEC SHIBBOLETH (Identity federation and attributes
propagation with shibboleth).
2.1.1 Service Provider (SP)
From an architecture perspective, an SP is made of the 3 following parts:
1. Assertion Consumer Service - this is the endpoint of the SP dedicated to the SSO part of
the protocol. It behaves like a Web filter and redirects an unauthenticated user to his IdP
(this may be done in conjunction with the WAYF service if it’s been implemented14) so that
he can authenticate. Depending on the protocol profile, the assertion consumer service
may either receive SAML assertions and optionally get additional attributes from the IdP, or
receive a user artifact (a SAML artifact is a reference to a SAML assertion) and get user
assertion and attributes from the IdP. It eventually redirects the client to the requested
application resource. The collected attributes are transmitted to an access controller which
decides whether or not the applicative resource may be accessed.
2. Attribute Requester - Based on a user artifact (used in some protocol profiles) this
component is in charge of getting the user attributes from the IdP. This happens directly,
without using the browser through redirections.
3. Access control - This component, as its name suggests it, is in charge of allowing or
denying access to the applicative resource.
6
13
Education-Recherche Renater federation: https://federation.renater.fr/
14
An SP may declare 0 or 1 WAYF service in the Shibboleth system.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
Identity Provider
2) GET/302
3ter) POST/200
WAYF
3bis) POST/200
1bis) GET/302
Client
3) POST/302
Assertion
Consumer
Service
Attribute
Requester
Access control
Application
Resources
4) GET/200
1) GET/302
Service Provider (SP)
Internet2 Shibboleth 2
2.1.2 Identity Provider (IdP)
On the other side, an IdP is composed of three elements:
1. Authentication/SSO Service: this service is in charge of authenticating a user who has
been redirected to the IdP.
This is not an inner part of the IdP, but an IdP would be useless without a component that
authenticates the user. This service must send to the IdP, more specifically the
Authentication Authority a unique identifier for the user. This unique identifier will then be
used to prepare and generate the user’s attributes. In practice, any mechanism (this
includes the protocol and the users data source) available for web authentication may be
used. This may be a Web SSO authentication system.
Indeed, integrating with the CAS (Central Authentication
Service)15 Web SSO service that was developed by Yale University is quite common
among Universities in France. CAS is commonly used to only perform authentication and
web single sign on. Document FÉDÉRATION D’IDENTITÉS ET PROPAGATION D’ATTRIBUTS AVEC
SHIBBOLETH also describes how Shibboleth IdP and CAS Web SSO can be brought
together as a consistent solution. Further details about this are outside the scope of this
guide which concentrates on how SharePoint 2010 can be a SP for a Shibboleth identity
federation.
2. Authentication Authority: This authority is in charge of associating the name identifier
artifact (an opaque identifier) with the preceding user unique identifier ;
3. Attribute Authority: This authority is the one which responds to SP invocations through a
Web service; those invocations provide a user name identifier and expect the
corresponding user attributes. The relationship between a user name identifier and the
15
Service CAS (Client Authentication Service): http://www.yale.edu/tp/auth
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
7
user attributes is maintained by the authentication authority. Different data sources (LDAP
directory, SQL data bases, etc.) can be used as a user repository. The Shibboleth
implementation is able to handle several data sources at once.
4. Artifact Resolution Service: This service responds to a SP invocations through Web
services, in relationship with the translation of a user artifact into an authentication
assertion.
Identity Provider (IdP)
Internet2 Shibboleth 2
Authentication
Authority
Attribute
Auhtority
SSO
Service
Artifact
Resolution
Service
2) GET/302
1bis) GET/302
WAYF
3ter) POST/200
Client
3bis) POST/200
3) POST/302
4) GET/200
1) GET/302
Service Provider
The Shibboleth IdP technical implementation is a Java application that requires a Java EE servlet
container such as Tomcat. Apache web server may also be used in front of Tomcat.
2.2 Interaction principles and associated profiles
2.2.1 Profiles that come from SAML 1.1
In Shibboleth, like in SAML 1.1, browser/POST and browser/Artifact profiles differ from one another
by the way the authentication assertion is sent.
A Shibboleth authentication assertion is a message which is encoded in a URL, then sent to the
IdP authentication service (cf. section § 2.1.2 IDENTITY PROVIDER (IDP)). It contains the SP identifier
(providerId), the URL of IdP’s authentication service (cf. section § 0 THIS DESCRIPTION OF THE
components as well as the interaction between them is how the authors of this document see the
system provided by the Internet2’s Shibboleth project.
The
SHIBBOLETH
ARCHITECTURE
TECHNICAL
OVERVIEW
document,
available
at
http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-overview-latest.pdf, describes the
system and precisely defines the Shibboleth project terminology. While the document is about the
version 1.x of Shibboleth, the main elements are still valid in the context of Shibboleth 2.x, which
this guide is about.
In the context of a French speaking community, as well as for planning considerations in your
specific environment, you are encouraged to read resources made available in the context of the
Education & Research federation (fédération Education-Recherche), a service provided by “GIP
8
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
RENATER”. Those resources are available
online at the following address:
https://federation.renater.fr/. As a first step, you can read the document called FÉDÉRATION
D’IDENTITÉS ET PROPAGATION D’ATTRIBUTS AVEC SHIBBOLETH (Identity federation and attributes
propagation with shibboleth).
Service Provider (SP)), the return address to the SP (target), and the epoch request issuance date.
Beyond what was described in section § 2.1.2 IDENTITY PROVIDER (IDP), Shibboleth standard
precisely describes how such a request is handled.
2.2.1.1 Browser/POST profile
It extends the corresponding SAML 1.1 profile.
Step(s)
Flow description
1
Browser queries a page which is protected by the SP
2
SP redirects the browser to the WAYF service (with the Shibboleth authentication request
parameters)
3
Browser queries the WAYF service with those parameters
4
The WAYF service sends back an HTML form (the authentication request parameters are the
hidden fields inside the HTML form)
5
User selects an IdP in the list, the browser sends a GET request to the WAYF service
6
The WAYF service redirects the browser to the IdP, providing it with a URL that contains the
authentication request parameters
7
The browser queries the IdP with this URL. The IdP delegates the user authentication to the
authentication service
8
IdP sends an HTML form to the browser that contains the SAML response, including the
authentication assertion
9
The browser sends the form to the SP, either manually (user action), either automatically
(with JavaScript)
10
SP computes the authentication assertion, creates a security context and sends a SOAP
SAML message to the IdP that requests user attributes
11
IdP handles this requests and sends back a SOAP response with an attributes assertion
12
SP filters the attributes, updates the security context and redirects the browser to the page
that was initially requested by the browser
13
The browser requests the page
14
The SP sends back the page
2.2.1.2 Browser/Artifact profile
It extends the corresponding SAML 1.1 profile. The attributes are provided in an attributes
assertion together with the authentication assertion. As these are two different assertions, two
artifacts are used instead of one.
Step(s)
Flow description
1
Browser queries a page which is protected by the SP
2
SP redirects the browser to the WAYF service (with the Shibboleth authentication request
parameters)
3
Browser queries the WAYF service with those parameters
4
The WAYF service sends back an HTML form (the authentication request parameters are the
hidden fields inside the HTML form)
5
User selects an IdP in the list, the browser sends a GET request to the WAYF service
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
9
Step(s)
Flow description
6
The WAYF service redirects the browser to the IdP, providing it with a URL that contains the
authentication request parameters
7
The browser queries the IdP with this URL. The IdP delegates the user authentication to the
authentication service
8
IdP redirects the browser to the SP’s assertion consumer service. Two artifacts are
appended to the redirection URL, one for authentication, the other one for attributes
9
Browser queries the SP’s assertion consumer service
10
The SP handles the request and sends to the IdP a SAML request that contains the two
artifacts (as a SOAP HTTP POST request)
11
IdP responds by sending the two requested assertions back to the SP
12
SP filters the attributes, updates the security context and redirects the browser to the page
that was initially requested by the browser
13
The browser requests the page
14
The SP sends back the page
2.2.2 Defined profiles in SAML 2.0
SAML 2.016 defines an important number of profiles; the one we are mostly interested in is the Web
Browser SSO profile.
It is similar to the initial browser/artifact and browser/POST Shibboleth profiles because the
sequence starts with the SP.
The way IdP is selected (WAYF is an example) is not defined. Initial redirection from the SP to the
IdP is not only possible through an HTTP redirect but also through an HTTP POST or a binding
called HTTP artifact (it is based on HTTP redirects and SOAP message exchanges through HTTP).
The authentication assertion is sent either through HTTP POST, either through the HTTP Artifact
binding.
2.3 Federation metadata defined
With the Shibboleth system, the different trust relationships between the members of a federation
are implemented as (federation) metadata. They are the foundation of a federation trust.
16
10
Security Assertion Markup Language (SAML) 2.0: http://go.microsoft.com/fwlink/?LinkId=193996
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
In order for an SP to be recognized by an IdP federation, it must be listed in the federation
metadata. Similarly, in order for an IdP to be recognized by the SP inside the federation, it must be
listed in the federation metadata. A Shibboleth SP may recognize only a subset of the IdP inside
the federation, by defining a white list. Besides, for local needs, an IdP and an SP may trust each
other, by exchanging their metadata files.
The Shibboleth 2.x technical implementation automatically publishes its metadata at the following
URL: http(s)://<fqdn serveur>/Shibboleth.sso/Metadata. This URL can be used for mutual trust
relationships with an IdP or to register inside a federation.
Each provider’s metadata contains the provider’s unique identifier (entityID attribute) as a URN
(Uniform Resource Name, Cf. RFC 2141 URN Syntax17), organizational and technical contact
addresses, the name of the certificate this provider uses, the certificate authority URL and the
attributes authority URL (for attribute requests) for an IdP, or the assertion consumer service URL
(to receive attrbutes) for an SP.
Metadata also include certificate authorities (CA) which emit certificates that are trusted inside the
federation.
For further information, Internet2 documentation about metadata
NativeSPMetadataProvider
page
https://spaces.internet2.edu/display/SHIB2/NativeSPMetadataProvider.
is
available
in
the
at
Those metadata are usually expressed as an XML file. In order to ensure its integrity, this file is
usually digitally signed. In a production federation, recording a new provider or updating information
about an existing provider goes through a process that ensures the request is valid and legitimate.
In a federation, the XML file is managed centrally and it is used by all the IdP and SP inside the
federation to mutually trust themselves.
As far as the Renater federation is concerned, the test fedaration metadata are available at
https://services-federation.renater.fr/metadata/renater-test-metadata.xml while the education &
research
federation
metadata
are
available
at
https://servicesfederation.renater.fr/metadata/renater-metadata.xml. These URL are available in the following
Renater federation Web site18.
17
RFC 2141 URN syntax: http://tools.ietf.org/html/rfc2141
18
Renater federation metadata: https://federation.renater.fr/technique/metadata
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
11
3 SharePoint 2010 Platform
This chapter briefly introduces the different products and technologies which are related to
Microsoft SharePoint 2010, which constitutes the main topic of this white paper.
Beyond what will be explained here, the following guides may be read in order to evaluate
SharePoint 2010 efficiently as a development platform:

MICROSOFT SHAREPOINT 2010 IT PROFESSIONAL EVALUATION GUIDE19

SHAREPOINT 2010: PROFESSIONAL DEVELOPER EVALUATION GUIDE AND W ALKTHROUGHS20
Their goals are to help you discover the different features of SharePoint 2010.
For further information, one can go to the Microsoft SharePoint web site21.
3.1 A brief overview of SharePoint 2010
SharePoint 2010 is a Web product that helps users access their information, wherever they are.
Integrated document management and list features that users already know were extended in
several ways so that new usage scenarios become easy. Enhancements in the domain of data
allow better list management, better validations and offer connectivity to the line of business
systems.
SharePoint 2010 is a natural portal for line of business applications (LOB) data. LOB are a
fundamental need for any organization; the same is true for front end systems that help accessing
central LOB systems which host the core business capabilities. Traditional LOB applications
usually have core business users who are well trained to use the application, and a wider set of
users who only use the application occasionally. SharePoint 2010 integration with core LOB
systems through BCS (Business Connectivity Services) makes SharePoint 2010 a means of choice
to help access core LOB systems data.
More generally, SharePoint 2010 has six ready to use core capabilities:
1. Sites - Enables storage and retrieval of information in lists and document libraries in an
easy way which is also integrated with Microsoft Office applications.
2. Communities - Helps locating and interacting with people through expertise, relationship,
content tagging and rating;
3. Content - Helps managing content which can be a web page, a document or a set of
documents; This includes records management for that content;
4. Search - Enables searching content from within SharePoint and outside SharePoint,
including content in structured databases;
5. Insights - Leverages Microsoft Office Excel to access data and show them on a web page;
data can be presented as pivot tables and key performance indicators (KPI) in order to let
raw data be manageable.
6. Composites - Helps information workers create their own solutions by leveraging
connectivity and usage of core platform features.
Further detailed information about those capabilities is available in the MICROSOFT SHAREPOINT
2010 IT PROFESSIONAL EVALUATION GUIDE that was mentioned above.
19
MICROSOFT SHAREPOINT 2010 IT PROFESSIONAL EVALUATION GUIDE: http://go.microsoft.com/fwlink/?linkid=167123
20
SHAREPOINT 2010: PROFESSIONAL DEVELOPER EVALUATION GUIDE AND WALKTHROUGHS:
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=cffb14e8-88a9-43bd-87aa-4792ab60d320
21
12
Microsoft SharePoint Web site: http://SharePoint.Microsoft.com
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
Different editions of SharePoint 2010 are available: Foundation, Standard and Enterprise. These
editions can be compared in a table available on SharePoint Web Site22. Microsoft SharePoint
Foundation 2010 is available from the Microsoft download center23.
In terms of configuration, such a platform requires a server environment that has the right
capacities to host it. It is worth noting that SharePoint 2010 is only available as 64-bit software, and
thus, a consequence is that the Windows operating system (either client or server) that hosts it
must also be a 64-bit version.
The minimal system requirements for a SharePoint 2010 platform are the followings:

Microsoft Windows Server 2008 64-bit with Service Pack 2 (SP2) or above, or Windows
Server 2008 R2;
-or-

Microsoft Windows Vista 64-bit with Service Pack 1 (SP1) or above, or Microsoft Windows
7 64-bit for development environments;

Microsoft SQL Server 2005 64-bit with Service Pack 2 (SP2) or above, or Microsoft SQL
Server 2008 64-bit;

Microsoft .NET Framework 3.5 with Service Pack 1 (SP1) installed.
A first browser support level allows the following browsers on Windows operating system:

Windows Internet Explorer 7 32-bit;

Internet Explorer 8 32-bit;

Firefox 3.x 32-bit.
And for the second level:

Internet Explorer 7 64-bit;

Internet Explorer 8 64-bit;

Firefox 3.x (on Windows operating systems);

Safari 3.x (on Windows operating systems).
For a complete list of Hardware and software requirements, SharePoint 2010 documentation on the
TechNet site has the following page: HARDWARE AND SOFTWARE REQUIREMENTS (SHAREPOINT
SERVER 2010)24.
3.2 Office Web Apps companion
Office Web Apps is the online companion to Office Word 2010, Excel 2010, PowerPoint 2010 and
OneNote 2010 applications that enables users to access, slightly change or share documents from
nearly anywhere.
This online companion gives more flexibility to users who can use the web browser to work on their
documents. For instance, Word Web App offer high fidelity viewing of Word documents and
features that enable reading, updating and sharing documents are presented in the familiar Office
Ribbon. Thus, those new usages can be leveraged without having to learn new products. This is
similar for other Office applications.
22
Compare SharePoint Editions: http://sharepoint.microsoft.com/en-us/buy/Pages/Editions-Comparison.aspx
23
Download Microsoft SharePoint Foundation 2010:
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=49c79a8a-4612-4e7d-a0b4-3bb429b46595
24
HARDWARE AND SOFTWARE REQUIREMENTS (SHAREPOINT SERVER 2010): http://technet.microsoft.com/enus/library/cc262485.aspx
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
13
Enterprises who purchased Microsoft Office 2010 volume licensing can install and execute
Microsoft Office Web App companion on a server that hosts Microsoft SharePoint Foundation 2010
or Microsoft SharePoint Server 2010.
For further information, one can read the Microsoft TechNet resource center for Microsoft Office
Web Apps25, as well as blog posts from Microsoft Office Web Apps product team26.
3.3 Overview of authentication in SharePoint 2010
The complexity of managing and implementing authentication and authorization for applications as
well as other resources in the enterprise makes it difficult for developers and IT professionals to
fulfill their organization needs.
The SharePoint platform like most applications, whatever software foundation and technical
environment they are based on, uses identities. A digital identity is, generally speaking, a set of
information pieces about an entity like a user. Identity data influence applications behavior – they
set what a user is allowed to do, they also control the way an application interacts with a user, for
instance.
The notion of identity is essential, but working with identities has become difficult: depending on the
situation and the access context that must be provided, many options around technologies (as well
as standards) are available, with lots of representations (and protocols), as well as a diversity of
programming models that depend on preceding elements and technical environments.
Having so many identity technologies, protocols and security token formats implies noticeable
complexity and implementation costs in a specific context, without satisfying all needed access
control scenarios with corresponding security requirements.
This fact, beyond default options, applies to preceding versions of SharePoint, including
SharePoint 2007.
Therefore, based on so much complexity about connecting several applications, technologies and
organizations, and in order to

Simplify identity and access control management, and secured collaboration within an
enterprise that extended outside the firewall perimeter,

Make application developers and Chief Security Officers (CSO) lives easier,
A new approach became necessary!
SharePoint 2010 introduces significant improvements in how identity is managed in the
platform.
“Stop hard-coding security into applications and stop creating operating system (OS)-level
accounts on servers. Consume these as services external to the application.”
Neil MacDonald 13 April 2006
Gartner Group: Achieving agility: building blocks for a policy-driven, agile security services
infrastructure
It is vitally important to understand how these changes affect solution design and platform
configuration to enable federated collaboration scenarios (and beyond).
When learning about identity in the context of authentication in SharePoint 2010 technologies, you
can conceptually look at how the platform handles identity in three key scenarios:
1. Incoming authentication,
2. Inter/Intra farm authentication,
14
25
Microsoft Office Web Apps Deployment: http://technet.microsoft.com/en-us/office/ee815687.aspx
26
Microsoft Office Web Apps: http://blogs.msdn.com/officewebapps/
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
3. And outgoing authentication.
Client
SharePoint 2010 Farm
External
System
Web Front-End (WFE)
Service Applications
Microsoft SharePoint 2010
Microsoft SharePoint 2010
Claims
Windows Identity
Foundation (WIF)
Windows Identity
Foundation (WIF)
Trust
Relationship
Classic
(Windows
Integrated
Authentication)
SharePoint Security
Token Service (STS)
Windows Integrated
Authentication
Claims
Windows Identity
Foundation (WIF)
Claims
SharePoint
Claims Provider
Incoming
Authentication
Intra/Inter Farm
Authentication
Outgoing
Authentication
Whilst our walkthrough scenario focuses on the first key scenario, it is still important to have an
overview of the authentication as a whole in SharePoint 2010.
3.3.1 Incoming Identity
The incoming authentication scenario represents the means in which a client presents its identity to
the platform, or in other words “authenticates” with the Web application or Web service. SharePoint
2010 will use the client’s identity to authorize the client to access SharePoint secured resources
such as web pages, documents, etc.
SharePoint 2010 technologies support two modes in which a client can authenticate with the
platform, Classic mode and Claims Mode.
3.3.1.1 Classic mode
Classic mode allows the typical Internet Information Services (IIS) authentication methods you may
already be acquainted with from previous versions of SharePoint like SharePoint 2007. When a
SharePoint 2010 Web application is configured to use classic mode, you have the option of
leveraging the following IIS authentication methods.
Integrated Windows authentication (NTLM or Kerberos authentication) allows windows clients to
seamlessly authenticate with SharePoint 2010 without having to manually provide credentials
(username/password). Users accessing SharePoint 2010 from Internet Explorer will authenticate
using the credentials the Internet Explorer process is running under, by default the credentials the
user used to log into the desktop. Services or applications that access SharePoint 2010 in
Windows integrated mode will attempt to authenticate using the credentials of the running thread,
which is the identity of the process by default.
In addition to Integrated Windows authentication, SharePoint 2010 supports other types of IIS
authentication such as basic, digest, and certificate based authentication which will not be covered
in this document.
For further understanding of how these protocols function, please see AUTHENTICATION METHODS
SUPPORTED IN IIS 6.0 (IIS 6.0)27.
27
AUTHENTICATION METHODS SUPPORTED IN IIS 6.0 (IIS 6.0): http://go.microsoft.com/fwlink/?LinkId=196646
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
15
3.3.1.2 Claims-based authentication
Support for Claims Authentication is a new feature in SharePoint 2010 technologies and is built on
the Microsoft Windows Identity Foundation (WIF) 1.0.
WIF is a set of API for ASP.NET and WCF (Windows Communication Foundation) developers who
need to design applications that consume claims and establish a trust relationship in the context of
a federation.
In the context of this new approach, WIF also constitutes a hosting framework for existing
applications that need a well-known security context such as Kerberos. For that, WIF can use
received claims in order to create such a context and send them to the application; this is done
through the WIF Claims to Windows Token Service (C2WTS).
WIF is also a base for writing custom STS.
The goal of Windows Identity Foundation (WIF) is to make claims based identities real and
to provide this through technologies that are open and interoperable.
Today, an application typically retrieves a single simple identity such as user name information. For
more information, the application needs to query a remote repository such as a directory service or
a local database.
In a claims model, SharePoint 2010 will accept one or more “claims” about an authenticating client
to identify and authorize him. It can request claims it exactly needs. In practice, a claim may:

Identify a user,

Transport a group membership or a role

Transport personalization information such as the user’s name to display,

Grant or deny the right to do something like accessing a piece of information or invoke
specific methods,

Restrict the right to do something like having a maximum delegation amount,

Etc.
The claims come in the form of SAML tokens and are simply “facts” about the client stated by a
“trusted” authority.
If this claim came from a provider trusted by SharePoint 2010, the platform could use this
information to authenticate a user and to authorize him to access SharePoint resources. A trusted
provider trusted is a Security Token Services (STS).
For more information about claims authentication, see A GUIDE TO CLAIMS-BASED IDENTITY AND
ACCESS CONTROL28.
The type of claims that SharePoint 2010 technologies support for incoming authentication are:

Windows-Claims - In the windows-claims mode sign in, SharePoint 2010 will authenticated
the client using standard Integrated Windows authentication (NTLM or Kerberos) then
translate the resulting Windows Identity into a Claims Identity;

FBA-Claims - In FBA-claims mode, SharePoint 2010 will redirect the client to a login page
hosting the standard ASP.NET login controls. The page will authenticate the client using
ASP.NET membership and role providers, similar to how forms based authentication
functioned in SharePoint 2007. After the identity object representing the user is created,
SharePoint will then translate this identity into a claims identity object.
As previously mentioned (see section § 1.3 ABOUT THIS GUIDE), the release of starter kit
shib4moss 1.0 (Shibboleth for SharePoint 2007) was announced in order to allow a
SharePoint 2007 Web site to use the Shibboleth Service Provider (SP) software package
28
16
A GUIDE TO CLAIMS-BASED IDENTITY AND ACCESS CONTROL: http://go.microsoft.com/fwlink/?LinkID=187911
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
(see Shibboleth download site29) for Microsoft Internet Information Services (IIS) as an
authentication provider and Shibboleth attributes for authorization. This starter provides
among other blocks, ASP.NET membership and role providers in order to integrate with the
Shibboleth SP software package;

SAML-Claims - In SAML-Claims mode, SharePoint 2010 will accept SAML tokens from a
trusted external Security Token Provider (STS). When the user attempts to login, he/she
will be directed to an external claims provider (e.g. Active Directory Federation Services
(AD FS) 2.0), which will authenticate the user and produce a SAML token.
SharePoint 2010 will accept and process this token, augmenting the claims and creating a
claims identity object for the user.
All the above modes are handled and managed by a SharePoint 2010 internal STS. As far as the
latter mode is concerned, this internal STS supports the WS-Fed Passive protocol30 (OASIS WSFederation standard) for browser-based passive clients and the OASIS WS-Trust standard for
smart clients.
Having SharePoint 2010 technologies supporting WS-Fed Passive protocol potentially allows
interoperability with major market solutions like:

BMC Universal Identity Federator ;

CA eTrust SiteMinder Federation Security Services (6 SP5) ;

IBM Tivoli Federated Identity Manager ;

Internet2 Shibboleth System (1.3) (with extension) / Internet2 Shibboleth System31;

Microsoft Active Directory Federation Services ;

Novell Access Manager ;

Oracle Identity Federation ;

Ping Identity PingFederate Server ;

RSA Federated Identity Manager ;

Sun OpenSSO ;

symLABS Federated Identity Suite ;

Version3 Enhanced Authentication Edition.
Claims augmentation is done via the interaction with a SharePoint Claims provider.
For more information about claims-based authentication in SharePoint 2010 technologies, please
refer to SHAREPOINT CLAIMS-BASED IDENTITY32.
3.3.2 Incoming Claims Authentication and the Claims to Windows Token
Service (C2WTS)
Some SharePoint 2010 service applications require the use of the WIF C2WTS service to translate
claims within the farm to Windows credentials for outbound authentication.
It is important to understand that service applications that come with SharePoint Server 2010 can
leverage the C2WTS service only if the incoming authentication method is either classic mode or
Windows claims. Service applications accessed through web applications that leverage SAML
29
Shibboleth download site: http://go.microsoft.com/fwlink/?LinkId=204016
30
W EB SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.2 : http://docs.oasisopen.org/wsfed/federation/v1.2/ws-federation.pdf
While fully implemented/supported, the support of the WS-Fed Passive protocol isn’t widely used with Shibboleth-based
communities.
31
32
SHAREPOINT CLAIMS-BASED IDENTITY: http://go.microsoft.com/fwlink/?LinkId=196647
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
17
claims or FBA claims do not use the C2WTS service, and therefore they are not able to translate
claims to Windows credentials.
3.3.3 Identity within a SharePoint environment/farm
SharePoint 2010 technologies use claims authentication for intra and inter-farm communications
with most SharePoint 2010 service applications and SharePoint 2010 integrated products
regardless of the incoming authentication mechanism used.
This means that even in situations where classic authentication is used to authenticate with a
particular Web application, SharePoint 2010 will convert the incoming identity into a claims identity
to authenticate with SharePoint 2010 service applications and products that are claims-aware. By
standardizing on the claims model for intra/inter farm communications, the platform can abstract
itself from the incoming protocols used.
Note:
Some SharePoint 2010 integrated products, like SQL Server Reporting Services, are not claimsaware out of box and do not leverage the intra-farm claims authentication architecture. SharePoint
2010 may also rely on classic Kerberos delegation as well as claims in other scenarios, for
example when the RSS viewer Web part is configured to consume an authenticated feed. Please
refer to each product or service application’s documentation to determine if it can support claimsbased authentication and/or identity delegation.
3.3.4 Outbound identity
Outbound identity in SharePoint 2010 Products represents the scenarios where services within the
farm need to authenticate with external line of business systems and services. Depending on the
scenario, authentication can be performed in one of two basic conceptual models.
3.3.5 Trusted sub-system
In the trusted subsystem, the front end service authenticates and authorizes the client then
authenticates with additional backend services without passing the client identity to the back end
system. The back end system “trusts” the front end service to do authentication and authorization
on its behalf. The most common way to implement this model is to leverage shared service account
to authentication with the external system:
In SharePoint 2010, this model can be implemented in various ways:

Using the IIS application pool identity - usually achieved by running code in the web
application which elevates permissions while making an off box call to an external system.
Other methods such as using RevertToSelf can also use the application pool’s identity to
authenticate with external systems;

Using a service account - typically achieved by storing application credentials in the Secure
Store then using those credentials to authenticate with an external system. Other methods
include storing the service account credentials in other ways such as embedded
connection strings;

Anonymous Authentication - this is where the external system does not require any
authentication therefore the front end SharePoint services does not have to pass any
identity to the backend system.
3.3.6 Delegation
In the Delegation model, the front end service first authenticates the client then uses the client’s
identity to authenticate with another backend system which performs its own authentication and
authorization:
In SharePoint, this model can be implemented in various ways:
18
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies

Kerberos delegation - If the client authenticates with the front end service using Kerberos
authentication, Kerberos delegation can be used to pass the clients identity to the backend
system.

Claims - claims authentication allows the clients claims to be passed between services as
long as there is trust between the two services and both are claims aware.
Note:
Currently, some out-of-the-box SharePoint 2010 service applications do not allow outbound claims
authentication, but outbound claims is a platform capability which will be leveraged in the future.
Further, many of the most common line-of-business systems today do not support incoming
claims authentication, which means the use of outbound claims authentication may not be
possible or will require additional development to work properly.
Note:
For additional information, please refer to the paper CONFIGURING KERBEROS AUTHENTICATION FOR
MICROSOFT SHAREPOINT 2010 PRODUCTS33.
3.4 Federated SharePoint 2010 SAML-Claims authentication with
the SAML 2.0 protocol
Interoperability between applications in heterogeneous technological environments is a first-class
dimension for organizations collaboration.
As previously mentioned, in SAM-Claims mode for browser-based scenario, the SharePoint 2010
internal STS will accept SAML tokens from a trusted external WS-Fed Passive-based Security
Token Provider (STS).
Although such support is provided in Shibboleth 2, it isn’t widely implemented/supported in
Shibboleth-based communities that today mostly rely on the SAML 2.0 protocol.
In such a context, the SharePoint 2010 federated collaboration scenario requires a protocol
gateway for “impedance adaptation” in order to provide an end-to-end solution. This can be
achieved through Microsoft Active Directory Federation Services (AD FS) 2.0.
3.4.1 AD FS 2.0 as a gateway
AD FS 2.0 is a component of the Windows (Server) platform and, as such, the right to use it is
included in the associated license costs.
AD FS 2.0 is a STS that uses Active Directory Domain services as a credential store, but it can
also use attributes coming from Active Directory Lightweight Directory Services (AD LDS), and
other data sources.
AD FS provides final users with a rich SSO experience (on the Web among other scenarios)
between applications, services, and platforms:

Within the enterprise;

Between organizations;

On the Internet and in the Cloud as the Microsoft Windows Azure platform 34, the Microsoft’s
Cloud services platform or the Microsoft Office 36535, the cloud versions of the Microsoft
33
CONFIGURING KERBEROS AUTHENTICATION FOR MICROSOFT SHAREPOINT 2010 PRODUCTS:
http://go.microsoft.com/fwlink/?LinkID=196600
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
19
communications and collaboration products with the latest version of the desktop suite for
businesses of all sizes.
It supports multiple OASIS standards: SAML 2.0, WS-Federation, WS-Trust and IMI.
These capacities are recognized by the market. Indeed, on the occasion of the European Identity
Conference (EIC) 2009, the leading European event for Identity and Access Management (IAM)
and GRC (Governance, Risk Management, and Compliance), the analyst firm Kuppinger Cole
conferred the European Identity Award 200936, in the category “Best innovation”, to Microsoft for the
Geneva project (AD FS 2.0 & WIF 1.0), in which federation becomes part of user containers, “one
of the most significant enhancements for future use and dissemination of the Identity Federation”.
On the occasion of the European Identity Conference 2010 (EIC), Kuppinger Cole conferred the
European Identity Award 201037, in the category “Best Project B2C”, to the University of
Washington (UW). UW was honored for its identity federation solution based on both AD FS 2.0 &
WIF 1.0 in research and education which was developed together with Microsoft and is intended to
form part of the “Live@Edu” initiative.
“The University of Washington is delighted to have its work with Microsoft on federation services
honored by Kuppinger Cole”, said RL "Bob" Morgan, Identity Architect for UW Information
Technology and Shibboleth Project core team member. “At UW, we are committed to standardsbased federation to extend the value of UW identity to the services our users need. It is great to
partner with Microsoft since they too are making a commitment to federation for Windows Live and
Live@edu. Live@edu's support of higher-education federations including InCommon is a key
differentiator. Making it all work has many challenges, but it's essential so the higher-ed community
can collaborate seamlessly and securely in cloud environments.”
Nathan Dors, manager of Identity and Access Management for UW Information Technology, added
that: “we agree with Microsoft on the importance of being both standards-oriented and pragmatic.
Choice of federating technology is key and we appreciate Microsoft's striving to reach parity
between AD FS 2.0 and Shibboleth solutions”.
AD FS 2.0 natively offers the ability of a protocol gateway by acting as a gateway between SAML
2.0 and WS-Fed Passive protocols.
Both SAML 2.0 protocol support and the ability to bridge protocols were greeted by Scott Cantor:
“As a Shibboleth and OpenSAML project developer, and a deployer of the Shibboleth software at
The Ohio State University, I’m excited and gratified that Microsoft is implementing the SAML 2.0
Web SSO profile in its upcoming products. Throughout the life of the Shibboleth project, and my
work on the SAML 2.0 standard, our goal has been to leverage open standards to foster broad
interoperability in federated identity within the higher education community and between it and its
many commercial and non-commercial partners. Microsoft is clearly one of those critical partners,
and as a key technology supplier, its support for the SAML standard reflects an understanding of
our community’s needs and goals, and will expand the scope and impact of our efforts.
Our users will benefit by obtaining access to the broadest potential set of federated applications
and services, and our worldwide community will benefit from the opportunity to deploy Microsoft’s
identity solutions with the knowledge that they will interoperate with Shibboleth. Microsoft’s
willingness to listen to our requirements and suggestions demonstrates a commitment to real-world
compatibility. I look forward to continuing the dialog with Microsoft as we drive further
34
Microsoft Windows Azure platform: http://www.windowsazure.com/
35
Microsoft Office 365: http://office365.microsoft.com/
36
European Identity Award 2009: http://www.id-conf.com/blog/2009/05/07/awards-for-outstanding-identity-managementprojects/
37
European
honored/
20
Identity
Award
2010:
http://www.id-conf.com/blog/2010/05/05/outstanding-projects-and-initiatives-in-im-
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
interoperability in the use of federation metadata to scale and simplify both SAML 2.0 and WSFederation deployments.”
Vis-à-vis SAML 2.0 protocol, AD FS 2.0 more especially supports the OASIS SAML 2.0 IdP Lite
and SP Lite operation modes (see OASIS CONFORMANCE REQUIREMENTS FOR THE OASIS SECURITY
ASSERTION MARKUP LANGUAGE (SAML) V2.038) as well as the eGov SAML 2.0 Profile v1.5, first of
many vertical-specific constraining profiles (General Service Administration) version 1.5 (see
LIBERTY ALLIANCE EGOVERNMENT PROFILE FOR SAML 2.039).
AD FS 2.0 successfully passed the SAML 2.0
interoperability tests for these modes as described in the document LIBERTY INTEROPERABILITY
TESTING PROCEDURES FOR SAML 2.0 VERSION 3.2.240 (see Liberty Alliance press release ENTRUST,
IBM, MICROSOFT, NOVELL, PING IDENTITY, SAP AND SIEMENS PASS LIBERTY ALLIANCE SAML 2.0
INTEROPERABILITY TESTING41).
In practice, part of the conversation between SharePoint 2010 and AD FS 2.0 (in both ways)
happens under WS-Fed Passive protocol, while the other part between AD FS 2.0 and Shibboleth
2 (in both ways) happens under SAML 2.0 protocol.
As a consequence of that, AD FS 2.0 is seen by the Shibboleth 2 IdP as a Shibboleth 2 SP, and it
is seen by SharePoint 2010 as a trusted STS (for identity tokens) or Claims Provider (in AD FS 2.0
vocabulary).
38
CONFORMANCE REQUIREMENTS FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0: http://docs.oasisopen.org/security/saml/v2.0/saml-conformance-2.0-os.pdf
39
LIBERTY ALLIANCE EGOVERNMENT PROFILE FOR SAML 2.0:
http://www.projectliberty.org/liberty/content/download/4711/32210/file/Liberty_Alliance_eGov_Profile_1.5_Final.pdf
40
LIBERTY INTEROPERABILITY TESTING PROCEDURES FOR SAML 2.0 VERSION 3.2.2:
http://www.projectliberty.org/liberty/content/download/4709/32204/file/Liberty_Interoperability_SAML_Test_Plan_v3.2.2%20.
pdf
41
Liberty Alliance press release ENTRUST, IBM, MICROSOFT, NOVELL, PING IDENTITY, SAP AND SIEMENS PASS
LIBERTY ALLIANCE SAML 2.0 INTEROPERABILITY TESTING:
http://www.projectliberty.org/liberty/news_events/press_releases/entrust_ibm_microsoft_novell_ping_identity_sap_and_sie
mens_pass_liberty_alliance_saml_2_0_interoperability_testing
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
21
Identity Repository, e.g.
Active Directory Lightweight
Directory Services (AD LDS)
Metadata-based
Trust Relationship
6
WAYF
4
Identity Provider (IdP)
Internet2 Shibboleth 2
SAML 2.0 protocol
3
Service Provider (SP)
7
Microsoft Active Directory
Federation Services
(AD FS) 2.0
5
Metadata-based
Trust Relationship
Client
WS-Federation protocol
8
2
1
Web Front-End (WFE)
Microsoft SharePoint 2010
The above figure intentionally omits all the HTTP 302 redirects to the client for the federation
protocols to be simple as possible (: arrows 2, 4, 7 and 8 are HTTP 302 redirect-based.)
This capability of AD FS 2.0 is a consequence of the major announcement42 that was made by
Microsoft on February 2008 about the enhancements of its products openness, interoperability, and
the creation of new opportunities for developers, partners, customers and competitors.
Exchanging information between people and organizations, interoperability between applications
and services have become first-class needs. Microsoft committed to interoperability a while ago,
after having been exchanging with their customers about their interoperability needs and listening
to them on how Microsoft products should become even more open and interoperable.
In order to fulfill those stakes and needs, Microsoft applies four interoperability principles to their
own broadly used products like Windows Server, SharePoint, etc. from now on:
1. Guarantee an open connection to these products;
2. Promote data portability;
3. Enhance industry standards support;
4. Favor exchange and collaboration in the IT industry including with the Open Source
communities about interoperability and standards topics.
Of course, these principles apply to AD FS 2.0 which clearly has such goals.
Required operations to set up exchanges, redirections and interactions between Shibboleth 2 and
AD FS 2.0 are explained in chapter § 5 CONFIGURE SHIBBOLETH on one hand, and those between
AD FS 2.0 and SharePoint 2010 are explained in chapter § 6 CONFIGURE SHAREPOINT 2010 AS A
RELYING PARTY FOR AD FS 2.0 on the other hand.
42
News Press Release. Microsoft Makes Strategic Changes in Technology and Business Practices to Expand
Interoperability: http://www.microsoft.com/presspass/press/2008/feb08/02-21ExpandInteroperabilityPR.mspx
22
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
4 About the testing environment
This guide assumes the pre-existence of deployments of Shibboleth 2, AD FS 2.0 and SharePoint
2010 as described in the following section.
4.1 Prepare the virtual machines
To simplify the implementation stages of installation and configuration in a testing environment, this
guide is based on the definition of three machines running under Windows Server 2008 R2 as
follows, including for the Shibboleth 2 system acting as an Identity Provider.
AD LDS
Internet 2 Shibboleth 2
AD DS, AD CS
AD FS 2.0
Idmgt-ip0
Idmgt-dc
idmgtext.demo
idmgt.demo
Microsoft
SharePoint 2010
Idmgt-sps
The environment used in guide is based, to do this, on the definition of three virtual machines
running on top of the Microsoft Hyper-V environment onto Windows Server 2008 R2:
VM Name
RAM
Software installed
IP configuration
IDMGT-DC
1.5 GB
Operating system: Windows Server 2008 R2
Enterprise
Roles: AD DS, AD CS, (DNS)
Applications: AD FS 2.0
Domain name: idmgt.demo
Host name: idmgtdc.idmgt.demo
Host alias: sts.idmgt.demo
IDMGT-SPS
1.5 GB
Operating system: Windows Server 2008 R2
Enterprise
Applications: Microsoft SharePoint
Foundation 2010
Domain name: idmgt.demo
Host name: idmgtsps.idmgt.demo
IDMGT-IP0
1.5 GB
Operating system: Windows Server 2008 R2
Enterprise
Roles: AD LDS
Applications: Tomcat 6, Shibboleth 2
Domain name:
idmgtext.demo43
Host name: idmgtip0.idmgtext.demo
The following sections describe the main steps relating to the configuration and installation of the
Shibboleth 2, AD FS 2.0 and SharePoint 2010 systems and/or platforms.
To easily replicate the configuration illustrated in this guide in a testing environment:
43
“ext” stands for external
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
23

You must follow the steps described in the two following chapters in the order in which
these steps appear in order to have, at the end, hopefully a fully operational testing
environment.
These steps assume the prior existence of the domains idmgt.demo & idmgtext.demo (as
entries in the related machine hosts file).
Generally speaking, they also assume that the considered Windows Server 2008 R2
environments have all the prerequisites required to the installation of Shibboleth 2, AD FS
2.0, and SharePoint 2010 and therefore do not necessary describe the installation of
these prerequisites. A dedicated section entitled PREREQUISITES AND REQUIREMENTS at the
beginning of each of these two chapters briefly recap the technical expectation before
addressing the steps that follow.

You can create your own virtual machines that you will configure later to perform the tasks
relating to the steps outlined in the rest of this guide.
In order to do that, if you do not already have clean-installed Windows Server 2008 R2
virtual hard drive images, you can download and use the base evaluation .VHD files to
build the base VMs for this lab. The files are available on the Microsoft Web site at
Windows Server 2008 R2 Virtual Hard Drive Images44.
For example, if you are creating a virtual hard drive for IDMGT-DC and also using the
downloaded base .VHD image, follow the instructions provided in the download page
here: Windows Server 2008 R2 Evaluation Virtual Hard Drive Images for Hyper-V (180
Days)45.
All the VM images should be configured to use a virtual private network (VPN) interface.
The following procedure explains how to re-create this network in Hyper-V to support the
use of the VM images in your own test lab environment.
4.2 Perform the preconfiguration tasks
Perform the prerequisite configuration steps to prepare the environment for testing:

Shibboleth 2 as a Claims Provider/Identity Provider on top of SAML 2.0 protocol (with the
SAML 2.0 HTTP POST binding)/AD FS 2.0 as a Relying Party/Service Provider role vis-àvis Shibboleth on top of SAML 2.0 protocol (see section § 5 CONFIGURE SHIBBOLETH 2 AS A
CLAIMS PROVIDER FOR AD FS 2.0);

And AD FS 2.0 as a Claims Provider role vis-à-vis SharePoint 2010 on top of WSFederation protocol/SharePoint 2010 as the Relying Party role on top of WS-Federation
(see section § 6 CONFIGURE SHAREPOINT 2010 AS A RELYING PARTY FOR AD FS 2.0).
Note:
All of the actions in this section were performed while logged into Windows with administrative
privileges.
4.2.1 Ensure IP Connectivity
Make sure that the Shibboleth (idmgt-ip0.idmgtext.demo), the AD FS 2.0 (sts.idmgt.demo), and the
SharePoint 2010 (idmgt-sps.idmgt.demo) computers have IP connectivity between them.
44
Windows Server 2008 R2 Virtual Hard Drive Images : http://go.microsoft.com/fwlink/?LinkId=179734
45
Windows Server 2008 R2 Evaluation Virtual Hard Drive Images for Hyper-V (180 Days):
http://go.microsoft.com/fwlink/?LinkId=179736).
24
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
4.2.2 Configure Name Resolution
In this guide, we use the hosts file on both computers to configure name resolution of the partner
federation servers and SharePoint 2010 applications.
Note:
Production deployments should use Domain Name System (DNS) instead.
To configure name resolution, proceed as follow:
1. Locate the hosts file on the Shibboleth computer (idmgt-ip0.idmgtext.demo). The default
location is C:\windows\system32\drivers\etc\hosts.
2. Right-click the file, and then click Open. Select Notepad to open the file.
3. Add an entry for sts.idmgt.demo and another one for idmgt-sps.idmgt.demo, for example:
192.168.1.2
192.168.1.3
sts.idmgt.demo
idmgt-sps.idmgt.demo
4. If idmgt-ip0.idmgtext.demo is not a Windows domain controller, add a second entry that
points to itself in the hosts file, for example:
192.168.1.1
idmgt-ip0.idmgtext.demo
5. Save and close the file.
6. Locate the hosts file on the AD FS 2.0 computer (sts.idmgt.demo), and open it with
Notepad.
7. Add an entry for idmgt-ip0.idmgtext.demo and another one for idmgt-sps.idmgt.demo, for
example:
192.168.1.1
192.168.1.3
idmgt-ip0.idmgtext.demo
idmgt-sps.idmgt.demo
8. Save and close the file.
9. Locate the hosts file on the SharePoint 2010 computer (idmgt-sps.idmgt.demo), and open
it with Notepad.
10. Add an entry for idmgt-ip0.idmgtext.demo and another one for sts.idmgt.demo, for
example:
192.168.1.1
192.168.1.2
idmgt-ip0.idmgtext.demo
sts.idmgt.demo
11. Save and close the file.
4.2.3 Verify Clock Synchronization
Federation events typically have a short Time to Live (TTL). To avoid errors based on time-outs,
ensure that both computers have their clocks synchronized.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
25
Note:
For information about how to synchronize a Windows Server 2008 R2 domain controller to an Internet time
server, see article 816042 HOW TO CONFIGURE AN AUTHORITATIVE TIME SERVER IN WINDOWS SERVER46.
46
Article 816042 HOW TO CONFIGURE AN AUTHORITATIVE TIME SERVER IN WINDOWS SERVER:
http://go.microsoft.com/fwlink/?Link ID=60402
26
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
5 Configure Shibboleth 2 as a Claims Provider for AD FS
2.0
This chapter describes the configuration steps to complete on the Shibboleth environment that will
act as a Claims Provider/Identity Provider 2, as well as on the AD FS 2.0 platform, which will act
conversely as Relying Party/Service Provider.
This first part of our walkthrough, as a global federated collaboration scenario, uses the SAML 2.0
POST profile.
Note:
All of the actions in this section were performed while logged into Windows with administrative
privileges.
Note:
Please note that running the Shibboleth environment on a Windows system is not a requirement.
There are many guides that describe the installation for a Linux system.
5.1 Prerequisites and requirements
The steps described in the following sections assume the availability of:

The IDMGT-DC (sts.idmgt.demo) (virtual) machine with ADFS 2.0 RTW 47 installed and up
and running at the following address: https://sts.idmgt.demo/adfs/ls/. This chapter also
assumes the default AD FS identifier is used: https://sts.idmgt.demo/adfs/services/trust.
For the prerequisites for AD FS 2.0, we invite you to consult in a complementary way the
guide entitled AD FS 2.0 FEDERATION WITH A WIF APPLICATION STEP-BY-STEP GUIDE48, which
can be considered as a starting point to build a Windows Server 2008 R2 instance that
hosts AD FS 2.0.

The IDMGT-IP0 (idmgt-ip0.idmgtext.demo) (virtual) machine on which the Shibboleth
system will be installed. Installation and deployment guides for Shibboleth are available at
the Shibboleth 2 documentation home page49 Web site.
This machine must have a recent version (5 or later) of the Java runtime environment
(JRE) for Windows 32-bit. This guide uses Oracle Java SE Runtime Environment (JRE)
6u2250.
47
AD FS 2.0 RTW: http://www.microsoft.com/downloads/details.aspx?FamilyID=118c3588-9070-426a-b6556cec0a92c10b&displaylang=en
48
AD FS 2.0 Federation with a WIF Application Step-by-Step Guide: http://go.microsoft.com/fwlink/?LinkId=193997
49
Shibboleth 2 documentation home page: http://go.microsoft.com/fwlink/?LinkId=204014
50
Oracle JRE 6u22: http://go.microsoft.com/fwlink/?LinkId=204015
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
27
Note:
Set the JAVA_HOME environment variable to the install directory for this JRE (for example,
C:\Program~2\Java\jre6) before running the Shibboleth IdP installer. Do not use C:\Program Files
(x86)\ but C:\Progra~2 because some software don’t support having spaces in paths
JAVA_HOME= C:\Program~2\Java\jre6\
For information on the prerequisites of the Shibboleth 2 system on Linux environments as
well as the installation and configuration of an Identity provider onto these environments,
we invite you to visit complementarily the documentation made available by the EducationResearch RENATER Federation.
5.2 Install Shibboleth 2
To install the Shibboleth 2 IdP software
ip0.idmgtext.demo) machine, proceed as follow:
package
onto
the
IDMGT-IP0
(idmgt-
1. Visit the Shibboleth download site51 and download the latest IdP (Identity Provider)
software package. This guide uses the Java WebApp with Ant-based Installer version
2.2.0: shibboleth-identityprovider-2.2.0-quickinstall.msi.
2. Unzip the package shibboleth-identityprovider-2.2.0-quickinstall.msi to c:\shibboleth\.
3. In an elevated command prompt, run c:\shibboleth\install.bat and accept the default values
when prompted. This will install Shibboleth into the c:\opt\shibboleth-idp\ folder.
Note:
This installer automatically installs and configures Apache Tomcat52 6.0.26 for 32-bit Windows. It
depends on an existing 32-bit Java JRE installation.
4. Set the TOMCAT_HOME and IDP_HOME environment variable to their install directories.
If you install to default locations, the right values to set will be:
TOMCAT_HOME=c:\progra~2\apache~1\tomcat~1.0\
IDP_HOME=c:\opt\shibboleth-idp\
5.3 Configure Servlet Container for SSL and Shibboleth
Unless noted otherwise, all the instructions below are executed on the IDMGT-IP0 (idmgtip0.idmgtext.demo) machine.
These instructions assume you are using Apache Tomcat, which should normally be the case if
you’ve followed the previous instructions.
5.3.1 Create an SSL Certificate
Federation relies heavily on public key infrastructure (PKI), including Secure Sockets Layer (SSL)
encryption, for trustworthy transactions. To properly use SSL security in this lab, run the following
28
51
Shibboleth download site: http://go.microsoft.com/fwlink/?LinkId=204016
52
Apache Tomcat 6.x : http://tomcat.apache.org/download-60.cgi
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
to create a Secure Sockets Layer (SSL) certificate Apache that Tomcat will use to protect your
Shibboleth IdP web site:
mkdir c:\certs\
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -dname CN=idmgt-ip0.idmgtext.demo
c:\certs\.keystore -keypass changeit -storepass changeit
-keyalg
RSA
-keystore
5.3.2 Enable SSL in Apache Tomcat
To enable SSL in Apache Tomcat, proceed as follow:
1. Open %TOMCAT_HOME%\conf\server.xml.
2. Uncomment the SSL Connector element and add the keystoreFile and keystorePass
attributes. It should look like:
<Connector
port="8443"
protocol="HTTP/1.1"
SSLEnabled="true"
maxThreads="150"
scheme="https"
secure="true"
keystoreFile="c:\certs\.keystore"
keystorePass="changeit"
clientAuth="false"
sslProtocol="TLS" />
5.3.3 Add Shibboleth Servlet to Apache Tomcat
To add the Shibbleth Servlet to Apache Tomcat, proceed as follow:
1. Create a file called %TOMCAT_HOME%\conf\Catalina\localhost\idp.xml with the following
contents:
<Context docBase="c:/opt/shibboleth-idp/war/idp.war"
privileged="true"
antiResourceLocking="false"
antiJARLocking="false"
unpackWAR="false"
swallowOutput="true" />
2. Restart the Apache Tomcat service by running the following commands:
net stop Tomcat6
net start Tomcat6
You should now be able to visit https://idmgt-ip0.idmgtext.demo:8443/idp/profile/Status and see a
page that says “ok”.
5.4 Configure Shibboleth 2
Unless noted otherwise, all the instructions below are executed on the IDMGT-IP0 (idmgtip0.idmgtext.demo) machine.
In this section, perform the prerequisite configuration steps to prepare the environment for using
Shibboleth 2 as an identity provider.
5.4.1 Install AD LDS and declare it for login
By default, no LDAP (Lightweight Directory Access Protocol) repository is installed for the
Shibboleth IdP.
Consequently, in order to have an LDAP repository that will provide attributes and user accounts to
Shibboleth IdP, Active Directory Lightweight Directory Services (AD LDS for short) is installed.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
29
Note:
For information about AD-LDS, please refer to the Active Directory Lightweight Directory Services
documentation53 available on the Microsoft TechNet Web site.
Note:
Another LDAP repository like the OpenLDAP software54 could have been installed instead.
5.4.1.1 Install the AD LDS role and configure the instance
To both install an AD LDS role and configure the instance onto the idmgt-ip0.idmgtext.demo
Windows Server 2008 R2 machine and declare it for logon for the Shibboleth IdP, proceed as
follow:
1. Add the AD LDS role to the Windows instance as explained in the STEP 1: INSTALL THE AD
LDS SERVER ROLE page55. This will end with the following result in the Add Roles wizard:
2. From the Server Manager console, select the Active Directory Lightweight Directory
Services node in the console tree under the Roles node.
53
Active
Directory
Lightweight
us/library/cc731868(WS.10).aspx
30
Directory
Services
documentation:
http://technet.microsoft.com/en-
54
OpenLDAP Software: http://www.openldap.org/
55
STEP 1: INSTALL THE AD LDS SERVER ROLE page: http://technet.microsoft.com/en-us/library/cc754486(WS.10).aspx
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
3. In the right pane, click the Click here to create an AD LDS instance link. The Active
Directory Lighweight Directory Services Setup Wizard opens up.
4. On the Welcome page, click the Next button.
5. On the Setup Options page, select the option A unique instance, and then click the Next
button.
6. On the Instance Name page, type for example “ShibbolethDir” in the Instance name
textbox and “Shibboleth Directory AD LDS instance” in the Description textbox, and then
click the Next button.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
31
7. On the Ports page, keep the default port number for both LDAP and SSL, and then click
the Next button.
8. On the Application Directory Partition page, select the option Yes, create an
application directory partition for the Shibboleth IdP, then type for example
“cn=Users,dc=IDMGT,dc=COM” in the Partition name textbox, and finally click the Next
button.
9. On the File Locations page, keep the default path for both the data files and the data
recovery files, and then click the Next button.
32
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
10. On the Service Account Selection page, keep the default network service account, and
then click the Next button.
11. On the AD LDS Administrators page, keep the default currently logged on user as the
instance administrator, and then click the Next button.
12. On the Importing LDIF Files page, make sure that the LDIF files MS-InetOrgPerson.LDF
and MS-User.LDF are checked, and then click the Next button.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
33
13. On the Ready to Install page, review the selections made so far, and then click the Next
button to start the installation.
14. Once completed without any error, the completing page appears. Click the Finish button to
complete the instance installation.
5.4.1.2 Create a Shibboleth service user
It is now time to create a user inside the LDAP directory so that the Shibboleth IdP can access AD
LDS.
To create a new user in the newly installed AD LDS instance, proceed as follow:
1. From the Server Manager console, select the Active Directory Lightweight Directory
Services node in the console tree under the Roles node.
34
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
2. In the right pane, click the ADSI Edit link. The ADSI Edit application opens up.
3. Right-click the ADSI Edit node and select the Connect to item. The Connection Settings
dialog box opens up.
4. In the Connection Point frame, select the option Select or type a Distinguished Name
or Naming Context and type the partition name specified earlier during the AD LDS
instance installation, for example “CN=Users,DC=IDMGT,DC=COM” in our case.
In the Computer frame, select the option Select or type a domain or server: (Server |
Domain [:port]), then type “localhost:389”, and finally click the OK button to confirm the
settings and close the dialog box.
5. In the ADSI Edit console, right-click the “CN=Users,DC=IDMGT,DC=COM” node, then
click the New item, and then click the Object item. The Create Object dialog box opens
up.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
35
6. In the Create Object dialog box, select the class User and then click the Next button.
7. In the Create Object dialog box, type for example “ShibbolethServiceAccount” for the
value and then click the Next button.
8. In the Create Object dialog box, click the Finish button to create the user.
5.4.1.3 Configure the Shibboleth service user
We then have to set the “CN=ShibbolethServiceAccount” user’s password.
To set the user’s password, proceed as follow:
1. Right-click the newly created “CN=ShibbolethServiceAccount” user object and click the
Reset Password item. The Reset Password dialog box opens up.
2. Specify the new password, for example MIwgsymf29, in the New password and Confirm
password textboxes and then click the OK button to confirm and close the dialog box.
For the CN=ShibbolethServiceAccount user, the msDS-UserAccountDisabled attribute must be
changed to false.
36
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
To set this attribute, proceed as follow:
1. Right-click the “CN=ShibbolethServiceAccount” user object and click the Properties item.
The properties dialog box opens up.
2. Select the msDS-UserAccountDisabled attribute in the attributes list and then click the Edit
button. The Boolean Attribute Editor dialog box opens up.
3. Select the False option and then click the OK button to close the editor dialog box.
4. Similarly, set the msDS-UserDontExpirePassword attribute of the same account to true.
5. Click the OK button to close the properties dialog box.
Finally the “CN=ShibbolethServiceAccount” user must belong to the “CN=Administrators” role.
To place the service user in the Administrators role, proceed as follow:
1. Click the “CN=Roles” container in the left pane, then right-click the “CN=Administrators”
object in the right pane and finally click the Properties item. The properties dialog box
opens up.
2. Click the Edit button. The Multi-valued Distinguished Name With Security Principal
Editor dialog box opens up.
3. Click the Add DN button. The Add Distinguished Name (DN) dialog box opens up.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
37
4. Type the DN for the service account, for example in our case “CN=
ShibbolethServiceAccount,CN=Users,DC=IDMGT,DC=COM”, and then click the OK
button.
5. Click the OK button to close the editor dialog box.
6. Click the OK button to close the properties dialog box.
5.4.1.4 Create and configure a test user for the Shibboleth IdP
In order to interact with the AD FS 2.0 machine in the other realm, a test user has to be created.
The required steps are similar as the one outlined in sections § 5.4.1.2 CREATE A SHIBBOLETH
SERVICE USER and § 5.4.1.3 CONFIGURE THE SHIBBOLETH SERVICE USER:

Create a new object of type user, named “cc” instead of “ShibbolethServiceAccount”
(“CN=cc,CN=Users,DC=IDMGT,DC=COM”);

Reset its password;

Set its msDS-UserAccountDisabled attribute to false.

You may also want to set its msDS-UserDontExpirePassword attribute to true.
Note:
This user doesn’t have to be added in any role.
The following additional attributes are set (they will eventually be transformed as claims):
Attribute name
Value
department
“sampleEduPersonAffiliation”
mail
“cc@windows.shibboleth”
5.4.1.5 Modify Shibboleth configuration files
Shibboleth has a number of configuration files that need to be modified in order to have the server
connect to AD LDS and emit the claims.
These configuration files are at %IDP_HOME%\conf, e.g. C:\opt\shibboleth-idp\conf.
Here are the files that need to be changed: handler.xml and login.config files.
38
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
Note:
In the following configuration files excerpts, comments may be omitted
Edit the handler.xml file
For the purposes of this walkthrough, we’ll let Shibboleth authenticate users via their
username/password credentials. Proceed as follow:
1. Edit %IDP_HOME%\conf\handler.xml.
2. Replace the set of LoginHandler elements with the following:
<LoginHandler xsi:type="UsernamePassword"
jaasConfigurationLocation="file://C:\opt\shibboleth-idp/conf/login.config">
<AuthenticationMethod>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</AuthenticationMethod>
</LoginHandler>
Edit the login.config file
When omitting the comments, the file should look like this:
ShibUserPassAuth {
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="localhost:389"
base="CN=users,DC=IDMGT,DC=COM"
ssl="false"
userField="uid"
subtreeSearch="true"
serviceUser="cn=ShibbolethServiceAccount,cn=Users,dc=IDMGT,dc=COM"
serviceCredential="MIwgsymf29";
};
Note:
Replace MIwgsymf29 by your own password previously set in section § 5.4.1.3 CONFIGURE THE
SHIBBOLETH SERVICE USER for the Shibboleth service user.
5.4.2 Add the AD FS 2.0 SSL Certificate to Java’s Trusted Certificate Store
Note:
You only need to do this step if you are using a test or self-signed certificate for the AD FS SSL
certificate, which is the case for this lab. The situation could be different for production
deployments.
If you are using the self-signed auto-generated certificate, you will get an SSL handshake error
when Shibboleth downloads AD FS’s metadata document. One way to fix this is to add this
certificate to Java’s trusted certificate store.
To add the AD FS 2.0 self-signed auto-generated certificate to Java’s trusted certificate store,
proceed as follow:
1. Visit https://sts.idmgt.demo/FederationMetadata/2007-06/FederationMetadata.xml
Internet Explorer.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
with
39
2. At the security warning, click the link to continue to the website. The Address Bar turns red
to signify that the page is protected by an SSL certificate that is not trusted.
3. Click the Certificate Error message next to the Internet Explorer address bar, and then
the View Certificate link. The Certificate dialog box opens up.
4. In the Certificate window, click the Details tab, and then click Copy to File to start the
Certificate Export Wizard.
5. Click the Next button.
6. On the Export File Format page, leave DER encoded binary X.509 selected, and then
click the Next button.
7. On the File to Export page, click the Browse button, navigate to the Windows desktop,
and then type the file name “adfs-root” (leaving the type as .cer). Click the Save button.
8. Click the Next button, click the Finish button, click the OK button, and then click the OK
button again.
9. Open a command prompt from Windows desktop, and then run the following commands:
%JAVA_HOME%\bin\keytool.exe -keystore %JAVA_HOME%\lib\security\cacerts -import -alias adfsroot -file adfsroot.cer -trustcacerts -storepass changeit –noprompt
5.4.3 Add the AD FS instance as a Service Provider using remote metadata
Adding a partner, using AD FS 2.0, into Shibboleth 2 is done by referencing the partner’s XML
metadata document in the Shibboleth configuration. The metadata file can reside locally or it can
be located at a URL.
The Shibboleth IdP does not require a scope variable in partner metadata (used for authorization
purposes). Therefore, here we’ll simply point Shibboleth to the AD FS 2.0 auto-generated metadata
document
(,
for
example
https://sts.idmgt.demo/FederationMetadata/200706/FederationMetadata.xml).
To add the AD FS instance as a new SP using metadata, proceed as follow:
1. Edit %IDP_HOME%\conf\relying-party.xml.
2. Under the MetadataProvider element with id=”ShibbolethMetadata”, add the following
element:
<MetadataProvider
id="URLMD"
xsi:type="FileBackedHTTPMetadataProvider"
xmlns="urn:mace:shibboleth:2.0:metadata"
metadataURL="https://sts.idmgt.demo/FederationMetadata/2007-06/FederationMetadata.xml"
backingFile="C:\opt\shibboleth-idp\metadata\adfs-metadata.xml">
<MetadataFilter
xsi:type="ChainingFilter"
xmlns="urn:mace:shibboleth:2.0:metadata">
<MetadataFilter
xsi:type="EntityRoleWhiteList"
xmlns="urn:mace:shibboleth:2.0:metadata">
<RetainedRole>samlmd:SPSSODescriptor</RetainedRole>
</MetadataFilter>
</MetadataFilter>
40
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
</MetadataProvider>
3. Save and close the relying-party.xml file.
5.4.4 Add attributes to a Shibboleth generated assertion
The Shibboleth IdP software is preconfigured to include a number of assertion attributes in the
SAML assertions it generates, including an example of eduPersonScopedAffiliation.
Here, we will modify the default configuration to add the mail and the eduPersonPrimaryAffiliation
attributes to the collection to use in AD FS 2.0 rules set in respect to the SharePoint 2010
application. These two attributes will be further used as an E-Mail Address claim, respectively a
Role claim from both an AD FS 2.0 and SharePoint 2010 perspectives.
Furthermore, for the simplicity of the walkthrough, we will not limit inclusion of these attributes to
assertions that are generated for the AD FS 2.0 realm.
5.4.4.1 Edit the attribute-resolver.xml file
For the purposes of this walkthrough, proceed as follow:
1. Use Windows Explorer to navigate to the folder where the attribute-resolver.xml
configuration file is located. This configuration file is at %IDP_HOME%\conf, e.g.
C:\opt\shibboleth-idp\conf.
2. Right-click the attribute-resolver.xml file, and then click Edit. The document should open in
Notepad.
3. Add or modify the attribute definitions to include the following XML:
<resolver:AttributeDefinition id="email" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="mail">
<resolver:Dependency ref="ADLDS" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:mail" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="eduPersonPrimaryAffiliation" xsi:type="Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="department">
<resolver:Dependency ref="ADLDS" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonPrimaryAffiliation" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.5" friendlyName="eduPersonPrimaryAffiliation" />
</resolver:AttributeDefinition>
4. Add the following data connector to the previously installed AD LDS instance.
<resolver:DataConnector id="ADLDS"
xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://localhost:389"
baseDN="cn=Users,dc=IDMGT,dc=COM"
principal="cn=ShibbolethServiceAccount,cn=Users,dc=IDMGT,dc=COM"
principalCredential=" MIwgsymf29">
<FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</FilterTemplate>
</resolver:DataConnector>
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
41
Note:
Replace MIwgsymf29 by your own password previously set in section § 5.4.1.3 CONFIGURE THE
SHIBBOLETH SERVICE USER for the Shibboleth service user.
5. Save and close the attribute-resolver.xml file.
5.4.4.2 Edit the attribute-filter.xml file
For the purposes of this walkthrough, please proceed as follow:
1. Use Windows Explorer to navigate to the folder where the attribute-filter.xml configuration
file is located. This configuration file is at %IDP_HOME%\conf, e.g. C:\opt\shibbolethidp\conf.
2. Right-click the attribute-filter.xml file, and then click Edit. The document should open in
Notepad.
3. Add or modify the list of attributes that will be released to include the following XML:
<AttributeFilterPolicy id="releaseToAnyone">
<PolicyRequirementRule xsi:type="basic:ANY" />
…
<AttributeRule attributeID="email">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
<AttributeRule attributeID="eduPersonPrimaryAffiliation">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
</AttributeFilterPolicy>
4. Save and close the attribute-filter.xml file.
5.4.5 Complete the Shibboleth configuration
At this stage, the Shibboleth configuration is almost completed.
5.4.5.1 Edit Shibboleth’s Metadata
By default, Shibboleth assumes it is located on port 443. Since Apache Tomcat uses port 8443,
you’ll need to edit your metadata document so that it is correct.
1. Use Windows Explorer to navigate to the folder where the idp-metadata.xml configuration
file is located. This configuration file is at %IDP_HOME%\metadata, e.g. C:\opt\shibbolethidp\metadata.
2. Right-click the attribute-resolver.xml file, and then click Edit. The document should open in
Notepad.
3. Replace all instances of
Location="https://idmgt-ip0.idmgtext.demo/
with
Location="https://idmgt-ip0.idmgtext.demo:8443/
4. Save and close the idp-metadata.xml file.
5.4.5.2 Adjust the level of logging
You may want to adjust the level of logging with this configuration file.
42
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
The following settings in %IDP_HOME%\conf\logging.xml may give the right level of information:
<!-- Logs IdP, but not OpenSAML, messages -->
<logger name="edu.internet2.middleware.shibboleth">
<level value="WARN" />
</logger>
<!-- Logs OpenSAML, but not IdP, messages -->
<logger name="org.opensaml">
<level value="WARN" />
</logger>
<!-- Logs LDAP related messages -->
<logger name="edu.vt.middleware.ldap">
<level value="WARN"/>
</logger>
<!-- Logs inbound and outbound protocols messages at DEBUG level -->
<logger name="PROTOCOL_MESSAGE">
<level value="TRACE" />
</logger>
<logger name="Shibboleth-Access">
<level value="ALL" />
<appender-ref ref="IDP_ACCESS" />
</logger>
<logger name="Shibboleth-Audit">
<level value="ALL" />
<appender-ref ref="IDP_AUDIT" />
</logger>
5.4.5.1 Restart the Apache Tomcat to take into account the updated Shibboleth
configuration
To complete the Shibboleth configuration, instance, proceed as follow:
1. Click Start, click Administrative Tools, and then click Services.
2. Right-click the Apache Tomcat service, and then click Restart.
5.5 Configure AD FS 2.0
Unless noted otherwise, all the instructions below are executed on the AD FS 2.0 IDMGT-DC
(idmgt-dc.idmgt.demo) machine.
5.5.1 Install the Shibboleth IdP SSL certificates in the Trusted Roots Store
At this stage, we need to add the self-signed certificates being used by Apache Tomcat at idmgtip0.idmgtext.demo into the Trusted Roots store of the AD FS 2.0 machine.
This makes it possible for Internet Explorer to trust this Web server during HTTPS communications.
To install the Shibboleth SSL certificate, proceed as follow:
1. Visit https://idmgt-ip0.idmgtext.demo with Internet Explorer.
2. At the security warning, click the link to continue to the website. The Address Bar turns red
to signify that the page is protected by an SSL certificate that is not trusted.
3. Click the Certificate Error message next to the Internet Explorer address bar, and then
click the View certificates link.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
43
4. In the Certificate window, on the General tab, click Install Certificate to start the
Certificate Import Wizard.
5. Click the Next button.
6. In the Certificate Store window, click the Place all certificates in the following store
option.
7. Click the Browse button, and then click the Show physical stores button.
8. In the Trusted Root Certificate Authorities folder, select Local Computer, and then click
the OK button.
9. Click the Next button, click the Finish button, click the OK button, and then click the OK
button.
10. Visit https://idmgt-ip0.idmgtext.demo:8443 with Internet Explorer. (Note the port number.)
Use the previous process to install this SSL certificate into the local computer’s Trusted
Roots store.
11. Close and then reopen Internet Explorer, and revisit both web addresses. In both cases,
the address bar should remain white, signifying working SSL channels.
5.5.2 Add the Shibboleth instance as a Claims Provider using metadata
We use the metadata import capabilities of AD FS 2.0 to create the Shibboleth claims provider. The
metadata includes the public key that is used to validate security tokens that Shibboleth signs.
We’ll use PowerShell to add the Shibboleth IdP to AD FS.
To add the Shibboleth instance as a claims provider, proceed as follow:
1. Open a command prompt and run the following PowerShell commands:
Add-PSSnapIn Microsoft.Adfs.PowerShell
Add-ADFSClaimsProviderTrust -Name "Shibboleth IdP" –MetadataFile https://idmgtip0.idmgtext.demo:8443/idp/profile/Metadata/SAML
Set-ADFSClaimsProviderTrust –TargetName "Shibboleth IdP" –SignatureAlgorithm
http://www.w3.org/2000/09/xmldsig#rsa-sha1
This will create an AD FS entry for the Shibboleth IdP using its metadata.
When it signs assertions, Shibboleth uses the Secure Hash Algorithm 1 (SHA-1) for
signing operations, while by default AD FS 2.0 expects partners to use SHA-256.
Consequently, for interoperability with Shibboleth, the above script specifies for AD FS 2.0
that Shibboleth will be using the SHA-1 hash algorithm for signing its responses.
Note:
For more information, see the AD FS 2.0 ADMINISTRATION WITH WINDOWS POWERSHELL56 section of
the AD FS 2.0 OPERATIONS GUIDE and the AD FS 2.0 CMDLETS REFERENCE 57.
5.5.3 Edit Claim Rules for Claims Provider Trust
The following claim rule describes how data from Shibboleth is used in the security token that is
sent to the AD FS 2.0.
44
56
AD FS 2.0 ADMINISTRATION WITH WINDOWS POWERSHELL: http://go.microsoft.com/fwlink/?LinkId=194005
57
AD FS 2.0 CMDLETS REFERENCE: http://go.microsoft.com/fwlink/?LinkId=177389).
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
To configure the claims for inbound receipt, proceed as follow:
1. Open the AD FS 2.0 Management console. On the Start menu, click Administrative
Tools, and then click AD FS 2.0 Management.
2. After the snap-in is loaded, click on the Trust Relationships node, and then highlight
Claims Provider Trusts.
3. In the AD FS 2.0 Management center pane, right-click Shibboleth IdP, and then click the
Edit Claim Rules item.
4. On the Acceptance Transform Rules tab, click the Add Rule button.
5. On the Select Rule Template page, select Send Claims Using a Custom Rule, and then
click the Next button.
6. On the Configure Rule page, in the Claim rule name box, type “Transform mail to E-Mail
Address”.
7. In the Custom Rule window, type or copy and paste the following:
c:[Type == "urn:oid:0.9.2342.19200300.100.1.3"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Issuer = c.Issuer,
OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);
8. Click the Finish button.
9. On the Acceptance Transform Rules tab, click the Add Rule button.
10. On the Select Rule Template page, select Send Claims Using a Custom Rule, and then
click the Next button.
11. On the Configure Rule page, in the Claim rule name box, type “Transform
eduPersonPrimaryAffiliation to Role”.
12. In the Custom Rule window, type or copy and paste the following:
c:[Type == "urn:oid:1.3.6.1.4.1.5923.1.1.1.5"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Issuer = c.Issuer,
OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);
13. Click the Finish button, and then click the OK button.
Note:
The object-identifier-style URN strings are the formal SAML 2.0 names for mail and
eduPersonPrimaryAffiliation names that the Shibboleth IdP software sends by default.
Note:
Attributes with formal names that are represented in URN strings cannot be passed
untransformed to WIF-based applications like SharePoint 2010, because WIF can only
understand claims using URL-style names. That is why we transform the incoming mail and
eduPersonPrimaryAffiliation attributes to E-Mail Address and Role claims, instead of retaining
their original claim types.
Note:
Unlike Shibboleth, when it reads inbound attributes AD FS 2.0 ignores the
urn:oasis:names:tc:SAML:2.0:attrname-format:uri name format that Shibboleth uses, and it
simply reads the value.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
45
Note:
Some Shibboleth attributes like eduPersonScopedAffiliation are scoped attributes, meaning
that Shibboleth (when it acts as the SP) checks the scope section of the attributes against a
value that is provided in an IdP partner's metadata.
When AD FS 2.0 acts as an SP, it does not read or store the IdP partner's scope value during
its metadata import. However, it is possible to use the AD FS 2.0 claim rule language to
simulate the "scope check" behavior of a Shibboleth SP, as shown below in the condition part
of a rule: c:[Type == "urn:oid:1.3.6.1.4.1.5923.1.1.1.9", Value =~ "^.+@<scope>"]
5.6 Test Shibboleth as the Identity Provider and AD FS 2.0 as the
Relying Party
All the instructions below are executed on the AD FS 2.0 IDMGT-DC (idmgt-dc.idmgt.demo)
machine.
Note:
Clear all the cookies in Internet Explorer on the AD FS 2.0 IDMGT-DC (idmgt-dc.idmgt.demo).
To clear the cookies, click Tools, click Internet Options, click Delete under Browsing History,
and then select cookies for deletion.
To test the federation relationship between Shibboleth and AD FS 2.0, proceed as follow:
1. Visit https://sts.idmgt.demo/adfs/ls/IdpInitiatedSignon.aspx with Internet Explorer.
2. When prompted at the AD FS 2.0 Home Realm Discovery page, choose Shibboleth IdP in
the combo box, and then click the button Continuer la connexion (Continue to Sign in
English).
You are redirected to Shibboleth IdP. The Shibboleth forms login page appears.
46
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
3. Log in with the user name “cc” and the password you created for the user earlier, and then
click the Login button. The Shibboleth IdP will grant you access and send an encrypted
token back to AD FS 2.0.
5.7 Other Issues?
If you run into issues, you may wish to check Tomcat and Shibboleth’s log files, located at:


%TOMCAT_HOME%\logs\

catalina.DATE.log

localhost.DATE.log
C:\opt\shibboleth-idp\logs\

idp-process.log
If you are still stumped, please check out the Shibboleth troubleshooting58 document at the
Internet2 site.
58
Shibboleth troubleshooting information: https://spaces.internet2.edu/display/SHIB2/Troubleshooting
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
47
6 Configure SharePoint 2010 as a Relying Party for AD
FS 2.0
In this second part of our walkthrough, AD FS 2.0 is the Claims Provider. We need to configure AD
FS 2.0 with information about our last Relying Party. In this case, SharePoint 2010 is our RP – it’s
depending on AD FS 2.0 to do the authentication and provide the claims. Based on the steps
outlined in the previous chapter, this task can be further delegated to the already configured
Shibboleth IdP.
From the SharePoint 2010 perspective, we have to configure it to trust the Claims Provider that is
sending us claims, and then we have to set up a web application and site that’s going to consume
those claims: http://idmgt-sps.idmgt.demo:8082/default.aspx.
To enable an identity federation trust between AD FS 2.0 and SharePoint 2010 both AD FS 2.0 and
SharePoint 2010 must undergo configuration steps. The related configuration includes manual
steps from the UI and/or Windows PowerShell scripts to run.
Whether you configure either SharePoint 2010 or AD FS 2.0 first or second does not matter. The
federation trust will not be complete until both are complete configured. We’ll begin by creating the
relying party in AD FS 2.0.
This part of the global federated collaboration scenario uses the WS-Federation protocol.
6.1 Prerequisites and requirements
The steps described in the following sections assume the availability of:

The IDMGT-DC (sts.idmgt.demo) (virtual) machine with AD FS 2.0 installed and up and
running at the following address: https://sts.idmgt.demo/adfs/ls/. This chapter also
assumes the default AD FS identifier is used: https://sts.idmgt.demo/adfs/services/trust.
This should normally be the case if the steps in the preceding chapter (first part of the
walkthrough) were covered.

The IDMGT-SPS (idmgt-sps.idmgt.demo) (virtual) machine with SharePoint 2010
Foundation (or Server) installed and configured, with the administration capabilities at the
following address: http://idmgt-sps.idmgt.demo:2010.
A bunch of articles and posts describe the setup of such a machine. One can use instead
the SharePoint Easy Setup59 Windows PowerShell scripts (see post ANNOUNCING
SHAREPOINT EASY SETUP FOR DEVELOPERS60).
6.2 Configure SharePoint 2010 as Relying Party in AD FS 2.0
Unless noted otherwise, all the instructions below are executed on the AD FS 2.0 IDMGT-DC
(idmgt-dc.idmgt.demo) machine.
59
SharePoint Easy Setup: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=54dc2eef-e9ea-4c7b-9470ec5cb58414de
60
ANNOUNCING SHAREPOINT EASY SETUP FOR DEVELOPERS:
http://blogs.msdn.com/b/cjohnson/archive/2010/10/28/announcing-sharepoint-easy-setup-for-developers.aspx
48
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
6.2.1 Configure SharePoint 2010 as a new Relying Party
To add SharePoint 2010 as a new relying party, proceed as follow:
1. Open the AD FS 2.0 Management console. On the Start menu, click Administrative
Tools, and then click AD FS 2.0 Management.
2. After the snap-in is loaded, click on the Trust Relationships node, and then highlight
Relying Party Trusts.
3. Right-click on Relying Party Trusts and click the Add Relying Party Trust item to start
the Relying Party trust wizard. The Add Relying Party Trust Wizard opens.
4. Click the Start button to begin adding the SharePoint 2010 Web application as a Relying
Party.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
49
5. On the Select Data Source page, select Enter data about the Relying party manually,
and then click the Next button.
6. On the Specify Display Name page, enter a display name, for example “SharePoint” and
optionally a description for the relying party, for example “This is for my SharePoint 2010
SAML claims web application”, and then click the Next button.
50
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
7. On the Choose Profile page select AD FS 2.0 profile and click the Next button.
8. On the Configure Certificate page, you can select a certificate to encrypt the SAML
assertion itself. This isn’t done frequently because AD FS 2.0 will require our connection to
SharePoint 2010 be made over SSL, so the channel the token is sent over is encrypted
already. Click the Next button.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
51
9. Check the box to Enable support for the WS-Fed Passive protocol. For the protocol
URL, you need to enter the URL for the SharePoint 2010 web application’s root site, and
include the “_trust” subdirectory. In this guide, the URL to the SharePoint 2010 web
application is https://idmgt-sps.idmgt.demo:8082, so the WS-Fed Passive protocol URL is
https://idmgt-sps.idmgt.demo:8082/_trust/. After entering your URL, click the Next button.
Note:
This is the URL of the federation services endpoint in the SharePoint 2010 built in STS
(SharePoint 2010 WIF integrated) of this Web Application.
10. On the Configure Identifiers page, you need to enter a realm that your Web application
will pass to AD FS 2.0 when users log into the web application.
52
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
The realm is generally created in the format of urn:foo:bar. The realm is associated with a
web application and is how AD FS 2.0 can map the login request that’s come in to the
relying party trusts it has. When used with SharePoint 2010, AD FS 2.0 sees the realm
associated with the login request, it looks that up to find the relying party trust, and then
after it authenticates the user it looks to that WS-Fed Passive protocol URL to know where
to redirect the user afterwards.
So in this case, we’ve entered a realm of urn:sharepoint:portal. When we try navigating to
the SharePoint 2010 site at https://idmgt-sps.idmgt.demo:8082, we’ll be redirected to AD
FS 2.0 and we’ll configure SharePoint 2010 to use the realm urn:sharepoint:portal for that
request. Once AD FS 2.0 has authenticated us it will redirect us again to https:// idmgtsps.idmgt.demo:8082/_trust/ because that’s the passive protocol URL for that relying party.
Add whatever realm you want to use here and make a note of it because you will need to
enter it again when you configure SharePoint 2010. Then click the Next button.
Note:
All identifiers must be unique among relying party configurations, also the identifier must match
the realm string value in the SPTrustedIdentityTokenIssuer configuration.
11. On the Choose Issuance Authorization Rules page, keep default select and click the
Next button.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
53
Note:
In most cases you will want all of your users to be able to use this relying party. We’ll assume
that’s the case for this scenario.
12. On the Ready to Add Trust page, review trust configuration settings. If you needed to
make any other configuration changes at this time to the relying party trust you could do it
here. For this scenario we don’t need to so just click the Next button to continue.
13. We’re done configuring the relying party trust but we still need to create a claim rule to tell
AD FS 2.0 what claims to send back to SharePoint 2010. So leave the box checked to
Open the Edit Claim Rules dialog for this relying party trust when the wizard closes
and click the Close button.
54
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
14. After Relying party trust is added, click the Close button and start edit claim mappings for
the SharePoint 2010 Web Application Relying Party.
15. Now we are going to create a new rule, so in the Rules Editor, on the Issuance Transform
Rules tab, click the Add Rule button.
For our scenario we want to send email address and the roles to which the user belongs
back to SharePoint 2010.
We are going to use email address as the identifier for the person
(http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress), and we want all the
groups or roles a user belongs to pass through in the Role claim
(http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role).
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
55
16. For internal users, we are going to send LDAP attributes as claims because we are getting
information from Active Directory in this case, meaning we will authenticate at AD FS and
AD FS is going to use the corporate IDMGT Active Directory to authenticate us and
determine what our attributes are. So leave the default value selected and click the Next
button to continue.
17. Start out by typing in a Claim rule name; it can be whatever you want, for example “Active
Directory Claims”.
18. Next, in the Attribute store drop down select Active Directory. Next, for our walkthrough,
we want to send email address and the groups to which the corporate user belongs in the
IDMGT domain back to SharePoint 2010.
To do the mapping, select the attribute you want from the drop down on the left side, and
then select the claim that it will be sent out as in the drop down in the right pane.
In this case we want :

The E-Mail-Addresses attribute from Active Directory to be sent out in the standard EMail Address claim.

The groups to which a user belongs to be sent out in the standard Role claim. In this
case we’ve selected Token-Groups – Unqualified Names because it sends the group
name out as a simple string – the name of the group. You could send out the SID of
the groups but that becomes more difficult to use when you are trying to assign a Role
claim to a SharePoint group.
After you’ve finished configuring this rule as described here, click the Finish button to
complete the rule.
56
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
19. Now we are going to create a new rule for the external users that authenticate with the
Shibboleth IdP. Indeed, for these external users, at this point, incoming claims can be
received at AD FS 2.0, but rules that describe what to send to the SharePoint 2010
application have not yet been created. So, we are going to extend the existing claim rules
for the SharePoint 2010 application to take into account the Shibboleth external claims
provider.
Since we want to send both the E-Mail Address and the Role claims back to SharePoint
2010, we are consequently going to create two new rules, one for each of the two above
claims, so in the Rules Editor, on the Issuance Transform Rules tab, click the Add Rule
button.
20. In the Select Rule Template page, select Pass Through or Filter an Incoming Claim,
and then click the Next button.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
57
21. On the Configuration Rule page, type the following values:
Name
Value
Claim rule name
“E-Mail Address Claim from Shibboleth”
Incoming claim type
E-Mail Address
22. Leave the Pass through all claim values option selected, and then click the Finish
button.
23. On the Issuance Transform Rules tab, click the Add Rule button.
24. On the Select Rule Template page, select Pass Through or Filter an Incoming Claim,
and then click the Next button.
25. On the Configure Claim Rule page, type the following values:
Name
Value
Claim rule name
“Role Claim from Shibboleth”
Incoming claim type
Role
26. Leave the Pass through all claim values option selected, and then click the Finish
button.
27. Once all claim mappings are created click the Apply button, then the OK button to close
the Edit Claim Rules for SharePoint and to complete the process of creating your relying
party trust in AD FS 2.0.
From a configuration standpoint in AD FS 2.0, there’s nothing else we need to do. However there is
one other thing we need to get from it. AD FS 2.0 uses a certificate to sign the tokens it sends out.
This ensures the consumer of the token that it has not been tampered with since it was created.
To configure SharePoint 2010 and create a SpTrustedIdentityTokenIssuer in SharePoint, we need
a copy of this certificate because we’ll use it when configuring it to use AD FS 2.0 as the trusted
identity provider.
58
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
6.2.2 Export the AD FS token signing certificate
To get this token signing certificate from AD FS 2.0, proceed as follow :
1. In the AD FS 2.0 Management console, expand the Service node and click on the
Certificates node.
2. There is a section there for Token-signing certificates. You may have one to many tokensigning certificates, but there will always be ONLY one Primary token signing certificate.
Click on that certificate, and then click on the View Certificate link in the right pane.
3. Now that you are viewing the certificate, click on the Details tab at the top of the dialog
box.
4. Click on the Copy to File button. That will start a wizard to save a copy of the certificate to
disk.
5. Click the Next button to continue.
6. You don’t need the private key, so accept the default settings and click the Next button.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
59
7. The default format is fine so click the Next button to continue.
8. Pick a location to save the certificate and click the Next button. Make sure you remember
this location because you will need to copy the certificate from where you save it over to
the SharePoint 2010 IDMGT-SPS (idmgt-sps.idmgt.demo) machine.
60
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
9. All the information needed to copy the certificate locally has been captured now so click the
Finish button to complete the wizard and save the certificate to a local file.
10. Copy this file to the SharePoint 2010 machine, for instance under the c:\share folder and
then we are finished with the AD FS 2.0 machine.
Switch over to the SharePoint 2010 machine and we will begin configuring it.
6.3 Create a SharePoint 2010 Web application
Unless noted otherwise, all the instructions below are executed on the SharePoint 2010 IDMGTSPS (idmgt-sps.idmgt.demo) machine.
On the SharePoint 2010 machine, we need to create, at this stage, a SharePoint Web application
using claims based authentication.
Since this is a more than common operation on SharePoint, we don’t want to dive into much detail
on how to create such a Web application in order to keep this guide as concise as possible.
Consequently, we simply mention the key steps and outline the key screenshots for the settings for
the claims based authentication.
Note:
Keep NTLM/KERBEROS[Windows Claims] Authentication, In a production deployment of
SharePoint 2010 you would want 2 web applications with the default using
NTLM/KERBEROS[Windows Claims] Authentication and a second using only the trusted claims
identity authentication.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
61
Modify SharePoint Web Application URL (http://idmgt-sps:8082) to add FQDN (http://idmgtsps.idmgt.demo:8082) through Alternate Access Mappings edit screen.
Once you’ve created your web application remember to go into the IIS Manager, create a domain
Certificate for idmgt-sps.idmgt.demo and edit the bindings for the new virtual server so you can
assign the appropriate SSL idmgt-sps.idmgt.demo certificate.
These steps are somehow outside the scope of this document, but are well-documented in many
places around the Internet.
To recap, for our walkthrough then there is, at this stage, a Web application we’ve created that
uses Port 8082 and SSL and the URL for that Web application is https://idmgtsps.idmgt.demo:8082.
62
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
6.4 Create a Trusted Identity Provider corresponding to the AD
FS 2.0 instance
All the instructions below are executed on the SharePoint 2010 IDMGT-SPS (idmgtsps.idmgt.demo) machine.
The first thing we are now going to do on the SharePoint 2010 side is to add the token signing
certificate we’ve previously copied from the AD FS 2.0 machine. Before we do that though, we
need to look at the certificate.
Indeed, the token signing certificate may have one or more parent certificates in its chain. If it
does, we need to add every certificate in that chain to SharePoint’s list of trusted root authorities.
To figure that out, we’ll find the token signing certificate we copied over from AD FS 2.0 and
double-click on it; that brings up the certificate properties window.
If you click on the Certification Path tab you can see if there are any other certificates in the chain.
In our scenario, our token signing certificate DOESN’T have a parent – it is a self-signed certificate.
If the token signing certificate would have parent(s), what we need to do now, is for each certificate
in the chain above our token signing certificate, we need to save a copy of each one locally. We
can do that by clicking on the certificate, which enables the View Certificate button in the dialog. If
we click on that it will open a separate properties dialog for that certificate.
We can then follow the same process we described earlier to save a copy of the certificate to disk:
1. Click on the Details tab,
2. Click on the Copy to File button,
3. Then save the certificate locally as a .cer file.
In our case, we simply have to consider the token signing certificate we copied from the AD FS 2.0
machine: c:\share\adfs.cer.
Now, we need to add it to our list of trusted root authorities. We’re going to do that in
PowerShell with this script. All the following commands should be entered at the PowerShell
Prompt with an Enter after each statement.
Note:
Windows PowerShell cmdlets available to administer security for SharePoint 2010 are detailed in the
page SECURITY CMDLETS (SHAREPOINT SERVER 2010)61.
Open PowerShell Management Console for SharePoint 2010 as an Administrator:
1. Click Start, All programs, Microsoft SharePoint 2010 Products and SharePoint
Management Shell to run Windows PowerShell commands.
After PowerShell opens, run the following two commands below to get a reference to the
token signing certificate copied from the AD FS 2.0 machine:
$certPath = “c:\share\adfs.cer”
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath")
2. Create a new trusted root authority provider with SharePoint 2010. Run the following
command:
New-SPTrustedRootAuthority -Name "IDMGT ADFS Token Signing Trusted Root Authority" -Certificate $cert
61
: http://technet.microsoft.com/en-us/library/ee890110.aspx
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
63
Note:
As aforementioned, you’ll want to repeat this for each of the certificate(s) in the chain.
Also, confirm that your certificate(s) were added to the trusted root authority (by viewing the
certificate(s) under General Security/Manage Trust in Central Administration. In our
walkthrough, there should be one entry (“IDMGT ADFS Token Signing Trusted Root
Authority”) listed in the Trust Relationships tab:
3. Create the claim mappings that SharePoint 2010 is going to use. If you recall from earlier
in this document we mentioned that we were going to use the standard E-Mail Address and
Role claims in SharePoint 2010.
Here’s the PowerShell that we’ll use to create those mappings:
$map1 = New-SPClaimTypeMapping -IncomingClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName
"EmailAddress" –SameAsIncoming
$map2 = New-SPClaimTypeMapping -IncomingClaimType
"http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –
SameAsIncoming
4. Create a variable for the realm (a unique URI for your site) that we want SharePoint 2010
to use. It must match what has been configured for the site in AD FS 2.0.
For this walkthrough, this is the realm urn:sharepoint:portal. Also create another variable
for the sign-in URL. This is how AD FS 2.0 knows which site to pass the claims back to.
Here’s the PowerShell to create these realm and signinurl variables:
$realm = "urn:sharepoint:portal"
$signinurl = “https://sts.idmgt.demo/adfs/ls”
5. Create and configure a new SPTrustedIdentityTokenIssuer in order to configure
SharePoint 2010 to accept SAML claims (WS-Fed Passive only).
This is where we tie together all of the configuration information so SharePoint 2010 knows
how to connect and work with our AD FS 2.0 instance. We’ll show the PowerShell here and
then explain the important parts:
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFSv2-sts.idmgt.demo" -Description "ADFSv2-sts.idmgt.demo" realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2 -SignInUrl $signinurl IdentifierClaim $map1.InputClaimType
64
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies

The Name attribute is what is going to show up in your web application when you
configure what authentication provider it should use.

The realm attribute is where we plug in the realm that we want SharePoint to use with
this trusted identity token issuer.

The ImportTrustCertificate attribute is where we pass it the token signing certificate
that we copied from the AD FS 2.0 machine.

The ClaimsMappings attribute is where we tell it what the claims are that we want this
trusted identity token issuer to use.

The SignInUrl is the URL that users should be redirected to in order to authenticate
with our AD FS 2.0 instance. In this case we want users to further authenticate with
the Shibboleth IdP, so we send them to the /adfs/ls subdirectory for home realm
discovery.

Finally, the IdentifierClaim attribute tells SharePoint 2010 which of the claims is going
to be THE claim that is used to identify users. In this case we’re saying the standard
E-Mail Address claim is how you identify a person.
Once
that
last
PowerShell
command
has
executed,
we
have
a
SPTrustedIdentityTokenIssuer that can be used with our SharePoint 2010 Web
application.
6. Review the SPTrustedIdentityTokenIssuer settings with the following command:
Get-SPTrustedIdentityTokenIssuer –Identity "ADFSv2-sts.idmgt.demo"
7. Close the SharePoint Management Shell.
6.5 Declare the Trusted Identity Provider for the Web application
All the instructions below are executed on the SharePoint 2010 IDMGT-SPS (idmgtsps.idmgt.demo) machine.
To declare the Trusted Identity Provider for the web application, proceed as follow:
1. Click Start, All programs, Microsoft SharePoint 2010 Products and SharePoint 2010
Central Administration.
2. Under Application Management, then click on the Manage Web Applications link.
3. Highlight in the list the web application created earlier that’s going to use AD FS 2.0 to
authenticate and click Authentication Providers in the ribbon.
4. On the Authentication Provider page, click the link in the dialog that corresponds to the
appropriate zone in which you are going to use AD FS 2.0 to authenticate. This is the
Default Zone in our walkthrough.
5. In the Edit Authentication page, slide down to the Claims Authentication Types section.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
65
6. Select Trusted Identity Provider and then “ADFSv2-sts.idmgt.demo” in the list of trusted
providers.
Note:
After we added the SPTrustedIdentityTokenIssuer, this functionality is enabled, also we can leave
Windows Authentication enabled in the same zone
7. Leave Windows Authentication selected.
Note:
A great new feature in SharePoint 2010 is the ability to specify multiple authentication providers on a
given zone within a web application. E.g. you can leave Windows Authentication (NTLM) checked and
also check Trusted Identity Provider. Doing so will give you an option when you load the web
application to choose which authentication method you want.
8. Click Save to save changes.
9. Close SharePoint 2010 Central Administration.
Now you can go and create a SharePoint 2010 site collection for the web application created above
and a Site Administrator using Windows Claims authentication.
Again, describing that process step-by-step is not in scope for this document, but there is one
important thing to remember when you do this. When you add the Site Collection Administrator,
remember to enter the name in the format of your identity claim. For example, in this walkthrough
the identity claim is the standard E-Mail Address claim.
66
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
So when we added the Site Collection Administrator, the name we used was spadmin@idmgt.demo, because that’s the email address of the person we want to be the Site
Collection Administrator.
6.6 Test the Web application as a Corporate User
All the instructions below are executed on the AD FS 2.0 IDMGT-DC (idmgt-dc.idmgt.demo)
machine.
Note:
Clear all the cookies in Internet Explorer on the AD FS 2.0 IDMGT-DC (idmgt-dc.idmgt.demo).
To clear the cookies, click Tools, click Internet Options, click Delete under Browsing History,
and then select cookies for deletion.
To try and go to the SharePoint 2010 Web application as a corporate internal user, proceed as
follow:
1. Visit https://idmgt-sps.idmgt.demo:8082 with Internet Explorer. You are now invited to
choose which authentication method you want (from the SharePoint 2010 perspective).
2. Select “ADFSv2-sts.idmgt.demo” in the combo box to be authenticate by our AD FS 2.0
instance that is trusted as an identity provider.
The first thing that happens is a redirect to the SignInUrl for the
SPTrustedIdentityTokenIssuer that’s associated with our web application. If you recall
from the PowerShell that was used to create the SPTrustedIdentityTokenIssuer, that URL
is https://sts.idmgt.demo/adfs/ls. So here’s what we see in the browser address bar:
You can see the URL in the browser window now points to our AD FS machine and you
can see the graphic in the background behind the login dialog is for the AD FS machine.
3. Select “sts.idmgt.demo” in the combo box and click the Continuer la connexion button
(Continue to Sign in English). You are now invited to enter your credentials.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
67
You may notice that we’re signing in using our Windows credentials, i.e. domain\user. The
sp-admin account must have an email address, in our case: sp-admin@idmgt.demo.
Remember we’re authenticating on the AD FS 2.0, not on SharePoint 2010. Indeed,
SharePoint 2010 is configured to use the standard E-Mail Address claim as the identity, but
what is going to happen is that we’ll authenticate over on AD FS 2.0, and then it will use
the claim rule we created to pull out the email address and put them into claims that will be
sent back to SharePoint 2010.
4. So then after we’ve authenticated, we’re redirected back to SharePoint 2010 at
https://idmgt-sps.idmgt.demo/_trust/, as we configured in the relying party we set up in AD
FS 2.0.
At that point SharePoint 2010 will complete the authentication process on its side as it
takes the claims it got in the SAML token and converts it into an SPUser. Then we finally
arrive at the home page for the site:
You’ll notice the login control in the upper right-hand part of the page is displaying the identity as
email address, since that is the identity claim.
68
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
6.7 Test the Web application as a Shibboleth external user
Let’s test now some email address not related to any corporate account. In this walkthrough, we
are going to authenticate as the cc@windows.shibboleth user previously created on the Shibboleth
side (see section § 5.4.1.4 CREATE AND CONFIGURE A TEST USER FOR THE SHIBBOLETH IDP).
This requires giving him permissions through SharePoint 2010.
From this point, all the instructions below are executed on the AD FS 2.0 IDMGT-DC (idmgtdc.idmgt.demo) machine.
Note:
Clear all the cookies in Internet Explorer on the AD FS 2.0 IDMGT-DC (idmgt-dc.idmgt.demo).
To clear the cookies, click Tools, click Internet Options, click Delete under Browsing History,
and then select cookies for deletion.
To try and go to the SharePoint 2010 Web application as a Shibboleth external user, proceed
as follow:
1. Visit https://idmgt-sps.idmgt.demo:8082 with Internet Explorer. You are now invited to
choose which authentication method you want (from the SharePoint 2010 perspective).
2. Select “ADFSv2-sts.idmgt.demo” in the combo box to be authenticate by our AD FS 2.0
instance that is trusted as an Identity Provider.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
69
1. When prompted at the AD FS 2.0 Home Realm Discovery page, choose Shibboleth IdP in
the combo box, and then click the button Continuer la connexion (Continue to Sign in
English).
You are redirected to Shibboleth IdP. The Shibboleth forms login page appears.
2. Log in with the user name “cc” and the password you created for the user earlier, and then
click the Login button. The Shibboleth IdP will grant you access and send an encrypted
token back to AD FS 2.0, which emits in turn a token back to the SharePoint 2010
application.
And now we are using SharePoint 2010 with a cc@windows.shibboleth email identity.
That’s the complete end-to-end process with a little explanation on the side.
You should now be able to use it to get your SharePoint 2010 sites configured and running by
these instructions in the context a Shibboleth-based federation.
As mentioned before, Office Web Apps, the online companion to Office Word 2010, Excel 2010,
PowerPoint 2010 and OneNote 2010 applications, enables users to access, and slightly change
documents directly from SharePoint 2010. This online companion gives more flexibility to users
who can use the Web browser to work on their documents.
70
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
We don’t illustrate this scenario in so far as it doesn’t introduce anything new from our identity and
security perspective, considering the below established security context.
The next section rather illustrates the use of Office 2010 applications in conjunction with
SharePoint 2010 sites.
Before covering this scenario, we strongly encourage you to complete this walkthrough with the
reading of some of the posts of the weblog Share-n-dipity62 from the Microsoft employee Steve
Peschka. As a starting point, we want to outline the following posts amongst many others of
interest:

SETTING THE LOGGING TOKEN EXPIRATION CORRECTLY FOR SHAREPOINT 2010 SAML CLAIMS
USERS63.

HOW TO OVERRIDE THE DEFAULT NAME RESOLUTION AND CLAIMS PROVIDERS IN SHAREPOINT
201064.

REPLACING THE OUT OF BOX NAME RESOLUTION IN SHAREPOINT 2010 – PART 265.

MORE INFORMATION ON ADDING AND CHANGING CUSTOM CLAIMS PROVIDERS IN SHAREPOINT
201066.

Etc.
Thanks again Steve Peschka.
6.8 Use Office 2010 with the Web application a Shibboleth
external user
From this point, all the instructions below are executed on the AD FS 2.0 IDMGT-DC (idmgtdc.idmgt.demo) machine.
6.8.1 Add document to the Shared Documents library
This section assumes that you are currently using SharePoint 2010 with a cc@windows.shibboleth
email identity with a valid opened Internet Explorer session.
To add, as a Shibboleth external user, a Word document to the Shared Document library of the
SharePoint 2010 Web application, proceed as follow:
1. From the https://idmgt-sps.idmgt.demo:8082/SitePages/Accueil.aspx Web site home page,
click the Documents partagés link (Shared Documents in English) in the upper left
corner. You are now redirected the Shared Documents library.
62
Weblog Share-n-dipity: http://blogs.technet.com/b/speschka/
63
SETTING THE LOGGING TOKEN EXPIRATION CORRECTLY FOR SHAREPOINT 2010 SAML CLAIMS USERS:
http://blogs.technet.com/b/speschka/archive/2010/08/09/setting-the-login-token-expiration-correctly-for-sharepoint-2010saml-claims-users.aspx
64
HOW TO OVERRIDE THE DEFAULT NAME RESOLUTION AND CLAIMS PROVIDERS IN SHAREPOINT 2010:
http://blogs.technet.com/b/speschka/archive/2010/04/28/how-to-override-the-default-name-resolution-and-claims-providerin-sharepoint-2010.aspx
REPLACING THE OUT OF BOX NAME RESOLUTION IN SHAREPOINT 2010 – PART 2:
http://blogs.technet.com/b/speschka/archive/2010/05/25/replacing-the-out-of-box-name-resolution-in-sharepoint-2010-part2.aspx
65
66
MORE INFORMATION ON ADDING AND CHANGING CUSTOM CLAIMS PROVIDERS IN SHAREPOINT 2010:
http://blogs.technet.com/b/speschka/archive/2010/06/02/more-information-on-adding-and-changing-custom-claimsproviders-in-sharepoint-2010.aspx
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
71
2. Click the Ajouter un document link (Add a document in English).
3. In the SharePoint dialog box Télécharger un document (Download a document in
English), specify a Word document, for example “Lorem.docx”, and click the OK button.
The document now belongs to the library.
4. Repeat the steps 2 and
“LoremSpreadSheet.xlsx”.
3
to
add
an
Excel
spreadsheet,
for
example
6.8.2 Open a document from a Document library
This section assumes that you are still using the same session with SharePoint 2010 as the one
used in the previous section.
72
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
To open, as a Shibboleth external user, a Word document from the Shared Document library of
the SharePoint 2010 Web application, proceed as follow:
1. From the https://idmgt-sps.idmgt.demo:8082/Documents partages page, double click the
Word document, for example “Lorem.docx”. The Open Document dialog box pops up.
2. Click the OK button to confirm. Office Word 2010 starts.
The document transparently opens. You are now able to work with the document with
Office Word 2010.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
73
3. Close the Office Word 2010 application.
6.8.3 Open a document stored in SharePoint 2010 from Office Word 2010
To open from within Office 2010 Word, as a Shibboleth external user, a Word document from
the Shared Document library of the SharePoint 2010 Web application, proceed as follow:
1. Launch the Office Word 2010 application.
2. From the File tab in the Ribbon, click the Open button.
The Open dialog box opens.
3. In the File name textbox, type the address of the SharePoint Web application, for example
https://idmgt-sps.idmgt.demo:8082 and click the Open button. A https://idmgtsps.idmgt.demo dialog box opens.
3. You are now invited to choose which authentication method you want (from the SharePoint
2010 perspective).
74
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
4. As already done before, select “ADFSv2-sts.idmgt.demo” in the combo box to be
authenticate by our AD FS 2.0 instance that is trusted as an Identity Provider.
3. When prompted at the AD FS 2.0 Home Realm Discovery page within the dialog box,
choose Shibboleth IdP in the combo box, and then click the button Continuer la
connexion (Continue to Sign in English).
You are redirected to Shibboleth IdP. The Shibboleth forms login page appears within the
dialog box.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
75
4. Log in with the user name “cc” and the password you created for the user earlier, and then
click the Login button. The Shibboleth IdP will grant you access and send an encrypted
token back to AD FS 2.0, which emits in turn a token back to the SharePoint 2010
application.
And now we are authenticated in SharePoint 2010 with a cc@windows.shibboleth email
identity.
4. Back in the Open dialog, double click the Documents partagés link (Shared Documents
in English) in the upper left corner. You are now redirected the Shared Documents library
from with the Open dialog.
76
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
5. Once again, select the Word document, for example “Lorem.docx” and then click the Open
button.
The document transparently opens. You are now able to work with the document with
Office Word 2010.
1. Close the Office Word 2010 application.
6.8.4 Open a spreadsheet stored in SharePoint 2010 from Office Excel 2010
In order to demonstrate that the integration depicted for Office Word 2010 is not specifically limited
to the Office Word 2010 application, this section illustrates the same scenario as the one outlined in
the previous section, but, this time, with the Office Excel 2010. Again, the same scenario could
have been demonstrated with the Office PowerPoint 2010.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
77
To open from within Office 2010 Excel, as a Shibboleth external user, a spreadsheet from the
Shared Document library of the SharePoint 2010 Web application, proceed as follow:
1. Launch the Office Excel 2010 application.
2. From the File tab in the Ribbon, click the Open button. The Open dialog box opens.
3. In the File name textbox, type the address of the SharePoint Web application, for example
https://idmgt-sps.idmgt.demo:8082 and click the Open button. A https://idmgtsps.idmgt.demo dialog box opens.
5. You are now invited to choose which authentication method you want (from the SharePoint
2010 perspective).
6. As already done before, select “ADFSv2-sts.idmgt.demo” in the combo box to be
authenticate by our AD FS 2.0 instance that is trusted as an Identity Provider.
5. When prompted at the AD FS 2.0 Home Realm Discovery page, choose Shibboleth IdP in
the combo box, and then click the button Continuer la connexion (Continue to Sign in
English). You are redirected to Shibboleth IdP.
78
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
6. Log in with the user name “cc” and the password you created for the user earlier, and then
click the Login button. The Shibboleth IdP will grant you access and send an encrypted
token back to AD FS 2.0, which emits in turn a token back to the SharePoint 2010
application.
We are now authenticated in SharePoint 2010 with a cc@windows.shibboleth email
identity.
4. Back in the Open dialog, double click the Documents partagés link (Shared Documents
in English) in the upper left corner. You are now redirected the Shared Documents library
from with the Open dialog.
5. Once again, select the Excel spreadsheet, for example “LoremSpreadSheet.xlsx” and then
click the Open button. You are now able to work with the spreadsheet with Office Excel
2010.
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
79
6. Close the Office Excel 2010 application.
80
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
Appendix A. Use AD FS 2.0 in the RENATER Federation
In addition to the configuration steps provided earlier in this document, the following is a list of
additional considerations for organizations using AD FS 2.0 for participation in the EducationRecherche RENATER Federation67.
In the context of this federation, the federation testing metadata are accessible at https://servicesfederation.renater.fr/metadata/renater-test-metadata.xml while the one related to the ÉducationRecherche federation are located at https://services-federation.renater.fr/metadata/renatermetadata.xml. All the associated information is grouped at the Renater federation web site68.
Topic Areas
Issue Description
Workarounds
Metadata
The RENATER metadata file includes
multiple
federation
entities
(EntityDescriptors), but AD FS 2.0 cannot
import metadata files that include more than
one EntityDescriptor.
Open-source solution
discussed below.
Metadata,
Certificates
RENATER
EntityDescriptor
elements
sometimes contain more than one
encryption certificate, but AD FS 2.0 fails to
import entities that include more than one
encryption certificate.
No
product-based
workaround.
Organizations using AD FS 2.0 can
add these organizations manually,
ignoring all but one encryption
certificate. Organizations publishing
metadata through RENATER can
improve AD FS 2.0 interoperability
by publishing only one encryption
certificate per entity.
Metadata,
Certificates
The RENATER metadata file includes
instances where multiple EntityDescriptors
share a single certificate, but AD FS 2.0 fails
to import any entities that present a
certificate already in the database.
No
product-based
workaround.
Organizations publishing metadata
through RENATER can improve
AD FS 2.0 interoperability by using
unique certificates per entity. The
same certificate can be used for
signing and encryption.
MACE-Dir Profiles
support
The RENATER testing federation includes a
support for the MACE-Dir SAML Attribute
Profiles69, in which a Name ID is provided in
an
XML-based
eduPersonTargetedID
attribute statement. In accordance to
interoperability profiles like INTEROPERABLE
SAML 2.0 W EB BROWSER SSO DEPLOYMENT
PROFILE, AD FS 2.070 doesn’t support nonstring attribute values.
No product-based workaround.
(FEMMA)
67
Education-Recherche RENATER Federation: https://federation.renater.fr/
68
RENATER federation metadata: https://federation.renater.fr/technique/metadata
69
MACE-DIR SAML ATTRIBUTE PROFILES: http://middleware.internet2.edu/dir
70
INTEROPERABLE SAML 2.0 W EB BROWSER SSO DEPLOYMENT PROFILE, AD FS 2.0: http://saml2int.org/profile/current
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
81
Parse metadata with FEMMA
The open source FEMMA (FEderation Metadata Manager for ADFS71)
project on SourceForge, written by Cristian Mezzetti of the University of Bologna, is a Python script
that parses Shibboleth federation metadata XML content and creates (a) a pool of metadata files
(one for each partner entity) and (b) a Windows PowerShell command-line interface script that
automatically imports the entities into AD FS 2.0.
In addition, FEMMA includes templates for automatically importing claim rules into newly created
partner entities.
Note:
FEMMA is a tool that is independent and separate from both AD FS 2.0 and Shibboleth. Microsoft,
Internet2, and RENATER neither developed this tool nor endorse it through its reference in this
whitepaper.
Note:
Larger files like the Education-Recherche RENATER metadata file may take a long time to
process, because Windows PowerShell will encounter numerous exceptions during the import
related to the second and third (certificate-related) issues in the previous table.
FEMMA includes a blacklist capability for optionally excluding entities from the generated
Windows PowerShell script, which can improve performance.
Install FEMMA on the AD FS 2.0 (shib.adatum.com) machine:
To install FEMMA on the AD FS 2.0 machine, proceed as follow:
1. Download Python 2.572.
2. Install Python.
3. Download lxml73.
4. Place the lxml install file in the Python folder (C:\Python25\).
5. Install lxml.
6. Download FEMMA.
7. Unzip FEMMA.
82
71
FEDERATION METADATA MANAGER FOR ADFS: http://sourceforge.net/projects/femma/files/
72
Python 2.5: http://go.microsoft.com/fwlink/?LinkId=204170
73
Lxml: http://go.microsoft.com/fwlink/?LinkId=204171
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
Use FEMMA to Import IdPs
As of writing, FEMMA, in its current form, i.e. version 0.4.1, unfortunately only imports and
configures SPSSODescriptors in SAML 2.0 metadata files. The support for IDPSSODescriptors is
expected to be part of the next version 0.5.
In the context of this guide, those interested in importing IDPSSODescriptors can use the edited
Python script and template files available in the guide AD FS 2.0 STEP-BY-STEP GUIDE: FEDERATION
WITH SHIBBOLETH 2 AND THE INCOMMON FEDERATION74. As mentioned in the introduction (see section
§ 1.3 ABOUT THIS GUIDE), this guide describes how to configure AD FS 2.0 and Shibboleth to
federate using the SAML 2.0 protocol.
74
AD FS 2.0 STEP-BY-STEP GUIDE: FEDERATION WITH SHIBBOLETH 2 AND THE INCOMMON FEDERATION:
http://go.microsoft.com/fwlink/?LinkId=204784
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
83
Appendix B. Other possibilities outside the scope of this
guide
The purpose of this section is to highlight other possibilities that are outside the scope of this
document but are available to architects when they deploy federation between Shibboleth 2 and
AD FS 2.0.
WS-Federation support
AD FS 2.0 also supports the WS-Federation protocol for Web-based federation and SSO. The
Shibboleth 2 likewise supports WS-Federation.
For information about how to deploy a test lab between Shibboleth and AD FS using WSFederation, see the legacy ADFS STEP-BY-STEP GUIDE: FEDERATION WITH SHIBBOLETH FEDERATION
SERVICES75. While this document was written using older versions of AD FS and Shibboleth, the
content in this document can be extrapolated to current versions.
With the use of the WS-Federation, one should note that a trust can be established directly
between Shibboleth 2 and SharePoint 2010 (and more specifically the SharePoint 2010 Security
Token Service (STS) exposed on the Web Front-End). This said having AD FS 2.0 playing the role
of a Federation Server for the organization that exposes the SharePoint 2010 resource eases the
exposition of additional relying party applications like Outlook Web Access (OWA) 2010.
Certification authority–issued, token-signing certificates
For security reasons, production federation deployments require the use of digitally signed security
tokens. This guide uses self-signed, private key certificates, which are generated from inside the
Shibboleth 2, AD FS 2.0 and SharePoint 2010 products, for signing security tokens.
As an alternative, organizations can choose to use a private key certificate issued by a certification
authority (CA) for security-token signing. The primary benefit of using certificates that are issued by
a CA for token-signing is the ability to check for possible certificate revocation against the
certificate revocation list (CRL) from the issuing CA when acting as a Relying Party or Service
Provider.
Shibboleth 2 does not perform CRL checking. Instead, it uses continuously refreshing/expiring
metadata to manage the replacement and discontinuation of support for a given certificate. In
AD FS 2.0, CRL checking is enabled by default for all Claims Provider trusts. This has implications
in federation deployments between Shibboleth (acting as an Identity Provider/Claims Provider) and
AD FS 2.0 (acting as a Service Provider/Relying Party) as considered in this guide:
75

If the signing private key that Shibboleth 2 uses includes a CRL Distribution Point (CDP)
extension, that location must be accessible by the AD FS 2.0 Federation Server, or CRL
checking fails, resulting in a failed access attempt. CDP extensions are added by default to
certificates that are issued by Active Directory Certificate Services (AD CS) in
Windows Server 2008 R2.

If the signing private key does not include a CDP extension, no CRL checking is performed
by AD FS 2.0.

You can turn off CRL checking for a specific Claims Provider trust by using the
Windows PowerShell command-line and scripting environment.
ADFS
STEP-BY-STEP
GUIDE:
FEDERATION
http://go.microsoft.com/fwlink/?LinkId=204190
84
WITH
SHIBBOLETH
FEDERATION
SERVICES:
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
Note:
For more information, see the AD FS 2.0 ADMINISTRATION WITH WINDOWS POWERSHELL76 section of
the AD FS 2.0 OPERATIONS GUIDE and the AD FS 2.0 CMDLETS REFERENCE77.
Federated single logout
AD FS 2.0 includes support for federated single logout. Federated single logout makes it possible
for a user to log out completely from their IdP Shibboleth 2 federation server, as well as any relying
party applications that are federated through a particular browser session. Federated logout seeks
to improve security by leaving no sessions open for misuse, hijacking, or other malicious actions.
SAML 2.0 artifact profile
Both AD FS 2.0 and Shibboleth support the SAML 2.0 HTTP artifact binding as part of their support
for the SAML 2.0 protocol. The artifact profile differs in approach from the HTTP POST profile, and
it may be preferred in some situations.
Handling name qualifiers in AD FS 2.0
In AD FS 2.0, the consumption of name qualifiers for use with Name ID elements is done using the
custom-developed claim rules.
When it acts as a Relying Party/Service Provider token service, AD FS 2.0 can use custom claim
rules (like the one below) to read and use name qualifier variables. This rule passes inbound
Name IDs to the application, retaining their original format but changing the value to include the
NameQualifier and SPNameQualifier values in the output string.
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
=> issue(Type = c.Type,
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =
c.Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"], Value =
c.Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] + "!" +
c.Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] + "!" +
c.Value);
Note:
This script works only when the Name ID is sent in the Subject element of the XML assertion. In
cases in which a Name ID is provided in an AttributeStatement (for example, as the value of an
eduPersonTargetedID attribute), the Name ID value (that is, the opaque identifier) is usable, but
the name qualifiers cannot be appended to the value, as shown above.
76
AD FS 2.0 ADMINISTRATION WITH WINDOWS POWERSHELL: http://go.microsoft.com/fwlink/?LinkId=194005
77
AD FS 2.0 CMDLETS REFERENCE: http://go.microsoft.com/fwlink/?LinkId=177389).
Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 technologies
85