Guide to planning ForgeRock® Access Management deployments. ForgeRock Access Management provides authentication, authorization, entitlement and federation software.

• ForgeRock Access Management. Context-based access management system. AM 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. AM is deployed as a simple .war file, featuring an architecture that is platform independent, flexible, and extensible, and highly available and scalable.

• ForgeRock Identity Management. Cloud-focused identity administration. Identity Management is a lightweight provisioning system, built on resource-oriented principles. IDM is a self-contained system, providing workflow, compliance, synchronization, password management, and connectors. IDM features a next-generation modular architecture that is self-contained and highly extensible.

• ForgeRock Directory Services. Internet scale directory server. Directory Services provides full LDAP protocol support, multi-protocol access, cross-domain replication, common REST framework, SCIM support, and many other features.

• ForgeRock Identity Gateway. No touch single sign-on (SSO) to enterprise, legacy, and custom applications. Identity Gateway is a reverse proxy server with specialized session management and credential replay functionality. IG works together with AM 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.

  "ForgeRock Identity Platform" illustrates these components:

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

• Reduces Operational Cost and Complexity. AM 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. AM 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. AM enables users to experience more services using SSO without the need of multiple passwords.

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

• Increased Compliance. AM 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. AM 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, 12.0, and 12.0.1

• 2015: OpenAM 11.0.3 and 12.0.2

• 2016: OpenAM 12.0.3, 12.0.4, 13.0.0, and 13.5.0

• 2017: AM 5 and 5.5

• 2018: AM 6

• 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 a larger session cache or more policies. Horizontal scaling involves adding additional host servers, possibly behind a load balancer, so that the servers can function as a single unit.

• 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.

  Which type of clients will be supported? The type of client determines the components required for the deployment. For example, applications deployed on a web server require a web agent. Applications deployed in Java containers require a Java agent. An AJAX application can use AM's RESTful API. Legacy or custom applications can use the ForgeRock Identity Gateway. Applications in an unsupported application server can use a reverse proxy with a web or Java 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 AM server behind a firewall, you can deploy a reverse proxy, such as Identity Gateway. 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 AM 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 configuration.

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

  • Determine if AM 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 web or Java agent behind a load balancer with SSL offloading, ensure that you set the web or Java agent's override request URL properties.

  • For multiple AM 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 cache, 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 AM servers and load balancers for scalability and availability purposes.

  • Determine whether to configure AM to store authentication sessions in the CTS token store, on the client, or in AM's memory:

    • Client-based authentication sessions provide authentication high availability and are easier to deploy in global authentication environments, but the authentication session is held by the client.

    • CTS-based authentication sessions provide high availability and keep the authentication session in your environment, but require consistent and fast replication across the CTS token store deployment.

    • In-memory authentication sessions do not provide authentication high availability, but keep authentication session in your environment.

  • Determine whether to configure AM to store sessions in the CTS token store or on the client. Client-based sessions allow for easier horizontal scaling but do not provide equivalent functionality to CTS-based 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. AM provides numerous plugin points and REST endpoints.

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

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

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

  • Tune AM's JVM, caches, LDAP connection pools, container thread pools, and other items. For information on tuning AM, see "Tuning an Instance" in the Setup and Maintenance Guide.

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

  • Consider implementing separate file systems for both AM and DS, 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.

• Web Agent. Comprised of agent modules tailored to each web server and several native shared libraries. Configure the web agent in the web server's main configuration file.

  The following figure illustrates a simplified flow of a request to a protected resource on a web server:

  Web Agent

  
  
  

  For a detailed explanation of the flow, refer to the ForgeRock Access Management Web Agents documentation.

• Java Agent. Comprised of an agent filter, an agent application, and the AM SDK libraries.

  The following figure illustrates a simplified flow of a request to a protected resource in a Java container:

  Java Agent

  
  
  

  The figure represents the agent filter (configured in the protected Java application) and the agent application (deployed in the Java container) in the same box as a simplification.

  For a detailed explanation of the flow, refer to the ForgeRock Access Management Java Agents documentation.

• Cookie Reset. Web and Java agents can reset any number of cookies in the session before the client is redirected for authentication. Reset cookies when the agent is deployed with a parallel authentication mechanism and when cookies need to be reset between mechanisms.

• Authentication-Only Mode. Instead of enforcing both authentication and resource-based policy evaluation, web and Java agents can enforce authentication only. Use the authentication-only mode when there is no need for fine-grain authorization to particular resources, or when you can provide authorization by different means.

