This part of the Sun OpenSSO Enterprise 8.0 Technical Overview contains introductory material concerning Sun OpenSSO Enterprise 8.0 (OpenSSO Enterprise). It includes the following chapters:
Sun OpenSSO Enterprise 8.0 (OpenSSO Enterprise) integrates authentication and authorization services, single sign-on (SSO), and open, standards-based federation protocols (including the Liberty Alliance Project specifications, WS-Federation and Security Assertion Markup Language [SAML]) to provide a comprehensive solution for protecting network resources by preventing unauthorized access to web services, applications and web content, and securing identity data. This introductory chapter contains a high-level description of OpenSSO Enterprise and what it does. It contains the following sections:
OpenSSO Enterprise is a single product that combines the features of Sun Java™ System Access Manager, Sun Java System Federation Manager, and the Sun Java System SAML v2 Plug-in for Federation Services. Additionally, it is enhanced with new functionality developed specifically for this release. OpenSSO Enterprise provides access management by allowing the implementation of authentication, policy-based authorization, federation, SSO, and web services security from a single, unified framework. The core application is delivered as a simple web archive (WAR) that can be easily deployed in a supported web container.
OpenSSO Enterprise is Sun Microsystems' commercial distribution of the open source code available at OpenSSO.
To assist the core application, policy agents, the Client SDK, and (possibly) other disparate pieces must be installed remotely and be able to communicate with the OpenSSO Enterprise server. See What Does OpenSSO Enterprise Do? for a high-level picture of the deployment architecture and Chapter 2, Examining OpenSSO Enterprise for more specific information.
The following types of interactions occur daily in a corporate environment.
An employee looks up a colleague’s phone number in the corporate phone directory.
A manager retrieves employee salary histories to determine an individual’s merit raise.
An administrative assistant adds a new hire to the corporate database, triggering the company’s health insurance provider to add the new hire to its enrollment.
An engineer sends an internal URL for a specification document to another engineer who works for a partner company.
A customer logs into a company’s web site and looks for a product in their online catalog.
A vendor submits an invoice to the company’s accounting department.
A corporate human resources administrator accesses an outsourced benefits application.
For each of these transactions, the company must determine who is allowed to view the information or use the application. Some information such as product descriptions and advertising can be made available to everyone in a public online catalog. Other information such as accounting and human resources data must be restricted to employees only. And other sensitive information such as pricing models and employee insurance plans is appropriate to share only with partners, suppliers, and employees. This need for access determination is met by Sun OpenSSO Enterprise, an access management product with authentication, authorization, and single sign-on (SSO) services provided out of the box.
When a user or an external application requests access to content stored on a company’s server, a policy agent (available in a separate download and installed on the same machine as the resource you want to protect) intercepts the request and directs it to OpenSSO Enterprise which, in turn, requests credentials (such as a username and password in the case of a user) for authentication. If the credentials returned match those stored in the appropriate identity data store, OpenSSO Enterprise determines that the user is authentic. Following authentication, access to the requested content is determined by the policy agent which evaluates the policies associated with the authenticated identity. Policies are created using OpenSSO Enterprise and identify which identities are allowed to access a particular resource, specifying the conditions under which this authorization is valid. Based upon the results of the policy evaluation, the policy agent either grants or denies the user access. Figure 1–1 illustrates a high-level deployment architecture of OpenSSO Enterprise.
The following sections contain an overview of the functions of OpenSSO Enterprise.
OpenSSO Enterprise manages authorized access to network services and resources. By implementing authentication and authorization, OpenSSO Enterprise (along with an installed policy agent) ensures that access to protected resources is restricted to authorized users. In a nutshell, a policy agent intercepts a request for access to a resource and communicates with OpenSSO Enterprise to authenticate the requestor. If the user is successfully authenticated, the policy agent then evaluates the policies associated with the requested resource and the user to determine if the authenticated user is authorized to access the resource. If the user is authorized, the policy agent allows access to the resource, also providing identity data to the resource to personalize the interaction. For more information on access control, see Core Services and Part II, Access Control Using OpenSSO Enterprise.
With the introduction of federation protocols into the process of access management, identity information and entitlements can be communicated across security domains, spanning multiple trusted partners. By configuring a circle of trust and defining applications and services as providers in the circle (either identity providers or service providers), users can opt to associate, connect or bind the various identities they have configured locally for these providers. The linked local identities are federated and allow the user to log in to one identity provider site and click through to an affiliated service provider site without having to reauthenticate; in effect, single sign-on (SSO). OpenSSO Enterprise supports several open federation technologies including the Security Access Markup Language (SAML) versions 1 and 2, WS-Federation, and the Liberty Alliance Project Identity Federation Framework (Liberty ID-FF), therefore encouraging an interoperable infrastructure among providers. For more information on federation management, see Core Services and Part III, Federation Management Using OpenSSO Enterprise.
A web service is a component service or application that exposes some type of business or infrastructure functionality through a language-neutral and platform-independent, network interface; enterprises might use this web service to build larger service-oriented architectures. In particular, the service defines its interface (for example, the format of the message being exchanged) using the Web Services Description Language (WSDL), and communicates using SOAP and eXtensible Markup Language (XML) messages. The web service client (WSC) communicates with the web service provider (WSP) through an intermediary — usually a firewall or load balancer.
Although web services enable open, flexible, and adaptive interfaces, their openness creates security risks. Without proper security protections, a web service can expose vulnerabilities that might have dire consequences. Hence, ensuring the integrity, confidentiality and security of web services through the application of a comprehensive security model is critical for both enterprises and consumers. A successful security model associates identity data with the web services and creates secure service-to-service interactions. The security model adopted by OpenSSO Enterprise identifies the user and preserves that identity through multiple interactions, maintains privacy and data integrity, uses existing technologies, and logs the interactions. In OpenSSO Enterprise, the following web service security standards are implemented:
Liberty Alliance Project Identity Web Services Framework (Liberty ID-WSF)
WS-I Basic Security Profile
WS-Trust (from which the Security Token Service was developed)
The web services security framework uses the Security Token Service and separately installed security agents. For more information on OpenSSO Enterprise web services and web services security, see Core Services and Part IV, The Web Services Stack, Identity Services, and Web Services Security.
For some time, OpenSSO Enterprise has provided client interfaces for access to core features and functionality. These interfaces are used by policy agents and custom applications developed by customers. With this release, OpenSSO Enterprise now exposes certain functions as simple identity web services allowing developers to easily invoke them when developing their applications using one of the supported integrated development environment (IDE) products. (The IDE generates the stub code that wraps a call to the web service.) Identity Web Services are available using:
SOAP and Web Services Description Language (WSDL)
Representational State Transfer (REST)
They do not require the deployment of an agent or a proxy and include the following capabilities:
Authentication to validate user credentials.
Authorization to permit access to protected resources.
Provisioning for user attribute management and self registration.
Logging to keep track of it all.
For more information on identity services, see Identity Web Services and Part IV, The Web Services Stack, Identity Services, and Web Services Security.
OpenSSO Enterprise allows for:
Ease of Deployment: OpenSSO Enterprise is delivered as a web archive (WAR) that can be easily deployed as a Java EE application in different web containers. Most configuration files and required libraries are inside the WAR to avoid the manipulation of the classpath in the web container's configuration file. The OpenSSO Enterprise WAR is supported on:
Sun Java System Web Server 7.0 — Update 3 and above
Sun Java System Application Server 9.1 EE Update 2 and above (and Glassfish v2 update 2 and above)
BEA WebLogic Application Server 9.2 mp2
IBM WebSphere Application Server 6.1
Oracle Application Server 10g
Tomcat 5.5.x & 6.x
Tomcat 5.5.26 and 6.15 are not supported.
Geronimo (supported on the Sun SolarisTM 10 Operating Environment for SPARC, x86 & x64 and the Sun Solaris 9 Operating Environment for SPARC & x86 systems only)
Geronimo can install Tomcat and Jetty web containers; OpenSSO Enterprise supports only Tomcat.
See the Sun OpenSSO Enterprise 8.0 Release Notes for updates to this list.
Portability: OpenSSO Enterprise is supported on the following operating systems:
Sun Solaris 10 Operating Environment for SPARC, x86 & x64 systems
Sun Solaris 9 Operating Environment for SPARC & x86 systems
Windows Server 2003 and Windows XP (development only) operating systems
Red Hat Enterprise Linux 4 Server (Base)
Red Hat Enterprise Linux 4 Advanced Platform
Red Hat Enterprise Linux 5 Server (Base)
Red Hat Enterprise Linux 5 Advanced Platform
Windows 2003 Standard Server
Windows 2003 Enterprise Server
Windows 2003 Datacenter Server
IBM AIX 5.3 (supported with the IBM WebSphere Application Server 6.1 container only)
See the Sun OpenSSO Enterprise 8.0 Release Notes for updates to this list.
Open Standards: OpenSSO Enterprise is built using open standards and specifications as far as possible. For example, features designed for federation management and web services security are based on the Security Assertion Markup Language (SAML), the Liberty Alliance Project specifications, and the WS-Security standards.
Ease of Administration: OpenSSO Enterprise contains a web-based, graphical administration console as well as command line interfaces for configuration tasks and administrative operations. Additionally, an embedded, centralized data store allows for one place to store server and agent configuration data.
Runtime security enables an enterprise's resources to be protected as configured and OpenSSO Enterprise services to be accessed by authorized entities only.
Administration security ensures only authorized updates are made to the OpenSSO Enterprise configuration data.
Deployment security implements best practices for installing OpenSSO Enterprise on different operating systems, web containers, and so forth.
Additionally, all security actions are logged.
Configuration Data Store: OpenSSO Enterprise can write server configuration data to a centralized configuration data store. You can also point to instances of Sun Java System Directory Server 5.2 or Directory Server Enterprise Edition 6.x during configuration of OpenSSO Enterprise for use as a configuration data store. See Data and Data Stores for more information.
User Data Store Independence: OpenSSO Enterprise allows you to view and retrieve user information without making changes to an existing user database. Supported directory servers include Directory Server 5.1, 5.2 & 6.2, IBM Tivoli Directory 6.1, and Microsoft Active Directory 2003. See Data and Data Stores for more information.
The configuration data store embedded with OpenSSO Enterprise should only be used as a user data store for proof of concepts and deployments in development.
Web and Non-Web-Based Resources: The core design of OpenSSO Enterprise caters to SSO for both web and non-web applications.
Performance, Scalability and Availability: OpenSSO Enterprise can be scaled horizontally and vertically to handle increased workloads, and as security needs change over time. There is no single point of failure.
Distributed Architecture Server and client components can be deployed across the enterprise or across domain boundaries as all application programming interfaces (API) provide remote access to OpenSSO Enterprise based on a service-oriented architecture.
Flexibility and Extensibility: Many OpenSSO Enterprise services expose a service provider interface (SPI) allowing expansion of the framework to provide for specific deployment needs.
Internationalization OpenSSO Enterprise contains a framework for multiple language support. Customer facing messages, API, command line interfaces, and user interfaces are localized in the supported languages.
OpenSSO Enterprise provides a pluggable architecture to deliver access management, secure web services, and federation capabilities. This chapter contains information on the internal architecture and features of OpenSSO Enterprise.
OpenSSO Enterprise is written in Java, and leverages many industry standards, including the HyperText Transfer Protocol (HTTP), the eXtensible Markup Language (XML), the Security Assertion Markup Language (SAML), and SOAP, to deliver access management, secure web services, and federation capabilities in a single deployment. It consists of client application programming interfaces (a Client Software Development Kit [SDK]), a framework of services that implement the business logic, and service provider interfaces (SPI) that are implemented by concrete classes and can be used to extend the functionality of OpenSSO Enterprise as well as retrieve information from data stores. Figure 2–1 illustrates the client/server architecture of OpenSSO Enterprise.
Each component of OpenSSO Enterprise uses its own framework to retrieve customer data from the plug-in layer and to provide data to other components. The OpenSSO Enterprise framework integrates all of the application logic into one layer that is accessible to all components and plug-ins. The Client SDK and Identity Web Services are installed on a machine remote to the OpenSSO Enterprise server that holds a resource to be protected; they provide remote access to the OpenSSO Enterprise for client applications. (The policy agent, also installed on the remote machine, is basically a client written using the Client SDK and Identity Web Services.) Applications on the remote machine access OpenSSO Enterprise using the Client SDK. Custom plug-in modules are installed on the machine local to OpenSSO Enterprise and interact with the OpenSSO Enterprise SPI to retrieve required information from the appropriate data store and deliver it to the plug-ins and, in turn, the OpenSSO Enterprise framework for processing.
To gain access to a protected resource, the requestor needs to be authenticated and have the authorization to access the resource. When someone (using a browser) sends an HTTP request for access to a protected resource, a policy agent (separately downloaded and installed on the same machine as the resource you want to protect) intercepts the request and examines it. If no valid OpenSSO Enterprise session token (to provide proof of authentication) is found, the policy agent contacts the server which then invokes the authentication and authorization processes. Figure 2–2 illustrates one way in which the policy agents can be situated to protect an enterprise's servers by directing HTTP requests to a centralized OpenSSO Enterprise for processing.
OpenSSO Enterprise integrates core features such as access control through authentication and authorization processes, and federation. These functions can be configured using the administration console or the ssoadm command line utility. Figure 2–3 is a high-level illustration of the interactions that occur between parties (including the policy agent, browser, and protected application) during authentication and authorization in a OpenSSO Enterprise deployment.
For more information, see Part II, Access Control Using OpenSSO Enterprise.
Services developed for OpenSSO Enterprise generally contain both a server component and a client component. The server component is a simple Java servlet developed to receive XML requests and return XML responses. (The deployment descriptor web.xml defines the servlet name and description, the servlet class, initialization parameters, mappings, and other startup information.) The client component is provided as Java application programming interfaces (API), and in some cases C API, that allow remote applications and other OpenSSO Enterprise services to communicate with and consume the particular functionality.
Each core service uses its own framework to retrieve customer and service data and to provide it to other OpenSSO Enterprise services. The OpenSSO Enterprise framework integrates all of these service frameworks to form a layer that is accessible to all product components and plug-ins. The following sections contain information on the OpenSSO Enterprise core services.
Many services also provide a public SPI that allows the service to be extended. See the Sun OpenSSO Enterprise 8.0 Developer’s Guide, the Sun OpenSSO Enterprise 8.0 C API Reference for Application and Web Policy Agent Developers, and the Sun OpenSSO Enterprise 8.0 Java API Reference for information.
The Authentication Service provides the functionality to request user credentials and validate them against a specified authentication data store. Upon successful authentication, it creates a session data structure for the user that can be validated across all web applications participating in an SSO environment. Several authentication modules are supplied with OpenSSO Enterprise, and new modules can be plugged-in using the Java Authentication and Authorization Service (JAAS) SPI.
The Authentication Service is based on the JAAS specification, a set of API that enables services to authenticate and enforce access controls upon users. See the Java Authentication and Authorization Service Reference Guide for more information.
Components of the Authentication Service include:
The Distributed Authentication User Interface allows the Authentication Service user interface to be deployed separately from OpenSSO Enterprise, if desired. By deploying this authentication proxy in the DMZ and using the authentication interfaces provided in the Client SDK to pass user credentials back and forth, you can protect OpenSSO Enterprise data (for example, the login URL information and hence the host information). JavaServer Pages (JSP) represent the interface displayed to users for authentication and are completely customizable.
The Core Authentication Service executes common processes across all authentication modules. Key responsibilities of this service include identification of the appropriate plan to authenticate the user (identify the authentication module, load the appropriate JSP) and creation of the appropriate session for the authenticated user.
The Authentication API are remoteable interfaces that don't need to reside on the same machine as the OpenSSO Enterprise server. This allows remote clients to access the Authentication Service. remote-auth.dtd defines the structure for the XML communications that will be used by the Authentication Service, providing definitions to initiate the process, collect credentials and perform authentication.
A number of authentication modules are installed and configured (including, but not limited to, LDAP, RADIUS, Windows Desktop, Certificate, and Active Directory). A configured authentication level for each module is globally defined. Mechanisms are also provided to upgrade a user's session after authenticating the user to an additional authentication module that satisfies the authentication level of the resource. New modules can be plugged-in using the JAAS SPI.
The Authentication Service interacts with both the database that stores user credentials (authentication data store) to validate the user, and with the Identity Repository Service plug-ins to retrieve user profile attributes. When the Authentication Service determines that a user’s credentials are genuine, a valid user session token is issued, and the user is said to be authenticated. Figure 2–4 illustrates how the local and remote authentication components interact within a OpenSSO Enterprise deployment.
More information on the architecture of the Authentication Service can be found in the Authentication Service Architecture document on the OpenSSO web site.
Authorization is the process with which OpenSSO Enterprise evaluates the policies associated with an authenticated user’s identity, and determines whether the user has permission to access a protected resource. (A policy defines the rules that specify a user's access privileges to a protected resource.) The Policy Service provides the authorization functionality using a rules-based engine. It interacts with the OpenSSO Enterprise configuration data store, a delegation plug-in (which helps to determine the administrator’s scope of privileges), and Identity Repository Service plug-ins to verify that the user has access privileges from a recognized authority. Policy can be configured using the administration console, and comprises the following:
A Schema for the policy type (normal or referral) that describes the syntax of policy.
A Rule which defines the policy itself and is made up of a Resource, an Action and a Value.
Condition(s) to define constraints on the policy.
Subject(s) to define the user or collection of users which the policy affects.
A ResponseProvider(s) to send requested attribute values, typically based on the user profile, with the policy decision.
Figure 2–5 illustrates how the local and remote components of the Policy Service interact within a OpenSSO Enterprise deployment. Note that the PolicyServiceRequestHandler maps to the PolicyRequest XML element.
Policy agents are an integral part of authorization. They are programs, available for installation separate from OpenSSO Enterprise, that police the web container which hosts the protected resources. When a user requests access to the protected resource (such as a server or an application), the policy agent intercepts the request and redirects it to the OpenSSO Enterprise Authentication Service. Following authentication, the policy agent will enforce the authenticated user’s assigned policies. OpenSSO Enterprise supports two types of policy agents:
The web agent is written in C and can protect any URL-based resource.
The Java Platform, Enterprise Edition (Java EE) agent enforces URL-based policy and Java EE-based policy for Java applications on Java EE containers.
When policy agents are implemented, all HTTP requests are implicitly denied unless explicitly allowed by the presence of two things:
A valid session
A policy allowing access
If the resource is in the Not Enforced list defined for the policy agent, access is allowed even if there is no valid session.
More information on the architecture of the Policy Service can be found in the Policy Service Architecture document on the OpenSSO web site. For an overview of the available policy agents and links to specific information on installation, see the Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for J2EE Agents.
The mission of the OpenSSO Enterprise Session Service is to maintain information about an authenticated user's session across all web applications participating in a user session. Additionally, OpenSSO Enterprise provides continuous proof of the user’s identity, enabling the user to access multiple enterprise resources without having to provide credentials each time. This enables the following types of user sessions.
Basic user session. The user provides credentials to log in to one application, and then logs out of the same application.
SSO session. The user provides credentials once, and then accesses multiple applications within the same DNS domain.
Cross domain SSO (CDSSO) session. The user provides credentials once, and then accesses applications among multiple DNS domains.
A user session is the interval between the time a user attempts authentication through OpenSSO Enterprise and is issued a session token, and the moment the session expires, is terminated by an administrator, or the user logs out. In what might be considered a typical user session, an employee accesses the corporate benefits administration service. The service, monitored by OpenSSO Enterprise, prompts the user for a username and password. With the credentials OpenSSO Enterprise can authenticate, or verify that the user is who he says he is. Following authentication, OpenSSO Enterprise allows the user access to the service providing authorization is affirmed. Successful authentication through OpenSSO Enterprise results in the creation of a session data structure for the user or entity by the Session Service. Generally speaking, the Session Service performs some or all of the following:
Generates unique session identifiers, one for each user's session data structure
A session data structure is initially created in the INVALID state with default values for certain attributes and an empty property list. Once the session is authenticated, the session state is changed to VALID and session data is updated with the user's identity attributes and properties.
Maintains a master copy of session state information
The session state maintained on the client side is a cached view of the actual session data structure. This cache can be updated by either the active polling mechanism or the session notification triggered by the Session Service.
Implements time-dependent behavior of sessions — for example, enforces timeout limits
Implements session life cycle events such as logout and session destruction
Notifies all participants in the same SSO environment of session state changes
Enables SSO and cross-domain single sign-on (CDSSO) among applications external to OpenSSO Enterprise by providing continued proof of identity.
Allows participating clients to share information across deployments
Implements high availability facilities
Figure 2–6 illustrates the interactions between the local and remote components of the Session Service within a OpenSSO Enterprise deployment.
Additionally, Figure 2–7 illustrates how the messaging capabilities of Message Queue can be used to push session information to a persistent store based on the Berkeley DataBase (DB). Using OpenSSO Enterprise in this manner enables the following key feature:
Session Failover allows an alternative OpenSSO Enterprise server to pick up a given user session when the server owning the original session fails.
Session Constraints allow deployments to specify constraints on a sessions, such as one session per user.
More information on the architecture of the Session Service can be found in the Session Service Architecture document on the OpenSSO web site. For more information on session failover, see Chapter 8, Implementing OpenSSO Enterprise Session Failover, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
When a user logs in to a resource protected by OpenSSO Enterprise, the Logging Service records information about the user's activity. The common Logging Service can be invoked by components residing on the same server as OpenSSO Enterprise as well as those on the client machine, allowing the actual mechanism of logging (such as destination and formatting) to be separated from the contents which are specific to each component. You can write custom log operations and customize log plug-ins to generate log reports for specific auditing purposes.
Administrators can control log levels, authorize the entities that are allowed to create log entries and configure secure logging (the latter for flat files only). Logged information includes the name of the host, an IP address, the identity of the creator of the log entry, the activity itself, and the like. Currently, the fields logged as a log record are controlled by the Configurable Log Fields selected in the Logging Configuration page located under the System tab of the OpenSSO Enterprise console. The Logging Service is dependent on the client application (using the Logging APIs) creating a programmatic LogRecord to provide the values for the log record fields. The logging interface sends the logging record to the Logging Service which determines the location for the log record from the configuration. A list of active logs can also be retrieved using the Logging API. Figure 2–8 illustrates the interactions between the local and remote components of the Logging Service in a OpenSSO Enterprise deployment.
Generally speaking, writing log records can be done remotely, using the Client SDK, but anything involving the reading API can only be done on the machine on which OpenSSO Enterprise is installed. Using the reading API uses a great deal of system resources, especially when database logging is involved.
Logs can be written to flat files or to one of the supported databases (Oracle and MySQL). See Chapter 15, Recording Events with the Logging Service for more information.
The Identity Repository Service allows OpenSSO Enterprise to integrate an existing user data store (such as a corporate LDAP server) into the environment. The Identity Repository Service is able to access user profiles (as well as group and role assignments if supported) and is capable of spanning multiple repositories — even of different types. The Identity Repository Service is configured per realm under the Data Stores tab and its main functions are:
To specify an identity repository that will store service configurations and attributes for users, groups and roles.
To provide a list of identity repositories that can provide user attributes to the Policy Service and Federation Services frameworks.
To combine the attributes obtained from different repositories.
To provide interfaces to create, read, edit, and delete identity objects such as a realm, role, group, user, and agent.
To map identity attributes using the Principal Name from the SSOToken object.
Access to the Identity Repository Service is provided by the com.sun.identity.idm Java package. The AMIdentityRepository class represents a realm that has one or more identity repositories configured and provides interfaces for searching, creating and deleting identities. The AMIdentity class represents an individual identity such as a user, group or role and provides interfaces to set, modify and delete identity attributes and assign and unassign services. IdRepo is an abstract class that contains the methods that need to be implemented by plug-ins when building new adapters for repositories not currently supported. The current implementation supports Sun Java System Directory Server, IBM Tivoli Directory and Microsoft Active Directory. The following diagram illustrates the design of the Identity Repository Service.
Administrator roles are also defined by the Identity Repository Service. (This is currently available only when the Sun Directory Server With FAM Core Services schema is loaded.) For example, the Realm Administrator can access all data in all configured realms while the Subrealm Administrator can access data only within the specified realm. For more information, see Sun OpenSSO Enterprise 8.0 Deployment Planning Guide. For information on realm privileges, see Chapter 2, Organizing Data within Realms, in Sun OpenSSO Enterprise 8.0 Administration Guide.
OpenSSO Enterprise provides an open and extensible framework for identity federation and associated web services that resolve the problems of identity-enabling web services, web service discovery and invocation, security, and privacy. Federation Services are built on the following standards:
Liberty Alliance Project Identity Federation Framework (Liberty ID-FF) 1.1 and 1.2
OASIS Security Assertion Markup Language (SAML) 1.0 and 1.1
OASIS Security Assertion Markup Language (SAML) 2.0
WS-Federation (Passive Requestor Profile)
Federation Services allows organizations to share identity information (for example, which organizations and users are trusted, and what types of credentials are accepted) securely. Once this is enabled securely, federating identities is possible — allowing a user to consolidate the many local identities configured among multiple service providers. With one federated identity, the user can log in at one identity provider’s site and move to an affiliated site without having to re-establish identity. Figure 2–10 illustrates the interactions between local and remote components of the Federation Services in a OpenSSO Enterprise deployment.
More information on the Federation Services can be found in the Open Federation Architecture and the Federation Use Case documentation on the OpenSSO web site. Also, see Part III, Federation Management Using OpenSSO Enterprise in this book.
The OpenSSO Enterprise Web Services Stack follows a standardized way of integrating web-based applications using XML, SOAP, and other open standards over an Internet Protocol (IP) backbone. They enable applications from various sources to communicate with each other because they are not tied to any one operating system or programming language. Businesses use web services to communicate with each other and their respective clients without having to know detailed aspects of each other's IT systems. OpenSSO Enterprise provides web services that primarily use XML and SOAP over HTTP. These web services are designed to be centrally provided in an enterprise's network for convenient access by client applications. OpenSSO Enterprise implements the follow web service specifications.
Liberty Alliance Project Identity Web Services Framework (Liberty ID-WSF) 1.x
Web Services-Interoperability (WS-I) Basic Security Profile
The following table lists the OpenSSO Enterprise web services.Table 2–1 OpenSSO Enterprise Web Services Stack
Web Service Name
Provides authentication to a web service client (WSC), allowing the WSC to obtain security tokens for further interactions with other services at the same provider. Upon successful authentication, the final Simple Authentication and Security Layer (SASL) response contains the resource offering for the Discovery Service.
A web service that allows a requesting entity, such as a service provider, to dynamically determine a principal's registered attribute provider. Typically, a service provider queries the Discovery Service, which responds by providing a resource offering that describes the requested attribute provider. The implementation of the Discovery Service includes Java and web-based interfaces.
A data service that supports storing and modifying a principal's identity attributes. Identity attributes might include information such as first name, last name, home address, and emergency contact information. The Liberty Personal Profile Service is queried or updated by a WSC acting on behalf of the principal.
The centralized Security Token Service that issues, renews, cancels, and validates security tokens is also used in tandem with the Web Services Security framework.
A set of Java APIs implemented by the developer of a Liberty-enabled identity service. The APIs are used to send and receive identity-based messages using SOAP, an XML-based messaging protocol.
OpenSSO Enterprise uses both XML files and Java interfaces to manage web services and web services configuration data. A OpenSSO Enterprise XML file is based on the structure defined in the OpenSSO Enterprise Document Type Definition (DTD) files located in path-to-context-root/opensso/WEB-INF. The main sms.dtd file defines the structure for all OpenSSO Enterprise service files (located in path-to-context-root/opensso/WEB-INF/classes).
Do not modify any of the DTD files. The OpenSSO Enterprise API and their internal parsing functions are based on the default definitions and alterations to them may hinder the operation of the application.
For more information, see Part IV, The Web Services Stack, Identity Services, and Web Services Security.
In message security, security information is applied at the message layer and travels along with the web services message. Message layer security differs from transport layer security in that it can be used to decouple message protection from message transport so that messages remain protected after transmission, regardless of how many hops they travel on. This message security is available as Web Services Security in OpenSSO Enterprise and through the installation of an authentication agent. Web Services Security is the implementation of the WS-Security specifications and the Liberty Alliance Project Identity Web Services Framework (Liberty ID-WSF). Web Services Security allows communication with the Security Token Service to insert security tokens in outgoing messages and evaluate incoming messages for the same. Towards this end, authentication agents based on the Java Specification Request (JSR) 196 must be downloaded and installed on the web services client (WSC) machine and the web services provider (WSP) machine.
JSR 196 agents can be used only on Sun Java System Application Server or Glassfish web containers.
To secure web services communications, the requesting party must first be authenticated with a security token which is added to the SOAP header of the request. Additionally, the WSC needs to be configured to supply message level security in their SOAP requests and the WSP needs to be configured to enable message level security in their SOAP responses. Figure 2–11 illustrates the components used during a secure web services interaction.
The stand alone applications can directly invoke the interfaces (secure request by WSC, and validate response by WSP) from the WS-Security Library and establish message-level end-to-end web service security. Standalone Java applications do not need the WS-Security Provider Plugin.
For more information, see Part IV, The Web Services Stack, Identity Services, and Web Services Security.
OpenSSO Enterprise contains client interfaces for authentication, authorization, session management, and logging in Java, C, and C++ (using a proprietary XML and SOAP over HTTP or HTTPs communication). These interfaces are used by policy agents and custom applications. Development using these interfaces, though, is labor-intensive. Additionally, the interfaces cause dependencies on OpenSSO Enterprise. Therefore, OpenSSO Enterprise has now implemented simple interfaces that can be used for:
Authentication (verification of user credentials, password management)
Authorization (policy evaluation for access to secured resources)
Provisioning (self-registration, creating or deleting identity profiles, retrieve or update identity profile attributes)
Search (return a list of identity profile attributes that match a search filter)
Identity Web Services also interact with the Logging Service to audit and record Identity Web Services interactions.
These Identity Services are offered using either SOAP and the Web Services Description Language (WSDL) or Representational State Transfer (REST). With SOAP Identity Web Services, you point an integrated development environment (IDE) application project to the appropriate URL and generate the stub code that wraps the function calls to the services. (You can also use wscompile.) With REST Identity Web Services, no coding is necessary. It works right out of box.
OpenSSO Enterprise supports Eclipse, NetBeans, and Visual Studio®.
When Identity Web Services have been implemented, a user interacts with the application which calls the identity repository to retrieve user profile data for authentication and personalization, the configuration data store to retrieve policy data for authorization, and the audit repository for log requests. The application authenticates, authorizes, audits, and finally creates personalized services for the user by calling either the SOAP/WSDL or REST Identity Web Service as provided by OpenSSO Enterprise.
For more information, see Part IV, The Web Services Stack, Identity Services, and Web Services Security.
Global services take configuration values and perform functions for OpenSSO Enterprise on a global basis. The following table lists the global services with brief descriptions.Table 2–2 Global OpenSSO Enterprise Services
What it Does
Contains configuration attributes for Federation Services.
Contains configuration attributes for the Liberty Alliance Project Identity Federation Framework.
Contains configuration attributes for the Liberty Alliance Project Identity Web Services Framework.
Contains configuration attributes for the Liberty Alliance Project Interaction Service — used to get consent from an owner to expose data, or to get additional data.
Contains configuration attributes for multi-federation protocol circles of trust.
Contains configuration attributes for the Password Reset Service.
Contains configuration attributes for the Policy Service.
Contains configuration attributes for the SAML v2 interactions.
Contains configuration attributes for SAML v2 SOAP Binding Service.
Contains configuration attributes for the Security Token Service.
Contains configuration attributes for the Session Service.
Contains configuration attributes for user profiles.
A realm is the unit that OpenSSO Enterprise uses to organize configuration information. Authentication properties, authorization policies, data stores, subjects (including a user, a group of users, or a collection of protected resources) and other data can be defined within the realm. The data stored in a realm can include, but is not limited to:
One or more subjects (a user, a group of users, or a collection of protected resources)
A definition of one or more data stores to store subject (user) data
Authentication details identifying, for example, the location of the authentication repository, and the type of authentication required.
Policy information that will be used to determine which resources protected by OpenSSO Enterprise the subjects can access.
Responder configurations that allows applications to personalize the user experience, once the user has successfully authenticated and been given access.
Administration data for realm management
You create a top-level realm when you deploy OpenSSO Enterprise. The top-level realm (by default opensso) is the root of the OpenSSO Enterprise instance and contains OpenSSO Enterprise configuration data; it cannot be changed after it is created. In general, you should use the default root realm to configure identity data stores, and manage policies and authentication chains. During deployment, OpenSSO Enterprise creates a Realm Administrator who can perform all operations in the configured root realm, and a Policy Administrator who can only create and manage policies.
All other realms are configured under the opensso realm. These sub-realms may contain other sub-realms and so on. Sub-realms identify sets of users and groups that have different authentication or authorization requirements. The use of sub-realms should be restricted to the following two scenarios.
Application Policy Delegation The use case for this is when you need to have different Policy Administrators to create policies for a sub-set of resources. For example, let's assume a sub-realm is created and named Paycheck. This sub-realm is configured with a policy referral from the root realm for configuring protection of resources starting with https://paycheck.sun.com/paycheck. Within the Paycheck sub-realm, a Paycheck Administrator role or group is created and assigned Policy Administration privileges. These administrators are now able to login to the sub-realm and create policies for their applications. By default, the sub-realm inherits the same configuration data store and authentication chains configured for its parent; if these configurations change in the parent, a corresponding change would be needed in the sub-realm. Additionally, all users will still log in to the root realm for access to all the applications. The sub-realm is primarily for the Policy Administrator to manage policies for the application. An educated guess on the number of sub-realms that can be supported would be about 100.
ISP/ASP/Silo The use case for this scenario is when each sub-realm is to have its own set of identity data stores, authentication chains, and policies. Ideally the only common thread between the root and the sub-realm would be the referral policy created in the root realm to delegate a set of resources to the sub-realm. Users would not be able to log in to the root realm (unless they are a member) but would have to authenticate to their sub-realm. Also, agents would have to be configured to redirect user authentication to the particular sub-realm. With regards to performance, the most resource consuming component would be when persistent searches created by the data stores connect to the same directory. An educated guess on the number of sub-realms that can be supported would be about 50.
The OpenSSO Enterprise framework aggregates realm properties as part of the configuration data. Figure 2–13 illustrates how configuration data can use a hierarchy of realms to distribute administration responsibilities. Region 1, Region 2, and Region 3 are realms; Development, Operations, and Sales are realms sub to Region 3.
The following sections provide information on additional components used in a OpenSSO Enterprise deployment.
OpenSSO Enterprise services need to interact with a number of different data stores. The following distinct repositories can be configured.
A configuration repository provides server and service specific data.
One or more identity repositories provide user profile information.
Authentication repositories provide authentication credentials to a particular module of the Authentication Service.
A common LDAP connection pooling facility allows efficient use of network resources. In the simplest demonstration environment, a single LDAP repository is sufficient for all data however, the typical production environment tends to separate configuration data from other data. The following sections contain more specific information.
The default configuration of OpenSSO Enterprise creates a branch in a fresh installation of a configuration data store for storing service configuration data and other information pertinent to the server's operation. OpenSSO Enterprise components and plug-ins access the configuration data and use it for various purposes including:
Accessing policy data for policy evaluation.
Finding location information for identity data stores and OpenSSO Enterprise services.
Retrieving authentication configuration information that define how users and groups authenticate.
Finding which partner servers can send trusted SAML assertions.
OpenSSO Enterprise supports Sun Java System Directory Server and the open source OpenDS as configuration data stores. Flat files (supported in previous versions of the product) are no longer supported but configuration data store failover is — using replication. Figure 2–14 illustrates how configuration data in the configuration data store is accessed.
Previous releases of Access Manager and Federation Manager stored product configuration data in a property file named AMConfig.properties that was installed local to the product instance directory. This file is deprecated for OpenSSO Enterprise on the server side although still supported for agents on the client side. See the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide for more information.
Configuration data comprises the attributes and values in the OpenSSO Enterprise configuration services, as well as default OpenSSO Enterprise users like amadmin and anonymous. Following is a partial listing of the XML service files that contribute to the data. They can be found in the path-to-context-root/opensso/WEB-INF/classes directory.
The data in this node branch is private and is mentioned here for information purposes only.
By default, the OpenSSO Enterprise configuration data is created and maintained in the configuration data store apart from any identity data. Although users can be created in the configuration data store this is only recommended for demonstrations and development environments.
For more information, see Configuration Data Store.
An identity repository is a data store where information about users and groups in an organization is stored. User profiles can contain data such as a first name, a last name, a phone number, group membership, and an e-mail address; an identity profile template is provided out-of-the-box but it can be modified to suit specific deployments.
Identity data stores are defined per realm. Because more than one identity data store can be configured per realm OpenSSO Enterprise can access the many profiles of one identity across multiple data repositories. Sun Java System Directory Server with OpenSSO Enterprise Schema, Microsoft Active Directory, IBM Tivoli Directory and the AMSDK data store are the currently supported identity repositories. Plug-ins can be developed to integrate other types of repositories (for example, a relational database). Figure 2–15 illustrates a OpenSSO Enterprise deployment where the identity data and the configuration data are kept in separate data stores.
The information in an identity repository is maintained by provisioning products separate from OpenSSO Enterprise. The supported provisioning product is Sun Java System Identity Manager.
OpenSSO Enterprise provides out-of-the-box plug-in support for some identity repositories. Each default plug-in configuration includes details about what operations are supported on the underlying data store. Once a realm is configured to use a plug-in, the framework can instantiate it and execute the operations on the appropriate identity repository. Each new plug-in developed must have a corresponding service management schema defining its configuration attributes. This schema would be integrated as a sub schema into idRepoService.xml, the service management file for the Identity Repository Service that controls the identity data stores available under a realm's Data Stores tab. The following sections contain information on the out-of-the-box plug-ins.
The Generic LDAPv3 identity repository plug-in can reside on an instance of any directory that complies with the LDAPv3 specifications. The underlying directory cannot make use of features that are not part of the LDAP version 3 specification, and no specific DIT structure can be assumed as LDAPv3 identity repositories are simply DIT branches that contain user and group entries. Each data store has a name that is unique among a realm's data store names, but not necessarily unique across all realms. The com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo class provides the default LDAPv3 identity repository implementation. There are also implementations for Active Directory and IBM Tivoli Directory
The Generic LDAPv3 identity repository plug-in was used to develop a default plug-in to write identity data to an instance of Microsoft® Active Directory®. The administration console provides a way to configure the directory but the schema needs to be loaded manually.
The Generic LDAPv3 identity repository plug-in was used to develop a default plug-in to write identity data to an instance of IBM Tivoli Directory®. The administration console provides a way to configure the directory but the schema needs to be loaded manually.
This repository resides in an instance of Sun Java System Directory Server and holds the identity data. This option is available during the initial configuration of OpenSSO Enterprise.
This repository resides in an instance of Sun Java System Directory Server and holds the configuration data when installing OpenSSO Enterprise in Legacy and Realm mode. This option must be manually configured.
The Access Manager Repository can reside only in Sun Java System Directory Server and is used with the Sun Directory Server With Access Manager Schema. During installation, the repository is created in the same instance of Sun Java System Directory Server that holds the configuration data. The Access Manager Repository Plug-in is designed to work with Sun Java System Directory Server as it makes use of features specific to the server including roles and class of service. It uses a DIT structure similar to that of previous versions of Access Manager.
This is no longer provided out of the box and many pieces are marked for deprecation. The Access Manager Repository is compatible with previous versions of Access Manager.
When you configure an instance of Access Manager in realm mode for the first time, the following occurs:
An Access Manager Repository is created under the top-level realm.
The Access Manager Repository is populated with internal Access Manager users.
The Java Enterprise System installer does not set up an Access Manager Repository when you configure an Access Manager instance in legacy mode. Legacy mode requires an identity repository that is mixed with the Access Manager information tree under a single directory suffix.
Authentication data contains authentication credentials for OpenSSO Enterprise users. An authentication data store is aligned with a particular authentication module, and might include:
SafeWord authentication servers
RSA ACE/Server systems (supports SecurID authentication)
LDAP directory servers
Identity data may include authentication credentials although authentication data is generally stored in a separate authentication repository. For more information, see Chapter 3, Configuring Authentication, in Sun OpenSSO Enterprise 8.0 Administration Guide.
OpenSSO Enterprise uses a file to bootstrap itself. Previously, AMConfig.properties held configuration information to bootstrap the server but now a file named bootstrap points to the configuration data store allowing the setup servlet to retrieve the bootstrapping data. After deploying the OpenSSO Enterprise WAR and running the configuration wizard, configuration data is written to the configuration data store by the service management API contained in the Java package, com.sun.identity.sm. The setup servlet creates bootstrap in the top-level configuration directory. The content in bootstrap can be either of the following:
A directory local to OpenSSO Enterprise (for example, /export/SUNWam) indicating the server was configured with a previous release. The directory is where AMConfig.properties resides.
An encoded URL that points to a directory service using the following format:
ldap://ds-host:ds-port/server-instance-name?pwd=encrypted-amadmin-password& embeddedds=path-to-directory-service-installation&basedn=base-dn& dsmgr=directory-admin&dspwd=encrypted-directory-admin-password
ldap://ds.samples.com:389/http://owen2.red.sun.com:8080/ opensso?pwd=AQIC5wM2LY4Sfcxi1dVZEdtfwar2vhWNkmS8&embeddedds= /opensso/opends&basedn=dc=opensso,dc=java,dc=net&dsmgr= cn=Directory Manager&dspwd=AQIC5wM2LY4Sfcxi1 dVZEdtfwar2vhWNkmS8
ds.samples.com:389 is the host name and port of the machine on which the directory is installed.
http://owen2.red.sun.com:8080/opensso is the instance name.
AQIC5wM2LY4Sfcxi1dVZEdtfwar2vhWNkmS8 is the encrypted password of the OpenSSO administrator.
/opensso/opends is the path to the directory installation.
dc=opensso,dc=java,dc=net is the base DN.
cn=Directory Manager is the directory administrator.
AQIC5xM2LY4SfcximdVZEdtfwar4vhWNkmG7 is the encrypted password for the directory administrator.
If more than one URL is present in the file and OpenSSO Enterprise is unable to connect or authenticate to the data store at the first URL, the bootstrapping servlet will try the second (and so on). Additionally, the number sign [#] can be used to exclude a URL as in:
# ldap://ds.samples.com:389/http://owen2.red.sun.com:8080/ opensso?pwd=AQIC5wM2LY4Sfcxi1dVZEdtfwar2vhWNkmS8&embeddedds= /opensso/opends&basedn=dc=opensso,dc=java,dc=net&dsmgr= cn=Directory+Manager&dspwd=AQIC5wM2LY4Sfcxi1dVZEdtf war2vhWNkmS8
Policy agents are an integral part of SSO and CDSSO sessions. They are programs that police the web container on which resources are hosted. All policy agents interact with the Authentication Service in two ways:
To authenticate itself in order to establish trust. This authentication happens using the Client SDK.
To authenticate users having no valid session for access to a protected resource. This authentication happens as a browser redirect from the Distributed Authentication User Interface.
When a user requests access to a protected resource such as a server or an application, the policy agent intercepts the request and redirects it to the OpenSSO Enterprise Authentication Service for authentication. Following this, the policy agent requests the authenticated user's assigned policy and evaluates it to allow or deny access. (A policy defines the rules that specify a user's access privileges to a protected resource.) OpenSSO Enterprise supports two types of policy agents:
The web agent enforces URL-based policy for C applications.
The Java EE agent enforces URL-based policy and Java-based policy for Java applications on Java EE containers.
Both types of agents are available for you to install as programs separate from OpenSSO Enterprise. Policy agents are basically clients written using the Client SDK and Identity Services.
All HTTP requests are implicitly denied unless explicitly allowed by the presence of a valid session and a policy allowing access. If the resource is defined in the Not Enforced list for the policy agent, access is allowed even if there is no valid session.
For more information, see J2EE Agent Architecture and Web Agent and C-API Architecture on the OpenSSO web site. For an overview of the available policy agents and links to specific information on installation, see the Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for J2EE Agents.
Authentication agents plug into web containers to provide message level security for web services, and supports both Liberty Alliance Project token profiles as well as Web Services-Interoperability Basic Security Profiles (WS-I BSP). (A profile defines the HTTP exchanges required to transfer XML requests and responses between web service clients and providers.) Authentication agents use an instance of OpenSSO Enterprise for all authentication decisions. Web services requests and responses are passed to the appropriate authentication modules using standard Java representations based on the transmission protocol. An HTTP Authentication Agent or a SOAP Authentication Agent can be used. For more information, see Web Services Security and the Security Token Service.
Contained within the OpenSSO Enterprise ZIP are ssoAdminTools.zip and ssoSessionTools.zip. The following sections have some information about these tools.
ssoadm, the command line interface (CLI), provides a second option to administer OpenSSO Enterprise using the command line. For example, ssoadm can be used to create a policy or import and export Liberty ID-FF metadata. ssoadm is the recommended way for batch processing. It is in ssoAdminTools.zip. For more information, see Chapter 6, Installing the OpenSSO Enterprise Utilities and Scripts, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide and Part I, Command Line Interface Reference, in Sun OpenSSO Enterprise 8.0 Administration Reference.
ssoSessionTools.zip contains scripts and binaries for setting up session failover and databases. For more information, see Chapter 8, Implementing OpenSSO Enterprise Session Failover, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
Enterprise resources cannot be protected by OpenSSO Enterprise until the OpenSSO Enterprise Client SDK is installed on the machine that contains the resource that you want to protect. (The Client SDK is automatically installed with a policy agent.) The Client SDK allows you to customize an application by enabling communication with OpenSSO Enterprise for retrieving user, session, and policy data. For more information, see Chapter 14, Using the Client SDK, in Sun OpenSSO Enterprise 8.0 Developer’s Guide and the Sun OpenSSO Enterprise 8.0 Java API Reference.
The OpenSSO Enterprise service provider interfaces (SPI) can be implemented as plug-ins to provide customer data to the OpenSSO Enterprise framework for back-end processing. Some customer data comes from external data base applications such as identity repositories while other customer data comes from the OpenSSO Enterprise plug-ins themselves. You can develop additional custom plug-ins to work with the SPI. For a complete list of the SPI, see the Sun OpenSSO Enterprise 8.0 Java API Reference. Additional information can be found in the Sun OpenSSO Enterprise 8.0 Developer’s Guide. The following sections contain brief descriptions.
The com.sun.identity.authentication.spi package provides interfaces and classes for writing a supplemental authentication module to plug into OpenSSO Enterprise. The com.sun.identity.authentication package provides interfaces and classes for writing a remote client application that can access user data in a specified identity repository to determine if a user’s credentials are valid.
The com.sun.identity.federation.services package provides plug-ins for customizing the Liberty ID-FF profiles implemented by OpenSSO Enterprise. The com.sun.identity.federation.plugins package provides an interface that can be implemented to perform user specific processing on the service provider side during the federation process. The com.sun.identity.saml2.plugins package provides the SAML v2 service provider interfaces (SPI). The com.sun.identity.wsfederation.plugins package provides the WS-Federation based SPI.
The com.sun.identity.idm package contains the IdRepo interface that defines the abstract methods which need to be implemented or modified by Identity Repository Service plug-ins. The com.sun.identity.plugin.datastore package contains interfaces that search for and return identity information such as user attributes and membership status for purposes of authentication.
The com.sun.identity.policy.interfaces package provides interfaces for writing custom policy plug-ins for Conditions, Subjects, Referrals, Response Providers and Resources.
The com.sun.identity.plugin.configuration package provides interfaces to store and manage configuration data required by the core OpenSSO Enterprise components and other plug-ins.
In previous releases, the functionality provided by the Service Configuration plug-in was known as the Service Management Service (SMS).
This chapter contains information on the usability and manageability features of OpenSSO Enterprise. It includes the following sections:
Previous versions of Sun Microsystems' access management server product were built for multiple hardware platforms, and different web containers. The complexity of this development process led to the release of separate platform and container patches. To alleviate this extraneous development, OpenSSO Enterprise is now available as a single ZIP file which can be downloaded, unzipped, and quickly deployed; there will be no separate installations for each hardware platform. The ZIP file will contain the full OpenSSO Enterprise web archive (WAR), layouts for the generation of other specific WARs, libraries, the Java API reference documentation, and samples. (Tools for use with OpenSSO Enterprise, including the command line interfaces and policy and authentication agents, can be downloaded separately.) Figure 3–1 illustrates the process for deployment, installation and configuration of a new OpenSSO Enterprise WAR and a patched WAR.
When patched, a full patched version of the OpenSSO Enterprise WAR will be included in the download, assuring that there is always a single download to get the latest bits.
The intent of this new process is to allow the administrator to download OpenSSO Enterprise and deploy it on the container or platform of choice, using the web container's administration console or command line interfaces. After the initial launch of the deployed WAR, the user is directed to a JavaServer Page (JSP) called the Configurator that prompts for configuration parameters (including, but not limited to, the host name, port number, URI, and repositories), provides data validation for the parameter values to prevent errors, and eliminates post-installation configuration tasks. Once successfully configured, any further changes to the configuration data store must be made using the OpenSSO Enterprise console or command line interfaces.
When deploying OpenSSO Enterprise against an existing legacy installation, the Directory Management tab will be enabled in the new console.
For more information including a directory layout of the ZIP, see the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
OpenSSO Enterprise has implemented an embedded configuration data store to replace the AMConfig.properties and serverconfig.xml files which had been the storage files for server configuration data. Previously, each instance of the server installed had separate configuration files but now when deploying more than one instance of OpenSSO Enterprise, all server configuration data is stored centrally, in one configuration data store per instance. After the OpenSSO Enterprise WAR is configured, a sub configuration is added under the Platform Service to store the data and a bootstrap file that contains the location of the configuration data store is created in the installation directory. Figure 3–2 illustrates how OpenSSO Enterprise is bootstrapped.
Post installation, the configuration data can be reviewed and edited using the administration console or the ssoadm command line interface. For more information see the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide and the Sun OpenSSO Enterprise 8.0 Administration Guide.
OpenSSO Enterprise also supports an LDAPv3–based solution that uses an existing directory server for configuration data storage. This is configured during installation. Supported directories include Sun Java System Directory Server, Microsoft Active Directory, and IBM Tivoli Directory.
Policy agents function based on a set of configuration properties. Previously, these properties were stored in the AMAgent.properties file, residing on the same machine as the agent. With Centralized Agent Configuration, OpenSSO Enterprise moves most of the agent configuration properties to the configuration data store. Now agent profiles can be configured to store properties locally (on the machine to which the agent was deployed) or centrally (in the configuration data store), making this new function compatible with both older 2.x agents and newer 3.0 agents. Following is an explanation of the local and central agent configuration repositories.
Local agent configuration is supported for backward compatibility. Agent configuration data is stored in a property file named AgentConfiguration.properties that is stored on the agent machine. It is only used by agent profiles configured locally.
Centralized Agent Configuration stores agent configuration data in a centralized data store managed by OpenSSO Enterprise. When an agent starts up, it reads its bootstrapping file to initialize itself. AgentBootstrap.properties is stored on the agent machine and indicates the location from where the configuration properties need to be retrieved. It is used by agent profiles configured locally or centrally. Based on the repository setting in AgentBootstrap.properties, it retrieves the rest of its configuration properties. If the repository is local, it reads the agent configuration from a local file; if the repository is remote, it fetches its configuration from OpenSSO Enterprise.
Thus, Centralized Agent Configuration separates the agent configuration properties into two places: a bootstrapping file stored local to the agent and either a local (to the agent) or central (local to OpenSSO Enterprise) agent configuration data store. AgentBootstrap.properties is the bootstrapping file used by agent profiles configured locally or centrally. It is stored on the agent machine and indicates the local or central location from where the agent's configuration properties are retrieved. If the repository is local to the agent, it reads the configuration data from a local file; if the repository is remote, it fetches its configuration from OpenSSO Enterprise. Choosing Centralized Agent Configuration provides an agent administrator with the means to manage multiple agent configurations from a central place using either the OpenSSO Enterprise console or command line interface. Figure 3–3 illustrates how an agent retrieves bootstrapping and local configuration data, and configuration data from the configuration data store.
An agent fetches its configuration properties periodically to determine if there have been any configuration changes. Any agent configuration changes made centrally are conveyed to the affected agents which will react accordingly based on the nature of the updated properties. If the properties affected are hot swappable, the agent can start using the new values without a restart of the underlying agent web container. Notification of the agent when configuration data changes and polling by the agent for configuration changes can be enabled. Agents can also receive notifications of session and policy changes.
A agent configuration data change notification does not contain the actual data; it is just a ping that, when received, tells the agent to make a call to OpenSSO Enterprise and reload the latest. Session and policy notifications, on the other hand, contain the actual data changes. Also, when using a load balancer, the notification is sent directly to the agent whose configuration has been changed. It does not go through the load balancer.
For more information see the Sun OpenSSO Enterprise 8.0 Administration Guide.
OpenSSO Enterprise has implemented a Common Tasks tab that allows an administrators to create federation-based objects using console wizards. The wizards offer simplified provider configuration with metadata input using the URL http://host-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp or a metadata file. The following things can be done using a Common Task wizard:
Create SAML v2 Providers They can be hosted or remote provider; and identity or service provider. To create them, you just need to provide some basic information about the providers.
Create Fedlet A Fedlet is a small ZIP file that can be given to a service provider to allow for immediate federation with an identity provider configured with OpenSSO Enterprise. It is ideal for an identity provider that needs to enable a service provider with no federation solution in place. The service provider simply adds the Fedlet to their application, deploys their application, and they are federation enabled. For more information, see The Fedlet.
Test Federation Connectivity This task validates your federation configuration. It will show if federation connections are being made successfully by identifying where the troubles, if any, are located.
Access Documentation This link opens the OpenSSO documentation page. View frequently asked questions, tips, product documentation, engineering documentation as well as links to the community blogs.
Register Your Product This link allows you to register your product with Sun Connection. You must have a Sun Online Account in order to complete the registration. If you do not already have one, you may request one as part of this process.
Figure 3–4 is a screen capture of the Common Tasks wizard.
For more information see the Sun OpenSSO Enterprise 8.0 Administration Guide.
OpenSSO Enterprise makes it easy to integrate with third-party software. Plug-ins and other tools have been developed to ease the integration of OpenSSO Enterprise and the following products.
For more information, see Sun OpenSSO Enterprise 8.0 Integration Guide.
Sun Java System Identity Manager enables an enterprise to manage and audit access to accounts and resources as well as distribute the access management overhead. A OpenSSO Enterprise policy agent is deployed on the Identity Manager machine to regulate access to the Identity Manager server. By mapping Identity Manager objects to OpenSSO Enterprise users and resources, you may significantly increase operational efficiency. For use cases, a technical overview, installation and configuration procedures, architecture diagrams and process flows, see Chapter 1, Integrating Sun Identity Manager , in Sun OpenSSO Enterprise 8.0 Integration Guide.
Computer Associates SiteMinder (originally developed by Netegrity) is one of the industry's first SSO products — used in a majority of legacy web SSO deployments to protect their intranet and external applications. OpenSSO Enterprise provides the tools for SSO integration with SiteMinder in both intranet and federated environments. They include a SiteMinder Agent and a OpenSSO Enterprise Authentication Module for SiteMinder. They can be found in the integrations/siteminder directory of the exploded opensso.war. For use cases, a technical overview, installation and configuration procedures, architecture diagrams and process flows, see Chapter 2, Integrating CA SiteMinder, in Sun OpenSSO Enterprise 8.0 Integration Guide.
Oracle Access Manager (originally developed by Oblix) is an SSO product with many of the same features as Sun OpenSSO Enterprise and Computer Associates SiteMinder. Oracle Access Manager can be deployed to protect both internal and external applications. OpenSSO Enterprise provides an Oracle Agent and a custom OpenSSO Enterprise Authentication Module for Oracle Access Manager. They can be found in the integrations/oracle directory of the exploded opensso.war. For use cases, a technical overview, installation and configuration procedures, architecture diagrams and process flows, see Chapter 3, Integrating Oracle Access Manager, in Sun OpenSSO Enterprise 8.0 Integration Guide.
Sun OpenSSO Enterprise can be deployed in a number of ways. This chapter contains two sample deployment architectures.
For more information, see Sun OpenSSO Enterprise 8.0 Deployment Planning Guide.
Figure 4–1 illustrates one deployment architecture for Sun OpenSSO Enterprise.
Figure 4–2 illustrates another deployment architecture for Sun OpenSSO Enterprise.