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 |
Description |
---|---|
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)
Token validation
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.