• OpenAM Context-Based Access Management System. OpenAM is an all-in-one industry-leading access management solution, providing authentication, authorization, federation, Web services security, adaptive risk, and entitlements services among many other features. OpenAM is deployed as a simple .war file, featuring an architecture that is platform independent, flexible, and extensible, and highly available and scalable.

• OpenIDM. Cloud-Focused Identity Administration. OpenIDM is a lightweight provisioning system, built on resource-oriented principles. OpenIDM is a self-contained system, providing workflow, compliance, synchronization, password management, and connectors. OpenIDM features a next-generation modular architecture that is self-contained and highly extensible.

• OpenDJ. Internet Scale Directory Server. OpenDJ provides full LDAP protocol support, multi-protocol access, cross-domain replication, common REST framework, SCIM support, and many other features.

• OpenIG. No Touch Single Sign-On (SSO) to enterprise, legacy, and custom applications. OpenIG is a reverse proxy server with specialized session management and credential replay functionality. OpenIG works together with OpenAM to integrate Web applications without needing to modify the target application or the container that it runs in.

• OpenICF. Enterprise and Cloud Identity Infrastructure Connectors. OpenICF provides identity provisioning connections offering a consistent layer between target resources and applications and exposing a set of programming functions for the full lifecycle of an identity. OpenICF connectors are compatible with OpenIDM, Sun Identity Manager, Oracle® Waveset, Brinqa® GRC Platform, and so forth.

  Figure 1.1, "ForgeRock IRM Platform" illustrates the ForgeRock IRM platform.

• Enables Solutions for Additional Revenue Streams. OpenAM provides the tools and components to quickly deploy services to meet customer demand. For example, OpenAM's Federation Services supports quick and easy deployment with existing SAMLv2, OAuth2, and OpenID Connect systems. For systems that do not support a full SAMLv2 deployment, OpenAM provides a Fedlet, a small SAML 2.0 application, which lets service providers quickly add SAML 2.0 support to their Java applications. These solutions open up new possibilities for additional revenue streams.

• Reduces Operational Cost and Complexity. OpenAM can function as a hub, leveraging existing identity infrastructures and providing multiple integration paths using its authentication, SSO, and policies to your applications without the complexity of sharing Web access tools and passwords for data exchange. OpenAM decreases the total cost of ownership (TCO) through its operational efficiencies, rapid time-to-market, and high scalability to meet the demands of our market.

• Improves User Experience. OpenAM enables users to experience more services using SSO without the need of multiple passwords.

• Easier Configuration and Management. OpenAM centralizes the configuration and management of your access management system, allowing easier administration through its console and command-line tools. OpenAM also features a flexible deployment architecture that unifies services through its modular and embeddable components. OpenAM provides a common REST framework and common user interface (UI) model, providing scalable solutions as your customer base increases to the hundreds of millions. OpenAM also allows enterprises to outsource IAM services to system integrators and partners.

• Increased Compliance. OpenAM provides an extensive entitlements service, featuring attribute-based access control (ABAC) policies as its main policy framework with features like import/export support to XACML, a policy editor, and REST endpoints for policy management. OpenAM also includes an extensive auditing service to monitor access according to regulatory compliance standards.

• In 2001, Sun Microsystems releases iPlanet Directory Server, Access Management Edition.

• In 2003, Sun renames iPlanet Directory Server, Access Management Edition to Sun ONE Identity Server.

• Later in 2003, Sun acquires Waveset.

• In 2004, Sun releases Sun Java Enterprise System. Waveset Lighthouse is renamed to Sun Java System Identity Manager and Sun ONE Identity Server is renamed to Sun Java System Access Manager. Both products are included as components of Sun Java Enterprise System.

• In 2005, Sun announces an open-source project, OpenSSO, based on Sun Java System Access Manager.

• In 2008, Sun releases OpenSSO build 6, a community open-source version, and OpenSSO Enterprise 8.0, a commercial enterprise version.

• In 2009, Sun releases OpenSSO build 7 and 8.

• In January 2010, Sun was acquired by Oracle and development for the OpenSSO products were suspended as Oracle no longer planned to support the product.

• 2010: OpenAM 9.0

• 2011: OpenAM 9.5

• 2012: OpenAM 10 and 10.1

