Section_J-Section_C.2_Attachment_IEP_control_Document-91916.pdf

Internal Revenue Service

Solicitation Number: TIRNO-16-R-00026 IRS Integrated Enterprise Portal 1.5 (IEP 1.5)

Section J – Attachment C.2 IRS Enterprise Portal Control Document (IEP CD) V4.0 (redacted version)

March 17, 2016

IRS Integrated Enterprise Portal Program

IRS Enterprise Portal Control Document (IEP CD)

Date: 03/17/2016

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

1.0 INTRODUCTION

1.1 PURPOSE

This document describes the application deployment process for the IRS Integrated Enterprise Portals (IEP) platform. Specifically, the sections outlined in this document assist IRS application owners with understanding the application styles and technologies currently supported by IEP. The document also outlines processes that IRS application owners may experience while interacting with IEP, such as application onboarding, application deployment, and new technology requests.

The IEP Control Document (IEP CD) is now the centralized document for IEP information, guidelines, and processes. The previously used terminology for IEP CD will now be referred to as the IEP Deployment Definition (IEP DD) going forward. The IEP DD is the deployment definition file within the IEP bundle which can either be in the form of XML or a Microsoft Word document.

1.2 SCOPE

This document provides step-by-step procedures for the leveraging IEP technology services from the perspective of an IRS application owner. The following topics are considered in-scope as of the publishing of this document:

Current IEP Application Styles

Current IEP Technologies

Requesting IEP Capacity

Introducing a New Technology into IEP

Legacy IEP Technologies

Supported IRS Environment Configurations

Definition of XML Schemas used for Deployments

Application Bundle Design used to Leverage IEP Services

Deploying an Application to IEP

Retrieving Performance and Log Data from an IEP Deployed Application

The following topics are considered out of scope:

Definition of IRS processes

IEP sub-processes and technologies that do not require IRS participation

1.3 ASSUMPTIONS

This document operates on the following assumptions:

The audience is familiar with XML and XML schema definition language

The audience is familiar with standard Java deployment artifacts including EAR,WAR, and JAR

1.4 REQUIRED READING

2. Standard application deployments in IEP are initiated via XML.

3. Bundle validation is required prior to IEP application deployments to facilitate the process and reduce deployment errors due to malformed bundles. The Bundle Validation Guide covers how to set up the working environment and how to validate the bundle’s structure.

Bundle Validation

Guide.pdf

Bundle Validation Guide

4. The IEP Standard Operating Procedure (SOP) describes the daily operational procedures for the platform. Specifically, the procedures described in the SOP help stakeholders request changes to the overall service, move key items such as application code patches and infrastructure changes through IEP, and track the deployment and usage of configuration items. The document can be requested from ETI.

1.5 HOW TO USE THIS DOCUMENT

This document assists IRS application owners with onboarding a new application, updating an existing application, and onboarding a new technology. By following the process flow below, application owners can navigate the document and obtain the information they need in order to engage with IEP.

Figure 1 – IEP Control Document (IEP CD) Guide

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

1.6 FREQUENTLY ASKED QUESTIONS (FAQ)

Q. Can an IEP configuration bundle have configurations for multiple applications including those utilizing alternative streams?

A. No, each IEP configuration bundle can have only one set of application configuration files. For more information on the IEP configuration bundle, please refer to Section 10.0 Bundle Design.

Q. When should an alternative stream of an application be utilized in IEP?

A. IEP has the capability to use alternative streams for a given application. The alternative stream application can serve different purposes such as a providing a separate entity to handle bugs related to the main application and testing or implementing an advance feature to add to the main application. Both the main application and alternative stream of the application follow the same application onboarding process because they are treated as two separate applications. Please refer to Section 4.0 IEP Application Onboarding for more information.

Q. Why can’t separate physical components of a bundle, particularly the WAS and the Web Server or Gateway, be deployed independently?

A. Based on the current IEP DD configuration, all of the required components must be included in the IEP bundle in order for the application to deploy through the standard process. For more information on the IEP configuration bundle, please refer to Section 10.0 Bundle Design.

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

2.0 APPLICATION STYLES SUPPORTED

This section describes the different applications styles supported within the IEP Deployment Definition (IEP DD). The main application styles include Application to Application (A2A) and Web Application. An application can also be classified as a Hybrid A2A Style in the IEP DD. A Hybrid A2A style includes the required and optional components of A2A and Web Application styles. For example, the MeF-IFA application is a Hybrid A2A because it contains A2A components and a web server from the Web Application style. The following sections describe the two main application styles and their technology components. The section also outlines Component Application style which currently is only available for FSG files.

