|
| |
| Sun[TM] Identity Manager Service Provider Edition 8.0 Deployment | |
Chapter 2
Planning the Identity Manager Service Provider InstallationThis chapter provides an overview of topics that must be considered before deploying Identity Manager Service Provider. Deploying this product requires knowledge about Identity Manager, LDAP directories, access control applications (such as Sun Java™ System Access Manager), and optionally, federation management. However, the topics of access control and federation management are not discussed.
Determining the ArchitectureService Provider may be deployed in either a one-tier or two-tier architecture. The following sections describe both of these architectures.
All implementations require a relational database for storing transaction information. There are no specific requirements for the database, or its host, other than it must be able to connect to Service Provider with JDBC. See the release notes for a list of supported databases.
Service Provider uses transactions to encapsulate provisioning work. (Workflows are not implemented in this product, but callouts are available.) Transactions include resource operations as well as updates to meta-data in a user’s entry in the master directory. The transaction manager, which executes these transactions, is configurable from the Identity Manager Administrator Interface. Configuration options include whether to process transactions synchronously, and when and how often to persist transactions. Transactions are stored in a database, and are tracked to completion through resource or server failures.
Service Provider requires an LDAP directory to query and provision user accounts. LDAP user account information is not stored in an Identity Manager repository. However, information stored in an LDAP directory may be provisioned to other accounts on other resources.
One-Tier Architecture
In a one-tier architecture, Service Provider and the user interface are installed on the same application server (or servers). This option is less secure, because the web server must have access to the internal databases and resources. The following diagram illustrates Service Provider in a one-tier environment.
Figure 2-1 Service Provider in a One-Tier Architecture
Two-Tier Architecture
In a two-tier architecture, the portal is in a demilitarized zone (DMZ), while Service Provider remains secure within the enterprise. The portal accesses Service Provider over SPML or with a RemoteContext.
Implementing a two-tier architecture means you must take additional security precautions. It is recommended that you perform the following steps to secure your network:
- Install a firewall between the portal server and the Service Provider server.
- Use either HTTPS or HTTP in conjunction with SSL for communications between the servers. This is especially true if Service Provider resides in an untrusted domain.
- Restrict the IP addresses that the portal server and Service Provider server can use to communicate.
The following diagram illustrates how Service Provider can be implemented in a two-tier architecture.
Figure 2-2 Two-Tier Architecture with a Custom User Interface
Planning Delegated AdministrationDelegated administration of Service Provider users is enabled through the following means:
Organization-Based Authorization
Service Provider administrators are Identity Manager users that are assigned capabilities and can control organizations. These administrators can be created and maintained in the same way as Identity Manager administrators.
Several different levels of administrators might be needed in your environment to perform various tasks, such as the following:
- The lowest level of administrator might be permitted to create and edit end user (customer) accounts only. There might be thousands administrators with these capabilities.
- Another level of administrator might be permitted to create, edit, and delete low-level administrators as well as customer accounts. There might be hundreds of such administrators.
- A set of administrators to manage the LDAP directory and other resources. There might be several dozen of this type of administrator.
- A few high-level administrators that have super user abilities.
The last two categories of administrators would likely be created and maintained manually in the Administrator Interface. However, to create the lower-level administrators, perform the following tasks:
- Review the object classes and attributes present in your LDAP directory and determine which of these items contain data that indicates the user should have administrative powers. For example, you might have an attribute that indicates a user is a retailer or manager. A retailer would have the ability to create accounts. A manager might be permitted to create retailer accounts.
- Add the attributes to the schema map of the LDAP resource.
- Determine how you will limit the scope of each administrator. For example, a retailer based in Texas probably should not be allowed to create accounts for users who live in New York. Similarly, a manager should not be allowed to delete accounts outside her realm.
- Create organizations in Identity Manager that correspond to the scopes defined in the previous step.
- Create a user form that creates an Identity Manager account, assigns capabilities as well as an organization for each administrator. The user form must use the attributes defined in Step 2.
- Use reconciliation or other data loading mechanism to load the administrator accounts into Identity Manager.
Admin Roles
For granting fine-grain capabilities and scope of control on Service Provider users, use an Admin Role whose authType is ServiceProviderUserAdminRole. The Admin Roles can be configured to be dynamically assigned to one or more Identity Manager or Service Provider Users at login time.
Rules can be defined and applied to the Admin Roles that specify the capabilities (such as Service Provider Create User) of the members of that admin role.
To use Admin Role delegation for Service Provider users, you must enable it in the Identity Manager system configuration object. See Identity Manager Administration for detailed information about this task.
To define this type of Admin Role, you must create one or more rules. See Delegated Administration for more information.
