Informatica Cloud Real Time Service Technology and

Security Overview
Technical Note
Dated: 1 June 2014

Contents
References .....................................................................................................................................................................2
Overview ........................................................................................................................................................................2
Technology Overview .....................................................................................................................................................2
Platform Components .................................................................................................................................................2
Informatica Process Developer...................................................................................................................................4
Interfaces and Protocols ................................................................................................................................................4
Broad Standards Support ...............................................................................................................................................5
Implementation Standards ..........................................................................................................................................5
Security and Authentication ........................................................................................................................................5
WS-Security Standards ...........................................................................................................................................5
SAML 1.1 ................................................................................................................................................................ 6
Supported Tokens, Algorithms & Identifiers ............................................................................................................6
Policy-Based............................................................................................................................................................... 6
WS-Security Policy Assertions ................................................................................................................................ 7
Informatica Cloud Secure Agent ....................................................................................................................................9
Informatica Cloud Secure Agent with Embedded Process Engine ............................................................................... 10
Cloud and On-Premise Service Interaction .................................................................................................................. 10
Cloud Process Server ............................................................................................................................................... 10
User Management, Authentication and Authorization .................................................................................................. 12
Console and Deployment Access to ICRT by Customers ............................................................................................ 13
ICRT Screenflow Integration with Salesforce ............................................................................................................... 14
Transport level Security ............................................................................................................................................... 16

Page 1 of 16
References
[1] Informatica Cloud architecture and security, Mercury Consulting, 2011

Overview
Informatica Cloud Real Time (ICRT), a component of the Informatica Cloud Service (ICS) provides the means for
customers to expose Business Services at service endpoints accessible via the Cloud as SOAP or REST (XML or
JSON) services.

This technical note describes the components of the ICRT architecture including the ICRT Cloud Process Engine, the
ICS Secure Agent Embedded Process Engine, and the technologies and capabilities of this platform.

Technology Overview
The Informatica Cloud Real Time (ICRT) platform is built on Informaticas ActiveVOS business process management
system. The Informatica ActiveVOS technology used by ICRT and Informatica Business Process Manager (IBPM)
makes it possible to use service-oriented standards to integrate data services, business services and processes into
a unified whole. Informatica Cloud Read Time leverages this platform in the Cloud or either embedded with the ICS
secure agent or stand-alone.

Platform Components
Informatica Process Server is the runtime environment that scales to meet the needs of the Cloud and enterprises of
any size. Process Server provides a number of sophisticated features to ensure business continuity. Process servers
can be deployed as a cluster in failover mode to ensure high-availability.

Informatica Process Server is ideal for service providers such as Informatica Cloud who wish to securely partition
Process Server into discrete groups to reduce management complexity and increase hardware utilization of large
installations. With a multi-tenant architecture, each client organization (or tenant) shares hardware and software
resources, but has their own private and secure access to Informatica Process Server functionality. Informatica
Clouds Real Time service employs these capabilities.

The Informatica Process Console provides a central location from which to manage and configure the process engine
and its deployed resources whether in the Cloud or on the ICS Secure Agents embedded process engine. The
Process Console also provides mechanisms to perform process scheduling and deploy new business process
archives.

Page 2 of 16
The Process Console provides customers with the means to perform root cause analysis in the event of process
exceptions, and respond with corrective actions. Process rewind a process exception management feature - offers
the ability to visually-rewind a process to a specific activity and redo the work without having to invoke any of the
built-in compensation logic, giving organizations unprecedented flexibility in managing running, in-flight processes.

Process versioning and migration permits the deployment of multiple versions of a process without needing to
terminate existing running instances if this is desired. Otherwise, pre-existing processes can be terminated or
migrated to the latest version.

Informatica Process Server has been built to support non-stop operation of composite business applications. With
Process Server you can:

Configure and enforce runtime behavior of an orchestration using standard policies