• 2013: OpenAM 11.0

• 2014: OpenAM 11.1 and 12.0

• What are you protecting? You must determine which applications, resources, and levels of access to protect? Are there plans for additional services, either developed in-house or through future acquisitions that also require protected access?

• How many users are supported? It is important to determine the number of users supported in your deployment based on system usage. Once you have determined the number of users, it is important to project future growth.

• What are your product service-level agreements? In addition to planning for the growth of your user base, it is important to determine the production service-level agreements (SLAs) that help determine the current load requirements on your system and for future loads. The SLAs help define your scaling and high-availability requirements.

  For example, suppose you have 100,000 active users today, and each user has an average of two devices (laptop, phone) that get a session each day. Suppose that you also have 20 protected applications, with each device hitting an average of seven protected resources an average of 1.4 times daily. Let's say that works out to about 200,000 sessions per day with 7 x 1.4 = ~10 updates to each session object. This can result in 200K session creations, 200K session deletions, and 2M session updates.

  Now, imagine next year you still have the same number of active users, 100K, but each has an average of three devices (laptop, phone, tablet), and you have added another 20 protected applications. Assume the same average usage per application per device, or even a little less per device. You can see that although the number of users is unchanged, the whole system needs to scale up considerably.

  You can scale your deployment using vertical or horizontal scaling. Vertical scaling involves increasing components to a single host server, such as increasing the number of CPUs or increasing heap memory to accommodate the number of users in your system. Horizontal scaling involves adding additional host servers, possibly behind a load balancer, so that the servers can function as a single unit. Configuring OpenAM to issue stateless sessions greatly simplifies deployment when using horizontal scaling.

• What are your high availability requirements? High availability refers to your system's ability to operate continuously for a specified length of time. It is important to design your system to prevent single points of failure and for continuous availability. Based on the size of your deployment, you can create an architecture using a single-site configuration. For larger deployments, consider implementing a multi-site configuration with replication over WAN in combination with one of the following two alternatives:

  • Stateless sessions

  • Sticky load-balancing and session failover

  Which type of clients will be supported? The type of client determines the components required for the deployment. For example, applications supported in a Web server require the use of a Web policy agent. Applications deployed in Java EE containers require the use of a Java EE policy agent. An AJAX application can use the OpenAM's RESTful API. Legacy or custom applications can use the OpenIG Identity Gateway. Applications in an unsupported application server can use a reverse proxy with a policy agent. Third party applications can use federation or a fedlet, or an OpenID Connect or an OAuth 2.0 component.

• What are your SSL/TLS requirements? There are two common approaches to handling SSL. First, using SSL through to the application servers themselves, for example, using SSL on the containers. Or second, using SSL offloading via a network device and running HTTP clear internally. You must determine the appropriate approach as each method requires different configurations. Determining SSL use early in the planning process is vitally important, as adding SSL later in the process is more complicated and could result in delays in your deployment.

• What are your other security requirements? The use of firewalls provides an additional layer of security for your deployment. If you are planning to deploy the OpenAM server behind a firewall, you can deploy a reverse proxy, such as OpenIG. For another level of security, consider using multiple DNS infrastructures using zones; one zone for internal clients, another zone for external clients. To provide additional performance, you can deploy the DNS zones behind a load balancer.

• Ensure all stakeholders are engaged during the planning phase. This effort includes but is not limited to delivery resources, such as project managers, architects, designers, implementers, testers, and service resources, such as service managers, production transition managers, security, support, and sustaining personnel. Input from all stakeholders ensures all viewpoints are considered at project inception, rather than downstream, when it may be too late.

• Project Initiation. The Project Initiation phase begins by defining the overall scope and requirements of the deployment. The following items can be planned:

  • Determine the scope, roles and responsibilities of key stakeholders and resources required for the deployment.

  • Determine critical path planning including any dependencies and their assigned expectations.

  • Run a pilot to test the functionality and features of OpenAM and uncover any possible issues early in the process.

  • Determine training for administrators of the environment and training for developers, if needed.

