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