Perform server-based runtime message correlation and handle service communication retries to free the
developer from runtime concerns
Perform endpoint management to make it easy to deploy an orchestration from one environment to another,
or deal with a change in topology
Suspend a running process using process exception management capabilities built into the Process
Console to handle bad data which would otherwise have unnecessarily failed a transaction, and correct the
problem via remote debugging
Deploy a new version of a process and control when it is activated and if running processes need to be
automatically migrated to the new version

Informaticas ICRT and IBPM are ideally suited for service-oriented and event-driven integration when you need:

Long running transactions that maintain state

Short-running or transactional system integration processes requiring integration sequences, different
execution paths or composite transactions
Rich semantics for parallel execution
Rich event, fault, and error handling, and catch exceptions and control how and what to compensate through
automated compensation to roll back a transaction if all required steps are not completed successfully
Timers and event triggers and associated event handlers
Orchestrate transactions that spawn across different companies, business units, different products or
services in order to realize horizontal business / integration processes e.g. order-to-cash
Visibility into what is going on in the business
Page 3 of 16
 o Know what is happening and what is not happening
o Report on processes that are in progress, not just individual requests
o Manage escalations, timeouts, schedules, etc.

Informatica Process Developer

Informatica Process Developer is a rich productivity tool that incorporates the BPMN, BPEL and BPEL4People
standards, and optimized and highly usable tooling that make easy it to create orchestrations quickly. And because
those BPM applications are based on standards, enterprises' business logic is freed from proprietary workflow
engines. Process Developer helps you rapidly create standards-based applications facilitating the following:

It makes it easy for architects, business analysts and developers to work collaboratively and approachable
for business end users with whom they need to interact. It achieves this by offering the latest BPMN notation
for modeling and implementing business processes.
It exposes the full power of BPMN enabling designers to control every aspect of the diagram. Process
Developer BPMN designer promotes modeling best practices while being significantly easier to use.
Structured activities can be dragged and dropped from the Process Developer palette onto the canvas,
significantly reducing the amount of time required to model a BPEL process.
When used on premise, it generates executable BPEL processes that orchestrate human activity and
services using a combination of BPEL and the BPEL Extensions for People (BPEL4People). Human activity
is not currently available as an ICRT service feature.
It allows users to perform service discovery and provides the ability to manage service references to help
users deal with changes of service definitions.
It orchestrates services defined using WSDL interfaces. Or, it allows designers to start with XML schema or
XML fragments if this is all that is available to start with.
It incorporates non-Web service-based assets through a Web Services Definition Language (WSDL)
interface faade enabling designers to leverage existing JMS, REST (XML or JSON), and Java based
assets. As such these are used as if they were services, each having a distinctive binding.
It simulates processes locally or using remote debugging, allowing designer to save simulations and test
data, which can then be used to generate unit tests and test suites to perform scenario testing.
Use wizard-based deployment to deploy new orchestrations and updates to the ICRT Cloud Process Server
or the Secure Agents Embedded Process Engine.

Interfaces and Protocols

Informatica Cloud Real Time (ICRT) and Informatica Business Process Manager (IBPM) deliver the ability to integrate
people, processes and services by leveraging standards. Services, be they exposed as SOAP, REST, JMS and Java
clases are exposed to developers at design time as a Web service thereby eliminating the binding details to the
underlying technology that implements these services.

Informaticas services platform provides rich support for SOA interfaces and protocols. This is a natural result of
supporting standards at its core. BPEL is layered on top of and extends the WSDL definition model. Thus WSDL
defines the specific service interfaces that are used to interact with a number of implementation types (e.g. Web
services, REST, JSON, JMS, and Java). BPEL defines how WSDL interfaces are composed to achieve a business
goal and further specifies extensions to WSDL in support of long-running asynchronous conversations.

As a core SOA standard, BPEL utilizes in turn other SOA related technologies and standards XML Schema,
XPATH, JavaScript, XSLT and WS-Addressing. BPEL consumes and produces WSDL defined services. It therefore
fits naturally in a SOAP enabled infrastructure. REST with XML or JSON binding are also built in.