• Architecting. The Architecting phase involves designing the deployment. The following items can be planned:

  • Determine the use of products, map requirements to features, and ensure the architecture meets the functional requirements.

  • Ensure that the architecture is designed for ease of management and scale. TCO is directly proportional to the complexity of the deployment.

  • Determine how the Identity, Configuration, and Core Token Service (CTS) data stores are to be configured.

  • Determine the Sites and Session Failover configuration.

  • Determine where SSL is used in the configuration and how to maintain and update the certificate keystore and truststore for OpenAM's components, such as the agent installer, ssoadm tool, agent server, and other OpenAM servers. Planning for SSL at this point can avoid more difficulty later in the process.

  • Determine if OpenAM will be deployed behind a load balancer with SSL offloading. If this is the case, you must ensure that the load balancer rewrites the protocol during redirection. If you have a policy agent behind a load balancer with SSO offloading, ensure that you set the policy agent's override request URL properties.

  • For multiple OpenAM deployments, there is a requirement to deploy a layer 7 cookie-based load balancer and intelligent keep-alives (for example, /openam/isAlive.jsp). The network teams should design the appropriate solution in the architecting phase.

  • Determine requirements for vertical scaling, which involves increasing the Java heap based on anticipated session, policy cache, federation session, and restricted token usage. Note that vertical scaling could come with performance cost, so this must be planned accordingly.

  • Determine requirements for horizontal scaling, which involves adding additional OpenAM servers and load balancers for scalability and availability purposes.

  • Determine whether to configure OpenAM to issue stateful or stateless sessions. Stateless sessions allow for easier horizontal scaling but do not provide equivalent functionality to stateful sessions.

  • Determine if any coding is required including extensions and plugins. Unless it is absolutely necessary, leverage the product features instead of implementing custom code. OpenAM provides numerous plugin points and REST endpoints.

• Implementation. The Implementation phase involves deploying your OpenAM system. The following items should be considered:

  • Install and configure the OpenAM server, datastores, and components. For information on installing OpenAM, see the Installation Guide.

  • Maintain a record and history of the deployment to maintain consistency across the project.

  • Tune OpenAM's JVM, caches, LDAP connection pools, container thread pools, and other items. For information on tuning OpenAM, see Chapter 25, "Tuning OpenAM" in the Administration Guide.

  • Tune the OpenDJ directory server. Consider tuning the database back end, replication purge delays, garbage collection, JVM memory, and disk space considerations. For more information, see the OpenDJ directory server documentation.

  • Consider implementing separate file systems for both OpenAM and OpenDJ, so that you can keep log files on a different disk, separate from data or operational files, to prevent device contention should the log files fill up the file system.

• Automation and Continuous Integration. The Automation and Continuous Integration phase involves using tools for testing:

  • Set up a continuous integration server, such as Jenkins, to ensure that builds are consistent by running unit tests and publishing Maven artifacts. Perform continuous integration unless your deployment includes no customization.

  • Ensure your custom code has unit tests to ensure nothing is broken.

• Functional Testing. The Functional Testing phase should test all functionality to deliver the solution without any failures. You must ensure that your customizations and configurations are covered in the test plan.

• Non-Functional Testing. The Non-Functional Testing phase tests failover and disaster recovery procedures. Run load testing to determine the demand of the system and measure its responses. You can anticipate peak load conditions during the phase.

• Supportability. The Supportability Phase involves creating the runbook for system administrators including procedures for backup and restores, debugging, change control, and other processes. If you have a ForgeRock Support contract, it ensures everything is in place prior to your deployment.

• Cookie Reset. Policy agents can be configured to reset any number of cookies in the session before the client is redirected for authentication. This feature is typically used when the policy agent is deployed with a parallel authentication mechanism and cookies need to be reset. Make sure that the name, domain, and path properties are defined.

• Disable Policy Evaluation. Policy agents act as a policy enforcement point (PEP) during the authorization phase for a client application. This feature is typically used when the policy agent is only used for SSO and does not require a policy evaluation request to OpenAM.

• Not-Enforced URLs/URIs List. Policy agents protect all resources on the Web server or in a Web application that it serves and grants access only if the client has been authenticated and authorized to access the resources. However, there may be some resources, such as public HTML pages, graphics, or stylesheet files that do not require policy evaluation. To account for such files, the policy agent maintains a Not-Enforced URL list, specifying the URLs or resources that are available to any user. J2EE agents use a Not-Enforced URI list.

