|
Oracle® Identity Management Concepts and Deployment Planning Guide
10g (9.0.4) for Windows or UNIX Part No. B10660-01 |
|
|
|
|
Oracle® Identity Management Concepts and Deployment Planning Guide
10g (9.0.4) for Windows or UNIX Part No. B10660-01 |
|
|
|
|
This chapter describes the planning methodology 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 you should 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 that must be analyzed when planning an Oracle Identity Management deployment. The requirements include process issues, functionality requirements, and high availability concerns. At the end of this analysis phase, you will decide on a high level logical deployment plan for the Oracle Identity Management infrastructure.
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 a small Oracle deployment, 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 the sharing of services across a variety of Oracle and third-party applications, and typically create a central group, comprised of application, network, and security administrators, to be 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.
Oracle Internet Directory and OracleAS Single Sign-On provides basic identity management services and Oracle Delegated Administration Services is the primary means for user password self-service. Given these considerations, plan on implementing Oracle Internet Directory, OracleAS Single Sign-On, and Oracle Delegated Administration Services
If you are integrating with other third-party directories, deploy Oracle Directory Integration and Provisioning. The directory integration platform is configured with specific directory synchronization profiles that enable synchronization with supported third-party directories.
Even if you are not using third-party directories, you should still consider deploying Oracle Directory Integration and Provisioning services because many Oracle products, such as OracleAS Portal and Oracle Collaboration Suite, leverage 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 leverage 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 smaller Oracle installation and pre-production environments, application administrators can install minimal instances of the Oracle Identity Management infrastructure to support their Oracle applications.
|
See Also: Oracle Application Server 10g Administrator's Guide for guidelines of such installations |
Finally, many organizations already have in place, or have plans to deploy, other identity management components. Oracle Identity Management is designed to leverage other enterprise identity management solutions as well as any applications you already have for provisioning and administering your enterprise environments.
Any Oracle components requiring identity management are supported by an Oracle Identity Management instance, which 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. An enterprise 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. The location and contents of the user entries in the overall directory information tree (DIT) must be planned prior to deploying Oracle Internet Directory and other identity management infrastructure components.
In application service provider (ASP) deployments where centralized identity management is required, different identity management realms must be created for the ASP administrators, as well as the users of each of the ASP customers (subscribers).
With the growth of e-business and enterprise applications, IT organizations need to consider how to reuse user profile information. Also, they have to provide access to a growing number of users, both inside and outside the corporation, without diminishing security or exposing sensitive information. The administration of multiple versions of user identities across multiple applications makes the task even more daunting. A central identity management infrastructure should therefore be considered 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 enterprise application deployment requirements:
Type of users that the application serves: It may be necessary for enterprise applications, such as OracleAS Portal, to be internet accessible for external (internet) users, such as business partners, in addition to internal (intranet) users. As a result, consider whether to use one Oracle Internet Directory to represent the user identities, or a separate Oracle Internet Directory to represent each group of user identities.
Application load requirements: Application load and availability requirements indicate the high availability deployment requirements of the identity management infrastructure
ASP requirements: Apart from the identity management deployment, consider the application-mandated requirements for ASP deployments
Departmental autonomy for deployment of new applications: For many large enterprises, it may be necessary to facilitate 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: An important consideration in identity management planning is the security policies for all the employees of a given business. It should be possible to manage the identity of the users according to common privileges defined by the security policies of the enterprise. Consider the administration models for managing the identity, roles, policies, and groups to suit the enterprise requirements.
Administrative autonomy for individual applications deployed against the identity management infrastructure: In a business, the administrator of enterprise user management might be different from that of the e-mail service; the administrator of financials may 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. Also, one must define which users need access to which resources and at what level of security. To meet the needs of these various administrators, and to satisfy the different security requirements, consider the administrative controls requirements.
There may be enterprise applications deployed, such as OracleAS Portal, that are required to be accessible by both employees and non-employees. Even though the application is shared by both internal and external users, it is important to ensure that corporate intranet resources are completely isolated from non-employees, and that intranet applications are protected from potential denial of service attacks aimed at the extranet portal. In such deployments, security separation may be necessary between the enterprise and non-enterprise identity management infrastructures.
Due to organizational constraints and high-level executive mandates, it may be necessary to consider deploying separate identity management infrastructures for different environments in order to maintain a clear demarcation 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.Foot 1
Consider the following integration functions if an enterprise has a third-party identity management infrastructure already in place:
Windows integration: If an enterprise is using Microsoft Windows infrastructure 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 the Oracle Internet Directory, and integrating OracleAS Single Sign-On authentication.
User provisioning: User provisioning refers to the process by which new users are added to and deleted from the various enterprise systems. New user provisioning can potentially be done 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 user provisioning creates the required user account profiles in other enterprise applications.
If an enterprise has deployed enterprise applications such as HR and CRM, consider the user provisioning integration functionality 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: In deployments where it is necessary for application users to access a combination of applications integrated with Oracle Identity Management, in addition to applications integrated with a third-party directory and 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 that work together to provide the services. For the identity management infrastructure to provide all essential services, all of the required components must be available. Any high availability solution must be able to detect and recover from any software failures of any of the processes associated with the identity management components. As high availability requirements depict the deployment configurations, these requirements should be considered as part of the deployment planning.
Based upon application usage and user traffic, performance requirements must be considered. Deployment configurations must be planned so that the deployment can scale very well as applications are deployed for increased user traffic.
"Planning the Physical Network Topologies" lists canonical 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 single centralized identity management infrastructure is deployed and administered by a central group within an organization. As instances of enterprise applications are deployed, they leverage 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 across an assortment of Oracle and other enterprise applications
Administrative controls to delegate the administration of the applications
An enterprise application, such as OracleAS Portal, is required to be accessible to both internal and external users. As a result, enterprise applications must maintain profile and privilege information for both employee and non-employee identities. While this integration is optimal, it is also important to ensure corporate intranet resources are completely isolated from non-employees and intranet applications are protected from potential denial of service attacks aimed at the extranet portal.
The following two 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.
A single logical Oracle Internet Directory, as shown in Figure 3-3, is used to store internal and external user profiles and user information is modeled 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
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 demarcation between internal and external user repositories. There is added availability if internal resources are not exposed to the external traffic.
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 non-sensitive profile information is synchronized with the enterprise directory, however intranet application identities and associated metadata are not replicated. Non-employee 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. The information model should be the same in both the 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: Employees 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: Provides the security environment isolation between groups of applications that require isolation among them, such as extranet and intranet environments
Accessibility: Applications are accessible to internal and external users and are served by 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 facilitate 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 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.
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, as shown in Figure 3-5. A centralized singler 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 against a separate departmental Oracle Internet Directory server, but they use a central identity management service for authentication. Departmentally, 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 experience across all applications
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 against a separate departmental Oracle Internet Directory and OracleAS Single Sign-On service. Departmentally, local administrators manage the departmental applications.
In this model, the user gets the unified login and logout experience for applications within each department, only. However, 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.
In this example, user provisioning is initially triggered by the enterprise application. Using Oracle Directory Synchronization Service, the user account footprint 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
If an enterprise has deployed Windows 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 under a default realm in Oracle Internet Directory. If there are multiple Active Directory domains in an enterprise deployment, they are modeled 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 they successfully log in to a Kerberos-enabled Windows desktop. In cases where Windows Kerberos authentication is not possible, the 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 of the 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.
This section outlined a number of requirements and considerations that a typical enterprise deployment should consider as part of the high level planning exercise. It also described 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 serves as the basis for the detailed deployment planning that is outlined in the next section.
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 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 serves their needs and use it as a deployment planning guide.
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. Since 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 serves as 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 facilitates the implementation of 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
This section contains the following topics:
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 is integrating 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 much more manageable.
In a single enterprise scenario, choosing a DIT design that aligns with the DNS 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.
If an enterprise has deployed an X.500 directory service and has no other third-party LDAP directories in production, it 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.
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: The name of a country
dc: A component of a DNS domain name
l: The name of a locality, such as a city, county, or other geographic region
o: The name of an organization
ou: The name of an organizational unit
st: The name of a state or province
A common mistake in DIT design is to try to reflect either the corporate divisional structure or organizational structure. Usually, this is not recommended because most corporations undergo frequent divisional restructuring and reorganization. It is important to insulate the corporate directory from organizational changes as much as possible.
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 modeling users and groups in Oracle Internet Directory.
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 any particular user's identity. The location and contents of these entries in the overall DIT must be planned by the enterprise prior to 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, subdividing the users into containers based on these administrative boundaries is recommended to simplify the setting of access controls and also help in cases where replication is needed
The default attribute for uniquely identifying users is CN or CommonName. Because the typical values of CommonName are the full name of the person, guaranteeing uniqueness for these values is problematic. Instead, you should choose an alternative attribute that uniquely identifies a user, such as the uid attribute or the mail 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 exploit this administrative infrastructure and use its policies.
All user entries created in the directory should belong to the following object classes: 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
Some applications that are integrated with the Oracle Identity Management infrastructure can also base their authorizations on enterprise-wide groups that are created by the deployment in Oracle Internet Directory. Like 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 Corporation 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 leverage 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, subdividing 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 an infinite number 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 only require 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 a few 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. There are options, such as Oracle Application Server Active Failover Cluster (Active Failover Cluster), available for individual identity management infrastructures to achieve 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 the canonical physical topologies of an identity management infrastructure 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
Identity Management Infrastructure Deployment on Active Failover Cluster
Application Deployments in Replicated Directory Environments
Geographically Distributed Identity Management Infrastructure Deployment
Disaster Recovery Deployment for Identity Management Infrastructure
A default installation of the Oracle Application Server infrastructure consists of installing 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 can specify that the entire OracleAS Single Sign-On server not be exposed to the public network. In this case, the deployment is split to deploy the Oracle Application Server infrastructure middle tier in the DMZ, and Oracle Internet Directory and its underlying database within the intranet firewall, as shown in Figure 3-13.
Since 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 provides security isolation between the infrastructure middle tier and Oracle Internet Directory and its underlying database.
Network level encryption should be provided between the Oracle Application Server Certificate Authority middle tier and the Oracle Application Server Certificate Authority repository to provide security isolation between the Oracle Application Server Certificate Authority middle tier and repository.
For highly available deployment requirements, multiple OracleAS Single Sign-On and Oracle Delegated Administration Services middle tiers can be deployed 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-14, 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. Examples of such failures are a system panic or node crash.
A two node hardware-based cluster is used to achieve high availability. As shown in Figure 3-15, the two nodes are attached to shared storage and a virtual logical IP address is active on one of the physical nodes (Node 1). Hence, Node 1 is the primary or active node. Only one Oracle Identity Management infrastructure is installed on a shared storage disk that can be accessed by both the physical nodes.
If the primary node fails, the logical IP address is moved over to the secondary node. All the infrastructure processes are then started on the secondary node. The application processes accessing the identity management infrastructure will see a temporary loss of service as the logical IP and the shared storage are moved over, and the database, database listener, and all other processes are started.
The cold failover solution provides high availability with some loss of service during the failover.
Oracle Application Server supports installation of the Oracle Application Server infrastructure on Active Failover Cluster. The default Oracle Application Server infrastructure installation installs all the infrastructure components on one Active Failover Cluster node: OracleAS Single Sign-On (including Oracle Application Server Containers for J2EE and Apache), Oracle Delegated Administration Services, Oracle Internet Directory, and the database, as shown in Figure 3-16.
A load balancer for HTTP and Oracle Internet Directory is used for failover access. OracleAS Single Sign-On provides database failover using JDBC failover support. Oracle Internet Directory can be configured with two types of database failover mechanisms: connection time failover and transparent application failover.
Active Failover Cluster deployment provides the high availability and failover access for the OracleAS Single Sign-On middle tier, Oracle Internet Directory server, and database.
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 in replication to provide the highly available Oracle Internet Directory server for middle tier access, as shown in Figure 3-17.
This deployment should be planned prior to 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 (state full) 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.
Multimaster Oracle Internet Directory replication networks provide 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 front-ending the network of replicas with appropriate load balancers or routing elements that can be configured such that if any Oracle Internet Directory node becomes unavailable, the applications are transparently failed-over to alternative nodes in the network
Load balance: Achieved by employing 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
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 in real time.
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 application user experience 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 multi-master 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 against 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 be temporarily failed over to alternate masters.
This deployment practice combines the flexibility of a multi-master network with the tighter data consistency of single-master configurations.
Data recovery for any given category of data becomes more manageable since 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 non-critical operations, such as end user 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 would ensure 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 password reset should share the same Oracle Internet Directory instance. Otherwise, a user could reset the password and find that he or she is unable to sign on because the OracleAS Single Sign-On server is connected to a different Oracle Internet Directory server from where the password change was 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 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 above guidelines, Figure 3-18 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 primary 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 geographical locations to authenticate users locally. This deployment, shown in Figure 3-19, 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 geographical 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 database are set up in replication, each OracleAS Single Sign-On site uses its own Oracle Internet Directory and database 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, the Oracle Internet Directory and OracleAS Single Sign-On servers are reconfigured to point to a database 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.
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 database and configuration files, in addition to replacing hardware or subcomponents. The most stringent requirement is to keep the services running despite the 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 Data Guard to protect against data center disaster. Oracle Data Guard also provides single-instance directory data recovery and transparent failover.
As shown in Figure 3-20, Oracle Data 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 database node.
During disaster recovery, the standby is switched to become 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 Corporation recommends deploying Oracle Application Server Certificate Authority on a separate host with its own repository. Other components of the Oracle Identity Management infrastructure can use any of the configurations described elsewhere in this document.
The Oracle Application Server Certificate Authority host 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 repository for Oracle Application Server Certificate Authority should be secured with database securing guidelines
Oracle Application Server should be secured
Turn on repository database auditing
Follow other guidelines to improve the security of the system, such as physical security and network security.
This section described the details of planning the directory information tree and listed 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 always 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 wherever necessary.
|
 Copyright © 2003 Oracle Corporation All rights reserved |
|
