This chapter provides an overview of the information that an engineer needs to know to deploy Oracle Waveset Service Provider. Deploying this product requires knowledge about Oracle Waveset, LDAP directories, and optionally, federation management. For a broader discussion about Service Provider, see Business Administrator's Guide. See Deployment Guide for more information about implementing Waveset.
Waveset Service Provider is a highly-scalable, extranet-focused identity management solution that is capable of provisioning and maintaining millions of end-user accounts that are stored on an LDAP directory server. Service Provider can also manages thousands of administrator accounts and synchronizes LDAP account data with other resources.
Service Provider is a component of Waveset and is installed automatically. However, deploying Service Provider functionality requires additional planning and effort beyond that required for Oracle Waveset.
You need to manage millions of extranet accounts defined in an LDAP directory.
You should deploy Service Provider in the following circumstances:
You have any number of employee and other internal accounts defined in an LDAP directory that can be managed simply.
You do not need the complex capabilities that Waveset workflows provide.
An Service Provider deployment adds the following to Oracle Waveset:
A user view that is specific to Service Provider users. The user view provides a data model for describing the provisioning operations to be performed, including attribute modifications, password resets, and account disables.
Transaction manager. Provides a mechanism for executing provisioning requests and ensures all resource operations are performed, including those that need to be retried due to resource or server failure. Transactions are logged in a separate database from the Waveset repository.
Enhanced reporting capabilities. Service Provider tracks system events, such as concurrent users and administrators, resource operations, and operation failures. Administrators can use the dashboard graph feature on the Waveset Administrator interface to quickly assess the current system and spot abnormalities, and to understand historical trends (such as concurrent users or resource operations over a time period.) For more information about this feature, see Business Administrator's Guide.
Service Provider also provides the following features:
Delegated administration. Administrators can view and edit only users that they control. This is enforced by assigning organizations and Service Provider-specific capabilities to administrators, or dynamically by rules granting finer grained capabilities and rights.
Synchronization services. Service Provider also synchronizes account information on the LDAP directory with accounts on other resources.
Service Provider does not have its own Administrator Interface. All administration tasks, such as system configuration and viewing dashboard graphs are performed from the Waveset Administration Interface. Service Provider provides a set of sample User pages that illustrate how the product can be implemented, but customizations are required for these pages.
Service Provider does not use many of the features present in Waveset, because they are less useful in large-scale “service provider” environments. Concepts not used in Service Provider include:
Reconciliation and loading from resources
Risk analysis
Compliance
Some concepts are applicable to both products, including the following:
Resource and Active Sync adapters
Forms
Delegated administration
Roles and rules
SPML
Infrastructure code, such as tracing and utilities
The following sections describe some of the differences in detail.
The IDMXUser view is similar to the Waveset User View. Both views allow the caller to create or check out a view, make changes to the view, and check in the results. However, the attributes within the two views differ greatly.
The IDMXUser view is much narrower in scope than the Waveset User view. For example, the IDMXUser view does not contain the global or password top-level attributes. The waveset attribute is not supported in IDMXUser, but some of its sub-attributes are supported through other attributes in IDMXUser. The IDMXUser view does not return resource-specific attributes unless specifically requested.
For a full description of the IDMXUser view and a comparison between the IDMXUser view and the Waveset User view, see Chapter 4, IDMXUser View.
Service Provider bypasses the Waveset repository in the following ways:
User accounts are not loaded into the repository. Instead, all account information is stored in an LDAP directory. Information that would be in the account index in Waveset is stored in a configurable LDAP attribute. Alternatively, an auxiliary object class may be created to identify the existing and to-be-provisioned users. However, if there are existing users in the master directory store, then this new auxiliary object class must be retroactively added to these users.
Transaction information is written to a separate database.
Workflows are powerful tools for provisioning users and establishing approvals in Waveset. However, because workflows often result in complex transactions involving human interaction, they are not ideally suited for environments in which simple provisioning actions need to be performed on millions of users.
As a result, Service Provider does not use workflows. Instead, Service Provider uses a transaction manager to carry out transactions, such as resource operations and updates to LDAP meta-data. The transaction manager persists all transactions into a database and ensures that any transaction failures caused by a resource or the Service Provider server are completed.
See Workflow Callouts for information about how callouts provide some of the functionality handled by workflows.
Service Provider does not require authentication or authorization when performing provisioning actions through the LighthouseContext API. A portal or an access management application can perform these services. Communications between the portal and Service Provider (if using SPML) must be secured by using SSL or similar technology.
Authentication and authorization are performed by Waveset. Service Provider administrators can be Waveset or Service Provider users that are assigned Service Provider-specific capabilities and are able to control organizations. The organizations are created in Waveset, but the administrators that belong in each organization are defined by the customers. These administrators can be determined by searching for specific values on LDAP attributes, or by enabling external authorization. External authorization on Service Provider Users can be enabled for the Service Provider End User interface or Waveset Administrator interface.
When enabled, viewing, creating, updating, and deleting can be controlled by one or more Service Provider User AdminRoles assigned to the user (Service Provider or Oracle Waveset) making the request. Whether the user is allowed to do the action is controlled the evaluation of Rules assigned one or more AdminRoles assigned to the user, which use external resource data to determine whether to grant access or not.
Service Provider does not load LDAP user account information into the repository. Instead, it uses the information already in place in the directory. As a result, there is no need to configure the resource adapter to perform reconciliation; nor is it necessary to perform a load from resource or a load from file operation to populate the account index with end user accounts.
However, if administrator accounts are not already defined within Waveset, you might need to populate administrator accounts into the repository. Any data loading mechanism can be used to accomplish this task. See Business Administrator's Guide for more information.
Service Provider provides a set of sample end-user pages that can be used as the starting point of your own user interface. The sample end-user pages are implemented using the Apache Struts Tiles Framework. This allows you to easily customize the default pages.
To implement Service Provider, you will need to perform the following tasks:
Install Waveset. You must create a transaction database as part of the installation process. See Installation Guide for detailed instructions.
Configure Service Provider as directed in Business Administrator's Guide. See Chapter 5, Other Objects in Service Provider for information about customizing user forms and rules.
Customize the end user pages or create a portal application that allows end-users to perform actions such as creating accounts, editing attributes, including passwords. The sample end-user pages are a starting point. You must use the LighthouseContext API or SPML to communicate with Service Provider. The IDMXUser view is used to perform all provisioning tasks.
Service Provider provides a REF kit to help you implement the product. This kit is located in the idmspe-refkit.zip file in the root directory of the installation media. The kit contains the following:
JAR files needed to develop and deploy Service Provider custom code.
A sample Java file (ApiUsage.java) that implements the most important features of the LighthouseContext and IDMXUser view.
A sample Java file (SpmlUsage.java) that demonstrates how to use implement Service Provider using SPML.
Several sample audit handlers, filters, and formatters.
Authentication/authorization filter used in the sample end-user pages.
The build.xml file, which is an Ant script that can be used to build, deliver, and test source.
Javadocs
The REF kit has the following requirements:
Optional for testing:
JUnit 3.8.x or higher
You might also need to copy any additional JAR files to the lib directory. The build will automatically load the JAR files for both compiling and testing.
See http://ant.apache.org for more information about using Ant.
Use the following general procedure to set up your development and testing environment. Refer to the JDK and Ant documentation for detailed instructions.
Install JDK 1.5 or higher.
Install Apache Ant 1.6.3 or higher.
Set the JAVA_HOME environment variable to point to the JDK. For example:
JAVA_HOME=c:\jdk-1.5.0_x |
Set the ANT_HOME environment variable to point to Ant. For example:
ANT_HOME=c:\apache-ant-1.6.3 |
Add JAVA_HOME\bin and ANT_HOME\bin to the PATH environment variable.
Install the REF kit.
mkdir spe-dev copy idmspe-refkit.zip spe-dev cd spe-dev unzip idmspe-refkit.zip |
You are now ready to change directories to spe-dev and run ant. You may run ant with or without an optional target. To specify a target, enter ant TargetName, such as ant compile. If you do not specify a target, ant will build everything in the src directory and create a JAR file in a new directory, dist.
The following table lists the possible targets.
Target |
Description |
---|---|
init |
Initializes the build environment by creating dependent directories. |
compile |
Compiles all source in the src directory into the build directory. |
resources |
Copies all non-Java source files into the build directory. This is for properties file support and other embedded resources. |
dist |
Create a JAR file from the files in the build directory into the dist directory. The name of the JAR will be the project name specified at the top of the build.xml file “MyProject” and a timestamp. |
clean |
Removes the dist, build, and reports directories and remove all .class files from the test directory. |
test |
Calls the compile, resources, test-compile, and test-run targets (in that order), then runs the JUnit reports task on the results to produce both HTML and text reports on the success or failure of the tests. The reports are written to the reports directory. |
test-run |
Calls the compile, resources, and test-compile targets. Then it runs each test case within the test directory whose file name contains the pattern *Tests.java. |
test-compile |
Calls the compile, and resource targets, then compiles all the files within the test directory. |