Sun Identity Manager Service Provider 8.1 Deployment

Chapter 1 Identity Manager Service Provider Overview

This chapter provides an overview of the information that an engineer needs to know to deploy Sun Java^TM System Identity Manager Service Provider. Deploying this product requires knowledge about Identity Manager, 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 Identity Manager.

What Is Identity Manager Service Provider?

Identity Manager 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 Identity Manager and is installed automatically. However, deploying Service Provider functionality requires additional planning and effort beyond that required for Identity Manager.

When Should Service Provider Be Deployed?

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 Identity Manager workflows provide.

Service Provider Features

An Service Provider deployment adds the following to Identity Manager:

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 Identity Manager 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 Identity Manager 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 Identity Manager 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.

Differences Between Identity Manager and Service Provider

Service Provider does not use many of the features present in Identity Manager, 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.

IDMXUser View

The IDMXUser view is similar to the Identity Manager 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 Identity Manager 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 Identity Manager User view, see Chapter 4, IDMXUser View.

Repository

Service Provider bypasses the Identity Manager 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 Identity Manager 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 and Approvals

Workflows are powerful tools for provisioning users and establishing approvals in Identity Manager. 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.

Authentication and Authorization

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 Identity Manager. Service Provider administrators can be Identity Manager or Service Provider users that are assigned Service Provider-specific capabilities and are able to control organizations. The organizations are created in Identity Manager, 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 Identity Manager 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 Identity Manager) 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.

Data Loading Mechanisms

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 Identity Manager, 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.

User Interface

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.

Implementation Overview

To implement Service Provider, you will need to perform the following tasks:

Install Identity Manager. 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.

Using the Service Provider REF Kit

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

Requirements

The REF kit has the following requirements:

JDK 1.5
Ant 1.6.3 or higher

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.

Building with the REF Kit

Use the following general procedure to set up your development and testing environment. Refer to the JDK and Ant documentation for detailed instructions.

Set Up Development and Testing Environment:

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