2.1 APPLICATION TO APPLICATION (A2A)

The IEP platform is designed to largely support web services in a virtual environment. The A2A style is generally used for system-to-system interaction. This style enables external applications to connect to IRS web services via HTTPS. This style does not present the user with a graphical user interface because the interaction is primarily system-to-system.

The following are potential components in the A2A style which are detailed in Section 3.0 Technologies Supported. In addition, Section 8.0 IEP Deployment Definition (IEP DD) includes information on the required and optional XML files which correspond to these components.

Application server (Required)

Database server

Secure File Transfer Protocol (SFTP)

Gateway

Messaging

IEP Virtual Machines (VMs) that connect to the Current Processing Environments (CPE) have a standard sizing model as depicted in Table 1 below. As the environment needs for applications may vary based on IRS policy or business objective, application owners must provide which of the supported environments (Table 1) are required during the Application Onboarding process. Furthermore, VM specifications for PETE and Production are also determined during the onboarding process through an IEP capacity request. Please refer to Section 4.0 IEP Application Onboarding for more information regarding the onboarding process and IEP capacity requests.

CPE IEP DD

SBX No

DEV No

SIT Yes

EITE Yes

FIT Yes

PETE Yes

PROD Yes

1 - Applications are granted developer access to the virtual machines and applications are manually deployed (i.e., there is no IEP bundle). Component specific changes can be modified and tested by the application owners.

Table 1. Profile of Application to Application VMs across CPE

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

2.2 WEB APPLICATION

The Web Application style provides a web front-end for end user interaction with the IEP applications.

This style supports applications that require a graphical user interface to interact with end-users. For registered end-users, the Web Application style currently supports login-authentication (LA) and self-authentication (SA) applications. IEP SA allows Web-based interaction with taxpayers who are not registered with the IRS, and, therefore, cannot be authenticated through log-in authentication. The SA method uses shared secrets, which contains read-only information from the taxpayer’s account that only the taxpayer should know (e.g., refund amount, adjusted gross income). IEP LA allows Web-based interaction with users who have registered with the IRS and have a username/User ID and password.

The following are potential components in the Web Application style which are detailed in Section 3.0 Technologies Supported. In addition, Section 8.0 IEP Deployment Definition (IEP DD) includes information on the required and optional XML files which correspond to these components.

Application server (Required)

Web server (Required)

Database server

Messaging

IEP VMs that connect to the CPE have a standard sizing model as depicted in Table 2 below. As the environment needs for applications may vary based on IRS policy or business objective, application owners must provide which of the supported environments (Table 1) are required during the Application Onboarding process. Furthermore, VM specifications for PETE and Production are also determined during the onboarding process through an IEP capacity request. Please refer to Section 4.0 IEP Application Onboarding for more information regarding the onboarding process and IEP capacity requests.

CPE IEP DD

SBX No

DEV No

SIT Yes

EITE Yes

FIT Yes

PETE Yes

PROD Yes

1 - Applications are granted developer access to the virtual machines and applications are manually deployed (i.e., there is no IEP bundle). Component specific changes can be modified and tested by the application owners.

Table 2. Profile of Web Application VMs across CPE

2.3 COMPONENT APPLICATION

The Component Application style enables IEP application owners to deploy configurations for a specific technology component instead of a group of technologies like other application styles. Currently, this style only supports the Gateway component type that uses FSG configuration files. Additionally, this style must follow the Specialized Deployment process described in Section 12.3.3. It is important to note that once an application style or component type is selected, it cannot be changed.

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

3.0 TECHNOLOGIES SUPPORTED

This section describes the standard technologies within IEP. For technologies no longer supported by IEP for new application use, please see Section 6.0 Legacy Technologies. If a technology is not listed in this section but is required to support a new application then IRS application owners should follow the IEP New Technology Onboarding process defined in Section 5.0.

3.1 APPLICATION SERVERS

JBoss Enterprise Application Server is the IEP standard Java application server. This is a standard component of the Web Application style and is also available for use under the A2A style. Any application request that requires Java are implemented using JBoss.

3.2 WEB SERVERS

Apache is the IEP standard web server. A common use of web servers in IEP is to provide separation between the application layer and the public. All Web Application styles utilize a web server for this purpose.

3.2.1 SiteMinder

IEP deploys the IRS standard of CA SiteMinder to support authentication and authorization of IRS application services.

