Additional Components

The following sections provide information on additional components used in a OpenSSO Enterprise deployment.

• Data and Data Stores

• The bootstrap File

• Policy Agents

• Security Agents

• OpenSSO Enterprise Tools

• Client SDK

• Service Provider Interfaces for Plug-ins

Data and Data Stores

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.

• Configuration Data

• Identity Data

• Authentication Data

Configuration Data

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.

Figure 2–14 Accessing Configuration Data

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.

• AgentService.xml

• amAdminConsole.xml

• amAgent70.xml

• amAuth.xml

• amAuth-NT.xml

• amAuthAD.xml

• amAuthAnonymous.xml

• amAuthCert.xml

• amAuthConfig.xml

• amAuthDataStore.xml

• amAuthHTTPBasic.xml

• amAuthJDBC.xml

• amAuthLDAP.xml

• amAuthMSISDN.xml

• amAuthMembership.xml

• amAuthNT.xml

• amAuthRADIUS.xml

• amAuthSafeWord-NT.xml

• amAuthSafeWord.xml

• amAuthSecurID.xml

• amAuthWindowsDesktopSSO.xml

• amClientData.xml

• amClientDetection.xml

• amConsoleConfig.xml

• amDelegation.xml

• amEntrySpecific.xml

• amFilteredRole.xml

• amG11NSettings.xml

• amLogging.xml

• amNaming.xml

• amPasswordReset.xml

• amPlatform.xml

• amPolicy.xml

• amPolicyConfig.xml

• amRealmService.xml

• amSession.xml

• amUser.xml

• amWebAgent.xml

• idRepoEmbeddedOpenDS.xml

• idRepoService.xml

• identityLocaleService.xml

• ums.xml

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.

Identity Data

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.

Figure 2–15 OpenSSO Enterprise Deployment with Two 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.

• Generic Lightweight Directory Access Protocol (LDAP) version 3

• LDAPv3 Plug-in for Active Directory

• LDAPv3 Plug-in for Tivoli Directory

• Sun Directory Server With FAM Core Services

• Sun Directory Server With Full Schema (including Legacy)

• Access Manager Repository Plug-in

Generic Lightweight Directory Access Protocol (LDAP) version 3

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

LDAPv3 Plug-in for Active 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.

LDAPv3 Plug-in for 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 IBM Tivoli Directory®. The administration console provides a way to configure the directory but the schema needs to be loaded manually.

Sun Directory Server With FAM Core Services

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.

Sun Directory Server With Full Schema (including Legacy)

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.

Access Manager Repository Plug-in

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

Authentication data contains authentication credentials for OpenSSO Enterprise users. An authentication data store is aligned with a particular authentication module, and might include:

• RADIUS servers

• 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.

The bootstrap File

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

  For example:

  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

  where

  • 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

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.

Security 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.

OpenSSO Enterprise Tools

Contained within the OpenSSO Enterprise ZIP are ssoAdminTools.zip and ssoSessionTools.zip. The following sections have some information about these tools.

• ssoadm Command Line Interface

• Session Failover Tools

ssoadm Command Line Interface

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.

Session Failover Tools

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.

Client SDK

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.

Service Provider Interfaces for Plug-ins

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.

• Authentication Service SPI

• Federation Service SPI

• Identity Repository Service SPI

• Policy Service SPI

• Service Configuration Plug-in

Authentication Service SPI

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.

Federation Service SPI

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.

Identity Repository Service 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.

Policy Service SPI

The com.sun.identity.policy.interfaces package provides interfaces for writing custom policy plug-ins for Conditions, Subjects, Referrals, Response Providers and Resources.

Service Configuration Plug-in

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).