The attached document (SAML 2 0 For WIF – Installation Guildeline v1.03.docx) describes how to install and configure the SAML 2.0 for WIF Service Provider Framework. Chapter 4 provides the step-by-step installation guideline for installing the Service Provider Demo web site in your own environment.
The documentation also includes an example of how to configure the IdP (in this case, Microsoft AD FS 2.0) for use with the Service Provider Demo web site/SAML 2.0 For WIF and vice versa.
- Windows Server 2008, Windows Vista or Windows 7.
- IIS 7 and above must be running ASP.NET (2.0.50727) with minimum .NET 3.5
- Certificate that is used by the Service Provider for signing and encryption (an X.509 certificate that should prove sufficient for testing purposes, SPCert, is included in the installation). This certificate is referred to as the signing certificate in the configuration file.
- One may also need to implement a SSL certificate at the web site that is protected by the Service Provider (any X.509 certificate that should prove sufficient for testing purposes, spdemo.safewhere.local is included in the installation). The service provider does not require SSL, but the Identity provider may demand that it is implemented at the Service Provider. It is not recommended to re-use the SSL certificate as the service provider signing certificate.
The SAML 2.0 for WIF framework also works on Windows 2003, Windows Vista, and Windows 7. However, these are not officially supported configurations.
Prerequisites for binary distribution
- .NET 3.5 runtime or later
- ASP.NET 3.5 or later
Overview of SAML 2.0 for WIF
SAML 2.0 for WIF is a DLL-file that extends the Windows Identity Foundation with native support for the SAML 2.0 protocol.
SAML 2.0 for WIF supports the following extensions all of which are available on request:
- Windows Security Token issuance (Kerberos Impersonation) – Allows you to generate an impersonation-level Windows security token from the SAML 2.0 security token, which will make it possible to login to OWA or other Kerberos-protected resources provided that the applicable user is already in Active Directory.
- Shadow Account Module for Active Directory – Allows you to create (and update) users and roles on the fly in Active Directory based on the content of the SAML 2.0 security token, which will make it possible to automatically login to resources that support Kerberos authentication and authorization even though the user isn’t present in Active Directory. This module supports the creation (and updating) of users and roles on the fly in virtually any user database or directory service based on the content of the SAML 2.0 security token, which will make it possible to automatically login to resources that are not SAML 2.0-compliant. Please note that this will also demand that a special SAML 2.0 token module is implemented “in front” of the applicable application(s).
- Shadow Account Module for user databases and directory services – The ADFS Shadow Account Synchronization Module enables on-the-fly shadow account user creation at Service Providers. For web applications that require existing user accounts the component allows user accounts to created and modified to reflect user properties and roles specified in the SAML token result of a user login. This enables existing web applications to be easily adapted to allow Single Sign On based on SAML 2.0 claims. By employing a Manager Provider model, the component can dynamically invoke user defined components to create user accounts in proprietary account stores such as SQL server databases, eDirectory, OpenLDAP or other.