Application owners are responsible for populating backend SiteMinder policy server information and service credentials to enable the orchestration. Details for SiteMinder configuration can be found in Section 8.0 IEP Deployment Definition (IEP DD).

3.3 DATABASE

Oracle Relational DataBase Management System (RDBMS) is the IEP standard for databases. RDBMS is primarily used for session persistence and content database. Please contact ETI if other uses are needed.

Session Persistence: Enables state-full interaction between the users and the application. These databases are used to overcome the connectionless nature of request-response paradigm inherent in the Transmission Control Protocol/Internet Protocol (TCP/IP). This is created automatically for all applications.

Content Database: Used by applications for application configuration content. In addition to session databases, certain IEP applications also use persistent data stores to store application configuration data. This is used by applications such as, Electronic Authentication (eAUTH), Internal Refund Fact of Filing (IRFOF), and Common Services (CS).

3.4 MESSAGING SERVICES

WebSphere MQ is used to facilitate reliable communication, messaging, and file transfer between back-end IRS applications and devices. WebSphere MQ allows multiple applications and services to use a single transport type to communicate. Currently, application servers utilize WebSphere MQ for messaging purposes.

Application owners can provide the configuration (config.ini) file containing WebSphere MQ queues information to IEP. The configuration files are in the resources directory for the application server component folder. Reference to these files can be declared as modules in application.xml. WebSphere MQ queue managers are supported and maintained by IEP. This includes patching and managing of

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

servers, building the queue managers, configuring all channel(s), listener(s), and clustering information.

Please see Section 14.3 Additional XML Configurations for more information.

3.5 SECURE FILE TRANSFER PROTOCOL (SFTP)

Applications in IEP use the Tectia Server to transfer attachments between the portal and backend applications via SFTP. When an attachment is ready for consumption, an IEP application sends a message to the back end application via the AMDAS API. The back end server then retrieves the attachment from the Tectia server using SFTP.

3.6 MCAFEE WEB GATEWAY

McAfee Web Gateway (MWG) is a server that scans messages and files sent to IEP for potential threats such as viruses, malware, and intrusions. As an infrastructure component, MWG is setup during the initial phases of application onboarding and is not automatically re-configurable through the deployment process. McAfee Web Gateway can validate file types and submission sizes that users upload to verify they comply with defined restrictions. Any submissions sent that McAfee determines are dangerous are logged and blocked. The McAfee Web Gateway can also decompress Zip files and perform anti-virus scans of uploaded files.

3.7 XML GATEWAYS

XML Gateways enable IEP to secure IRS hosted web services. XML Gateways provide a set of capabilities for processing and protecting inbound and outbound transactions including:

XML validation and transformation

Anti-virus protection

Denial-of-service protection

XML attack detection/prevention

Access management of Web Service

Logging and auditing

Currently, IEP supports both Forum Sentry and Layer 7 XML Gateways. SiteMinder is also available to use for both.

3.7.1 Forum Sentry

All infrastructure layer configurations for IEP are outside of the Forum Sentry Gateway (FSG) file and are configured, maintained and backed-up by the IEP team. Application owners provide the IEP team application-specific policies and configurations via the FSG file per IRS environment. IEP teams deploy the FSG to the intended IRS environment. Infrastructure layer configurations cannot be overwritten by the application FSG file. Below is a description of each type of application managed configuration:

Logging Configuration:

• Custom logging

• Log archival

Flow Control Configuration:

• Load balancing configuration via group remote policy

• Configuring content-based routing

Security Configuration:

• Enforce SSL Authentication

• Prevent against unauthorized access

• Define throttling settings such as rate limit control and delayed processing

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

• Configure Pattern Matching policies to protect against SQL Injection and other XML attacks

• XML schema validation and enforcement

• Denial of Service (DoS) detection: document size, depth, and count limits

• XML message encryption and decryption

• Sign and verification of XML Signatures

• Validation of WS-Security Header

• SAML creation and assertion

• WSDL conformance check

• WAF (Web Application Firewall) Rule configuration

Document Configuration:

• Document identification

• Document validation

• Document transformation

• Attachment processing

• Attribute mapping

3.7.2 Layer 7

Currently all Layer 7 configurations for ACA Release 3.0/4.0/5.0 are managed by the IEP team. Below is a description of each type of application managed configuration:

Operations Configuration:

• Layer 7 throttling is configured to handle and verify that the max throughput rate is not breached to the Portal and the IRS which is primarily done through message rejection.