• Not-Enforced Lists. Web and Java agents can bypass authentication and authorization and grant immediate access to specific resources or client IP addresses. Use not-enforced lists to configure URL and URI lists of resources that does not require protection, or client IP lists for IPs that do not require authentication or authorization to access specific resources.

• URL Checking and Correction. Web and Java agents require that clients accessing protected resources use valid URLs with fully qualified domain names (FQDNs). If invalid URLs are referenced, policy evaluation can fail as the FQDN will not match the requested URL, leading to blocked access to the resource. Misconfigured URLs can also result in incorrect policy evaluation for subsequent access requests. Use FQDN checking and correction when clients may specify a resource URL that differs from the FQDN configured in AM's policies, for example, in environments with load balancers and virtual hosts.

• Attribute Injection. Web and Java agents can inject user profile attributes into cookies, requests, and HTTP headers. Use attribute injection, for example, with websites that address the user by the name retrieved from the user profile.

• Notifications. AM can notify web and Java agents about configuration and session state changes. Notifications affect the validity of the web or Java agent caches, for example, requesting the agent to drop the policy and session cache after a change to policy configuration.

• Cross-Domain Single Sign-On (CDSSO). Web and Java agents can be configured to provide cross-domain single sign-on capabilities. Configure CDSSO when the web or Java agents and the AM instances are in different DNS domains.

• POST Data Preservation. Web and Java agents can preserve HTML form data posted to a protected resource by an unauthenticated client. Upon successful authentication, the agent recovers the data stored in the cache and auto-submits it to the protected resource. Use POST data preservation, for example, when users or clients submit large amounts of data, such as blog posts and wiki pages, and their sessions are short-lived.

• Continuous Security. Web and Java agents can collect inbound login requests' cookie and header information which an AM server-side authorization script can then process. Use continuous security to configure AM to act upon specific headers or cookies during the authorization process.

• Conditional Redirection. Web and Java agents can redirect users to specific AM instances, AM sites, or websites other than AM based on the incoming request URL. Configure conditional redirection login and logout URLs when you want to have fine-grained control over the login or logout process for specific inbound requests.

• Identity Data Stores. For identity repositories, AM provides built-in support for LDAP repositories. 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 "Directory Server 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 "Preparing Identity Repositories" in the Installation Guide.

  If AM does not support your particular identity data store type, you can develop your own customized plugin to allow AM to run method calls to fetch, read, create, delete, edit, or authenticate to your identity store data. For more information, see "Customizing Identity Data Stores" in the Setup and Maintenance 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. AM associates a realm with at least one identity repository and authentication process. When you initially configure AM, you define the identity repository for authenticating at the top level realm (/), which is used to administer AM. 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 "Setting Up Realms" in the Setup and Maintenance Guide.

• Configuration Data Stores. AM stores configuration data in the embedded DS 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 "Directory Server Requirements" in the Release Notes.

  The embedded DS 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, AM'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 "Configuring Secrets, Certificates, and Keys" in the Setup and Maintenance Guide.

• CTS Data Stores. The CTS provides persistent and highly available token storage for AM CTS-based sessions and authentication sessions, OAuth 2.0, UMA, client-based session blacklist (if enabled), client-based authentication session whitelist (if enabled), SAML 2.0 tokens for Security Token Service token validation and cancellation (if enabled), push notification for authentication, and cluster-wide notification.

  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 "Implementing 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 AM 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 AM and AM client applications. The load balancer itself must be redundant, too, so that it does not become a single point of failure. Illustrations in "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?

  AM 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. AM synchronizes configuration and policy data across sites, and by default also synchronizes session data as well. AM also expects profiles in identity data stores to remain in sync. As shown in "Example Deployment Topology", the deployment involves directory service replication between sites.

• What is the impact of losing individual session information?

  AM offers different ways of storing session information to suit your environment needs. If your environment requires session high availability, AM can store sessions in the CTS token store. Even if a server fails or the client browser crashes, the session remains available as long as the CTS is available.

  In deployments where an interruption in access to a protected resource could cause users to lose valuable information, configuring the CTS correctly can prevent the loss. The underlying directory service should replicate sessions stored in CTS. Because session information can be quite volatile—more volatile than configuration and policy data—replication of the CTS 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 "SNMP Monitoring for Policy Evaluation" in the Setup and Maintenance Guide.

• For a service that stores CTS-based 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 with 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 CTS-based 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 if you wanted to cache all 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 the session cache. Keep in mind that this is extra memory needed in addition to memory needed for everything else that the system does including running AM server.

  Session data is relatively volatile, as the CTS creates session 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 "Monitoring CTS Tokens" in the Setup and Maintenance Guide.

