| Oracle® Access Manager Deployment Guide 10g (10.1.4.2.0) Part Number E10353-01 |
|
|
View PDF |
| Oracle® Access Manager Deployment Guide 10g (10.1.4.2.0) Part Number E10353-01 |
|
|
View PDF |
This book provides methods, procedures, and guidelines to help you and your team successfully deploy Oracle Access Manager. This chapter provides an overview of Oracle Access Manager deployments and includes the following topics:
For a general overview of Oracle Access Manager, see the Oracle Access Manager Introduction.
Oracle Access Manager deployment types can be described as either an Identity System only type deployment, or as a joint Identity and Access System type deployment.
The Oracle Access Manager Identity System is comprised of the following three tiers:
In general, the Oracle Access Manager Identity System is a CPU intensive system. Identity System performance increases significantly with increased CPU power.
The Oracle Access Manager Access System cannot be deployed without the Identity System. The Access System is comprised of the following three tiers:
Presentation Tier: WebGates and custom AccessGates
Application Tier: Policy Manager and Access Server
Data Tier: A backend LDAP directory
Generally speaking, the Oracle Access Manager Access System is a memory intensive system. Access System performance increases significantly with increased system memory.
Whether you choose to deploy the Identity System only, or a joint Identity and Access System, your enterprise may have more than one deployment scenarios. For more information, see "Deployment Scenarios and Environments".
Many companies provide more than one deployment, each with a specific audience and purpose. Providing multiple deployments helps minimize service disruptions. For example, your company may have one or more of the following independent deployments:
Development and Test Deployment
This deployment is where you configure and test a fully configured and operational Oracle Access Manager system. On a development or test server, a smaller amount of RAM may be required. Assuming that only a small development team is using these systems (not the whole user population), you can run the Web server on the same host computer as the Identity Server.
Staging Deployment
This deployment is used for new application rollouts, software upgrades, and performance benchmarking can be performed without affecting your production and development environments. This deployment may closely resemble the production environment. However, the staging deployment may be a scaled down image of the production deployment. If so, a smaller amount of RAM may be used.
Production Deployment
This is fully deployed system that your end users can access. Oracle recommends you use a replicated directory and the native load-balancing features of Oracle Access Manager. You may also want to configure the Oracle Access Manager Servers for failover and load balancing and have separate machines for your Web servers.
These are a few examples. Your company may include other deployment scenarios that target the needs of the QA team or integration team.
Whether you have one or several deployment scenarios, each will fall into one of two categories. For more information, see "Deployment Categories".
Oracle Access Manager deployments can be classified into two primary categories: Extranet (B2B,G2C, B2C) and Intranet (B2E, G2E) deployments. While these are, generic categories they do provide some relevant patterns about deployment demographics.
For more information, see the topics:
Extranet deployments are those where you have:
A relatively large user population (over 20 thousand users)
The user population is being served through a relatively small number of applications (less than 20)
The applications are integrated with NetPoint (Oracle Access Manager), and are typically consolidated in a portal
The most typical characteristics for extranet deployments include:
A higher complexity on the Identity System deployment relative to the Access System
A large number of workflows (self-registration, self-service, delegated administration) typically involving Identity Event plug-ins (customizations)
Sophisticated delegated administration requirements, often involving various user types (at a minimum four levels of administrative roles/access) and reliance on ACLs, groups, and other objects.
User interface customizations (accomplished using XSL stylesheets, PresentationXML, and IdentityXML) because the majority of the requirements center on identity administration of a large number of users and ease of use is a paramount driver. The majority of implementations will exhibit front end user interfaces built on top of IdentityXML.
Features such as lost password management are very commonly configured.
A relatively small software footprint (for example, only a handful of servers—2 to 4 servers at each tier—often distributed between a few data centers), and a very low tolerance for downtime because the applications that rely on Oracle Access Manager are often business critical.
Commonly the directory environment is dedicated to Oracle Access Manager and the applications it supports. Therefore, there is a bit more control over the directory service in conjunction with Oracle Access Manager from an operational perspective. There are a relatively small number of stakeholders from the application side (typically belonging to a common line of business.)
Performing the upgrade to 10g (10.1.4.0.1) with minimal service disruption in such a highly complex environment can be challenging.
Intranet deployment environments are typically:
Internal facing portals with a relatively small user population (less than 20 thousand users)
The user population is being served through a relatively large number of applications (more than 20) integrated with NetPoint (also known as Oracle Access Manager)
The most typical characteristics for intranet deployments include:
A greater prevalence of the Access System customizations, if any, are typically:
On the front-end at the login page (or login front-end)
Or using custom built AccessGates
Or on the back-end using customized authentication or authorization plug-ins developed with the APIs
A relatively large number of applications (over 20) being protected where the emphasis is primarily on authentication and single-sign on (SSO), with a significant number of application-level integrations.
A high number of BEA WebLogic and IBM WebSphere Application Server integrations using Oracle Access Manager connectors for these servers.
Often the Identity System is either not widely deployed, or deployed only to an administrator user community (for example, the help desk, IT department, or system administrators).
Password management features are not typically configured or used, because Oracle Access Manager often relies on the same back end store as the NOS (AD), and it is rare to see self-registration workflows.
These environments tend to have a broad footprint, especially at the WebGate/AccessGate tier, with a high number of Web servers and Application servers with WebGate to Access Server ratios in the range of 10:1.
On the Access Server tier, intranet deployments tend to be global and geographically distributed, with a handful of servers deployed in each location.
The directory environment is often shared, because it is the employee directory or even the NOS directory (AD). Therefore, the number of dependencies associated to the directory is high (meta-directories, provisioning solutions, NOS logon, white pages, and the like). As a result, changes and operational impact to the directory is very rigorously managed. Many stakeholders need to be coordinated with in a change-control process, and tight operational windows are allowed. On the application front, there tends to be more flexibility on server availability, and applications tend to be "clustered" by line of business, geography, or security requirements. Therefore, the impact can be segregated.
Any deployment may be installed at a single site or across multiple sites whether Identity System only or a joint Identity and Access System, whether intranet or extranet.
Oracle Access Manager supports a variety of operating systems, directory servers, Web servers, compilers, and browsers, as well as integration with a number of application servers, portal servers, system management products, and packaged applications. For the latest support information, see details under the Certify tab on:
http://metalink.oracle.com
Go to MetaLink at https://metalink.oracle.com.
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Identity Manager and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, "Oracle Access Manager Certification" to display the certification matrix.
The following topics provide:
See Also:
In any production environment, Oracle recommends that you secure all transport between Oracle Access Manager components using either Simple or Certificate Mode. All intranet and extranet communications should be encrypted.
When enabling SSL with Simple or Certificate mode, ensure that the clocks of the servers hosting the WebGates, AccessGates, and WebPass as well as those hosting the Access or Identity Servers are within 1 minute of absolute time difference. This includes ensuring that daylight savings and time zones have no more than a 1-minute difference between the clocks in GMT. Oracle recommends that you use the Network Time Protocol (NTP) for ensuring server clocks are synchronized.
If Oracle Access Manager is running in Simple mode, once a year by default both the Identity and Access Servers need to refresh the self-signed certificate that Oracle Access Manager generates to provide SSL encryption. The frequency of updates can be configured. In this case, however, be sure to:
Update the Simple certificates for a Web server running the WebPass.
Update the certificate required for Policy Manager to work in Simple mode.
Be sure the obSSOCookie is not shared between machines in the two different environments.
This would allow a user who exists in both environments to use single sign-on from the source environment. Updating the obSSOCookie is an important security precaution when migrating across environments.
Important:
Other ways of breaking SSO between different environments include changing domains, for instance, changing from dev.company.com to staging.company.com and updating the shared secret among different environments.For complete installation and setup details, see the Oracle Access Manager Installation Guide. For information about changing the transport security modes after installation, see the Oracle Access Manager Identity and Common Administration Guide.
Each component should be running on a stable and appropriately installed platform. Oracle recommends that you standardize on directory server versions and Web server versions, both within and across all deployments. Also, Oracle recommends that you document the host computers, IP addresses, transport security modes, searchbases and directory profiles in your deployment. For more information, see the Oracle Access Manager Installation Guide.
Oracle recommends that you have a dedicated machine for the LDAP directory server within each Oracle Access Manager deployment and that you standardize the layout of the file system. For more information, see "LDAP Directory and Data Recommendations".
Oracle recommends that you create a /customizations directory and document all changes to your deployment. For more information, see "Customization Recommendations".
Oracle Access Manager servers is a generic phrase that refers to the Oracle Access Manager Identity Server and Oracle Access Manager Access Server components.
To improve reliability, Oracle recommends that you install and operate Identity Servers and Access Servers on independent, dedicated hardware. This means that you need a dedicated machine for each Identity or Access Server. As an example, consider a small Oracle Access Manager deployment for up to 15,000 users. You could use four server-class computers: two installed with Identity Servers and two installed with Access Servers, with IP switching technology in front of each pair of Web servers to provide load balancing and failover.
When your deployment has light load conditions, where the primary Identity Server and Access Server have a combined utilization of 85% or less, you may conserve hardware by using a cross-over deployment. In this case, you may install a primary Identity Server and a secondary Access Server on one machine and a secondary Identity Server with a Primary Access Server installed on a different machine. Failover is configured.
Oracle recommends that you dedicate one or two internal-facing, highly-secured Web servers to host the administrative interfaces for Oracle Access Manager: Identity System Console and the Access System Console. This helps protect the authentication and authorization system in the event the application Web servers are compromised.
Oracle recommends that you install WebPass instances on a dedicated set of Web servers, especially if you expect that they will serve IdentityXML (SOAP) calls.
When you have a joint Identity and Access System deployed, Oracle recommends that you install both WebPass and WebGate against the same Web server instance This allows WebGate to provide authentication and single sign-on (SSO) to actions that go through WebPass. For example, when a user performs self-registration or an identity administrator accesses the Identity System Console.
Oracle also recommends that you standardize on Web server versions within deployments, as discussed in "Standardization Recommendations".
For capacity planning and sizing guidelines, see Chapter 2. For performance tuning recommendations, see Chapter 3.
In general, the following factors impact the overall performance of the LDAP directory server and of Oracle Access Manager itself. However, your own business requirements will drive the decisions that you make regarding the following:
DIT structure: Flat versus deep will have an impact on search operation performance
Replication: Frequency, multi-mastering, network latency
Disk size and I/O response time
Disk I/O contention for attribute operations (searching and indexing) versus LDAP access and error logging
Attribute indexing
Cache size and life span
Connection overhead: Long- lived connections are preferred, especially if LDAPS is used. Be aware that many current network routers and switches contain connection state tables (like traditional firewalls) and can sever connections between systems, which can result in substantial overhead for transactions (timeout plus connection recovery plus operation response time).
Oracle recommends that you have a dedicated machine for the LDAP directory server within each Oracle Access Manager deployment and that you standardize the layout of the file system. For example, consider locating all Oracle Access Manager-specific files in one particular directory path in each deployment. Oracle recommends that you use the same Web server and directory server versions across all deployments.
Also, consider storing Oracle Access Manager configuration and policy data in a separate directory from user and group data. This allows greater flexibility when upgrading to a later release and minimizes the impact on the user and group directory (typically a shared, enterprise directory). Separating the data is particularly beneficial for workflow-driven processes that generate a significant load on the directory. Configuring separate logical directory instances will also ensure that each directory can be tuned and managed independently improve overall performance.
Note:
If directories cannot be separated due to hardware or topology related issues, consider creating a dedicated suffix to hold the Oracle Access Manager configuration and policy data.Oracle also recommends that you standardize on directory server versions within deployments, as discussed in "Standardization Recommendations".
For more information, see "Considerations for the LDAP Directory Server". For capacity planning and sizing guidelines, see Chapter 2. For performance tuning recommendations, see Chapter 3. For specific directory server requirements, see the Oracle Access Manager Installation Guide.
Whenever possible, Oracle recommends that you use a database to record and store all Oracle Access Manager audit data. This protects the audit information and makes it easier to generate audit trails and reports.
For more information about logging and auditing, see the Oracle Access Manager Identity and Common Administration Guide.
In general, Oracle Access Manager timeout values should be configured to be the lowest of all application timeouts. Timeouts are enforced by WebGate or the Web server, and not by application. The goal is to avoid having applications time out before Oracle Access Manager times out. Otherwise session issues within the applications may arise producing potential discrepancies in behavior
There are a number of considerations in selecting timeout values. For example, applications which are able to regenerate a session from an existing Oracle Access Manager session (or header variable) can timeout earlier than Oracle Access Manager. The Identity System, in fact, is a good example of an application where having a shorter session timeouts than WebGates is recommended.
Generally speaking. however, these timeout values should be close to each other. One exception to this rule is for AccessGates, which are typically deployed downstream from a WebGate, for example supporting a BEA WebLogic implementation. In this case it is recommended that the AccessGate have a greater idle timeout than the WebGate to avoid the problem of a fresh browser session being rejected by the downstream AccessGate. For AccessGates, Oracle recommends configuring the idle and maximum timeouts to be the same.
For more information, see the chapter on configuring WebGates and Access Servers in the Oracle Access Manager Access Administration Guide.
You can tailor Oracle Access Manager for your deployment and users. For example, you can create front-end customizations using IdentityXML, PresentationXML, and the Access Manager API. You may create back-end customizations with the Identity Event API, Authentication API, Authorization API (including custom AccessGates and plug-ins).
Oracle recommends that you create a /customizations directory to ensure that any customized information resides in a directory that is outside of any Oracle Access Manager component installation directory. This is important when re-installing or upgrading Oracle Access Manager because all sub directories are deleted during these processes.
Oracle recommends that you document any changes or customizations made within any deployment. Also, develop test scripts that verify the behavior of your customizations to help ensure that these work as expected. This will help simplify the task of redeploying the customizations to a larger deployment, or upgrading to a later Oracle Access Manager release.
Task overview: Creating and testing customizations and plug-ins
Review considerations here and in "Customizing the Look and Feel of Embeddable User Interface Elements".
Install and setup Oracle Access Manager 10g (10.1.4.0.1) in a small test or development deployment (ideally a sandbox-type setting) where a dependency on the overall Oracle Access Manager deployment is minimal.
For details, see the Oracle Access Manager Installation Guide.
Develop deterministic test scripts to run both before and after creating your customizations to exercise a full end-to-end transaction and ensure that everything works as expected.
Your test scripts will depend on the specific customization being exercised. For example, your script could request a single page that requires authentication and authorization and a workflow request (all triggered by a single page request).
Compile the code or deploy the customization, and develop a set of instructions that explain how to configure the customization in a given deployment.
For details about using the Oracle Access Manager Software Developer Kit and APIs, see the Oracle Access Manager Developer Guide.
Test any customization (styles, AccessGates, or plug-ins, for example) to ensure things are working as expected.
When the test is successful, redeploy any compiled binaries and customizations in a larger deployment for further testing before migrating this information to a production environment.
Before deploying Oracle Access Manager into production, Oracle recommends that you run a thorough and extended load test and benchmark analysis. This enables you to fine tune and predict the behavior of the overall system. Based on the performance figures, you can tune performance, for example, by altering cache settings, timeout values, the number of directory connections, and increasing the number of threads on the Identity or Access Servers.
For performance tuning recommendations, see Chapter 3.
This section offers general recommendations for any Identity System deployment, including those in a joint Identity and Access System deployment:
For capacity planning details, see Chapter 2. For specific performance tuning details, see Chapter 3.
Oracle Access Manager Identity combines Extensible Style Language (XSL) stylesheets and Extensible Markup Language (XML) data to dynamically create almost all of the pages presented to its users. This capability, known as PresentationXML, provides developers with design flexibility and avoids the need for static HTML content.
PresentationXML is the recommended approach if your intent is to deal with front-end, user interface issues, for example, look and feel, layout of the tags, enhancing the navigation, and so on. It is not recommended for back-end logic, for example, pre-filling values based on data on a database, computing values based on other input values, communicating with external systems, and so on.
Oracle recommends:
Before modifying or using a stylesheet, create a new style based on the default (style0) style of Oracle Access Manager. Replicate all related graphics, stylesheets and Javascripts in the Identity Server and WebPass so that the default style remains unchanged.
For details about creating a new style, see the Oracle Access Manager Identity and Common Administration Guide. For details about customizing Identity System pages, copying styles, testing, and propagating styles throughout the deployment, see the Oracle Access Manager Customization Guide.
To expedite development and testing when developing PresentationXML, use a powerful XML or XSL editor, for example, XMLSpy. These editors provide an integrated development environment (IDE) to simplify and speed up the process of XSL programming.
For more information about testing, and propagating styles throughout the deployment, see the Oracle Access Manager Customization Guide.
Use caution when implementing Javascript code in PresentationXML
When the need arises to insert JavaScript code to a front-end page through PresentationXML, the best practice is to encapsulate all of the JavaScript code into a file, then include the file in the XSL file. At deployment time, you must deploy this file on the appropriate WebPass installation directory.
When including JavaScript code in PresentationXML, do not modify the main misc.js file in the WebPass installation directory. This file is used for client-side processing and is common to all Oracle Access Manager components. Any modification can adversely affect all components.
For more information about customizing interfaces with PresentationXML, see the Oracle Access Manager Customization Guide.
If you need to remove an Identity Server instance on one machine and reinstall it on another machine, you may re-use the original Identity Server instance name. However, this requires that you take specific steps to ensure that Oracle Access Manager recognizes the new instance and does not look for the original instance.
If you do not delete the Identity Server name from the System Console, a login following setup may result in the message "Application has not be set up". For more information about recycling an Identity Sever instance name after uninstalling the instance, see the Oracle Access Manager Installation Guide.
This section discusses the following general recommendations for any deployment that includes the Access System:
Using IP Validation, HTTPS, and Secure Cookies to Mitigate The Risk of a Cookie Reply Attack
Deploying WebGates On Reverse Proxies to Simplify Management
Developing Document Protection Policies to Minimize WebGate Calls to the Access Server
For capacity planning details, see Chapter 2. For specific performance tuning details, see Chapter 3.
Oracle recommends that you always enable IP validation to mitigate the risk of a cookie reply attack. If exceptions are required, for example, when deploying using a reverse proxy topology, ensure that only allowed IP addresses are included in the exception list. Avoid ever turning off IP validation.
To avoid the risk of cookie reply attacks, you can also deploy content securely over HTTPS. This prevents unauthorized clients from eavesdropping on the ObSSOCookie. Also, specify the parameter ssoCookie:secure for the Challenge Parameter for a Form, Basic, or External challenge method to ensure that the ObSSOCookie set during authentication is sent only through SSL. This prevents the ObSSOCookie from being sent back to a non-secure Web server. This parameter setting requires configuring all protected Web servers for SSL. An SSL Web server will not perform single sign-on with a non-SSL Web server. A browser will not return a secure cookie obtained from an SSL Web server to a non-SSL Web server in the same domain.
For more information, see the chapter on configuring user authentication in the Oracle Access Manager Access Administration Guide.
Generally, Oracle recommends using dynamic groups instead of authorization filters to specify authorization rules. Dynamic groups allow you to separate the management of the filter ("Who is a virtual member of the group?") from the management of the authorization rule. This enables you to delegate the management of the authorized role to a class of administrators that is separate from those who configure the access policies. Additionally, group management allows tracking of changes and approvals for changes, whereas authorization rule filters do not.
For more information, see the chapter on configuring user authentication in the Oracle Access Manager Access Administration Guide.
There are a number of benefits to deploying WebGates on reverse proxies. These include:
You can protect all Web content from a single logical component by directing all requests through the proxy.
This is true even for platforms that are not supported by Oracle Access Manager. If you have different types of Web servers, for example, iPlanet, Apache, and so on, on different platforms, for example, MacOS, Solaris x86, mainframe and so on, all content on these servers can be protected. A reverse proxy can be a workaround for unsupported Web servers, eliminating the need to write custom AccessGates for unsupported Web servers or for platforms where there is no AccessGate support.
You can install a WebGate on only the reverse proxy, rather than on every Web server.
This creates a single management point. You can manage the security of all of the Web servers through the reverse proxy without establishing a footprint on the other Web servers.
A reverse proxy provides architectural flexibility and can enable you to expose the same application on the intranet and the extranet without requiring any changes to the application already deployed.
The main pitfall of using a proxy is the extra work involved in setup. If you deploy the WebGate on a Web server that resides behind a reverse proxy, the following are required:
Ensure that any Web server that uses the reverse proxy for authentication only accept requests from the reverse proxies.
You must configure the WebGate deployed on this Web server to not enforce IP validation on requests coming from the reverse proxy server or servers acting as its front end. You must configure the IP addresses of the reverse proxy server or servers in the IP Validation list for the WebGate. Oracle does not recommend turning IP validation off for the WebGate because it can expose a security risk.
Update the virtual hosts that are configured in the Policy Manager so that the Access System intercepts requests that are sent to the reverse proxy.
Prevent people from circumventing the proxy by entering URLs that point directly to the back-end system. You can add Access Control List (ACL) statements in the server to prevent users from bypassing the reverse proxy and directly accessing restricted content. Or, you can configure firewall filters.
Since the proxy processes all user requests, you must deploy enough proxy servers to enable the system to handle the load.
Redirect all existing URLs to the host name and port number of the reverse proxy server.
This often requires configuring the reverse proxy to inspect content and rewrite URLs, for example, to prevent any absolute HTML links from resulting in a broken link. This is available in most reverse proxies, and it is functionality that is independent of the Access System. It is a best practice that you configure URL links exposed to the front-ended applications to contain only relative URLs (../../sub-path/resource) rather than absolute URLs (http://hostname.domain:port/path/resource) or pseudo-relative URLs (that is, /path/resource). Absolute URLs can break links on the end user's browser when deployed behind a reverse proxy.
For more information, see the chapter on configuring WebGates and Access Servers in the Oracle Access Manager Customization Guide.
When specifying policies to protect all the documents on a Web server, there are two approaches that will work:
Protecting all the documents from the root of the document tree, and specifically allowing access to specified documents
Setting the DenyOnNotProtected flag, and specifically allowing access to specified documents.
In general, the second approach provides better performance. When protecting Web documents from the root, the WebGate must always contact the Access Server for each request to check if the user is authorized to access the resource. This places additional load on the Access Server. When using the DenyOnNotProtected flag, the WebGate caches information from Access Server on whether a particular URL is protected by the Access System. As a result, it can simply deny access to subsequent requests for unprotected resources without contacting the Access Server thereby reducing server overhead.
For more information, see the chapter on configuring WebGates and Access Servers in the Oracle Access Manager Identity and Common Administration Guide.
When implementing form-based authentication with Oracle Access Manager, develop code in such a way as to avoid login errors. This includes embedding code to validate input fields in the form to avoid posting the wrong credentials. For example, you can check that user name and password fields are not blank. In addition, use HTML code that prevents content caching, for example: <meta http-equiv="pragma" content="no-cache">.
For more information, see the chapter on form-based authentication in the Oracle Access Manager Access Administration Guide.
Oracle strongly recommends that before starting any deployment task, you and your team become familiar with all topics suggested in Figure 1-1, and the overview that follows the figure.
Task overview: Planning for your deployment
Review the information in this chapter to get a high-level overview and general recommendations about deployments. For more information, see the following topics:
Review "Planning Deliverables" for details about the planning document you need to produce for each deployment.
Review Chapter 2 for the methods and strategies you will use to determine capacity and sizing requirements for each deployment, for an Oracle Access Manager Reference Server Footprint, and for a Sample Medium-to-Large-Scale Deployment.
Review Chapter 3 for performance tuning recommendations, as well as tools and methods.
Review Chapter 4 for details about configuring failover and load balancing between Oracle Access Manager servers and Web components, as well as between Oracle Access Manager servers and directories.
Review Chapter 5 for details about cloned and synchronized components and caching system configuration information.
Review Chapter 6 for details about what can be reconfigured and how to do it.
Review Chapter 7 for details about synchronizing clocks across time zones.
Review Chapter 8 for details about migrating data and upgrading to a later Oracle Access Manager release.
Planning activities include preparing a document where you define and record a detailed plan for each deployment.
Task overview: Developing your planning deliverables
Decide Deployment Details: Define a plan that identifies the following information for each deployment:
Deployment Type and Tiers: Decide and record the deployment type (Identity System only versus a joint Identity and Access System), as described in "About Oracle Access Manager Deployment Types and Tiers".
Deployment Scenario: Decide and record each deployment scenario, as described in "Deployment Scenarios and Environments".
Deployment Category: Decide if your deployment is to be an intranet versus extranet deployment, which have individual characteristics and dependencies as described in "Deployment Categories".
Deployment Size and Distribution of Components: Decide and record the number and location of installed components, whether on one site or many. For capacity planning details, see Chapter 2.
Standardization: Each component should be running on stable and appropriately installed platforms and follow:
Administrative Access: Schema and other operations require administrative access with write permissions to the directory and Oracle Access Manager files. Contact the individuals selected to be administrators for each deployment.
Customizations: Customized configurations can be created to tailor Oracle Access Manager for your environment and users, as described in "Customization Recommendations". Research the types of customizations that may be needed in your deployment.
Create a Planning Document: Record deployment decisions in a document using the details in Table 1-1 as a guide.
Table 1-1 General Deployment Details
| Deployment Details | Description |
|---|---|
|
Type |
Identity System on versus Joint Identity and Access System |
|
Scenario |
Test or QA or Staging or Production or other |
|
Category |
Intranet versus Extranet |
|
Administrators |
Oracle Access Manager Master Administrator Master Identity Administrator Master Access Administrator Directory bind credentials used by Oracle Access Manager |
|
Directory Profile |
Transport Security: Open versus SSL-enabled Master/replica configuration Failover configuration For more information, see: |
|
Oracle Access Manager Security |
Transport Security Mode: Simple, Cert, or Open |
|
Identity System |
Identity Server instances WebPass instances Failover configuration For more information, see: |
|
Access System |
Policy Manager instances Access Server instances WebGate instances Failover configuration For more information, see: |
|
3rd Party Integration Applications |
See the Oracle Access Manager Integration Guide for implementation details for supported third-party applications. |
|
Customizations |
Front-end customizations created using IdentityXML, PresentationXML, and the Access Manager API. Back-end customizations with the Identity Event API, Authentication API, Authorization API Custom AccessGates and plug-ins created using the Oracle Access Manager Software Developer Kit. For more information, see:
|
Fill in Installation Preparation Worksheets: Review and record installation details in the preparation worksheets available in the Oracle Access Manager Installation Guide.
Record Any Changes to the Deployment: Be sure to keep a record of any changes within the deployment, including:
Identity Servers (and Access Servers) configured for auditing to files or a database
Identify any Identity Event plug-ins
PresentationXML and XSL stylesheet customizations
File-based changes, for example to globalparams.xml or .lst files
Customized authentication or authorization plug-ins for the Access Server
Status of the Access Management flag
Details for each AccessGate, WebGate, and Policy Manager, such as the HTTP Cookie domain, preferred host name, cache timeout and size, failover threshold; custom IdentityXML clients; any virtual IP and DNS aliases used to reference the WebPass or Web server farm protected with WebGate
Before starting your deployment, there are several broad guidelines to follow:
Think Strategically, Act Tactically: Plan and design the solution from a strategic perspective, with a long-term view and a road map that is not necessarily tied to nor limited by tactical deadlines. Divide the plan into measurable and attainable phases, each of which contributes to the strategic goal while providing some return-on-investment (ROI) with every milestone.
Seek the Advise of Experts: During planning, requirements gathering, and design, there is tremendous value in engaging experts. Consult with individuals who have years of industry experience and who have completed projects in various vertical markets. The time and cost involved in engaging experts is offset by mitigating risks, adopting industry best practices, and defining a validated strategy for achieving success. Industry expertise is typically two fold:
Industry Expertise: Refers to knowledge of established policies, procedures, and standards; familiarity with compliance with governmental regulations and guidelines; information security best practices; security management and operations; technical infrastructure.
Technical Expertise: Refers to the best use of the technology in addressing business requirements; technical infrastructure; Oracle technology and application security; identity management; access management, Web services security, information assurance, and privacy management.
Invest in Knowledge:Ensure that your team has the appropriate technology and product knowledge to support the deployment before you start any design. Oracle strongly recommends providing specific training to capture and transfer knowledge that enables individuals to independently support and maintain an evolving infrastructure. This investment is key to a successful deployment.
In addition to the recommendations throughout this guide, see the Oracle Application Server Best Practices Guide. It includes recommendations that may involve a combination of tools and manual processes to achieve a desired result that fall outside the scope of thi smanual.
The Oracle Application Server Best Practices Guide is updated on a quarterly basis. It focuses on the Oracle Identity and Access Management Suite, which covers the following technology areas:
Oracle Access Manager: All recommendations specific to Oracle Access Manager are repeated in this guide.
Oracle Internet Directory
Oracle Virtual Directory
Security
Oracle Application Server High Availability