• Schedule enforcement enables a service window for a web service and enforce usage by service consumers to pre-defined schedules.

• Layer 7 generates a SOAP fault for invalid messages and containment of message based threats.

• Fault templates can be configured to send various fault codes and messages.

• JDBC queries can be executed to create/remove/update/delete data from a database.

• Layer 7 contains both operational logs (e.g., administration activities of system administrators) and transactional logs (e.g., the processing of messages going through the Portal).

Security Configuration:

• Intrusion Detection: Detects and protects against unauthenticated and unauthorized access to the system.

• Encryption/Decryption: Encrypted channels with SOAP over HTTPS, to minimize the risk of messages being sniffed or diverted. Each request is sent over HTTPS using TLS encryption and uses X.509 certificate for authentication.

• XML Borne Threats: Catches all XML-based threats such as oversized payloads, recursive elements, coercive parsing, XPATH injections, etc.

• Schema Validation: Matches incoming messages to the XML schema in the WSDL, including checking of required fields, field sizes and types, etc.

• WSDL Conformance: Detects whether the inbound message conforms to the WSDL specifications, such as, appropriate SOAP actions, message structure, attachment count, attachment size etc.

• Application Threats: Catches threats against applications such as SQL injection, code injection, falsified messages, ‘buffer overflow’ attacks, etc. Application threats are caught and handled by Layer 7 gateways.

• Authorization: Authorizes the service consumer to check against pre-defined access control lists before forwarding on the service request.

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

• DoS Detection: The rate limit assertion is applied via a global policy that determines the maximum transactions per seconds for the transactional cluster and maximum concurrency settings for the bulk cluster.

• WS-Security: Used to validate digital signature and verify the authenticity of a message.

• Authentication: Authenticates the Service Consumer; Partners generate X.509 certificates and provide to Portal.

• Attachment Validation: Validates all attachments are XML and are well-formed.

• WSDL Based Threats: Catches all WSDL-based threats such as WSDL enumeration, message snooping, Malicious Includes, etc. WSDL-based threats are caught and handled by Layer 7 gateways.

• Schema Conformance: Matches incoming messages to the XML schema in the WSDL, including checking of required fields, field sizes and types, etc.

• HTTP Validation: Detects whether the HTTP / SOAP headers are malformed or malicious.

T4GLB

None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

4.0 IEP APPLICATION ONBOARDING

When a new IEP application or a change to an existing IEP application is identified, application owners work with ETI and the IEP team to onboard the application. There are initial steps that must be taken which kick-off the application onboarding process. These steps include estimating the impacts to IEP, requesting IEP capacity, and other platform setup activities. By following the diagram in Figure 2, application owners can navigate the process of estimating for the application onboarding process.

Figure 2 – IEP Application Onboarding Process

The Service Catalog is used to generate a Service Catalog VROM estimate. The Service Catalog is a Microsoft Excel document which includes information on configuration assumptions, services, questions and user input, FAQ, IRFOF sample, next steps, and estimate assumptions. The instructions and configuration assumption tabs should be read before starting the questions and user input tab.

Furthermore, if additional capacity is needed for the application changes then a capacity request must be confirmed prior to final approval of the Service Catalog. The capacity request process is detailed in Section 4.2 Capacity Request.

4.1 NEW AND EXISTING IEP APPLICATION CHANGES

Applications owners requesting a new application or requesting changes to an existing IEP application for new streams or changes to deployment parameters should initiate the process by working with ETI to fill out the Service Catalog. In collaboration with ETI and the IEP team, application owners determine the estimate for onboarding changes to existing IEP applications based on the scope of work and the application requirements.

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

For changes to existing applications, IRS application owners should submit an Application Change Request and an Application Migration Request (AMR) for IRS environment other than Sandbox (SBX) or DEV. The requestors must provide detailed information of the change in various tickets. In order for an application owner to implement changes for their application, they need to provide an IEP bundle and an AMR per IRS environment in which the change will be deployed to. More information on the IEP bundle, Application Change Request, and AMR can be found in Section 10.0 Bundle Design and Section 12.0 Application Deployment.

4.2 CAPACITY REQUEST

The IEP team works with the ETI and application owners for capacity allocation to best satisfy business demand within the existing IEP platform. IEP teams monitor and manage the capacity usage, analyze capacity trends, and incorporate capacity forecasts. Before new applications are added to the IEP platform, the IEP team works with the IRS to determine the capacity required. This section outlines the process of a capacity request being approved for implementation for all capacity request types and within all IRS environment configurations.

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