• What level of network traffic do you expect for session change notifications?

  When sizing the network, you must account for change notifications from the Core Token Server token store to the AM server.

  In AM deployments, there is no direct network traffic between AM servers.

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

  AM stores data in user profile attributes. AM can use or provision many profile attributes, as described in "To Configure an Identity Data Store" in the Setup and Maintenance 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 AM. You can access online information, meet with your ForgeRock Sales representative, go to a seminar, or call ForgeRock about AM's capabilities.

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

  Initial Questions

  Initial Tasks	Done ?
  Understand the access management problems that AM helps to solve	Y	N
  Learn how to protect a Web site with AM	Y	N
  Get to know the AM software deliverables	Y	N
  Get to know the tools for administering AM	Y	N
  Get to know the APIs for AM 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 AM demo or set up a pilot to determine how you want to use AM 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 AM 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.

  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.

  Services

  Services Task	Done ?
  Understand the services AM 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 AM protects (who consumes AM services)	Y	N

  
  

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

  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 (AM service availability, authentication availability, authorization decision availability, session availability, elasticity)	Y	N
  Understand how AM services scale for high availability	Y	N
  Understand the restrictions in an AM deployment that uses client-based sessions	Y	N
  Plan for availability (number of sites and servers, load balancing and AM 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.

  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 AM deployment: CPU	Y	N
  Size servers for AM deployment: Memory	Y	N
  Size servers for AM deployment: Network	Y	N
  Size servers for AM deployment: I/O	Y	N
  Size servers for AM 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.

  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 AM services (including external dependencies)	Y	N
  Plan installation of AM web and Java agents, Fedlets, and IG (might be done by partner service providers)	Y	N
  Plan integration with client applications	Y	N
  Plan customization of AM (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, AM service, custom logger, custom policy enforcement points or agents).	Y	N

  
  

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

  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.

  Post-Deployment Tasks

  Post Deployment Tasks	Done ?
  Plan administration following AM deployment (services, agents/IG, 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, DS for the core token service (CTS), and the LDAP identity repository. For information on installing data repositories, see "Preparing for Deployment" in the Installation Guide.

• Obtain the AM Software. The ForgeRock BackStage website hosts downloadable versions of AM, including a .zip file with all of the AM components, the .war file, AM tools, the configurator, web and Java agents, IG, and documentation. Verify that you review the Software License and Subscription Agreement presented before you download AM files.

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

• Set up your Realms. Within AM, set up your realms and realm administrators if any. For more information on realms, see "Setting Up Realms" in the Setup and Maintenance Guide.

• Configure Session Location. Configure AM to store sessions in the CTS token store or in the client. For more information on session location, see "Session Storage Location" in the Authentication and Single Sign-On Guide.

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

• Secure AM. Configure AM to access external resources over HTTPS and LDAPS. Set up secure cookies and certificates. For more information, see "Securing Installations" in the Installation Guide.

• Configure High Availability. Configure the load balancers, site(s), and reverse proxies. Configure AM for session high availability and server failover. For information about deploying AM behind a load balancer and configuring sites, see "Installing Multiple Servers" in the Installation Guide. For an example of a reverse proxy with AM, see Simple Apache Reverse Proxy for AM with Certificate-Based Authentication.

• Prepare the Agent Configuration. Prepare the agent profile, agent authenticator, and configuration for a Java or web agent. For more information, see Create Agent Profiles in the Java Policy Agents documentation or Create Agent Profiles in the Web Policy Agent documentation.

• Install Agents. Install web or Java agents depending on the Java container or web server type. For more information, see Install Java Agent in the Java Policy Agents documentation or Install Web Agent in the Web Policy Agents documentation.

• Customizing the AM User Interface. Customize AM for your organization. For information on customizing the AM user interface, see the UI Customization Guide.

• Install Identity Gateway. Determine which IG deliverable to install (whether federation is involved). Prepare the Apache Tomcat, JBoss, Jetty, Oracle WebLogic app servers for installation. Install IG. See the IG 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 "Backing Up and Restoring Configurations" in the Setup and Maintenance Guide.

• Plan an AM 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 AM. Upgrade AM and other instances with or without the AM console. Upgrade the setup tools (configurator), configuration tools (ssoadm, ampassword, amverifyarchive), and the Java and/or web agents. Upgrade IG. For more information on upgrades, see the Upgrade Guide.

• Remove AM. If required, remove AM with or without the AM console. Remove setup and configuration tools. Remove the Java and/or web agents. Remove IG. For more information on removing AM, see "Removing Installations" in the Installation Guide.