Page 4 of 16
Broad Standards Support
Informatica Cloud Real Time, the ICS Secure Agents embedded Process Engine and Informatica Business Process
Manager (IBPM) support a broad set of standards summarized here.

Implementation Standards
Process Modeling Notation
OMG BPMN 2.0

Process Implementation
OASIS WS-BPEL 2.0 Standard (also supports BPEL 1.1)
OASIS Contributed WS-Human Task 1.0 Specification
OASIS Contributed BPEL Extensions for People 1.0 Specification

Expression Languages
XPATH, XQUERY, XSLT, JavaScript

Protocols
REST (XML or JSON bindings)
SOAP 1.1/1.2 over HTTP/HTTPS
SOAP/Plain XML over JMS
WS-Reliable Messaging 1.0
o WS-ReliableMessaging (February 2005)
xmlns:wsrm = http://schemas.xmlsoap.org/ws/2005/02/rm
o WS-ReliableMessaging Policy (February 2005)
xmlns:wsrmp= http://schemas.xmlsoap.org/ws/2005/02/rm/policy

Governance
WS-Policy

Interface and Definitions

WSDL 1.1
XML Schema 1.0
WS-Addressing
o WS-Addressing (March 2003)
xmlns:wsa=http://schemas.xmlsoap.org/ws/2003/03/addressing
o WS-Addressing (March 2004)
xmlns:wsa=http://schemas.xmlsoap.org/ws/2003/03/addressing
o WS-Addressing (August 2004)
xmlns:wsa=http://schemas.xmlsoap.org/ws/2004/08/addressing
o WS-Addressing 1.0
wsa=http://www.w3.org/2005/08/addressing

Security and Authentication

WS-Security
SAML 1.1

WS-I Basic Profile

WS-I Basic Profile V1.1

WS-I Basic Security Profile V1.0

Security and Authentication

WS-Security Standards
ICRT/IBPM supports the following WS-Security V1.0 (WSSE) profiles and standards:

Page 5 of 16
 OASIS: Username Token Profile V1.0 (Jan 2004)