• URL Correction. OpenAM is aware of the access management network and its registered clients, implementing a fully qualified domain name (FQDN) mapper that can be configured to correct invalid URLs. It also holds a list of invalid URLs and compares them to the URL the policy agent is attempting to access.

• Attribute Injection Into Requests. Policy agents can be configured to inject user profile attributes into cookies, requests, and HTTP headers.

• Notifications. Both agents have the ability to receive configuration notifications from OpenAM. In deployments with stateful sessions, both agents can receive session notifications from OpenAM.

• Cross-Domain Single Sign-On. In deployments with stateful sessions, both agents can be configured for cross-domain single sign-on (CDSSO).

• Identity Data Stores. For identity repositories, OpenAM provides built-in support for LDAP and JDBC storage systems. You can implement a number of different directory server vendors for storing your identity data, allowing you to configure your directory servers in a number of deployment typologies. For a list of supported data stores, see Section 2.4, "Data Store Requirements" in the Release Notes.

  When configuring external LDAP Identity data stores, you must manually carry out additional installation tasks that could require a bit more time for the configuration process. For example, you must manually add schema definitions, access control instructions (ACIs), privileges for reading and updating the schema, and resetting user passwords. For more information, see Section 1.4, "Preparing an External Identity Repository" in the Installation Guide.

  If OpenAM does not support your particular identity data store type, you can develop your own customized plugin to allow OpenAM to run method calls to fetch, read, create, delete, edit, or authenticate to your identity store data. For more information, see Section 4.6, "Customizing Identity Data Storage" in the Developer's Guide.

  You can configure the Data Store authentication module to require the user to authenticate against a particular identity data store for a specific realm. OpenAM associates a realm with at least one identity repository and authentication process. When you initially configure OpenAM, you define the identity repository for authenticating at the top level realm (/), which is used to administer OpenAM. From there, you can define additional realms with different authentication and authorization services as well as different identity repositories if you have enough identity data. For more information, see Chapter 4, "Configuring Realms" in the Administration Guide.

• Configuration Data Stores. OpenAM stores configuration data in the embedded OpenDJ directory server. Configuration data includes authentication information that defines how users and groups authenticate, identity data store information, service information, policy information for evaluation, and partner server information that can send trusted SAML assertions. For a list of supported data stores, see Section 2.4, "Data Store Requirements" in the Release Notes.

  The embedded OpenDJ directory server may be sufficient for your system, but you may want to deploy an external configuration store if required for large-scale systems with many policies or many realms. Like external identity stores, you must manually add schema definitions, ACIs, privileges for reading and updating the schema, and indexes for attributes used to access the configuration data.

  SAML keys are stored in the configuration store and are thus replicated. Also, OpenAM's signing keys are shipped with a test certificate. If you upgrade the keystore, you need to redistribute the certificates to all nodes so that they can continue to communicate with each other. For more information, see Chapter 23, "Managing Certificates" in the Administration Guide.

• CTS Data Stores. The CTS provides persistent and highly available token storage for OpenAM session, OAuth 2.0, and SAML 2.0 tokens. If configured, CTS supports session token persistence for stateful session failover.

  CTS traffic is volatile compared to configuration data, so deploying CTS as a dedicated external data store is advantageous for systems with many users and many sessions. For more information, see Chapter 6, "Configuring the Core Token Service" in the Installation Guide.

To start thinking about the trade offs, answer the following questions.

• What is the impact of the OpenAM service becoming unavailable?

  In an online system this could be a severe problem, interrupting all access to protected resources. Most deployments fall into this category.

  In an embedded system protecting local resources, it might be acceptable to restart the service.

  Deployments that require always-on service availability require some sort of load balancing solution at minimum between OpenAM and OpenAM client applications. The load balancer itself must be redundant, too, so that it does not become a single point of failure. Illustrations in Chapter 3, "Example Deployment Topology", show multiple levels of load balancing for availability and firewalls for security.