4.3 PLATFORM SETUP ACTIVITIES

Based on the application onboarding estimate and the capacity request, the IEP team directs the application onboarding request to the Middleware, Infrastructure, and Automation teams for corresponding platform setup activities. In addition, the application owner and ETI must fill out the System Access Requirements (SAR) form which is provided and reviewed by the IEP team. The form must be filled out prior to an Application Change Request being submitted . After the form is reviewed, an Application Change Request ticket can then be created. More information on the Application Change Request can be found in Section 12.0 Application Deployment.

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

5.0 IEP NEW TECHNOLOGY ONBOARDING

When a new IEP technology is identified, the application owners work with ETI and the IEP team to onboard the technology. There are initial steps that must be taken which prepare the technology for onboarding in IEP. In addition to the process outlined below, the following diagram assumes that standard IRS processes for procurement (i.e. UWRs) have been completed. The new IEP technology steps are outlined in Figure 4.

Figure 4 – New Technology Onboarding Process

The initial step for onboarding a new technology is for the IRS application owners and ETI to send a New Technology Request to the Technology Review Board (TRB) with the High Level Business Requirements.

The output of this phase is the TRB review decision and an estimate for the Analysis phase for the new technology.

In the Analysis phase, application owners work with ETI and IEP team to analyze the new technology in order to prepare for IEP deployment. An approved estimate for the analysis phase, work request, and VM capacity request are the inputs for this phase. Throughout the analysis phase, application teams and supporting IEP teams capture technology requirements and configuration parameters. The description of the outputs for this phase are provided below:

VM Capacity Request Approval – If capacity is needed for the new technology then a ticket requesting capacity should be submitted and approved by the Capacity Working Group.

Detailed Technical Requirements – The high level business requirements are translated into detailed requirements for the new technology.

IEP Requirements for New Technology – Updated IEP requirements to support the new technology.

New IEP DD – The Word document variant of the IEP DD which includes the IEP deployment parameters for the IEP team.

161616

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

New Design Document – The technical design and specifications for the new technology.

Updated IEP CD – The necessary sections of the IEP CD (this document) are updated.

Analysis TRB Review – Review the analysis phase effort as part of TRB.

Estimate for Implementation Phase (VROM) – Provide an estimate for the implementation and deployment phase of work.

The final phase is the new technology implementation and deployment. The input for this phase includes an approved TRB implementation and deployment decision as well as an approved estimate and work request. Application owners and supporting IEP teams work together to implement and deploy the new technology to IEP based on the output parameters and documentation developed during the analysis phase.

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

6.0 LEGACY TECHNOLOGIES

This section describes technologies which IEP no longer supports for new applications.

6.1 WEBSPHERE APPLICATION SERVER (WAS)

WebSphere Application Server (WAS) is a software product that performs the role of a web application server. More specifically, it is a software framework and middleware that hosts Java based web applications. WAS is similar in nature to Oracle WebLogic, Apache Tomcat, RedHat JBoss, etc. Support for WAS is only for legacy applications such as PeopleSoft e-File Application. While the IEP team does maintain patching and management for WAS applications, most of the configuration is done manually and outside of the controlled IEP deployment process. The only part of the controlled IEP deployment process that is followed is the placement of the new/updated JVM files on the shared storage location, also referred to as the Jump Server throughout this document.

None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

7.0 IRS ENVIRONMENT CONFIGURATIONS

This section describes the different CPE within IEP. These include SBX, DEV, SIT, EITE, FIT, PETE, and

PROD.

Each IRS environment configuration is comprised of specific and variable infrastructure. For example, Infinispan is used for session persistence in clustered environments, or environments with multiple JBoss nodes, such as EITE, FIT, PETE, and PROD. To utilize this service, application owners can enable session persistency in application.xml. For more information on the XML configurations, please see Section 8.0 IEP Deployment Definition (IEP DD) – XML Only.

7.1 ITE ENVIRONMENTS

7.1.1 Sandbox (SBX)

The SBX environment is used by the development team for proof of concept and for the testing of new application functionality. Application owners are granted developer access to the virtual machines and applications are self-deployed (i.e., there is no IEP bundle). Component specific changes can be modified and tested by the application owners and applications are granted one (1) VM for each application server and web server.

7.1.2 DEV