OASIS: X.509 Token Profile V1.0 (Jan 2004)
OASIS: SAML Token Profile V1.0 (Jan 2004)
W3C Recommendation: Canonical XML Version 1.0 (March 2002)
W3C Working Draft: XML Encryption Syntax and Processing (March 2002)
W3C Recommendation: XML Signature Syntax and Processing (February 2002

SAML 1.1
ICRT/IBPM supports SAML 1.1 and gives users the option to use a declarative approach within the deployment
descriptors to specify how to generate and consume messages containing SAML Assertions. ICRT and IBPM
conforms to:

SAML1.1: SOAP over HTTP binding specified in the oasis-sstc-saml-conform-1.1.pdf document produced by
the OASIS Security Technical Committee.
SAML 1.1 section of the WS-I Basic Security Profile 1.1

ICRT/IBPM supports:

Participation as a relying party in a trust relationship based on SAML

Ability to produce, validate, and verify SAML 1.1 assertions with both holder-of-key or sender-vouches
confirmation methods

Supported Tokens, Algorithms & Identifiers

The following are supported

Supported Token Types

o Username Token
o SAML Token 1.1
o X.509 Token
Direct Binary Reference (send & receive) Preferred method, used where possible.
Issuer Serial - (send & receive) Preferred external reference method, if direct not
possible.
X509 Identifier (receive only)
Subject Key Identifier (receive only)
Embedded Token References - (receive only)
Symmetric Data Encryption Algorithms:
o http://www.w3.org/2001/04/xmlenc#tripledes-cbc (send & receive)
o http://www.w3.org/2001/04/xmlenc#aes128-cbc (receive only)
o http://www.w3.org/2001/04/xmlenc#aes256-cbc (receive only)
Encryption Key Transport Algorithms:
o http://www.w3.org/2001/04/xmlenc#rsa-1_5
(send & receive)
o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p (receive only)
Signature Digest Algorithm:
o http://www.w3.org/2000/09/xmldsig#sha1
(send & receive)
Signature Algorithm:
o http://www.w3.org/2000/09/xmldsig#rsa-sha1
(send & receive)
Canonical XML Transform Algorithm:
o http://www.w3.org/2001/10/xml-exc-c14n#
(send & receive)

Policy-Based
ICRT/IBPM provides important process governance features. This enables continuous deployment/evolution of
business processes and incremental development:

Supports continuous operation

Page 6 of 16
 o Support dynamic deployment of BPEL and SOA artifacts
o Support version management at multiple granular levels -policy can be specified at process level
Supports exception management
o Process may be suspended on uncaught fault for examination and recovery
Process persistence policy can be specified at multiple granular level
Supports policy assertions for partner interaction
o Supports WS-Policy assertions at multiple granular levels
o Support Web Service invocation retry policy (policy can be programmatically asserted)
o Support setting JMS messaging properties through WS-Policy assertions
Policy-based configuration:
o Supports a rich set of configuration options through WS-Policy assertions.
o Support for WS-Security Authentication, Encryption & Signature; SAML 1.1; WS-Reliable
Exchange guaranteed message delivery; and retry quality of service policy
o Runtime configuration through policy is declared and not coded
WS-Policy & WS-Policy Attachment V1.2 (March 2006)
o ICRT/IBPM uses the WS-Policy and WS-Policy Attachment v1.2 framework and binding to WSDL
1.1

WS-Security Policy Assertions

ICRT/IBPM provides support for built-in and user-defined policy assertions. ICRT and IBPM use WS-Policy attached
to endpoints and services to specify additional quality of service (QoS) attributes that apply when sending or receiving
messages, including any WS-Security related items. These can be applied to:

myRole where assertions control server side behavior when receiving web service requests and sending
responses.
partnerRole where assertions control the client side when sending requests to partners and receiving
response messages.

The supported policy assertions are described in the following table:

Policy Description

WS-Security Policy Credentials required for access to a service

Assertions:

Authentication

Encryption Describes the parts of a SOAP message to encrypt

Signature Describes the parts of a SOAP message to sign with an XML Signature, using an X.509
Certificate token

Timestamp Adds a <Timestamp> element to the SOAP header of a message

Other Policy Describes when and how many times to retry an invoked service that does not reply
Assertions:

Retry

User-Defined Policy Placeholder for a custom solution you provide for handling messages from a particular
Assertion service provider. Place where you can add WS-Policy Reference.

Engine-Managed A My Role policy assertion that directs the Process Server to use WS-Addressing to
Correlation transmit replyTo endpoint references during transmissions to the Partner Role partner link

WS-Reliable Specifies that a partner link participates in an industry-standard protocol that supports

Page 7 of 16
Messaging guaranteed delivery of messages

JMS Delivery Options For details, see Using a Java Messaging Service Invoke Handler

HTTP Transport Used for REST-based invocations

REST Enabled Used for REST-based invocations

SAML The Security Assertions Markup Language (SAML) is an OASIS standard that enables
loosely coupled and federated identity integration.

Message Validation Provide fine-grained validation of WSDL messages for a partner link to enable faster
processing

Web Service Timeout Set an amount of time to wait for a specific Web service to time out

Invoke Recovery Select whether to suspend a process with a pending invoke when the recovers from a
failed server

Send WS-Addressing Explicitly add addressing to invokes

Headers

WSDL Binding Applicable for a my role partnerlink to refer to a WSDL binding instead of RPC or
Reference Document

Suppress xsi:type A workaround for suppressing schema validation in SOAP messages, useful for dealing
with legacy services that cannot handle xsi:type attributes

Page 8 of 16
Informatica Cloud Secure Agent
Please refer to [1] for a security overview of the Informatica Cloud Service and its Secure Agent. The Secure Agent is

comprised of the following components depicted here.

These components carry out the following tasks:

Agent Manager Java UI client used to manage (start, stop, proxy config) secure agent
Agent Core resilient ever-running single-threaded process checking for upgrades and responsible for
managing Tomcat process
Channel Client provides secure, resilient communication to ICS channel servers
Catalog database DDL support (create/update table) for data replication service
Metadata used to fetch metadata for files, databases, ODBC endpoints, ICS toolkit endpoints (NetSuite,
Eloqua, )
rDTM Data transformations

Communication between the Secure Agent and Informatica Cloud is carried out through the Secure Channel that the
agent initiates. This is depicted here as an example of how the SA facilitates data integration between a local
database and Salesforce CRM and/or Force.com.

Page 9 of 16
Informatica Cloud Secure Agent with Embedded Process
Engine
Customer that license Informatica Clouds Real Time service offering are provided with the ability to deploy processes
to ICRT in the Cloud and on Premise to a Secure Agents Embedded Process Engine. The Secure Agent is the same
used for data integration than that used for service integration. The only difference is the addition of the Process

Engine package that gets downloaded automatically by the secure agent when ICRT is licensed as depicted here.

Cloud and On-Premise Service Interaction

Cloud Process Server
Incoming service requests to a cloud-deployed process such as depicted here can originate from a cloud consumer
over SOAP or REST either to initiate the process, perform a callback, or in the form of a subsequent event. Invoking
services in the Cloud (e.g. Salesforce or NetSuite) employs the security mechanism offered by the service called.
Invoking services on premise is performed via an ICS secured channel between a process instance running in ICRT
and the process engine running in an ICS Secure Agent. This is depicted below by the connection from the Lookup
Part Price service invoke to the Parts Inventory process deployed to the Secure Agent. Calls from ICRT to the
Secure Agent can only be carried out by ICRT through a mutually authenticated session.

Page 10 of 16
REST services exposed by customers are secured using HTTPS Basic-Auth. SOAP services exposed by customers
are secured using Basic-Auth at the HTTPS layer. Additional forms of authentication are available via WS-Security in
the form of WSSE tokens. The following token formats are supported: username token, X.509 token and SAML
token.

Page 11 of 16
Based on the process definition deployed, the ICRT Cloud Process Server receives and invokes service consumers
and providers deployed to the cloud. It can also receive service requests from on premise service consumers and
response synchronously to them (via the HTTPS connection established by the service consumer). For asynchronous
callbacks though these need to be made exclusively via the Secure Agents Embedded Process Engine, as is the
case for invokes to any on premise services as depicted here. The reason for this is that the Agents secure channel
is the only way to reach on premise services, something that is achieved exclusively via the Secure Agents

Embedded Process Engine.

In order to provide for the Embedded Process Engine with this ability, process definitions are deployed to the secure
agent in the same manner than they are in the Cloud with one exception: you specifically select at deployment time
which agent to deploy the service definitions.

Cloud to Embedded Process Engine communication is performed via the same Secure Agent Channel created by the
ICS Secure Agent when it starts up. As previously stated, calls from ICRT to the Secure Agent can only be carried
out by ICRT through a mutually authenticated session.

User Management, Authentication and Authorization

The user accounts and groups used for this purpose are held by the ICS user and group store. Customers create and
manage the accounts and groups used to authenticate applications calling their services. ICRT authenticates access
to services but does not actually hold credentials, a function of the ICS user and group store.

Page 12 of 16
Console and Deployment Access to ICRT by Customers
Customers process administrators can deploy process definitions and manage process instances from the ICRT
console as depicted below. Process administrators log in as a tenant and are granted access to tenant specific data
and configuration information. Access to the console provides customers access to transient data flowing through the
system as a result of executing a process. This provides customers access to variable data (e.g. inputs and outputs
to the process, input/output to services calls) of running process instances and completed/faulted process instances.

Console access to deploy process definitions or access process instances are secured by an ICS username and
password that customers manage in the ICS user and group store.

Page 13 of 16
ICRT Screenflow Integration with Salesforce
Screenflow embedded within Salesforce is a feature of the ICRT product. Screenflow provides users with interactive
access to data within Salesforce or mobile devices as well as help users carry out their tasks in Salesforce. This
offering is also known as Informatica Cloud Extend (ICE).

Authentication of ICE users is carried out by Salesforce and an SSO session is established and maintained using
Salesforce session tokens. ICE does not offer the means for a customer to authenticate to it, rather authentication
and authorization is performed by Salesforce. The session tokens obtained from Salesforce are used in SOAP API
calls. SSO and SOAP API calls depicted below are secured via certificate-based mutual authentication (client &
server) over an HTTPS session using TLS between Salesforce and the Cloud Extend Service. This is a form of multi-
factor authentication.

The Informatica Cloud Extend (ICE) Service integrates with Salesforce via Salesforces Enterprise WSDL-based

SFDC

iFrame-based Integration supported by SDFC

objects, Force.com pages and corresponding AEI-
provided supporting classes and components

Rendering of HMTL-
based screenflows over
HTTPS

Cloud Extends Hosted ActiveVOS Server

(includes ActiveVOS Engine and
Salesforce SOAP API Calls from the
ActiveVOS Central Webapp)
ActiveVOS Engine to update
Salesforce objects and create new
objects (e.g. tasks, events)

SSO interaction between SFDC and Cloud Extends ActiveVOS Server

1. Salesforce user loads screenflow via iFrame on the page
2. A request is made to ActiveVOS. The request includes a generated SSO token
containing URL parameters
3. ActiveVOSs SSO filter intercepts the request and invokes a service to validated the
token
4. The response from the Salesforce API being called (implemented as an Apex class)
determines if the user is valid or not.

If the response is valid, a session is established using the SFDC userid returned. This
information is used to perform over the SFDC SOAP APIs updates to SF objects
service as depicted here.

Informatica Cloud Extend is comprised of Salesforce objects, pages and corresponding supporting classes and
components. Salesforce sections within Salesforce objects (created by end user admins) are used to contain pages
served up by ICRTs (ActiveVOS) Process Server via iFrame integration with Salesforce. Screenflows managed by
Process Server are shown to the user. Web service calls that result from user interaction create and update
Salesforce record using the identity of the user running the screenflow. This is achieved via impersonation.

Page 14 of 16
Informatica Cloud Extend uses a combination of the Salesforce Session ID and a Cloud Extend SSO token that is
submitted from a Salesforce page component. The security token is generated in Salesforce using an Apex class.
The class implements the generation of a security token that can be used to sign in to Process Servers Central
component shown above.

This class:

1. Generates an encrypted security token using the OrganizationId, UserId and current date. The encrypted
token is submitted by a Sales Guide section component. SSO is handled by posting to the Process Server
Custom SSO Provider URL with the security token appended as a URL parameter.

2. The Custom SSO Provider service will use the token and make a call back in to SFDC and decrypt the token
using the AeVerifySalesforceUser class. If the token is valid the isValid field is set to true and the userName
and displayName fields are set.

The ICRTs Process Server component of the Cloud Extend service and the Custom Salesforce SSO Provider
implemented is depicted here.

Page 15 of 16
Transport level Security
The following ciphers are currently enabled exclusively for TLS usage. SSL is not allowed.

Cipher Suites (sorted by strength; the server has no preference)

TLS_RSA_WITH_RC4_128_MD5 (0x4) 128

TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256

Worldwide Headquarters, 2100 Seaport Blvd, Redwood City, CA 94063, USA Phone: 650.385.5000 Fax: 650.385.5500

Toll-free in the US: 1.800.653.3871 informatica.com linkedin.com/company/informatica twitter.com/InformaticaCorp

2014 Informatica Corporation. All rights reserved. Informatica and Put potential to work are trademarks or registered
trademarks of Informatica

Corporation in the United States and in jurisdictions throughout the world. All other company and product names may be trade
names or trademarks.

Page 16 of 16