• Is the service critical enough to warrant deployment across multiple sites?

  OpenAM allows you to deploy replicated configurations in different physical locations, so that if the service experiences complete failure at one site, you can redirect client traffic to another site and continue operation. The question is whether the benefit in reducing the likelihood of failure outweighs the costs of maintaining multiple sites.

  When you need failover across sites, one of the costs is (redundant) WAN links scaled for inter-site traffic. OpenAM synchronizes configuration and policy data across sites, and by default also synchronizes session data as well. OpenAM also expects profiles in identity data stores to remain in sync. As shown in Chapter 3, "Example Deployment Topology", the deployment involves directory service replication between sites.

• What happens if individual session information is lost?

  In OpenAM session failover is different from service failover. Session failover consists of maintaining redundant information for stateful sessions, so that if a server fails, another server recovers the session information, preventing the user from having to authenticate again. Service failover alone consists of maintaining redundant servers, so that if one server fails, another server can take the load. With service failover alone, users who authenticated with a failed server must authenticate again to start a new session.

  In deployments where an interruption in access to a protected resource could cause users to lose valuable information, session failover can prevent the loss. To provide for session failover, OpenAM replicates the session information held by the CTS, relying on the underlying directory service to perform the replication. Session information can be quite volatile, certainly more volatile than configuration and policy data. Session failover across sites can therefore call for more WAN bandwidth, as more information is shared across sites.

To estimate sizing based on service levels, take some initial measurements and extrapolate from those measurements.

• For a service that handles policy decision (authorization) requests, what is the average policy size? What is the total size of all expected policies?

  To answer these questions, you can measure the current disk space and memory occupied by the configuration directory data. Next, create a representative sample of the policies that you expect to see in the deployment, and measure the difference. Then, derive the average policy size, and use it to estimate total size.

  To measure rates of policy evaluations, you can monitor policy evaluation counts over SNMP. For details, see Section 24.2.2, "SNMP Monitoring for Policy Evaluation" in the Administration Guide.

• For a service that stores stateful sessions, access, and refresh tokens, or other authentication-related data in the CTS backing store, what is the average session or access/refresh token size? What is the average total size of CTS data?

  As for policy data, you can estimate the size of CTS data by measuring the CTS directory data.

  The average total size depends on the number of live CTS entries, which in turn depends on session and token lifetimes. The lifetimes are configurable and depend also on user actions like logout, that are specific to the deployment.

  For example, suppose that the deployment only handles stateful SSO sessions, session entries occupy on average 20 KB of memory, and that you anticipate on average 100,000 active sessions. In that case, you would estimate the need for 2 GB (100,000 x 20,000) RAM on average to hold the session data in memory. If you expect that sometimes the number of active sessions could rise to 200,000, then you would plan for 4 GB RAM for session data. Keep in mind that this is the extra memory needed in addition to memory needed for everything else that the system does including running OpenAM server.

  Session data is relatively volatile, as the CTS creates sessions entries when sessions are created. CTS deletes session entries when sessions are destroyed due to logout or timeout. Sessions are also modified regularly to update the idle timeout. Suppose the rate of session creation is about 5 per second, and the rate of session destruction is also about 5 per second. Then you know that the underlying directory service must handle on average 5 adds and 5 deletes per second. The added entries generate on the order of 100 KB replication traffic per second (5/s x 20 KB plus some overhead). The deleted entries generate less replication traffic, as the directory service only needs to know the distinguished name (DN) of the entry to delete, not its content.

  You can also gather statistics about CTS operations over SNMP. For details, see Section 24.2, "Monitoring CTS Tokens" in the Administration Guide.

• What level of network traffic do you expect for notifications and crosstalk?

  When sizing the network, you must account both for inter-site replication traffic and also for notifications and crosstalk in high-throughput deployments.

  In OpenAM deployments using stateful sessions, much of the network traffic between OpenAM servers consists of notifications and crosstalk. When the session state changes on session creation and destruction, the OpenAM server performing the operations can notify other servers.

  Crosstalk between OpenAM servers arises either when configured (i.e., in OpenAM 12.0 or later), where you enable crosstalk to resolve non-local sessions instead of having OpenAM rely on the session persistence mechanism, or when a client is not routed to the OpenAM server that originally authenticated the client. In an OpenAM site, the server that originally authenticates a client deals with the session, unless that server becomes unavailable. If the client is routed to another server, then the other server communicates with the first, resulting in local crosstalk network traffic. Sticky load balancing can limit crosstalk by routing clients to the same server with which they started their session.

  When the OpenAM servers are all on the same LAN, and even on the same rack, notifications and crosstalk are less likely to adversely affect performance. If the servers are on different networks or communicating across the WAN, the network could become a bottleneck.

