This first part of Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0 provides introductory material and an overview of the deployment. It contains the following chapters:
Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0 provides detailed instructions for enabling the Security Assertion Markup Language version 2 (SAML v2) in a federated environment. The book includes procedures for installing, deploying and configuring a number of host machines and applications. This chapter contains the following introductory information on the deployment.
Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0 is designed to highlight the following key features:
All instances of OpenSSO Enterprise are deployed behind a load balancer for high-availability.
Instances of OpenSSO Enterprise acting as an identity provider are configured to work with instances of Sun Java™ System Directory Server configured as the user data store.
XML Signing is enabled for all SAML v2 protocols.
The SAML v2 URL end points are exposed through load balancers with SSL termination and regeneration configuration.
A web policy agent and a J2EE policy agent are deployed in front of the service provider instances of OpenSSO Enterprise; the policy agents work in single sign-on mode only.
In a deployment configured for communication using SAML v2 a service provider and an identity provider must be created within a circle of trust. The circle of trust enables business providers to easily conduct cross-network transactions for an individual while protecting the individual's identity. The following sections contain information on the architecture of the two providers in this deployment.
An identity provider specializes in providing authentication services. As the administrating service for authentication, an identity provider maintains and manages identity information. It establishes trust with a service provider in order to exchange user credentials, enabling single sign-on between the providers. Authentication by an identity provider is honored by all service providers with whom the identity provider is partnered. The identity provider domain is idp-example.com. The following image illustrates the identity provider architecture in this deployment.
The identity provider domain in this deployment is idp-example.com. The identity provider application represents a legacy system which relies on OpenSSO Enterprise to act as a secure gateway through which identity information can be transferred to another application in a different domain. This functionality is provided by the Secure Attribute Exchange feature of OpenSSO Enterprise which uses SAML v2 without having to deal with federation protocol and processing.
The following list of components will be installed and configured on the identity provider side using the procedures documented in Part II, Building the Identity Provider Environment.
Two instances of OpenSSO Enterprise provide the core functionality. Each instance is created with a configuration data store. Configuration data includes information about services, administrative users, realms, policies, and more. Two instances of Sun Java System Application Server are installed on the OpenSSO Enterprise host machines into which the OpenSSO Enterprise WAR is then deployed.
User data is accessed through a single load balancer deployed in front of two instances of Sun Java System Directory Server.
Two instances of Directory Server provide storage for user entries that will be created for testing this deployment. Both instances of Directory Server are masters that engage in multi-master replication, providing high availability to the OpenSSO Enterprise layer.
The command line is used for all Directory Server configurations in this guide.
The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. They are deployed as follows:
OpenSSO Enterprise Load Balancer. This load balancer exposes the web-based OpenSSO Enterprise console to internal administrators. Alternatively, internal administrators can bypass this load balancer and log in directly.
Directory Server Load Balancer. The load balancer in front of the Directory Server instances provide round-robin load balancing and a single virtual Directory Server host name. It detects individual Directory Server failures and recoveries, taking failed servers off the load balancer list.
A service provider offers web-based services to an identity. This broad category can include portals, retailers, transportation providers, financial institutions, entertainment companies, libraries, universities, governmental agencies, and other organizations that consume identity information for purposes of access. The service provider domain is sp-example.com. The following image illustrates the service provider architecture in this deployment.
The service provider domain in this deployment is sp-example.com. The service provider application represents a legacy system which relies on OpenSSO Enterprise to act as a secure gateway through which identity information can be received from the identity provider. This functionality is provided by the Secure Attribute Exchange feature of OpenSSO Enterprise which uses SAML v2 without having to deal with federation protocol and processing.
The following list of components will be installed and configured using the procedures documented in Part III, Building the Service Provider Environment.
Two instances of OpenSSO Enterprise provide the core functionality. Each instance is created with a configuration data store. Configuration data includes information about services, administrative users, realms, policies, and more. Two instances of Sun Java System Application Server are installed on the OpenSSO Enterprise host machines into which the OpenSSO Enterprise WAR is then deployed.
User data is accessed through a single load balancer deployed in front of two instances of Sun Java System Directory Server.
Two instances of Directory Server provide storage for user entries that will be created for testing this deployment. Both instances of Directory Server are masters that engage in multi-master replication, providing high availability to the OpenSSO Enterprise layer.
The command line is used for all Directory Server configurations in this guide.
The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. They are deployed as follows:
OpenSSO Enterprise Load Balancer. This load balancer exposes the web-based OpenSSO Enterprise console to internal administrators. Alternatively, internal administrators can bypass this load balancer and log in directly.
Directory Server Load Balancer. The load balancer in front of the Directory Server instances provides round-robin load balancing and a single virtual Directory Server host name. It detects individual Directory Server failures and recoveries, taking failed servers off the load balancer list.
Policy agents are used to restrict access to hosted content or applications. The policy agents intercept HTTP requests from external users and redirect the request to OpenSSO Enterprise for authentication. Web policy agents protect any resources under the doc root of the web container. J2EE policy agents protect a variety of hosted J2EE applications; in this deployment, agentsample is used. The agents communicate with the OpenSSO Enterprise instances through the configured load balancer.
The protected resource host machine contains the content to which access is restricted. Towards this end, BEA WebLogic Server, Sun Java System Web Server, and the respective J2EE and web policy agents will be installed. A sample Java Server Page included with OpenSSO Enterprise will be used to emulate a legacy application for purposes of demonstrating Secure Attribute Exchange using SAML v2. The protected resource host machine will be used in Chapter 14, Testing Attribute Mapping
The following image describes the interactions between the various components during the attribute mapping use case. See Chapter 14, Testing Attribute Mapping.
The following image describes the interactions between the various components during the single logout use case. See Chapter 12, Testing the SAML v2 Profiles.
This chapter contains technical information regarding the machines, software, and other components used in this deployment example. It contains the following sections:
The following table lists the attributes of the host machines used for this deployment example.
Table 2–1 Host Machines and Operating Systems
Host Machine |
Architecture |
Operating System |
---|---|---|
ds1.idp-example.com |
x86 |
Solaris 10 |
ds2.idp-example.com |
x86 |
Solaris 10 |
osso1.idp-example.com |
SPARC |
Solaris 10 |
osso2.idp-example.com |
SPARC |
Solaris 10 |
lb1.idp-example.com |
SPARC |
Solaris 10 |
lb2.idp-example.com |
SPARC |
Solaris 10 |
ds1.sp-example.com |
SPARC |
Solaris 10 |
ds2.sp-example.com |
SPARC |
Solaris 10 |
osso1.sp-example.com |
SPARC |
Solaris 10 |
osso2.sp-example.com |
SPARC |
Solaris 10 |
lb3.sp-example.com |
SPARC |
Solaris 10 |
lb4.sp-example.com |
SPARC |
Solaris 10 |
pr1.sp-example.com |
SPARC |
Solaris 10 |
The following table lists the software used in this deployment example.
Table 2–2 Software and Download Locations
Product |
Version |
Download Location |
---|---|---|
Sun OpenSSO Enterprise |
8.0 | |
Sun Java System Web Server |
7.0 Update 3 | |
Sun Java System Directory Server Enterprise Edition |
6.3 Update 3 | |
BEA Weblogic Server |
10 | |
Web Policy Agent (for Sun Java System Web Server) |
3.0 | |
J2EE Policy Agent (for BEA Weblogic Server) |
3.0 | |
Java (for OpenSSO Enterprise and policy agents) |
1.5.0_09 | |
BIG-IP Load Balancer |
The following sections summarize the main service URLs for the components used in this deployment example. For detailed configuration information, see Part V, Appendices.
The following tables summarize the main service URLs for the identity provider components.
Table 2–3 Identity Provider Components and Main Service URLs
Components |
Main Service URL |
|
---|---|---|
Directory Server Host Machines and Load Balancer |
||
Directory Server 1 |
ds1.idp-example.com:1736 (for monitor node) ldaps://ds1.idp-example.com:1736 (for user data) |
|
Directory Server 2 |
ds2.idp-example.com:1736 (for monitor node) ldaps://ds2.idp-example.com:1736 (for user data) |
|
Load Balancer 1 |
ldaps://lb1.idp-example.com:489 (for Directory Server access) |
|
OpenSSO Enterprise Host Machines and Load Balancer |
||
Application Server 1 |
Default Domain http://osso1.idp-example.com:4848 (for console) http://osso1.idp-example.com:8080 (for HTTP) https://osso1.idp-example.com:8181 (for HTTPS) |
|
Non—Root User Domain http://osso1.idp-example.com:8989 (for console) http://osso1.idp-example.com:1080 (for HTTP) https://osso1.idp-example.com:1081 (for HTTPS) |
||
OpenSSO Enterprise 1 |
https://osso1.idp-example.com:1081/opensso/console |
|
Application Server 2 |
Default Domain http://osso2.idp-example.com:4848 (for console) http://osso2.idp-example.com:8080 (for HTTP) https://osso2.idp-example.com:8181 (for HTTPS) |
|
Non—Root User Domain http://osso2.idp-example.com:8989 (for console) http://osso2.idp-example.com:1080 (for HTTP) https://osso2.idp-example.com:1081 (for HTTPS) |
||
OpenSSO Enterprise 2 |
https://osso2.idp-example.com:1081/opensso/console |
|
Load Balancer 2 |
https://lb2.idp-example.com:1081/opensso (for OpenSSO Enterprise access) http://lb2.idp-example.com:1082 (for virtual server proxy) |
|
The following tables summarize the main service URLs for the service provider components.
Table 2–4 Service Provider Components and Main Service URLs
Components |
Main Service URL |
|
---|---|---|
Directory Server Host Machines and Load Balancers |
||
Directory Server 1 |
ds1.sp-example.com:1736 (for monitor node) ldaps://ds1.sp-example.com:1736 (for user data) |
|
Directory Server 2 |
ds2.sp-example.com:1736 (for monitor node) ldaps://ds2.sp-example.com:1736 (for user data) |
|
Load Balancer 3 |
ldaps://lb3.sp-example.com:489 (for user data) |
|
OpenSSO Enterprise Host Machines and Load Balancer |
||
Application Server 1 |
Default Domain http://osso1.sp-example.com:4848 (for console) http://osso1.sp-example.com:8080 (for HTTP) https://osso1.sp-example.com:8181 (for HTTPS) |
|
Non—Root User Domain http://osso1.sp-example.com:8989 (for console) http://osso1.sp-example.com:1080 (for HTTP) https://osso1.sp-example.com:1081 (for HTTPS) |
||
OpenSSO Enterprise 1 |
https://osso1.sp-example.com:1081/opensso/console |
|
Application Server 1 |
Default Domain http://osso2.sp-example.com:4848 (for console) http://osso2.sp-example.com:8080 (for HTTP) https://osso2.sp-example.com:8181 (for HTTPS) |
|
Non—Root User Domain http://osso2.sp-example.com:8989 (for console) http://osso2.sp-example.com:1080 (for HTTP) https://osso2.sp-example.com:1081 (for HTTPS) |
||
OpenSSO Enterprise 2 |
https://osso2.sp-example.com:1081/opensso/console |
|
Load Balancer 4 |
https://lb4.sp-example.com:1081/opensso (for OpenSSO Enterprise access) http://lb4.sp-example.com:1082 (for virtual server proxy) |
|
Protected Resource 1 Host Machine Web Containers and Policy Agents |
||
Web Server |
https://pr1.sp-example.com:8989 (for Sun Java System Web Server administration console) http://pr1.sp-example.com:1080 (for Sun Java System Web Server managed instance) |
|
Web Policy Agent |
http://pr1.sp-example.com:1080 |
|
WebLogic Server |
http://pr1.sp-example.com:7001/console (for BEA Weblogic administration server) http://pr1.sp-example.com:1081 (for BEA Weblogic managed server) |
|
J2EE Policy Agent |
http://pr1.sp-example.com:1081/agentapp |
|
Throughout this deployment example, we use ldapsearch to view replicated entries. An alternative would be to enable the Directory Server audit log and run tail -f. Enabling the audit log will also help to track changes and updates made during OpenSSO Enterprise configuration.
This chapter contains information you need to know before beginning the documented installation and configuration procedures. It contains the following sections:
See Chapter 2, Technical Overview for a quick reference of host machines, port numbers, operating systems, naming conventions, and component names used in this deployment example. See Part V, Appendices for more detailed information.
The load balancer hardware and software used in this deployment environment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information. This document assumes that you have already installed the required load balancers. The following identity provider sections require load-balancing hardware and software.
The following service provider sections require load-balancing hardware and software.
In order to enable secure communications using the Secure Sockets Layer (SSL) protocol you need to obtain root certificates and server certificates from a certificate authority (CA). A CA root certificate proves that the particular CA issued a particular server certificate. CA root certificates are publicly available. The root certificate used in this deployment is a self-signed certificate issued by OpenSSL for testing purposes only; it is named ca.cer. You can obtain a root certificate from any commercial certificate issuer such as VeriSign, Thawte, Entrust, or GoDaddy.
The server certificates are requested from, and issued by, OpenSSL within each procedure. You should know how to request server certificates from your CA of choice before beginning this deployment. The following identity provider sections are related to requesting, installing, and importing root and server certificates.
To Import a Root Certificate and a Server Certificate to Directory Server 1
To Import a Root Certificate and a Server Certificate to Directory Server 2
To Import the Root Certificate to Directory Server Load Balancer 1
To Request a Certificate for OpenSSO Enterprise Load Balancer 2
To Install the Certificate Authority Root Certificate to OpenSSO Enterprise Load Balancer 2
To Install the Server Certificate to OpenSSO Enterprise Load Balancer 2
To Install a Root Certificate and a Server Certificate on Directory Server 1
The following service provider sections are related to requesting, installing, and importing root and server certificates.
To Install a Root Certificate and a Server Certificate on Directory Server 1
To Install a Root Certificate and a Server Certificate on Directory Server 2
To Import the Root Certificate to the User Data Load Balancer
To Request a Certificate for OpenSSO Enterprise Load Balancer 2
To Install a CA Root Certificate to OpenSSO Enterprise Load Balancer 2
To Install the Server Certificate to OpenSSO Enterprise Load Balancer 2
To Import a Certificate Authority Root Certificate to Protected Resource 1
To Import a Certificate Authority Root Certificate to Protected Resource 1
There are many ways to resolve the host names used in this deployment. You may use a DNS naming service, or you can map IP addresses to host names in the local host file on all UNIX® hosts. The same entries must also be added to equivalent files on Windows hosts, and on client machines where browsers are used. For example:
1xx.xx.xx.x1 ds1 ds1.sp-example.com 1xx.xx.xx.x2 ds2 ds2.sp-example.com 1xx.xx.xx.x3 osso1 osso1.idp-example.com 1xx.xx.xx.x4 osso2 osso2.idp-example.com |
See Appendix G, Known Issues and Limitations for descriptions of problems you may encounter when implementing the deployment example. This list will be updated as new information becomes available.
Although the instructions and procedures documented in this book incorporate many best practices, and may be suitable in many different scenarios, this is not the only way to achieve the same results. If you plan to deviate from the task sequence or details described, you should refer to the relevant product documentation for information on differences in platforms, software versions or other requirement constraints.