|
Oracle® Identity Management Concepts and Deployment Planning Guide
10g Release 2 (10.1.2) B14084-02 |
|
 Previous |
 Next |
|
Oracle® Identity Management Concepts and Deployment Planning Guide
10g Release 2 (10.1.2) B14084-02 |
|
|
Previous |
Next |
This chapter describes the planning methods for deploying Oracle Identity Management services.
This chapter contains the following sections:
Successful deployment and use of products depend on a well-planned identity management infrastructure.
This section outlines the deployment planning process for the Oracle Identity Management infrastructure, as follows:
A requirement analysis and high-level deployment considerations are presented along with some logical deployment plans that highlight these considerations.
Detailed deployment planning considerations are presented.
Figure 3-1 illustrates the process to follow when planning an identity management deployment.
As shown in Figure 3-1, the deployment planning process is iterative. Based on the initial requirements, you perform high-level planning to create a logical deployment plan, and you use the logical deployment plan to perform detailed deployment planning and create the physical deployment plan for the actual implementation. If new requirements emerge after implementation, you repeat the analysis, planning, and deployment process.
This section describes some of the typical enterprise requirements you must analyze when planning an Oracle Identity Management deployment. The requirements include process issues, functionality requirements, and high availability concerns. It also describes various logical deployment plans that can help you select the optimal logical architecture of the Oracle Identity Management infrastructure. Some of the main requirements that drive the logical deployment decision are enterprise integration, administrative controls, and application deployment requirements.
At the end of the requirement analysis process, you select a high-level, logical architecture for the Oracle Identity Management deployment consisting of one or more logical identity management infrastructures. This is the basis for the detailed deployment planning that is outlined in the next section.
This section contains the following topics:
This section describes high-level requirements and contains the following topics:
Deciding Who Will Plan and Deploy the Oracle Identity Management Infrastructure
Deciding Which Components of Oracle Identity Management to Deploy
Considering Third-Party Identity Management Integration Requirements
Considering High Availability, Scalability, and Performance Requirements
For small deployments, application administrators are typically responsible for planning, deploying, and administering Oracle Identity Management.
Large deployments can take advantage of the centralized services provided by an identity management infrastructure, such as sharing services across a variety of Oracle and third-party applications, and create a central group, that consists of application, network, and security administrators responsible for these services. This group typically performs the following tasks:
Designing the identity management system deployment
Defining security policies for the shared infrastructure
Managing and administrating the deployment
Monitoring processes and log files
Monitoring performance and machine loads
Implementing data backup strategies and restoring data in the event of failures
The components that comprise Oracle Identity Management centralize many administration tasks.
Plan on implementing Oracle Internet Directory, OracleAS Single Sign-On, and Oracle Delegated Administration Services. Oracle Internet Directory and OracleAS Single Sign-On provide basic identity management services, and Oracle Delegated Administration Services is the primary means for user password self-maintenance.
Deploy Oracle Directory Integration and Provisioning if you are integrating with other third-party directories. The directory integration platform is configured with specific directory synchronization profiles that enable synchronization with supported third-party directories.
If you are not using third-party directories, you should consider deploying Oracle Directory Integration and Provisioning services because many Oracle products, such as Oracle Application Server Portal and Oracle Collaboration Suite, use its provisioning integration features.
If you are deploying a public key infrastructure (PKI), you can use Oracle Application Server Certificate Authority to issue and manage certificates. If you have already deployed a third-party PKI, you can configure the rest of the Oracle Identity Management infrastructure and other Oracle products to use the existing certificate authority.
Additionally, some Oracle products require deployment of some Oracle Identity Management infrastructure components to support user administration.
|
Note: Specific information about the dependencies of individual Oracle products on the various Oracle Identity Management components are described in their respective administrator's guides. |
In small installations of Oracle products and in preproduction environments, application administrators can install minimal instances of the Oracle Identity Management infrastructure to support their Oracle applications.
Many enterprises have, or have plans to deploy, other identity management components. Oracle Identity Management is designed to use other enterprise identity management solutions and any applications you already have for provisioning and administering your enterprise environments.
Oracle components that use identity management, such as Oracle Application Server, Oracle Database, and Oracle Collaboration Suite, are supported by an Oracle Identity Management instance. This instance works with your deployed infrastructure components to provide transparent user management and Web single sign-on across both environments.
The Oracle Identity Management infrastructure uses Oracle Internet Directory as the repository for storing all user identities. A user can have access to multiple applications in the enterprise. Typically, however, there should be only one entry in Oracle Internet Directory representing any particular user's identity. You must plan the location and contents of the user entries in the directory information tree (DIT) before deploying Oracle Internet Directory and other identity management infrastructure components.
In application service provider (ASP) deployments where centralized identity management is required, you must create different identity management realms for the ASP administrators and for the users of each of the ASP customers (subscribers).
With the growth of e-business and enterprise applications, IT departments need to consider how to reuse user profile information and provide access to a growing number of users, both inside and outside the enterprise, without diminishing security or exposing sensitive information. The administration of multiple versions of user identities across multiple applications makes their task difficult Consider deploying a central identity management infrastructure to enable features such as centralized account creation and management, single password and credential management, and single sign-on to Web applications.
Typically, an identity management infrastructure is shared across an assortment of Oracle and other enterprise applications. Therefore, it is important to consider the following deployment requirements:
Types of users: It may be necessary for enterprise applications, such as OracleAS Portal, to be available to external (Internet) users, such as business partners, in addition to internal (intranet) users. As a result, you must determine if one Oracle Internet Directory for all identities or a separate Oracle Internet Directory for each group of identities is appropriate.
Application load requirements: Application load and availability requirements determine how available the identity management infrastructure must be. If applications must be highly available, so must the identity management infrastructure on which they depend.
ASP requirements: Apart from the identity management deployment, consider the requirements mandated by the application. For example, an ASP deployment might require administrative delegation.
Departmental autonomy for deployment of new applications: Large enterprises may require administrative autonomy for applications within independent departmental units. In such a case, it may be necessary to have a separate departmental application repository that contains some enterprise data, along with application-specific data, while maintaining a centralized identity management infrastructure.
Administrative autonomy for managing common identity information: Security policies are important considerations when planning identity management. Consider the administration models for managing the identity, roles, policies, and groups to meet the enterprise requirements. It should be possible to manage the identity of the users according to common privileges defined by the security policies of the enterprise.
Administrative autonomy for individual applications deployed against the identity management infrastructure: An enterprise may have a different administrator responsible for each enterprise application. For example, the administrator of enterprise user management might be different from that of the e-mail service; the administrator of financials might need full control over the privileges of its users; and the OracleAS Portal administrator may need full control over the Web pages for a specific user or a specific group. In addition, you must define which users need access to which resources and at what level of security. To meet the needs of the administrators, and to satisfy the different security requirements, you need to consider the administrative controls requirements.
There may be enterprise applications deployed, such as OracleAS Portal, that must be available to both internal users and external users. You must ensure that corporate intranet resources are isolated from external users, and that intranet applications are protected from denial of service attacks aimed at the extranet portal. In such deployments, security separation may be necessary between the internal and external identity management infrastructures.
Due to organizational constraints and high-level executive mandates, it may be necessary to deploy separate identity management infrastructures for different environments to maintain a clear separation between environments and provide protection from one environment to another. Sometimes, it may also be necessary to isolate some data changes to one environment or to delay their propagation.
|
Note: These are primarily high-level considerations and not derived from any actual throughput or capacity calculations, which are typically addressed by tuning and sizing in the next stage of planning. |
Consider the following integration functions if an enterprise has a third-party identity management infrastructure in place:
Windows integration: If an enterprise is using Microsoft Windows components, such as Active Directory and Kerberos authentication, consider the integration required for the identity management components. Examples of integration functions are synchronizing user information with Oracle Internet Directory, and integrating OracleAS Single Sign-On authentication.
User account management: User account management refers to the process by which new users are added to and deleted from enterprise systems. New user accounts can potentially be created from a number of different sources, such as human resource (HR) systems, customer relationship management (CRM) systems, and network administration environments. When a new user is created in one system, automated provisioning creates the required user account profiles in other enterprise applications.
If an enterprise has deployed enterprise applications such as HR and CRM, consider using the user provisioning integration features with the identity management system. The user provisioning can still be done from the different sources.
Directory services: If an enterprise has deployed an LDAP directory, such as iPlanet, consider synchronizing the LDAP server with Oracle Internet Directory to provide centralized user administration.
Runtime security service integration: If it is necessary for users to access applications integrated with Oracle Internet Directory and a third-party or Web authentication application, consider integration requirements that provide OracleAS Single Sign-On access to Web applications with a single digital identity.
Identity management infrastructures contain several components, and each has availability considerations. A high availability solution must be able to detect and recover from software failures of any of the processes associated with identity management. Components must be deployed to meet the availability requirements of the whole application.
Based upon application usage and user traffic, performance requirements must be considered. Deployment configurations must be planned so that the deployment can be scaled for increased user traffic as applications are deployed.
"Planning the Physical Network Topologies" lists accepted physical topologies that implement the requirements, such as high availability, scalability, and performance.
This section discusses commonly-used logical deployment models that can help you select a logical deployment plan. By matching your requirements to one or more of these models, you can derive a logical deployment plan.
This section contains the following topics:
Model of Deploying a Central Identity Management System - Standard Enterprise Model
Model of Providing Administrative Autonomy for Departmental Applications
Model of Integrating Oracle Identity Management in a Windows Environment
In a standard enterprise model, such as the one shown in Figure 3-2, a group within an organization manages and deploys a single centralized identity management infrastructure. As instances of enterprise applications are deployed, they use the centralized infrastructure. A centralized security model allows applications to install against a central infrastructure but with controlled privileges. This model makes deployment and administration of new applications much easier and improves application usability by enabling certain features, such as centralized account creation and management, single password and credential management, and single sign-on to Web applications. The information model is the same for all the users in this deployment.
This type of deployment implements the following:
Central administration through a single, enterprise-wide console to create enterprise identities and manage shared properties
A shared identity management infrastructure for Oracle and other enterprise applications
Administrative controls to delegate the administration of the applications
An enterprise application, such as OracleAS Portal, must be available to internal and external users. As a result, enterprise applications must maintain profile and privilege information for internal and external identities. While this integration is optimal, it is also important to ensure intranet resources are isolated from external users and intranet applications are protected from denial of service attacks aimed at the extranet portal.
The following examples illustrate access to internal and external users. Each provides the security environment isolation between groups of applications that require isolation among them, such as extranet and intranet environments.
Example A: Using one identity management infrastructure
A single logical Oracle Internet Directory, as shown in Figure 3-3, is used to store internal and external user profiles, and the user information is configured the same for both internal and external users. A different subtree is used to store user profiles for both types of users within the same logical Oracle Internet Directory. The password policies can be the same for both types of users.
This type of deployment implements the following:
Application deployment that provides access to internal and external users
Central services and administration
Example B: Using two identity management infrastructures—security isolation
This example uses two identity management infrastructures: one each for users accessing the applications from inside and outside the enterprise network, as shown in Figure 3-4. In this type of deployment, there is a clear boundary between internal and external user repositories. More resources are available to internal users if external users are restricted.
There are many deployment measures necessary to achieve the isolation described in this example. Isolating the directory service for an extranet portal is a key measure. Only an employee's identity and nonsensitive profile information is synchronized with the enterprise directory; however intranet application identities and associated metadata are not replicated. External user identities (self-registered or otherwise), extranet portal-specific user profiles, preferences, and identities and roles of applications attached to the extranet portal are represented within its dedicated directory but are not replicated to the enterprise directory. It is best if the information model is the same in both logical Oracle Internet Directory instances.
DNS-based routing can be used to route the users to different identity management infrastructures for single sign-on authentication.
|
Note: External users accessing applications within the intranet will have single sign-on access across the extranet portal and other internally deployed applications, such as Oracle Collaboration Suite. |
This type of deployment implements the following:
Security isolation: Boundaries among groups of applications that require isolation, such as extranet and intranet environments, are provided
Access: Internal and external users can access applications by using two identity management infrastructures.
Data synchronization: Application-required data is synchronized between the two identity management infrastructures.
Availability: A separate identity management infrastructure is available for internal and external users.
For many large enterprises, it may be necessary to have administrative autonomy for applications within independent departmental units. This type of deployment provides administrative autonomy for applications managed independently within departmental networks and organizational units.
In this type of deployment, fan-out replicas serve as a local infrastructure for autonomously managed applications. The fan-out replica is a replicated Oracle Internet Directory that is configured with one-way replication from the central replica but is configured to be editable for local applications to be deployed, provisioned, and managed directly against the local infrastructure. Any resulting local information will not be replicated back to the central replicas.
Example A: Central single sign-on and departmental autonomy for applications
This example provides a central single sign-on and user password management service across the enterprise while providing departmental autonomy for maintaining the application data, as shown in Figure 3-5. A centralized single sign-on is used for user authentication, so applications can link to different Oracle Internet Directory instances depending upon whether they use the central Oracle Internet Directory or a departmental Oracle Internet Directory.
Applications, such as OracleAS Portal, are installed to use a separate departmental Oracle Internet Directory server, but they use a central identity management service for authentication. Local administrators manage the departmental applications.
This type of deployment implements the following:
Administrative autonomy for applications within the department
Centralized identity management infrastructure
Unified login and logout across all applications
Example B: Departmental identity management system
This example provides a separate authentication service for each department while still using a central identity management service for enterprise applications, as shown in Figure 3-6.
Applications, such as OracleAS Portal, are installed to use a separate departmental Oracle Internet Directory and OracleAS Single Sign-On service. Local administrators manage the departmental applications.
In this model, the user gets the unified login and logout experience for applications within each department, only. This model is useful as a failover plan if the central service suffers a catastrophic outage. Fan-out Oracle Internet Directory replication is used to replicate the enterprise user and password policy information from the central Oracle Internet Directory to the departmental Oracle Internet Directory.
This type of deployment implements the following:
Administrative autonomy for applications within the department
A separate identity management infrastructure for departmental autonomy
Continuous availability of departmental applications regardless of any failures in the central identity management infrastructure
This deployment describes enterprise application integration between the Oracle Identity Management system and an existing enterprise application, such as Oracle Human Resources, and third-party LDAP servers, such as Microsoft Active Directory.
Example A: Integrating with enterprise provisioning
In this example, user provisioning is initially triggered by the enterprise application. Using Oracle Directory Synchronization Service, the user identity is created in Oracle Internet Directory and Active Directory, as shown in Figure 3-7.
Once the user identity is created in Oracle Internet Directory, OracleAS Single Sign-On authenticates users, and applications that are Oracle Internet Directory-enabled will have access to the user data. Similarly, Windows applications will have access to the user data created in Active Directory.
This type of deployment implements the following:
Identity management system integration with an enterprise user provisioning system, where user provisioning is triggered by the enterprise application and user profile data is synchronized from the application to Oracle Internet Directory
Integration with a third-party directory (in this example, Active Directory synchronization)
As the user accounts are synchronized in both Oracle Internet Directory and Active Directory, users will have access to applications enabled for both Oracle Internet Directory and Active Directory
Example B: Integrating with Windows user provisioning
If an enterprise has deployed Active Directory as a corporate directory for managing user and network resources, the Oracle Identity Management infrastructure can be integrated with an existing Active Directory, as shown in Figure 3-8.
In this example, user provisioning is initially done in the Windows environment. Windows administrators can use Windows tools to provision user accounts in the system. Synchronizing newly-created user account data in Active Directory with Oracle Internet Directory occurs using Oracle Directory Synchronization Service. Active Directory domain user data is synchronized in a default realm of Oracle Internet Directory. If there are multiple Active Directory domains in an enterprise deployment, they are configured for enterprise use of Oracle Internet Directory for Oracle Application Server by using multiple subtrees in one realm.
Once the user account is synchronized with Oracle Internet Directory, enterprise applications can access user profiles, and users can log in to the applications through a central OracleAS Single Sign-On.
Also, OracleAS Single Sign-On supports Windows native authentication using the Windows Kerberos-based protocol. This feature enables users who have been issued a valid Kerberos ticket in the Windows environment to log in to their Web applications without having to provide a username and password. With this support, a Windows user can automatically log in to a portal application after the user successfully logs in to a Kerberos-enabled Windows desktop. In cases where Windows Kerberos authentication is not possible, Oracle Internet Directory external authentication plug-in authenticates users to Active Directory.
This type of deployment implements the following:
Seamless integration of the Oracle Identity Management system with an existing Windows system
Integration with a third-party directory
Integration with Windows Kerberos authentication for single sign-on with partner applications
Seamless access for Windows users to the Oracle Identity Management infrastructure-enabled enterprise applications
In ASP deployments, different identity management realms must be created for the different namespaces of user populations. ASP administrators manage applications hosted for their customers, or subscribers, or both. Each subscriber has an associated identity management realm where the ASP manages its users, groups, and associated policies. Note that this deployment uses only one identity management infrastructure for all ASP identity management services by using a separate realm for each ASP subscriber.
Apart from using multiple realms in Oracle Internet Directory, the multiple realm feature should be enabled in OracleAS Single Sign-On and applications such as OracleAS Portal and Oracle Collaboration Suite.
Figure 3-9 illustrates a hosted deployment with two companies, Acme and XY Corporation.
As shown in Figure 3-9, the ASP users, defined in the default identity management realm, manage various applications hosted for the subscribers. Each subscriber has an associated identity management realm where the ASP manages its users, groups, and associated policies.
Once the logical architecture of the Oracle Identity Management deployment has been decided, the next step is deciding the additional details of the deployment. These include the specifics of the directory information model and details of the physical topologies.
This section describes the details of planning the directory information tree (DIT) and lists a number of different physical topologies that meet high availability and performance requirements.
At the end of detailed deployment planning, you should have selected the DIT and physical topology that best meets your requirements. The finalized physical network topology can include a combination of one or more physical topologies listed in this section.
After you have selected the physical topologies, refer to the Oracle Identity Management installation documentation and component-specific administrator's guides for installation and advanced configuration information.
Deployment planning is an iterative process that should be flexible enough to meet the changing needs of an enterprise. In addition to the actual implementation, identity management deployments should establish well-defined processes to monitor the health and performance of the identity management infrastructure and to take corrective actions when necessary.
This section contains the following topics:
Directory information is organized in a directory information tree (DIT). This section describes the details of defining the DIT. Deployment planners should review their objectives and identify the configuration that best meets their needs and use that configuration as a deployment planning guide.
This section contains the following topics:
Because the directory can potentially be used by several applications, both Oracle and third-party, the naming attributes used in the relative distinguished names constituting the overall DIT structure should be restricted to well-known attributes. The following attributes are generally well-known among most directory enabled applications:
c: Name of a country
cn: Common name
dc: Component of a DNS domain name
l: Name of a locality, such as a city, county, or other geographic region
o: Name of an organization
ou: Name of an organizational unit
st: Name of a state or province
Figure 3-10 illustrates a DIT for a hypothetical company called Acme, which makes the following decisions with respect to the logical organization of the directory information in its U.S. deployment:
A domain name-based scheme is used to represent the overall DIT hierarchy. Because the identity management infrastructure is being deployed in the U.S., the DIT chosen to represent all information is dc=us,dc=acme,dc=com.
All users are represented in a container called cn=users. Within this container, all users are represented at the same level. (There is no organization-based hierarchy.) In addition, the uid attribute is chosen as the unique identifier for all users.
All enterprise groups are represented in a container called cn=groups. Within this container, all enterprise groups are represented at the same level, and the naming attribute for all group entries is cn.
The container dc=us is chosen as the root of the identity management realm, which is named US. The deployment expects to enforce similar security policies for all users in the US realm.
Because Oracle Internet Directory is a shared repository for the entire identity management infrastructure, a well-planned DIT benefits the enterprise in the following ways:
It enables the Oracle Identity Management infrastructure to enforce security policies that are aligned with the deployment requirements.
It helps implement a more efficient physical deployment of the directory service.
In cases where the enterprise has already invested in a directory service, it enables the enterprise to quickly set up synchronization with Oracle Internet Directory.
For more information about LDAP attributes, see Oracle Internet Directory Administrator's Guide.
The objective of this task is to design the basic DIT hierarchy that all identity management-integrated applications in the enterprise will use, so that:
The directory organization facilitates effective access control. If you are planning to implement either full or partial replication, proper boundaries and policies for directory replication can only be enforced if the DIT design reflects the separation.
If the enterprise will be integrated with a third-party directory server, try to align the DIT design of Oracle Internet Directory with the existing DIT to simplify the necessary synchronization process. This consideration is also beneficial to current deployments of Oracle Internet Directory, where future plans of deploying other directories, such as Active Directory, are required for the operation of software from other vendors. In this case, choosing a DIT design for Oracle Internet Directory that is consistent with the preferred DIT design of the planned deployment of a third-party directory will make the synchronization tasks more manageable.
In a single enterprise scenario, choosing a DIT design that aligns with the domain name of the enterprise is sufficient. For example, if Oracle Internet Directory is being set up in a company that owns the domain name acme.com, a directory structure such as dc=acme,dc=com is recommended. Use of departmental or organization level domain components, such as engineering in engineering.acme.com, is not recommended. Most corporations undergo frequent divisional restructuring and reorganization. It is important to insulate the corporate directory from organizational changes as much as possible.
If an enterprise has deployed an X.500 directory service and has no other third-party LDAP directories in production, the enterprise may benefit by choosing a country-based DIT design. For example, a DIT design with the root of o=acme,c=US might be more suitable for an enterprise that already has X.500 directory service.
Most of the design considerations that are applicable to the overall DIT design are also applicable to the naming and containment of users and groups. However, there are additional considerations you must be aware of when configuring users and groups in Oracle Internet Directory.
Considerations for User Identities
Oracle Identity Management infrastructure uses Oracle Internet Directory as the repository for all user identities. Even though a user might have account access to multiple applications in the enterprise, there is only one entry in Oracle Internet Directory representing a particular user's identity. The location and contents of these entries in the overall DIT must be planned by the enterprise before deploying Oracle Internet Directory and other infrastructure components.
Consider the following when planning user identities:
Similar to planning the overall directory structure, avoid organizing users based on current departmental affiliations and hierarchy. Instead, record a user's organizational information as an attribute of the user's directory entry.
There are no performance benefits to organizing the users in a hierarchy based on the organizational affiliations or management chain, and you should therefore keep the DIT containing users as flat as possible.
If the deployment has different user populations, each maintained and managed by different organizations, dividing the users into containers based on these administrative boundaries is recommended to simplify the setting of access controls and also helps in cases where replication is needed
The default attribute for uniquely identifying users is cn or CommonName. The typical value of CommonName is the person's full name. People's names, however, can change and might not be unique. If possible choose an alternative attribute that will not change and that uniquely identifies a user, such as the uid attribute.
Typically, most enterprises have a human resources department that establishes rules for assigning unique names and numbers for employees. When choosing a unique naming component for directory entries, you should take advantage of this administrative infrastructure and use its policies.
All user entries created in the directory should belong to the object class inetOrgPerson and orclUserV2.
If the enterprise is using a third-party directory, or is planning to deploy one in the future, align the user naming and directory containment with the one commonly used in the third-party directory to simplify the synchronization and subsequent administration of the distributed directories
Considerations for Group Identities
Some applications that are integrated with the Oracle Identity Management infrastructure can also base their authorizations on enterprise-wide groups created by the deployment in Oracle Internet Directory. As with user identities, the location and content of the group identities should be carefully planned.
Considerations for planning group identities are as follows:
There are no performance benefits to organizing the enterprise groups in a hierarchy based on the organizational affiliations or ownership. Keep the DIT containing groups as flat as possible to facilitate easy discovery of groups by all applications and to foster sharing of these groups across applications.
Separate users and groups in the DIT so that different management policies can be applied to each set of entries.
The attribute used to uniquely identify a group should be cn or CommonName.
Oracle recommends that all group entries in the directory belong to the following object classes: groupOfUniqueNames and orclGroup. The former object class is an internet standard for representing groups. The latter can be used to take advantage of the self-service console to manage groups.
Instead of creating new directory access controls for each enterprise-wide group, consider using the owner attribute of the group to list which user or users owns this group and then create an access control policy at a higher level that grants all users listed in the owner attribute special privileges, such as modify and delete.
Consider populating the description attribute with text descriptions to make it easy for users to understand the purpose of the group.
Consider populating the displayName attribute from the orclGroup object class so that Oracle Delegated Administration Services units and the self-service console can display a more readable name for the group.
If the deployment has different sets of groups, each maintained and managed by different organizations with different administrative policies, dividing the groups into containers based on these administrative boundaries is recommended to simplify the setting of access controls, and to help in cases where replication is needed.
If the enterprise is using a third-party directory, or planning to deploy one in the future, align the group naming and directory containment with the one commonly used by the third-party directory to simplify the synchronization and subsequent administration of the distributed directories
The preceding sections described guidelines for structuring the overall DIT and the placement of users and groups. Because the implementation of these guidelines can lead to a variety of deployment configurations, you should capture the deployment intent in metadata in the directory itself. This metadata enables Oracle software, and other third-party software that relies on the Oracle Identity Management infrastructure, to understand the deployment intent and successfully function in customized environments.
The identity management realm in Oracle Internet Directory captures this deployment intent and also enables the deployment to set identity management policies relevant to the enterprise users and groups.
After you have selected the overall DIT and the placement of users and groups, identify the directory entry that will serve as the root of the identity management realm in Oracle Internet Directory. This entry helps determine the scope of the identity management policies defined in the identity management realm (by default, the scope is the entire directory subtree under the root of the identity management realm). Under this entry, a special entry called OracleContext is created which contains the following:
The deployment specific DIT design (including user and group naming and placement)
The identity management policies associated with this realm
Additional realm-specific information private to Oracle applications
Figure 3-11 illustrates a deployment for the Acme company that uses a domain name-based DIT structure.
In this case, the container dc=us,dc=acme,dc=com is the directory entry chosen as the root of the identity management realm. The cn=OracleContext container holds the realm-specific policies, including the user and group naming and containment policies.
A new identity management realm is created whose root is dc=us. The scope of the identity management realm, by default, is restricted to the entire directory subtree under the root, and its name is us.
Consider the following when planning for the identity management realm in Oracle Internet Directory:
The security needs of the enterprise dictate the choice of the identity management realm root. Typically, most enterprises require only one identity management realm in Oracle Internet Directory.
If an enterprise is using a third-party directory, or planning to deploy one in the future, align the choice of the identity management realm root with the DIT design of the third-party directory to simplify the synchronization and subsequent administration of the distributed directories.
Use Oracle Internet Directory administrative interfaces to set up and administer an identity management realm in Oracle Internet Directory, including Oracle Internet Directory Configuration Assistant, Oracle Internet Directory Self-Service Console, and other command-line tools.
Once the identity management realm is set up, plan on updating the directory naming and containment policies to reflect the customizations made by the deployment. This update must happen prior to installing and using other Oracle applications that use the Oracle Identity Management infrastructure.
|
See Also:
|
Physical topology choices for the identity management infrastructure are influenced by many requirements; the most common of which are high availability and scalability.
High availability describes the ability of a system to continue processing and functioning for a very high percentage of time. High availability can be implemented by reducing any single points-of-failure and using redundant components. Similarly, coupling multiple identity management component instances with a load balancer can provide a highly available environment.
This section describes several physical topologies you could use for high availability and scalability, and highlights the benefits of each deployment example. You should review your objectives and identify the configuration that most closely matches your enterprise's requirements.
This section contains the following topics:
Identity Management Infrastructure Deployment in a DMZ Network
Identity Management Infrastructure Deployment Using Multiple Middle Tiers
Identity Management Infrastructure Deployment Using Cold Failover Cluster Solution
Application Deployments in Replicated Directory Environments
Geographically Distributed Identity Management Infrastructure Deployment
Disaster Recovery Deployment for Identity Management Infrastructure
Oracle Application Server Certificate Authority Recommended Deployment
In a default installation of the Oracle Application Server infrastructure, you install all infrastructure components on the same system, including OracleAS Single Sign-On, Oracle Application Server Certificate Authority, and Oracle Delegated Administration Services, as shown in Figure 3-12.
This deployment is simple and automatically configures OracleAS Single Sign-On, Oracle Application Server Certificate Authority, and Oracle Delegated Administration Services as part of the repository and Oracle Internet Directory. This deployment is adequate for setting up a quick development or testing environment.
In production deployments, security policies might specify that the entire OracleAS Single Sign-On server not be exposed to the public network. One way to do this is to deploy the Oracle Application Server infrastructure middle tier in the DMZ, and Oracle Internet Directory and its underlying metadata repository within the intranet firewall, as shown in Figure 3-13.
Because Oracle Delegated Administration Services and Oracle Application Server Certificate Authority are middle tier components, the considerations are the same as they are for the OracleAS Single Sign-On middle tier.
This deployment isolates between the infrastructure middle tier from Oracle Internet Directory and its underlying metadata repository.
You must provide network level encryption between the Oracle Application Server Certificate Authority middle tier and the Oracle Application Server Certificate Authority repository to ensure security isolation between the Oracle Application Server Certificate Authority middle tier and repository.
Figure 3-13 OracleAS Single Sign-On, Oracle Delegated Administration Services Deployment, and Oracle Application Server Certificate Authority in a DMZ
The high-level deployment topology in Figure 3-14 shows an Oracle Application Server installation that allows Oracle Internet Directory and its underlying metadata repository to be available in the intranet zone while Web-enabled components are placed in the DMZ. Internet Web traffic is routed to the HTTP load balancer that routes traffic to the Web-enabled components. This deployment configuration provides enhanced security because Oracle Internet Directory and its metadata repository are separated from Internet traffic by firewalls.
If you require a highly available deployment, you can deploy multiple OracleAS Single Sign-On and Oracle Delegated Administration Services middle tiers to handle the load and support the failover process. Even though multiple OracleAS Single Sign-On middle tiers are deployed, they use the same Oracle Internet Directory server. This deployment, shown in Figure 3-15, provides increased scalability by adding more infrastructure middle tiers.
Cold failover deployment is an intrasite, high availability solution that provides protection from local hardware and software failures.
In this deployment, you use a two node hardware-based cluster to achieve high availability. As shown in Figure 3-16, the two nodes are attached to a shared storage disk. You only need to install one Oracle Identity Management infrastructure, as long as it is on a shared storage disk that can be accessed by both physical nodes. A virtual logical IP address is active on Node 1, so Node 1 is the primary (active) node and Node 2 is the secondary node.
If Node 1 fails, the logical IP address is moved to Node 2. All the infrastructure processes are then started on Node 2. The application processes accessing the identity management infrastructure will experience a temporary loss of service as the logical IP address and the shared storage are moved over, and the metadata repository, its database listener, and all other processes are started.
The cold failover solution provides high availability with some loss of service during the failover.
You could deploy replication-enabled Oracle Identity Management in different configurations, depending on your deployment requirements. For example, deploying two or more multimaster replication nodes in different locations provides distributed identity management. Deploying the same configuration in a single location could provide rolling upgrade support.
For highly available deployment requirements, multiple OracleAS Single Sign-On middle tiers can be deployed to bear the load and support failover access. Oracle Internet Directory servers can be set up as replicas to provide the highly available Oracle Internet Directory server for middle tier access, as shown in Figure 3-17.
This deployment should be planned before installing the Oracle Application Server infrastructure. The planning includes providing the URLs for the OracleAS Single Sign-On and Oracle Internet Directory servers and setting up the load balancer for both the infrastructure middle tier and Oracle Internet Directory.
The load balancer for Oracle Internet Directory should be configured with persistent routing and to use failover. The load balancer should not be configured to load balance requests.
This deployment provides high availability and failover for both the Oracle Internet Directory server and the OracleAS Single Sign-On middle tier.
Oracle Internet Directory multimaster replication provides the following benefits:
No single point-of-failure: Multiple identical replicas prevent the directory service from becoming a single point-of-failure for applications on the network.
Transparent failover: Achieved by placing load balancers or routing elements in front of the network of replicas. These elements are configured so that if an Oracle Internet Directory node becomes unavailable, the applications transparently fail over to other nodes in the network.
Load balance: Achieved by using load balancers to distribute application and user access requests among Oracle Internet Directory nodes in the replication network so that no one node is overloaded, leading to performance degradation.
Rolling upgrade support: In an enterprise organization, critical business applications require an identity management system to provide service without interruption. However, you might need to make a system unavailable for some time to perform maintenance work, such as patching or upgrading. You can solve this problem by deploying multimaster replication in Oracle Identity Management. This configuration enables you to take replica Node B out of the replication group for maintenance while other nodes handle business application requests. After your maintenance work is completed, you put Node B back online to handle application requests. Node B then retrieves changes from Node A that occurred while Node B was offline. Other nodes can be upgraded or patched by repeating this procedure.
In Figure 3-18, Oracle Identity Management Node A provides service to OracleAS Portal and Oracle Collaboration Suite applications while Node B is offline for maintenance. When the maintenance process is complete for Node B, Node A can be taken offline for maintenance while applications work with upgraded Node B.
|
See Also: High-level instructions for deploying Oracle Identity Management with multimaster replication, in Oracle Application Server High Availability Guide. |
Oracle Identity Management supports fan-out replication. In this configuration, changes to the master replica are propagated to the fan-out replica. Changes to the fan-out replica, however, are local, and do not propagate back to the master replica. Propagation from the master to the fan-out replica can include either the entire DIT or a subset of the DIT. The latter is known as a partial replica.
In Figure 3-19, Identity Management Node B is a fan-out replica of Node A. Data from Node A is replicated one way to the fan-out node, Node B. The identity management system on Node A provides service to the ERP application. Fan-out Node B is provides service to Oracle Portal.
Fan-out replication in Oracle Identity Management addresses the following business requirements in an enterprise organization:
Security isolation: An enterprise application, such as Oracle Portal, is required to be available to both internal and external users. As a result, enterprise applications must maintain profile and privilege information for both employee (internal) and other (external) identities. While this integration is optimal, it is also important to ensure corporate intranet resources are completely isolated from external users and intranet applications are protected from denial of service attacks aimed at the extranet portal. This can be achieved by setting up the master management node that delivers security information for the internal users and a fan-out identity management replica that is responsible for external users. At the same time internal users can also access the portal deployed using the fan-out replica.
Management and administrative isolation: This example provides a central single sign-on and user password management service across the enterprise while providing the departmental autonomy for maintaining the application data. A centralized single sign-on is used for user authentication, while applications can link to different Oracle Internet Directory instances depending upon whether they use the central Oracle Internet Directory or a departmental Oracle Internet Directory.
Applications, such as OracleAS Portal, are installed to use a separate departmental Oracle Internet Directory server, but they use a central identity management service for authentication. Local administrators manage the departmental applications.
This type of deployment implements the following:
Administrative autonomy for applications within the department
Centralized identity management infrastructure
Unified login and logout across all applications
Performance isolation: In an enterprise organization, directory enabled applications needs to access enterprise directory data. While it is necessary for all applications to access directory data, some overloaded applications may put an unexpected heavy load in the directory. This may lead to a service outage for all applications due to directory service unavailability. To address this problem, fan-out replica could be deployed and applications can be configured to access a particular directory instance to isolate the directory service load.
Application maintenance and upgrade isolation: Departmental administrators in an enterprise organization can install Oracle applications such as OracleAS Portal using the departmental fan-out replica node to address local departmental need. While these departmental applications can use enterprise users security information, they can administer these applications and corresponding directory data independently. In addition, departmental administrator can upgrade applications associated with the fan-out directory node independently.
Fan-out replicas can be further customized to support sophisticated deployment requirements of an enterprise such as:
Replicate a subset of data from the master.
Configure plug-ins at the fan-out replica to propagate some data modification back to the master.
For example, an enterprise might want to allow password modification at fan-out but then have them synchronize back to the master replica.
|
See Also: High-level instructions for deploying Oracle Identity Management with fanout replication, in Appendix A. |
Directory replication is an asynchronous mechanism, so the directory nodes in the network are loosely consistent. The directory replication mechanism guarantees that when changes are made on any node in the network, all other nodes will eventually converge and become consistent within an acceptable time interval. This, however, does not guarantee that all nodes will be identical at all times.
As a consequence of the loose coupling among replicas, different applications connected to different physical directory servers in the replication network can encounter temporary inconsistencies among their directory views. Such temporary inconsistencies do not adversely impact the application users and are generally acceptable. But, there are scenarios in which this could impact users. For example, upon password reset, if the resulting changes are not reflected immediately in the directory server to which OracleAS Single Sign-On is connected, it is bound to confuse or inconvenience the user.
In addition to the temporary inconsistency due to asynchronous replication, conflicting changes can occur in a multimaster network where different changes are made simultaneously to the same piece of information on different directory nodes. When that happens, Oracle Internet Directory replication is capable of bringing convergence among the various nodes using a process of reconciliation called conflict resolution.
To avoid these problems, it is important to adhere to appropriate best practices when deploying applications to use a replicated directory network. Following are guidelines that an administrator should consider while deploying directory-enabled applications in a replicated directory environment:
Primary replicas should be designated for each major category of directory data in the enterprise.
Typical categories for primary replicas are user entries and common user attributes; user passwords and other authentication credentials; user groups and distribution lists; user profiles, preferences, and roles associated with key application suites.
Designating a primary replica does not mean a single-master environment. There are actually many master nodes, but different ones designated for provisioning different categories of directory data. Upon directory or network failure, provisioning applications, like any other applications, can temporarily fail over to alternate masters.
This deployment practice combines the flexibility of a multimaster network with the tighter data consistency of single master configurations.
Data recovery for any given category of data becomes more manageable because it does not involve reconciliation among multiple masters.
Services sensitive to changes to specific attributes, such as authentication services on passwords, can rely on the associated primary replica for the most up-to-date values.
Middle tier and back-end server components of applications should be deployed to use specific directory server instances in the replication network.
Uniform load balancing and distribution is not acceptable and not recommended for application middle tier and back-end components. For example, if consecutive logon operations of an OracleAS Single Sign-On server were routed to different Oracle Internet Directory servers, authentication policies such as logon retry limit could not be enforced effectively.
Uniform load distribution is acceptable only for operations that are not critical, such as address book lookups.
Middle tier and back-end server components of related applications should be deployed to share directory server instances. Different groups of applications can share different directory instances.
This practice ensures that related applications are not affected by the temporary inconsistency between the different directory servers upon which they rely. For example, OracleAS Single Sign-On and the Helpdesk application used for resetting a password should share the same Oracle Internet Directory instance. Otherwise, users could reset the password and find that they are unable to sign on because the OracleAS Single Sign-On server is connected to a different Oracle Internet Directory server from where the password changes were made.
Any bulk provisioning of data in a directory should be performed only when the directory network and all the nodes in the directory network are in a healthy state.
When there is an outage in any part of the directory network or when there is an excessive backlog of changes waiting to be replicated or reconciled, continuing with any bulk provisioning would further aggravate the problems and might lead to more pervasive loss of data and service.
Replication environment health monitoring and diagnosis must be performed on a regular basis. Oracle Internet Directory includes tools that support these operations.
Considering the previous guidelines, Figure 3-20 shows an example of enterprise applications configured in a replicated directory environment. In this deployment, OracleAS Single Sign-On and other password modification services, such as Oracle Delegated Administration Services, are configured to use Replica B as the primary Oracle Internet Directory server and Replica A as the temporary failover server. Similarly, e-mail and other high-traffic applications are configured to use Replica C as the primary server and Replica A as the failover server.
Enterprises with geographically distributed operational branches want to set up multiple OracleAS Single Sign-On instances distributed across the different geographic locations to authenticate users locally. This deployment, shown in Figure 3-21, reduces the network round trips for authentication and provides faster access to applications. OracleAS Single Sign-On server data is replicated globally across all geographic branches, which enables an employee who travels to any remote business location to be authenticated locally.
For enterprises with applications deployed in multiple geographic locations, it is important to physically distribute the Oracle Internet Directory replicas in at least two regions. Such a configuration prevents regional availability problems (due to network failures or natural disasters) from turning into global service outages for dependent applications.
Even though Oracle Internet Directory and the metadata repository are set up in replication, each OracleAS Single Sign-On site uses its own Oracle Internet Directory and metadata repository located at the local site.
If replicated OracleAS Single Sign-On sites are distributed over a wide area network (WAN), local DNS servers should be configured to route user requests to the closest geographic site.
In case a database failure is detected at one site, Oracle Internet Directory and OracleAS Single Sign-On servers are reconfigured to point to a metadata repository at another site. In case an OracleAS Single Sign-On middle tier failure is detected, the network is reconfigured to route traffic to a remote middle tier.
Figure 3-22 provides another example of a geographically distributed deployment. Identity management Node A and Node B are located in different places. Applications such as OracleAS Portal and ERP applications located near Node A are using services provided by the local identity management system. Similarly, applications located near Node B are using services provided by the local identity management system. The nodes replicate Oracle Internet Directory andOracle Application Server Single Sign-On data.
Disaster recovery refers to how a system recovers from catastrophic site failures. Examples of catastrophic failures include earthquakes, tornadoes, floods, and fire. In simple terms, disaster recovery involves replicating an entire site, including the metadata repository and configuration files, in addition to replacing hardware or subcomponents. The most stringent requirement is to keep the services running despite a disaster. This deployment also protects the identity management infrastructure from site failures or media failures, which result in damage to, or loss of, data.
Identical software, such as a single instance of the identity management infrastructure, can be run in multiple data centers with Oracle Application Server Guard to protect against data center disaster. Oracle Application Server Guard also provides single-instance directory data recovery and transparent failover.
As shown in Figure 3-23, Oracle Application Server Guard is configured to maintain a physical standby identity management infrastructure that is synchronized with the primary Oracle Identity Management infrastructure. Oracle Internet Directory and other Oracle Internet Directory components are started on the primary identity management infrastructure metadata repository node.
During disaster recovery, the standby becomes the primary node, the virtual host name is moved to the standby, and the identity management processes are then started on the standby node.
In production deployments, Oracle recommends deploying Oracle Application Server Certificate Authority on a separate system with its own repository. Other components of the Oracle Identity Management infrastructure can use any of the configurations described in this chapter.
The Oracle Application Server Certificate Authority system should be secured with all known mechanisms, in addition to the following guidelines:
Physical access to the Oracle Application Server Certificate Authority system should be strictly controlled.
The operating system should be hardened and user accounts on the system should be limited.
The metadata repository for Oracle Application Server Certificate Authority should be secured with database securing guidelines.
Oracle Application Server should be secured.
Turn on metadata repository database auditing.
Follow other guidelines to improve the security of the system, such as physical security and network security.
|
See Also:
|