• What increase in user and group profile size should you expect?

  OpenAM stores data in user profile attributes. OpenAM can use or provision many profile attributes, as described in Procedure 4.5, "To Configure a Data Store" in the Administration Guide.

  When you know which attributes are used, you can estimate the average increase in size by measuring the identity data store as you did for configuration and CTS-related data. If you do not manage the identity data store as part of the deployment, you can communicate this information with the maintainers. For a large deployment, the increase in profile size can affect sizing for the underlying directory service.

• How does the number of realms affect the configuration data size?

  In a centrally managed deployment with only a few realms, the size of realm configuration data might not be consequential. Also, you might have already estimated the size of policy data. For example, each new realm might add about 1 MB of configuration data to the configuration directory, not counting the policies added to the realm.

  In a multi-tenant deployment or any deployment where you expect to set up many new realms, the realm configuration data and the additional policies for the realm can add significantly to the size of the configuration data overall. You can measure the configuration directory data as you did previously, but specifically for realm creation and policy configuration, so that you can estimate an average for a new realm with policies and the overall size of realm configuration data for the deployment.

• Learn about OpenAM. You can access online information, meet with your ForgeRock Sales representative, go to a seminar, or call ForgeRock about OpenAM's capabilities.

  The following are some general questions that you may want to have answered:

  Table 6.1. OpenAM Initial Questions

  OpenAM Initial Tasks	Done ?
  Understand the access management problems that OpenAM helps to solve	Y	N
  Learn how to protect a Web site with OpenAM	Y	N
  Get to know the OpenAM software deliverables	Y	N
  Get to know the tools for administering OpenAM	Y	N
  Get to know the APIs for OpenAM client applications	Y	N
  Find out how to get help and support from ForgeRock and partners	Y	N
  Find out how to get training from ForgeRock and partners	Y	N
  Find out how to keep up to date on new development and new releases	Y	N
  Find out how to report problems	Y	N

  
  

• Set up a Demo or Pilot. View an OpenAM demo or set up a pilot to determine how you want to use OpenAM to protect your site(s). ForgeRock Sales representatives can assist you with a demo or pilot.

• Attend a Training Class. ForgeRock presents effective training classes to deploy OpenAM in your environment. See ForgeRock University for more information.

• Complete the Accreditation Program. Complete the product-specific ForgeRock Accreditation Program to gain in-depth design and deployment expertise or seek partners who are ForgeRock Accredited Partners.

• Determine Your Service Level Agreements. ForgeRock provides a set of standard service level agreements that you can sign up for. ForgeRock also provides custom service level agreements if the standard set does not meet your needs.

  Table 6.2. OpenAM Standard SLAs

  Priority	Gold	Silver	Bronze
  Urgent (P1)	2 Hour	4 Hour	Next Business Day
  High (P2)	4 Hour	8 Hour	2 Business Days
  Normal (P3)	6 Hour	Next Business Day	3 Business Days
  Low (P4)	Next Business Day	2 Business Days	4 Business Days

  
  

• Determine Your Services. ForgeRock provides a full, proven-production Identity Management stack to meet your requirements.

  Table 6.3. OpenAM Services

  Services Task	Done ?
  Understand the services OpenAM software provides	Y	N
  Determine which services to deploy	Y	N
  Determine which services the deployment consumes (load balancing, application container, authentication services, configuration storage, profile storage, token/session storage, policy storage, log storage)	Y	N
  Determine which services the deployment provides (SSO, CDSSO, SAML Federation IDP/SP, XACML PDP, REST STS, OAuth 2.0/OpenID Connect 1.0, and so forth)	Y	N
  Determine which resources OpenAM protects (who consumes OpenAM services)	Y	N

  
  

