Pluggable Single Sign-On Provider
Represents a modular component that can be used to handle the storage and mapping of credentials for use in connecting with third-party or back-end systems.
Real World Example
A business data team needs a way for SharePoint users to access multiple back-end data sources and applications from Microsoft Office SharePoint Server 2007, using the users’ own credentials. They do not want the burden of adding Kerberos authentication to the SharePoint environment, and they do not want to use the built-in single sign-on (SSO) component. They develop a new SSO system that can be integrated into Office SharePoint Server 2007.
SSO providers store credentials for users so that Office SharePoint Server 2007 can use the credentials to access applications or data sources on behalf of and impersonating the user. After it is configured, the SSO provider is used by any SSO-aware controls or Web Parts, such as the Business Data Catalog Web Parts. A SharePoint server farm can have only one registered SSO provider.
You must install custom SSO providers in the global assembly cache, and register them by using the ProviderAdmin console application (located in the bin directory of the Office SharePoint Server 2007 installation). The ProviderAdmin application replaces the current SSO provider with the one you specify.
To use a custom SSO provider with a database line-of-business (LOB) system, you must modify the Business Data Catalog schema to add the SsoApplicationId and SsoProviderImplementation properties to the <LobSystemInstance> XML tag as follows.
<LobSytemInstance Name="AdventureWorks2000(SampleSSO)"> <Properties> <Property Name="AuthenticationMode" Type="System.String">WindowsCredentials</Property> <Property Name="SsoApplicationId" Type="System.String">AdventureWorks</Property> <Property Name="SsoProviderImplementation" Type="System.String">SampleSSOProvider.SimpleSSOProvider, SampleSSOProvider, Version=126.96.36.199, Culture=neutral, PublicKeyToken=e447e624e7099fd1</Property> </Properties> </LobSystemInstance>
Because SSO systems handle user credentials, you should scrutinize them carefully for security.
A child farm inherits its SSO settings from the parent farm, so SSO cannot be adjusted for a child farm. If a child farm must use a different SSO provider, it must either have the parent farm adopt the same SSO provider or must no longer be a child farm. If the parent farm adopts the requested SSO provider, then the SSO provider must also be installed on the child farm to operate correctly.