The DEV environment is used by the development team for software development as well as unit testing and functional testing. Application owners are granted developer access to the virtual machines and applications are self-deployed (i.e., there is no IEP bundle). Component specific changes can be modified and tested by the application owners and applications are granted one (1) VM for each application server and web server.

7.1.3 SIT

The SIT environment is used by the testing teams for system and integration testing of the applications.

SIT is the first environment where applications use the IEP controlled deployment process. While the IEP DD allows for VM count, applications are granted one (1) VM for each application server and web server.

Sanitized data or generated data is used by the testers.

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

7.1.4 EITE

The EITE environment is used by the testing teams for integration testing of the applications. Applications are deployed to EITE using the IEP bundle controlled deployment process. While the IEP DD allows for VM count, applications are granted up to two (2) VMs for each application server and web server.

Sanitized data or generated data is used by the testers. EITE is the only environment required before an application can be deployed to Production. EITE mimics the Production enterprise components but does not have the same size and load.

7.1.5 FIT

FIT is used by applications for final integration testing. Application can test backend connections . FIT is the only lower environment that uses “live” data for testing. While the IEP DD allows for VM count, applications are granted up to two (2) VMs for each application server and web server. Applications are deployed to FIT using the IEP bundle controlled deployment process.

7.1.6 PETE

PETE mimics the Production environment. The PETE environment is used by the performance testing teams for performance testing of the applications. Applications are deployed to PETE using the IEP bundle controlled deployment process. The PETE environment has external access for the applications to connect and drive load to the environment. Sanitized data or generated data is used by the testers. VMs in PETE are granted based on a predetermined sizing for each application.

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

7.2 PRODUCTION

The Production environment exists in both data centers ( ) and is load balanced for each application. Applications receive a predetermined number of VMs in both data centers which allows for failover.

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

8.0 IEP DEPLOYMENT DEFINITION (IEP DD) – XML ONLY

The IEP configuration bundle must have all necessary XML files following their appropriate schemas for the bundle to be valid. The following section is the XML Schemas guide for creating the IEP DD XML variant. The subsections define all possible XML files expected as well as the required and optional data for them. The XML guide is presented in sequence according to the schemas. Please follow the same order as specified with the elements and their respective sub-elements. Also, please note that regardless of application style, application owners are responsible for defining any optional component XMLs and elements necessary for the application to function properly. This section is not applicable to the IEP DD Word variant.

Table 10 below distinguishes the required and optional XML files for the two application styles:

Application To Application (A2A) Web Application

Required - application.xml

- environment.xml

- applicationserver.xml

- application.xml

- environment.xml

- applicationserver.xml

- webserver.xml

Optional - database.xml

- gateway.xml

- sftp.xml

- database.xml

*Please note that messaging.xml is defined in the IEP DD, but it is not currently used.

Table 10. Required and Optional XML files based on Application Style

8.1 ENVIRONMENT.XML

IEP configuration bundles must define an environment.xml describing the targeted environment for application deployment. Application owners are required to have a directory of the same name for the environment listed in this file. In addition, the environment should be the same as that requested in the Application Migration Request ticket. A reference to iep-cd-core and a namespace for this XML schema instance must be included. For the full XML schema guide containing both required and optional data, please see Section 14.3 Additional XML Configurations in the Appendix.

Schema: iep-cd-environment.xsd

The following is required for this XML file:

<iepApplicationEnvironments> o Describes the document as the environment.xml. It has two required string attributes: "irtt" and "cr". The "irtt" is the Installation Request Tracking Ticket, whereas the "cr" is the Change Request.

o Required sub-element: <environment>

<environment> o Describes the targeted environment for deployment. The xsi:type possible values include: devEnvironment, eiteEnvironment, peteEnvironment, sbxEnvironment, sitEnvironment, fitEnvironment, prodEnvironment.

o Note: devEnvironment and sbxEnvironment do not use the IEP bundle.

o Required sub-elements: <characteristics>, <name>

<characteristics>

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

o Describes the environment settings such as transactions, sessions, bandwidth, and data storage. This can be empty.

<name> (String) o Describes the shortened environment name. This can be left blank and the default value varies depending on the environment type.

8.2 APPLICATION.XML

IEP configuration bundles must define an application.xml describing the application style and components in which the application uses. For each component listed in application.xml, application owners must define it in a separate XML file under the appropriate component directory. A reference to iep-cd-core and a namespace for this XML schema instance must be included. For the full XML schema guide containing both required and optional data, please see Section 14.3 Additional XML Configurations in the Appendix.

Schema: iep-cd-application.xsd