• Determine Your Deployment Objectives. OpenAM provides proven performance and security in many production deployments. You should determine your overall deployment objectives.

  Table 6.4. OpenAM Deployment Objectives

  Deployment Objectives	Done ?
  Define deployment objectives in terms of service levels (expectations for authentication rates, active sessions maintained, session life cycles, policies managed, authorization decision rates, response times, throughput, and so forth)	Y	N
  Define deployment objectives in terms of service availability (OpenAM service availability, authentication availability, authorization decision availability, session availability, elasticity)	Y	N
  Understand how OpenAM services scale for high availability	Y	N
  Understand the restrictions in an OpenAM deployment that uses stateless sessions	Y	N
  Plan for availability (number of sites and servers, load balancing and OpenAM software configuration)	Y	N
  Define the domains managed and domains involved in the deployment	Y	N
  Define deployment objectives for delegated administration	Y	N
  Agree with partners for federated deployments on circles of trust and terms	Y	N

  
  

• Plan Sizing. At this stage, you should determine the sizing estimates for your deployment. ForgeRock Sales Engineers can assist you in this task.

  Table 6.5. OpenAM Sizing

  Sizing	Done ?
  Derive sizing estimates from service levels and availability	Y	N
  Understand how to test sizing estimates (load generation tools?)	Y	N
  Size servers for OpenAM deployment: CPU	Y	N
  Size servers for OpenAM deployment: Memory	Y	N
  Size servers for OpenAM deployment: Network	Y	N
  Size servers for OpenAM deployment: I/O	Y	N
  Size servers for OpenAM deployment: Storage	Y	N
  Quantify impact on external services consumed (LDAP, other auth services, load balancing, and so forth)	Y	N
  Plan testing and acceptance criteria for sizing	Y	N

  
  

• Plan the Topology. Plan your logical and physical deployment.

  Table 6.6. OpenAM Topology Planning

  Topology	Done ?
  Specify the logical and physical deployment topology (show examples of each)	Y	N
  Determine whether to use the embedded or external directory service for configuration, CTS, and user data	Y	N
  Plan installation of OpenAM services (including external dependencies)	Y	N
  Plan installation of OpenAM policy agents, Fedlets, and OpenIG (might be done by partner service providers)	Y	N
  Plan integration with client applications	Y	N
  Plan customization of OpenAM (classic UI or XUI, user profile attributes, authentication modules, identity repositories, OAuth 2.0 scope handling, OAuth 2.0 response types, post-authentication actions, policy evaluation, session quota exhaustion actions, policy evaluation, identity data storage, OpenAM service, custom logger, custom Web policy agents).	Y	N

  
  

• Plan Security. At this stage, you must plan how to secure your deployment.

  Table 6.7. OpenAM Security

  Security	Done ?
  Understand security guidelines, including legal requirements	Y	N
  Change default settings and administrative user credentials	Y	N
  Protect service ports (Firewall, Dist Auth UI, reverse proxy)	Y	N
  Turn off unused service endpoints	Y	N
  Separate administrative access from client access	Y	N
  Secure communications (HTTPS, LDAPS, secure cookies, cookie hijacking protection, key management for signing and encryption)	Y	N
  Determine if components handle SSL acceleration or termination	Y	N
  Securing processes and files (e.g. with SELinux, dedicated non-privileged user and port forwarding, and so forth)	Y	N

  
  

• Post-Deployment Tasks. At this stage, you should plan your post-deployment tasks to sustain and monitor your system.

  Table 6.8. OpenAM Post-Deployment Tasks

  Post Deployment Tasks	Done ?
  Plan administration following OpenAM deployment (services, agents/OpenIG, delegated administration)	Y	N
  Plan monitoring following deployment	Y	N
  Plan how to expand the deployment	Y	N
  Plan how to upgrade the deployment	Y	N

  
  

• Plan the Overall Deployment. The initial planning step involves establishing the overall deployment. You should determine who is responsible for each task and any external dependencies.

• Determine What To Install. Based on your deployment plan, determine what you need to install.

• Determine Your System Requirements. Based on your deployment plan, determine your system requirements.

• Prepare the Operating System. Prepare your operating system, depending on the OS: Linux, Solaris, Windows, Cloud (Amazon EC2, OpenStack, and so forth), Virtual Machines (VMWare, Xen, Hyper-V, and so forth)

• Prepare the Java Environment. Prepare your Java environment, depending on your vendor type: Oracle, IBM, OpenJDK.

• Prepare the App Server. Prepare your application server, depending on type: Apache Tomcat, JBoss 4/5, WildFly, Jetty, Oracle WebLogic, IBM WebSphere. Also, prepare each app server for HTTPS.

• Prepare the Directory Servers. Prepare the configuration directory server, OpenDJ for the core token service (CTS), and the LDAP identity repository. For information on installing data repositories, see Chapter 1, "Preparing For Installation" in the Installation Guide.

• Obtain the OpenAM Software. You should obtain a supported ForgeRock release of OpenAM, a nightly build, or an archive build. For the latest stable version of OpenAM, click Enterprise Downloads.

• Configure OpenAM. Install and configure OpenAM with or without the console, the setup tools (configurator), configuration tools (ssoadm, ampassword, amverifyarchive), or set up your scripted install and configuration of OpenAM. For information on installing OpenAM, see the Installation Guide.

• Set up your Realms. Within OpenAM, set up your realms and realm administrators if any. For more information on realms, see Chapter 4, "Configuring Realms" in the Administration Guide.

• Configure Session State. Configure sessions as stateful or stateless. For more information on session state, see Chapter 9, "Configuring Session State" in the Administration Guide.

• Install Another OpenAM Instance. Set up an identical instance of your first OpenAM instance. For information on installing multiple OpenAM servers, see Chapter 4, "Installation Considerations for Multiple Servers" in the Installation Guide.

• Secure OpenAM. Configure OpenAM to access external resources over HTTPS and LDAPS. Set up secure cookies and certificates. For more information, see Chapter 27, "Securing OpenAM" in the Administration Guide.

• Configure High Availability. Configure the load balancers, reverse proxies, and site(s). Configure OpenAM for session failover and server failover. For simple instructions to deploy OpenAM behind a load balancer, see Deploying OpenAM behind a load balancer. For an example of a reverse proxy with OpenAM, see Simple Apache Reverse Proxy for OpenAM with Certificate-Based Authentication. For information on configuring sites, see Chapter 4, "Installation Considerations for Multiple Servers" in the Installation Guide.

• Prepare the Policy Agent Profiles. Prepare the policy agent profile, agent authenticator, policy agent configuration, bootstrap configuration for a Java EE or Web policy agent. For more information, see Chapter 5, "Configuring Policy Agent Profiles" in the Administration Guide.

• Install the Policy Agents. Install the policy agents depending on the app server or Web server type. For app servers, Apache Tomcat, JBoss, Jetty, Oracle WebLogic, IBM WebSphere. For Web servers, Apache , Microsoft IIS. Set up any script installations of the policy agents. For more information, see the OpenAM Web Policy Agent documentation.

• Customizing OpenAM. Customize OpenAM for your organization. For information on customizing the OpenAM end-user pages, see Chapter 5, "Customizing the OpenAM End User Pages" in the Installation Guide.

• Install OpenIG. Determine which OpenIG deliverable to install (whether federation is involved). Prepare the Apache Tomcat, JBoss, Jetty, Oracle WebLogic app servers for installation. Install OpenIG. See the OpenIG documentation for details.

• Plan Application and Host Backup. Determine your backup strategy including LDIF exports, file system backups, tar files, and so forth. Also, consider log rotation and retention policies. For more information on backups, see Chapter 21, "Backing Up and Restoring OpenAM Configurations" in the Administration Guide.

• Plan an OpenAM Upgrade. You should know what is new or fixed in an upgrade version as well as the differences and compatibility between the current version and an upgrade. Know the limitations of an upgrade version. Plan a live upgrade without service interruption. Plan an offline upgrade with service interruption. Plan the test of the upgrade and revert a failed upgrade. For more information on upgrades, see the Upgrade Guide.

• Upgrade OpenAM. Upgrade OpenAM and other instances with or without the console. Upgrade the setup tools (configurator), configuration tools (ssoadm, ampassword, amverifyarchive), and the Java EE and/or Web policy agents. Upgrade OpenIG. For more information on upgrades, see the Upgrade Guide.

• Remove OpenAM. If required, remove OpenAM with or without the console. Remove setup and configuration tools. Remove the Java EE and/or Web policy agents. Remove OpenIG. For more information on removing OpenAM, see Chapter 8, "Removing OpenAM Software" in the Installation Guide.