The following is required for this XML file:

<iepDeployableApplication> o Describes the document as the application.xml. It has two required string attributes: "irtt" and "amr". The “irtt" is the Installation Request Tracking Ticket, whereas the "amr" is the Application Migration Ticket.

o Required sub-element: <application>

<application> o Describes the application style. The xsi:type possible values include:

applicationToApplicationStyle, hybridApplicationToApplicationStyle, webApplicationStyle.

o Note: hybridApplicationToApplicationStyle allows support of both applicationToApplicationStyle type and webApplicationStyle type. The only current application utilizing this style is FATCA.

o Required sub-elements: <name>, <publicURL>, <webServer> for Web and Hybrid Application Style only, <applicationServer>, and <integration>

<name> (String) o Defines the application name.

<publicURL> o Defines the default welcoming or landing page for the application. It has a required string attribute "hostHint". The "hostHint" is used to assist the VIP/Proxy Server by specifying if the URL uses login authentication, secondary/secure authentication, or alternative stream. The values for the three choices are: la, sa, and alt.

<webServer> o This element is to set up a web server for the application.

o Required sub-elements: <sizing> and <sessions> o The <sizing> describes the number of web servers needed for application with the required integer sub-element <min> being the minimum of servers needed. Note: <sizing> is currently not used for deployment.

o The <sessions> describes the web server session. Application owners have a choice of enabling or disabling sticky session for the web server.

The default session is sticky.

<applicationServer> o This element is to set up an application server for the application.

o Required sub-elements: <sizing> and <sessions>

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

o The <sizing> describes the number of application servers needed for application with the required sub-element <min> being the minimum of servers needed. Note: <sizing> is currently not used for deployment.

o The <sessions> describes the application server session. Application owners have a choice of enabling or disabling session attributes: sticky, persistent, and managed. All attributes are default to true.

<integration> o Describes application integration. The xsi:type possible values include:

joltBasedIntegration, messageBasedIntegration, serviceBasedIntegration.

o The sub-element available for all three integrations but only required for joltBasedIntegration and ServiceBasedIntegration: <remoteConnection> o The <remoteConnection> has three optional string attributes "type", "direction", and "protocol". The attribute "type" values are: udp, tcp, both.

The attribute "direction" values are: in, out, both. The attribute "protocol" values are: jolt for joltBasedIntegration, mq and sftp for messageBasedIntegration, http and https for serviceBasedIntegration. The required sub-elements include: <host> (String), <port> (Integer).

8.3 APPLICATIONSERVER.XML

Applications utilizing an application server must define an applicationserver.xml file. A reference to iep-cd-core, iep-cd-component, iep-cd-component-app-jboss and a namespace for this XML schema instance must be included. For the full XML schema guide containing both required and optional data, please see Section 14.3 Additional XML Configurations in the Appendix.

Schema: iep-cd-component-app-jboss.xsd

The following is required for this XML file:

<iepDeployableComponent> o Describes the document as the applicationserver.xml.

o Required sub-element: <component>

<component> o Describes the component as an application server of xsi:type "jboss". It has a required string attribute "version" to specify the version of the JBoss server.

The following is only required for this XML file only if application uses JDK 1.8:

< comp:jvm> o Describes the version of Oracle JDK o If left blank the version will default to JDK 1.6 (example: <comp:jvm>) o If specified JDK version 1.8 will be deployed (example: <comp:jvm version=”openjdk1.8”>

8.4 WEBSERVER.XML

Applications utilizing a web server must define a webserver.xml file. A reference to iep-cd-core, iep-cd-component, iep-cd-component-web-apache, iep-cd-pluggin-security-siteminder, and a namespace for this XML schema instance must be included. For the full XML schema guide containing both required and optional data, please see Section 14.3 Additional XML Configurations in the Appendix.

Schema: iep-cd-component-web-apache.xsd

Note: The SiteMinder is optional in the schema definition for the webserver.xml but is needed for certain applications to function properly.

None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

The following is required for this XML file:

<iepDeployableComponent> o Describes the document as the webserver.xml.

o Required sub-element: <component>

<component> o Describes the component as a web server of xsi:type "apacheHTTPD". It has a required string attribute "version" to specify the version of the Apache server.

o Required sub-element: <virtualHost>

<virtualHost> o This element is to set up a virtual host for the Apache server. Note: IEP only processes one virtual host at this time.

o Required sub-element: <module> o The <module> describes specific modules needed for the web server. If one of the available modules is not defined here, it will not be configured.

Not including a module here means that the application has obtained any necessary waivers. The xsi:type possible values include: mod_evasive, mod_proxy, mod_rewrite, mod_security. The required sub-elements according to type: <proxy> for mod_proxy, <rewrite> for mod_rewrite. The <proxy> describes the proxy modules which must be configured in the proxy.conf file located in /etc/httpd/conf.d directory. It has two optional attributes "reverse" and "cookie" in which both default to false. In addition, it has two required sub-elements <path> (String) and <url>. The <rewrite> describes the URL’s link appearance. It has two required sub-elements:

<map>, <rule>. The <map> describes the mapping to a URL reference using the required string sub-element <path>. The <rule> describes how to modify the URL by three required string sub-elements <pattern>, <subsitiution>, and <flag>.

8.5 MESSAGING.XML

Applications utilizing a messaging server must define a messaging.xml file. A reference to iep-cd-core, iep-cd-component, iep-cd-component-messaging-websphere, and a namespace for this XML schema instance must be included. For the full XML schema guide containing both required and optional data, please see Section 14.3 Additional XML Configurations in the Appendix.

Schema: iep-cd-component-messaging-websphere.xsd

Note: This file is currently not used and can be left blank.

8.6 DATABASE.XML

Applications utilizing a database server must define a database.xml file. A reference to iep-cd-core, iep-cd-component, iep-cd-component-database-oracle, and a namespace for this XML schema instance must be included. For the full XML schema guide containing both required and optional data, please see Section 14.3 Additional XML Configurations in the Appendix.

Schema: iep-cd-component-database-oracle.xsd

The following is required for this XML file:

<iepDeployableComponent> o Describes the document as the database.xml.

o Required sub-element: <component>

<component>

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

o Describes the component as a database of xsi:type "oracleDatabase". It has a required string attribute "version" to specify the version of the Oracle database.

o Required sub-element: <name>

<name> (String) o Database name

8.7 GATEWAY.XML

Applications utilizing a gateway server must define a gateway.xml file. A reference to iep-cd-core, iep-cd-component, iep-cd-component-gateway-forum, iep-cd-pluggin-security-siteminder, and a namespace for this XML schema instance must be included. For the full XML schema guide containing both required and optional data, please see Section 14.3 Additional XML Configurations in the Appendix.

Schema: iep-cd-gateway-forum.xsd

The following is required for this XML file:

<iepDeployableComponent> o Describes the document as the gateway.xml.

o Required sub-element: <component>

<component> o Describes the component as a gateway server of xsi:type "forumSentry". It has a required string attribute "version" to specify the version of the Forum Sentry.

o Required sub-element: <security>, <listeners>

<security> o This element is to set up the security measure for the gateway.

o Required sub-elements: <pki>, <siteminder> o The <pki> is the public key infrastructure with a required sub-element

<crl> which is a certificate revocation list. The <crl> has a required sub-element <connection> to describe the revoked users and their connections by a required sub-elements <host> (String), <port> (Integer), and <path>(String).

o The <siteminder> element is to set up the SiteMinder for the gateway. It has three required sub-elements: <connection>, <authentication>, <hostConfigurationObjectName>. Application owners need to set the <connection> with the required sub-elements <host> (String) and <port> (Integer). These elements are global to an environment. The method of <authentication> for SiteMinder of xsi:type includes: sharedSecret and usernamePassword. The required string sub-elements by type: <secret> for sharedSecret, <username> and <password> for usernamePassword.

Lastly, application owners also need to define the <hostConfigurationObjectName> (String) to hold the configurations for SiteMinder trusted hosts.

<listeners> o This element is to set up a listener for the gateway. It has an optional attribute "tls" to enable or disable the transport layer security. The attribute is default to false. All three string sub-elements <name>, <description>, and <port> are required to describe the listener’s property.

None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

Sticky Note Unmarked set by T4GLB

T4GLB

Sticky Note None set by T4GLB

T4GLB

Sticky Note MigrationNone set by T4GLB

T4GLB

8.8 SFTP.XML

Applications utilizing Secure File Transfer Protocol must define a sftp.xml file. A reference to iep-cd-core, iep-cd-component, iep-cd-component-sftp-tectia, and a namespace for this XML schema instance must be included. For the full XML schema guide containing both required and optional data, please see Section 14.3 Additional XML Configurations in the Appendix.

Schema: iep-cd-sftp-tectia.xsd

The following is the expected content for this XML…