Technical Data Sheet DirX Access V8.3 Web Access Management and Identity Federation

DirX Access is a comprehensive, cloud-ready, scalable, and highly available access management solution providing policy-based authentication, authorization and federation for Web applications and services. DirX Access delivers single sign-on, versatile authentication, SAML- and OAuth-based identity federation and proxying, just-in-time provisioning, entitlement management and policy enforcement for applications and services in the cloud or on-premise.

Your business technologists. Powering progress

Web Access Management and Identity Federation

Everything and everyone is always online, and securing access to applications provided either Protected Authentication Authorization Federation as on- and off-premise services or from the SAML, OAuth cloud has never been more important. Systems Businesses and government agencies are Web accelerating the formation of online partner- Entitlement Servers ships to respond quickly to potential revenue User Session Management Management Management HTTP opportunities, outsource non-core functions, XACML SOAP Application and deliver the widest variety of services to Servers their users. WS-* Web Policy Web Services To improve operational efficiency and respond Single Sign-On Management Security SAML Fine-grained WS-Trust, STS Web to user demand, they continue to put more and SSO policies Services more critical data and applications online for information sharing and self-service by con- sumers, mobile employees, channel partners Audit Delegated, Integration and and Role-Based Customization Applications and suppliers. Logging Administration Framework Cloud adoption has soared as it has proved to offer great economies of scale for many organi- zations by providing a lower-cost, flexible way to use applications and services. Figure 1: DirX Access Functionality Meanwhile, people have come to expect the online services they use to be always-available, users in each software as a service (SaaS) direc-  Supports regulatory compliance with audit on-demand one-stop shopping experiences tory. Partners also need to consider security functionality, both within and across security accessible through a single login and providing models for online user transactions that move domains. them with the same look and feel no matter collection and control of identity information what business they are transacting. With the away from online service providers and into the Authentication, Authorization and Audit – recent news of massive security breaches of hands of their users and assign the manage- Core Functionality for Access Management online service databases and the rise in phish- ment of this data to online identity providers. Authentication is the process of verifying the ing, spoofing, and other fraudulent online activi- identity of a user requesting a service or a ties, users are also beginning to worry that they Next Generation Web Access Management resource, while authorization is the process of are giving up too much of their critical identity with DirX Access verifying that an authenticated user has the information to too many Web sites. While users These challenges are driving the design and right to access a requested service or resource. may want to have a few different identities to deployment of new security models for Web Authentication and authorization answer the protect their privacy, creating and maintaining a access management (WAM). Identity federation questions "Who are you?" and "What are you one-to-one identity relationship with each online and secure Web services are joining authentica- entitled to do?". service provider is a tedious chore that can lead tion, authorization, audit, and Web SSO as es- to poor access credentials. Authentication and authorization address the sential capabilities for protecting Web resources real-time enforcement of enterprise security against unauthorized use in a flexible way. policies, while audit automatically records these Building a business-agile virtual enterprise using DirX Access is a comprehensive Web access transactions and stores these records securely on-premise applications and private and public management, Identity Federation, and Web for later compilation in reports to provide ana- cloud or software as service offerings involves Services Security solution protecting resources lytical insight and transparency in the identity numerous security challenges to provide end- against unauthorized use. DirX Access: and access management processes. to-end security. The emergence of cloud, mo- bile and social computing has heightened the  Provides for the consistent enforcement of The processes and technologies used to man- need for strengthened access controls to en- business security policies through external, age the users and their life cycles are referred sure compliance with organization authentica- centralized, policy-based authentication and to as identity management. The set of process- tion and authorization policies. Partners must authorization services. es and technologies to manage, deploy, enforce share or integrate their identity data, but they  Enhances Web user experience through local and audit access control policies across multiple must do it without overloading their IT admin- and federated single sign-on (SSO). enterprise applications, services, and systems is istration or inadvertently creating security holes.  Secures eGovernment and eBusiness initia- referred to as authorization or entitlement To maximize user satisfaction, they must pro- tives and provides seamless integration with management. vide for secure, seamless transactions between business and organizational partners through services offered by disparate sites in different identity federation. Authentication (Verifying security domains, and these transactions must  Protects Web services and applications with Who You Are) be completely auditable from beginning to end authentication and authorization services, to prove regulatory compliance. To improve the both on the premises and in the cloud. With DirX Access, authentication is provided as an external, central service that supports a user experience and ease the user login bur- Provides just-in-time provisioning to automat-  variety of well-known authentication methods, den, partners must offer single sign-on (SSO) ically create user accounts. capabilities to applications and services hosted such as passwords, X.509 certificates, Inte-  Decouples security management such as internally or in the cloud. They must also pro- grated Windows Authentication, smart cards, authentication and authorization from appli- vide rapid onboarding of new users to cloud HTML forms, one-time-password (OTP) tokens, cation logic and ensures consistent, fine- services to avoid the daunting task of manually biometrics and callback/out-of-band authentica- grained entitlement management across mul- and individually provisioning and managing tion. Administrators can apply the method that tiple applications and services. best matches the security requirements of

1 DirX Access V8.3 each individual application or resource without Enrich request/response rewriting or even touching the application. HTTP/SOAP/other Protected PEP Decoupling authentication from the application Resource or resource allows the authentication service to scale easily – administrators can add new au- Client Client Security subjects e.g. application thentication methods without affecting the SSO Service SOAP applications that depend on the service. JGroups SSO SSO engine Web service Centralized authentication services also enable Clustered SSO. Users present their login credentials once, DirX Access servers Invoke and are then allowed to access all applications Authentication JAAS and resources within the enterprise security Service domain for which they are authorized without LoginModules having to re-authenticate/log in again. Query/ update (authn-related metadata in accounts) Client Finally, the DirX Access central authentication e.g. application service allows authentication management to User Service HTTP LDAP Provisioning SOAP be concentrated in one configurable compo- client Web service nent. Because an external, central service by- LDAP passes the need for per-application authentica- DirX Access Manager tion, users no longer need to keep track of Web Application multiple login credentials, and administrators no User longer need to maintain and support redundant Repository authentication mechanisms. The authentication services provided by DirX Figure 2: DirX Access Authentication/SSO Subsystem Access include initial user authentication, SSO and federated authentication. thentication authorities and leverage the exist- Single Sign-On and Session Management Initial User Authentication ing authentication infrastructure. Once successfully authenticated, users do not Initial authentication refers to the first time a Administrators can define the preferred authen- have to re-authenticate themselves when ac- user authenticates against the system. It is tication method to use for each distinct re- cessing other DirX Access-protected resources based on a user account established in DirX source of Web and Web services applications or (unless a resource explicitly requires step-up Access and uses standards-based initial authen- the DirX Access-protected resources of other authentication) on arbitrary servers within the tication mechanisms such as: applications. In this way, administrators can same domain. The authentication state of users easily provide the most appropriate security is securely exchanged via HTTP cookie headers  SSL/TLS client authentication through X.509 level for each individual resource. or URI rewriting. certificates including path validation, OCSP support, CRL and ARL Administrators can use the DirX Access Server DirX Access manages security sessions by to assign a ranking to authentication methods. maintaining information on authenticated,  HTTP basic authentication through This ranking, provided by assurance levels, assured user identities. This information com- username/password indicates how secure the authentication meth- prises authentication method, authentication  HTML form-based authentication through ods are relative to each other on a numeric time, authentication credentials and other username/password scale. Assurance levels can be used as condi- parameters specific to this login event. DirX  HTML form-based authentication with OTP tions for authorization. For example, a critical Access provides an interface for plug-ins that algorithms based on IETF RFC 2289, IETF resource can be assigned a policy with an fetch subject attributes from additional third- RFC 4226 (HOTP) and IETF RFC 6238 (TOTP) assurance level condition of 4, requiring that party sources and enrich the session informa-  HTTP authentication through Integrated users be authenticated using only the most tion using these attributes. Windows Authentication (IWA) using the secure methods in order to achieve access. In addition, environmental information can be SPNEGO, Kerberos and NTLM authentication Assurance levels are defined in NIST Special handled in a configurable way in authenticated protocols Publication 800-63. subject representations; for example, solution- DirX Access provides step-up authentication to specific security environments like information DirX Access supports multi-factor authentica- request a re-authentication using a stronger on network trust level and device types can be tion by combining two or more authentication authentication mechanism when accessing a provided. methods sequentially; for example, user- more critical resource. DirX Access creates a new security session for name/password plus additional verification via DirX Access supports context-aware authentica- each successful login. A security session is OTP values or username/password plus an tion based on internal vs. external IP address established between Web browsers and a DirX external validation. ranges to minimize risks. This mechanism Access Server using a session identifier that DirX Access can validate the user credentials allows different authentication methods to be refers to the assured user identity information internally by performing the authentication itself applied to the different IP address ranges from in the cache. (the default), or it can externalize the validation which users access the services. For example, An existing security session is terminated by an task to an external validation service. administrators can enforce stronger authentica- explicit logout (initiated by the user), by session Externalizing validation is open to various algo- tion for Internet accesses and weaker authenti- time-out, by idle time-out, or by shutdown of all rithms and an interface for third-party verifiers cation for Intranet accesses. DirX Access Servers in a cluster. In all cases, the supports token-type authentication credentials; assured user information in the cache is invali- for example, SAP logon tickets. dated and can therefore no longer be refer- DirX Access can easily integrate existing au- enced by Web browsers.

DirX Access V8.3 2

Additional DirX Access session management Yes/No/ HTTP/SOAP/other Protected features include: PEP Resource  SSO session augmentation: DirX Access allows third-party applications to enrich the Client SSO state maintained for authenticated users Security subjects Authorization Context with arbitrary data (opaque to DirX Access). Service Handler Client Such data can be queried, used in authoriza- e.g. application tion decisions and included in SAML asser- Authorization SOAP PDP tions and audit records. Web service  SSO event callout interface for third-party plug-ins: this feature allows notifying third- Policy PIP party applications of SSO events such as user Finder logout, session time-out or idle time-out and is Client e.g. Query especially useful when third-party applications DirX Access Policy Manager attach application-specific session information Policy Service Policy SOAP to the SSO state in DirX Access. PAP HTTP Web service  SSO session correlation across multiple LDAP browsers: this feature allows matching and DirX Access Manager PDP – Policy Decision Point merging SSO state maintained for authenti- Web Application PEP – Policy Enforcement Point cated users based on criteria such as user Policy PIP – Policy Information Point identifiers and user origination (for example, Repository PAP – Policy Administration Point requestor IP addresses). This feature is op- tional and allows assigning the very same SSO state in DirX Access to user sessions es- Figure 3: DirX Access XACML-based Authorization Subsystem tablished through different frontends.

Federated Authentication faces and tools. DirX Access can use arbitrary Authorization and LDAP attributes for its authentication and au- Federated authentication is the process of Entitlement Management thorization needs. transferring information regarding authentica- When DirX Access performs its own user man- In DirX Access, authorization is provided as an tion state from an identity provider to a service external, centralized policy-based access control provider in a different domain. DirX Access agement, administrators can use DirX Access Manager to manage the user accounts; this tool service that allows for the "up front" definition of supports federated authentication according to a comprehensive set of access control policies SAML 2.0 and OAuth 2.0. provides an intuitive interface for user man- agement and is described in more detail in the and then grants or denies access to resources In contrast to the concept of initial authentica- Administration section of this data sheet. based on these policies. tion, federated authentication does not require Once authenticated, the full user re- Based on the XACML (eXtensible Access Con- that each user has a corresponding unique user trol Markup Language) standard from OASIS account at the side of the service provider. cord/attributes can be used in federation or authorization scenarios (issuing SAML asser- (Organization for the Advancement of Struc- Instead, the identity provider typically assigns tured Information Standards), access policies roles to users and the service provider grants or tions, releasing OAuth user profile data, evaluat- ing authorization policies, etc.) using user data can be defined according to the authorization denies access to a resource according to the model that best suits the environment. roles from the security assertion statement. In from arbitrary LDAP repositories. For example, a role-based access control this way, all information necessary to perform DirX Access provides just-in-time (JIT) provision- (RBAC) model defines access policies based on authentication (such as digital identity, authenti- ing for federated authentication. JIT provision- the roles assigned to a user, while attribute- cation credentials, etc.) are managed locally at ing can create user accounts in the DirX Access based access control (ABAC) defines access the identity provider but the final access deci- user repository on the fly at the service provider policies based on attribute values, and with sion remains in the sole responsibility of the site based on the information in the SAML discretionary access control (DAC) access service provider. SSO is also provided for feder- token. policies are defined by the owner of an object. ated authentication scenarios. DirX Access provides an SPML-based provision- The owner decides who is allowed to access ing Web service for provisioning user accounts Authentication and SSO in DirX Access are the object and what privileges they are granted. delivered by the authentication/SSO subsystem and their attributes in the DirX Access user Policy-driven authorization has many advan- as shown in figure 2. repository. Both SPML V1.0 and V2.0 are sup- ported. tages. Access control policy definition and management is performed outside of the indi- For more complex tasks, such as assigning user vidual application and removes the need for User Management attributes and privileges, integrating multiple individual application access control logic. It Initial authentication of users requires that directories, user databases, and application- makes access policy creation an initial task identities are managed in an LDAP directory. specific repositories, it is recommended to use rather than an ongoing one, simplifies the ad- This directory can be an externally managed an identity management solution such as DirX ministration of access rights to multiple Web directory with its own schema, for example, Identity. DirX Identity also provides workflow- applications and resources, and provides for the inetOrgPerson, or an LDAP directory under DirX based user self-registration and self- consistent application of access rights and Access administrative control, referred to as the management functionality as well as many enforcement of security policies over time. DirX Access user repository. other advanced identity management function- In the first case, user management is performed alities. DirX Access uses XACML 1.x/2.0 as the underly- ing authorization technology and supports the using the corresponding external user inter-

3 DirX Access V8.3 following authorization models:  Arbitrary, application-defined authorization Identity Provider Service Provider models. Any authorization model that can be expressed as valid XACML objects can be Responsible forTrust Enforces Access Control for used. The actual policy content is form-free as Relationship IT Resources Identity Management long as policy syntax requirements (well- Application Authentication formedness, validity) are met. Services  An RBAC authorization model, allowing or denying access to Web services and Web application resources and the resources of Authenticates at Accesses Resources at other applications based on the role held by Identity Provider Service Provider the requesting user within the organization. Administrators define the business roles used in the organization and specify the resources User that should be available to each role based on Web Browser business needs. This authorization model is constrained by the RBAC profile of XACML; the policies that can be expressed in this au- Figure 4: DirX Access Federation Model thorization model need to comply with this dedicated profile. user LDAP attributes, SAML assertion attributes, Identity Federation OAuth user profile data, application and envi- Identity federation is a set of standards and ronment-specific attributes passed by the PEP Authorization in DirX Access is delivered by the technologies that allow partner organizations to to the server (client device identification, appli- following building blocks (see Figure 3): establish trust relationships regarding each cation information), etc.  PEPs (policy enforcement points), deployed other's security policies and infrastructure, and as plug-ins to Web and Web application serv- In addition, DirX Access reacts in real-time to then allow or deny access to resources based ers or other applications, process access re- modification of user records; for example, by on this trust. revoking access when user attributes are quests, send authorization decision requests Identity federation enables for the secure shar- changed. to PDPs and provide the authorization deci- ing of digital identities and login sessions across sion to their environment. Some PEPs enforce security domains. It facilitates secure and seam- the PDP authorization decision themselves, Policy Management less online collaboration by providing safe while other PEPs just inform their environ- Policy management in DirX Access comprises access to partner resources without the need ment about them. functions to create, modify, delete and view for re-authentication, and permits partners to  PDPs (policy decision points), provided as part authorization and authentication policies based trust and share identity information for authen- of the DirX Access Server, render authoriza- on the XACML standard. tication and authorization without the need to tion decisions for access requests sent from create and maintain it at each partner site. In DirX Access, administrative policies govern PEPs. They base their decisions on authoriza- the administration of DirX Access, and business In DirX Access, identity federation extends the tion policies obtained from PAPs. policies govern the access of users to the pro- core services of authentication and authoriza-  PAPs (policy administration points) are au- tected resources. tion to the virtual enterprise. The identity fed- thorization policy authorities that allow ad- eration model consists of a service provider (SP) Authentication policies enforce the use of spe- ministrators to create, supply and maintain (also called a resource provider), an identity cific authentication methods for different sys- authorization policies. The PAP is represented provider (IdP), metadata that describes a part- tem resources. by the policy service in a DirX Access Server. ner site in a circle of trust, and a protocol for This service can be used via the DirX Access Authorization policies apply authorization rules exchanging authentication and authorization Manager, the DirX Access Provisioning Web controlling actions on protected resources. data between security domains. Fine-grained authorization policies help to service (authorization policies complying to In a federated transaction, the identity provider define the level of granularity needed for au- the RBAC model) , the DirX Access Policy is the "authentication authority" that performs thorization. They consider the properties of Web services (other authorization policies) or authentication for service providers in the circle requested resources (such as security classifica- via the DirX Access Policy Manager. Working of trust, while the service provider is the "au- tions) and requesting subjects (such as user with the PAP is subject to authorization and thorization authority" that owns the requested names, group memberships or role assign- authentication through DirX Access. resource. A service provider relies on an identity ments) to enable authorized access to re- PIPs (policy information points) can be used provider's authentication and is responsible for  sources and deny unauthorized access. to access information about the application authorizing the authenticated identity's access environment that may be required in evaluat- to the requested resource. ing policy decisions. PIPs can also provide Access Tester DirX Access supports both SAML-based and information on the subject or resource in- Authorization policies can be tested from within OAuth-based identity federation. volved in the request. the DirX Access Manager Tools section. The Identity federation can Access tester allows the administrator to simu- Cut the cost and complexity of online collabo- late any user or role based access against the  DirX Access supports dynamic access con- ration by eliminating the need for multiple actual policy to see what will happen and if the trol/authorization with the help of attribute user profiles. configuration has the desired outcome. finders, which provide the PDP with configur- Deliver a positive user experience through  able information for access decisions. All infor- cross-domain SSO. mation contained in the authenticated session  Improve productivity by providing secure, (JAAS subjects) can be used; for example, the

DirX Access V8.3 4

convenient access to the resources of trusted IdP partners. SP Proxying IdP  Interoperate with other standards-compliant federation solutions. SAML 2.0 SAML 2.0 IdP SP Identity Service In identity federation scenarios, identity data Provider Provider IdP comes in the form of transient authentication SP statements that are transferred in an IdP interoperable and secure way. These authentication statements are also known as security tokens and come in the form of SAML assertions or as OAuth access tokens in DirX Figure 5: DirX Access Sample: Proxying IdP in a Hub/Spoke Scenario Access.

SAML-based Federation  Basic Attribute profile SAML identity provider endpoint to external In the case of SAML-based federation, DirX  X.500/LDAP Attribute profile SAML identity provider endpoints. Access uses Security Assertion Markup  UUID Attribute profile A proxying identity provider is a combination of Language (SAML) assertions to represent  XACML Attribute profile a traditional SAML authentication identity pro- identities in federated transactions. vider (implementing SAML SingleSignOnService

DirX Access supports both SAML 2.0 federation in particular) and a traditional service provider DirX Access supports the following SAML scenarios: (implementing SAML protocols:  Service provider-initiated: In this case, the user AssertionConsumerService).  Authentication request protocol attempts to access a resource on a federated With SAML proxying:  Artifact resolution protocol domain without first authenticating. The re-  Multiple proxying identity providers can be mote site then redirects the user to the identi-  Single logout protocol configured between the service provider and ty provider for authentication. If authentica-  Assertion Query and Request Protocol with the actual identity provider. tion is completed successfully, the user is re- authentication query, attribute query, authori-  A proxying identity provider can be config- turned transparently to the destination site for zation decision query and request for asser- ured to connect to multiple identity providers authorization and, ultimately, for access to the tion by identifier elements and/or to multiple service providers. In this desired resource. Request/response objects can be signed (en- configuration, the proxying identity provider  Identity provider-initiated: In this case, the veloped XML signature). serves as a hub/bridge/gateway in a hub and user first authenticates in the local domain spoke identity federation model, allowing for and then makes a request for a service or DirX Access supports SAML assertions with the easier management of configuring trust for a resource located on a federated domain. following contents: large number of identity providers and ser- In both scenarios, DirX Access can represent  Authentication statements vice providers in a federation scenario. the identity provider that authenticates the user,  Attribute statements or the service provider that owns the resource  Authorization decision statements Just-in-Time Provisioning and relies on the source site’s authentication. Assertion objects and protocol objects can be DirX Access provides a dynamic user provision- DirX Access supports the following SAML 2.0 signed (enveloped XML signature). SAML asser- ing model for SAML-based federation environ- profiles, associated message protocol flows and tions, NameIds, and attributes can be encrypted. ments known as just-in-time (JIT) provisioning. It bindings according to the SAML 2.0 is targeted at (cloud) federation scenarios, conformance requirements document: where (cloud) service providers require identity DirX Access can include environmental  Web Browser SSO profile with AuthnRequest data from an identity provider as a prerequisite message from SP to IdP via HTTP redirect or information – for example, solution-specific for authorizing access to their (cloud) services. security environments like information on HTTP POST binding Just-in-time provisioning is primarily a service network trust level and device types - into the Web Browser SSO profile with IdP Response provider-side solution. It enables a service pro-  SAML assertions. message to SP via HTTP POST or HTTP arti- vider to create user accounts on the fly the first fact binding including Unsolicited Responses DirX Access supports SAML metadata import time the user successfully authenticates via (IdP first) and export, which addresses the mutual SAML Web SSO federation protocol with a configuration that needs to be established Identity Provider Discovery profile with cookie SAML assertion issued by a trusted identity  between an identity provider and a service setter and cookie getter messages via HTTP provider, It uses the attributes of incoming provider. binding SAML assertions issued by a trusted identity

 Single Logout profile with LogoutRequest and provider to create and update user accounts in LogoutResponse messages via HTTP redirect, SAML Proxying the destination application directory. Just-in- HTTP POST, HTTP artifact or SOAP binding DirX Access supports SAML proxying based on time provisioning is useful for cases where the the SAML 2.0 specification. In SAML proxying, user’s identity does not need to be known in  Artifact Resolution profile with ArtifactResolve advance by the service provider, such as supply and ArtifactResponse message via SOAP identity providers can proxy an authentication chain portals, collaborative projects and many binding request from a service provider to a different identity provider that has already authenticated SaaS applications.  Assertion Query/Request profile with authen- the user or is capable of authenticating the user, DirX Access supports both push- and pull-based tication query, attribute query, authorization enabling the delegation of initial user authenti- JIT provisioning scenarios: decision query and request for assertion by cation in SAML Web SSO federation from a local identifier messages via SOAP binding  In the push model, the service provider cre-

5 DirX Access V8.3 ates user accounts using the identity data of OAuth Authorization Server the incoming SAML assertion. The DirX Ac- Acting as Identity Provider DirX Access cess identity provider FEP supports a SAML- used for Authentication with based, push-based JIT provisioning scenario OAuth and for Authorization with its own DirX Access user repository and Google with any SAML SP that supports JIT provision- OAuth Client Endpoint ing, for example Salesforce.com. SSO Service  In the pull model, the cloud service provider Facebook decides when and how to pull identity data from the identity provider originating the

SAML assertion. The service provider first DirX Access PEP asks the identity provider for the required DirX Access identity data and then creates the user ac- OAuth Server IT Resources count based on a union of identity data con- Endpoint tained in the SAML assertion and received in Authenticates at the response to the additional requests. Accesses Resources

Proven SAML 2.0 Interoperability User Web Browser DirX Access passed Liberty Alliance SAML 2.0 interoperability testing in 2009. DirX Access Figure 6: OAuth-based SSO with Social Identities participated in the third Liberty Interoperable™ full-matrix testing event for SAML 2.0 together or in conjunction with browser-based SSO for soft Internet Information Server. They integrate with eight other products from different ven- either an IdP or an SP deployment: with the down-stream applications that they dors and demonstrated that DirX Access fulfills  In an SP deployment, the OAuth client federa- protect mainly through header injection. Via the stringent test criteria for open, secure and tion endpoint client requests and uses the header injection, data from various sources can privacy-respecting federated identity manage- access token to access the protected re- be made available to applications, e.g. user- and ment. sources session-related data as well as data from arbi-

 In an IdP deployment, the OAuth server trary LDAP repositories. Identity Federation and Cloud Computing federation endpoint can be used to authenti- DirX Access provides container PEPs for Java- DirX Access provides SSO for cloud-based cate and provide the access token with asso- based application servers like JBoss Application applications or for SaaS to secure access in a ciated user information. Server, SAP NetWeaver, Oracle/BEA WebLogic cost-efficient and reliable manner. Federation and IBM WebSphere. They protect J2EE appli- cations (servlets, JSP, JSFs, EJB, and others) standards such as SAML are being used for Figure 6 shows an OAuth-based single sign-on deployed in these servers via the standard J2EE authentication of users to off-premise applica- scenario where users authenticate with their tions (SaaS or cloud-hosted). interfaces JAAS and JACC. social identities from systems such as Google, Facebook, etc. to access IT resources that are The DirX Access PEP and the IBM WebSphere Preconfigured SAML Service Providers protected by DirX Access. In this scenario DirX application server - through its LTPA token - DirX Access supports preconfigured SAML Access is used for authentication via OAuth and also allow for the further integration and single service providers. This functionality allows for authorizing access the IT resources in an SP sign-on of the Lotus Notes/Domino Web access administrators to easily establish SAML-based deployment. (iNotes). interoperability between the DirX Access identi- Application PEPs can be provided for applica- ty provider and well-known cloud service pro- tions that support standard or published inter- viders such as Google Apps, Citrix ShareFile, Securing Web Applications faces. One important example is servlet applica- Microsoft Office 365 and Salesforce.com with Access management solutions were initially tions, which can be protected individually by out-of-the-box configurations delivered with focused on securing access to Web applications the DirX Access servlet filter PEP. Applications DirX Access. It also allows for parameterizing and Web content behind eBusiness, eGovern- that do not provide such integration points can provider instances and creating custom tem- ment, and eShop portals. To this end, DirX be protected with a custom-developed PEP plates for other preconfigured service providers Access WAM capabilities apply the concepts of built with the DirX Access Client SDK. and identity providers. external, central, policy-based authentication and authorization services, identity federation and SSO to provide secure, convenient, and Securing Web Services OAuth-based Federation reliable access to multiple Web applications With the advent of Web services-based SOAs, DirX Access also supports the OAuth 2.0 stand- with one authentication step. WAM solutions must move beyond securing ard for authorization in identity federation The DirX Access PEPs that secure Web applica- traditional Web applications. Consequently, DirX scenarios. OAuth defines a resource authoriza- tions can be classified as protocol stack exten- Access also provides authentication and au- tion protocol that allows resource owners to sion PEPs, container PEPs, and application PEPs. thorization services that secure access to Web delegate resource access rights. This enables In addition, custom PEPs can be created based content published by Web services providers sharing resources across organizational on the client SDK or by the DirX Access Web and requested by Web services clients using boundaries without sharing user credentials. To services. messaging protocols like SOAP over HTTP or support this use case, DirX Access provides HTTP over SSL/TLS, both within and across Protocol stack extension PEPs reside in protocol both OAuth client functionality and OAuth security domains. authorization server functionality. stacks. The most common examples are the HTTP stack PEPs (Web PEPs) like the ones for DirX Access supports the relevant standards for DirX Access can be configured independently Apache Web Server, Apache Tomcat or Micro- implementing security for Web Services. The

DirX Access V8.3 6

OASIS WS-Security and SAML assertion security token standards facilitate Web services authen- tication, authorization, and SSO between Web service providers and clients, while the OASIS WS-Trust standard can be used to implement identity federation, including cross-domain SSO in Web services-based SOAs. DirX Access provides SOAP stack PEPs (Web Services PEPs) for both JAX-WS (the Java API for XML Web Services) and WCF (Windows Communication Foundation), which extend these SOAP protocol stacks in order to secure Web Services.

Securing Legacy Applica- tions The demand for online collaboration, increased operational efficiency and 24/7 access to busi- ness resources is driving companies to bring their legacy applications online at a rapid pace. Figure 7: DirX Access Manager GUI Sample DirX Access offers a way to secure these legacy applications with the same external, centralized, which provides authentication and SSO func- cess can be seamlessly integrated with DirX policy-based authentication and authorization tionality. Identity or cooperate with other identity man- services used for modern Web applications.  The Authorization Web service, which pro- agement solutions. DirX Access supports application PEPs that vides authorization decision-making and test- integrate with specific applications and protect ing based on the OASIS XACML standard. Access control for administration uses the same them. Depending on the integration mecha-  The Policy Web service, which provides au- authentication and authorization mechanisms nism, they can be classified as: thorization policy querying and management as access control for protected organizational  Application source PEPs, which are custom based on the OASIS XACML standard. resources. PEPs that use Client SDK methods integrated  The Federation Web service, which provides DirX Access administration is performed into the sources of the application. SAML assertion issuance and an OASIS WS- through the DirX Access Manager (see figure 7),  Application extension PEPs, which are custom Trust security token service (STS). a Web-based administration tool that allows or off-the-shelf PEPs that extend applications;  The Provisioning Web service, which provides administrators to perform a variety of tasks, for example, aspect-oriented programming the ability to provision DirX Access with users, such as: (AOP)-based PEPs. groups and organizational units, and to con-  Creating business roles.

trol the assignment of those objects to roles. It  Defining users, groups and organizational Legacy applications can use PEPs and PDPs as is based on the OASIS SPML V1.0 and V2.0 units that require access to protected re- their access management system, providing an standards. sources, and importing existing users from external, centralized method for controlling  The Configuration Web service, which is used external repositories. access to these applications rather than having to configure the DirX Access system.  Creating authentication policies using a to build in access management security on an resource tree. application-by-application basis. Administration  Creating authorization rules and policies using a resource tree. Security Web Services Administrative responsibilities reflect business structures so that companies can place the  Setting authorization conditions, such as the The problem of externalizing and centralizing management of users, groups, and policies for time of day, authentication method, assur- application-specific security also applies to Web access to resources with someone close to the ance level, or the IP range required for access. services-based SOAs. When migrating applica- demands of a particular business line. DirX  Assigning policies to roles. tions to run as discrete Web services, how do Access provides methods for flexible, secure  Assigning users, groups and organizational you handle the individual (and usually unique) delegation of administrative responsibilities to units to roles. security logic and data that is present in each respond to temporary changes in personnel  Configuring the internal representation of application? and shifts in organizations and processes and authenticated subjects. DirX Access responds to this challenge by support the business-agile enterprise. DirX  Configuring the SAML assertions of authenti- providing its security features as out-of-the box Access provides Web-based administration cated subjects. Web services for deployment in Web services- tools that permit administrative activities to run  Configuring federation. based SOAs. Businesses can then add security in parallel for fast, efficient deployment of ac-  Configuring servers. logic as well-defined, published Web services for cess policies across the virtual enterprise. DirX use by any business process service running in Access provides graphical resource explorers  Configuring PDPs. a Web services based SOA. that offer easy, effective discovery and registra-  Configuring PEPs and resource explorers. DirX Access provides the following off-the-shelf tion of resources in the virtual enterprise. If Web services: there is a need for more complex identity man- To define and enforce access effectively, DirX  The Authentication and SSO Web service, agement and provisioning activities, DirX Ac- Access must be aware of resources on the

7 DirX Access V8.3 network. Resource explorers are administrative utilities Web and Application Server, Customer Applications that scan the Web and application servers, on PEPs for Target Systems which they are deployed, listing available re- sources such as Web pages, servlets, beans and bean methods. If resources are discovered by explorer agents, they are added to the hierar- chical resource tree in the Web-based DirX DirX Access DirX Access DirX Access Access Manager. This automatic discovery Core Services Web Services Applications reduces manual data input, saving time and User Web browser improving accuracy. Authentication Authentication / SSO SAML Endpoints Repository Authorization Authorization OAuth Endpoints Additional administrative applications provided Administration Federation Authentication Appl. by DirX Access include: Audit Policy Provisioning  Deployment Manager, a command-line based Configuration standalone Java application plus optional Web applications Web GUI for the initial setup and basic con- OSGi Framework figuration of DirX Access product deliverables.  Policy Manager, a Java Swing GUI-based application to edit XACML policies and em- ploy the DirX Access Policy and Authorization Figure 8: DirX Access Architecture and Integration into Applications Web services.

 Account and password management (for Integration and Customi- Multi-Tenancy example, changes, expiration time reached) zation Framework To support multi-tenancy, multiple tenant-  Policy management (for example, role, au- specific instances of DirX Access can be de- thentication and authorization policy creation DirX Access functions and components are ployed providing own tenant-specific configura- and modification) designed for integration into customer envi- tion for each tenant. This allows serving multiple ronments as described in previous sections.  User management (for example, user and client organizations (tenants) with one single group creation and modification) Comprehensive configuration capabilities pro- installation of the software. vide extensive customization options that allow  Configuration events for easy adaptation to customer deployments.

Audit (Knowing What Was DirX Access provides an audit externalization Done and Being Able to interface that supports custom implementa- DirX Access Architecture Prove It) tions of audit events processing via plug-ins. Many third-party business applications in the The following implementations are provided enterprise can use DirX Access for access In order to prove compliance with an increasing with the product: management and enforcement; for example, number and complexity of business and pri- portals, Web servers, application servers, and vacy regulations, the DirX Access Audit service  An implementation based on Log4J which other applications. They can be broadly struc- provides complete transaction accountability uses Log4J appenders (for example, for con- tured according to the Client, Web, Application, across the virtual enterprise. The system: sole, file, database, syslog, and other items) to process DirX Access audit events. This is the and Data tier. DirX Access typically integrates  Audits transactions both within and across default audit plug-in provided by DirX Access. into the Web and Application tiers. Depending security domains.  Out-of-the-box integration to the DirX Audit on the technology of these integration tiers, one  Logs all security events for proof of activity; product. may use DirX Access off-the-shelf capabilities for example, the result of authentication and (PEPs, explorers and federation endpoints) or

authorization requests or password and poli- the DirX Access Client SDK to integrate other cy changes. DirX Audit can be used for centralized, secure applications such as legacy systems. storage, analysis, correlation and review of DirX Access integrates with the applications it identity- and access-related audit logs and for All authorization requests for a given protects through capturing agents (referred to creating reports. DirX Audit is part of the DirX transaction can be correlated to previous as PEPs - policy enforcement points) deployed product suite and can be ordered separately. authentication events; therefore all transactions as plug-ins to Web and Web application servers can be traced back to their origins. This design DirX Access provides for the export of its or other applications. They act as DirX Access applies to all relevant system features deployment, configuration, policies and user Server clients, mediating the authentication and (authorization, authentication, identity data as XML files through various Web services. authorization process, enforcing the access federation, user management, policy and This feature can be customized and decisions of the server and providing the user configuration management). transformed, for example, by XSLT to custom browser and the downstream applications with reports. Audit data generated by the DirX Access audit session and state information. This setup also service corresponds directly to the actions of includes reverse-proxy configurations. identifiable and authenticated users. Actions Logging The DirX Access Server provides the core secu- recorded for each user include: DirX Access logging records internal system rity services—authentication, authorization (PDP  Authentication: (who, when, how) operations for problem diagnostics and debug- - policy decision point), SSO, federation, policy,  Authorization (who, when, for what) ging. The amount of information each server configuration and others— to the PEPs, medi-  Session management (for example, session generates can be controlled by restricting its ates the access to the LDAP repositories, ex- lifetime, idle timeout) logs to a given level. poses the services as Web services and/or

DirX Access V8.3 8

federation services to third-parties and provides Client Tier:  Configuration Web service the Web-tier logic for the Web-based manage- For details, see the Security Web Services sec- ment interfaces. DirX Access Applications tion in this document. The PDP access decisions are driven by the DirX Access provides the following categories XACML-based authorization policies, which are of off-the-shelf Web applications: DirX Access managed by the policy administration point Manager, DirX Access Authentication Applica- Server Tier: DirX Access (PAP). The PAP is implemented by the policy tion and federation applications. Core Services service in the server and is also provided as a DirX Access Manager provides an intuitive Web- The DirX Access services provide the core Web service. It can be used through a Web- based interface that allows full or delegated functionality of the product, including authenti- based GUI provided with the DirX Access Man- administrators to manage the system (for de- cation and SSO, authorization, administration ager (specializing on RBAC) as well as the DirX tails, see the Administration section of this and audit services. This functionality is realized Access Policy Manager (specializing on ABAC). document). using SOA principles and consists of core and The policy information points (PIPs) are used to DirX Access Authentication Application is a DirX supporting services. access information about the application envi- Access component that performs initial user The DirX Access Server services are used by ronment or on the subject or resource involved authentication on behalf of DirX Access PEP native communications as well as through in the request. and FEP components. The layout of the user bundled Web applications and Web services. DirX Access uses LDAP directory servers to interface is customizable. The Authentication store user, configuration and policy data. Application allows for context-aware authentica- Data Tier: Directory Server The DirX Access architecture can be structured tion based on internal vs. external IP address DirX Access can use two different LDAP direc- in tiers as follows: ranges to minimize risks. tory servers in parallel, one for user and one for  Client tier: DirX Access federation applications provide endpoints for federated identity management: policy/configuration data.  DirX Access PEPs and explorers  The SAML service provider federation end- Any standard LDAP directory with a schema  DirX Access applications such as federation suitable for user management (for example, endpoints, Authentication Application, DirX point (SP FEP) provides a federation endpoint for SAML service providers InetOrgPerson object class) can serve as a user Access Manager, and Web services repository.  The SAML identity provider federation end-  Server tier: DirX Access Servers providing DirX Access can supplement the user record security services point (IdP FEP) provides a federation end- point for SAML identity providers. obtained from the user directory with infor-  Data tier: Directory servers used to store user, mation from other stores using standard and/or  The SAML identity provider federation end- configuration and policy data for DirX Access. custom-build attribute finders, which are func- point supports SuisseId and the SAML service tionally comparable with virtual directories. provider federation endpoint provides sup- DirX Access services and applications are uni- port for SuisseID-enabled identity providers. Policy data includes the following elements: formly deployed in ready-to-use OSGi-based SuisseID is a national ID infrastructure project  Authentication policies containers, This configuration allows for net- in Switzerland. SuisseID follows a user-centric  Authorization policies (RBAC/ABAC), including work separation when deploying services in a identity management approach and extends rule, condition and action components protected network and applications in a DMZ. the SAML 2.0 specification by user-centric Figure 8 presents the DirX Access architecture identity management features. Configuration data includes the following ele- and its integration points in existing applications  The OAuth server federation endpoint repre- ments: from a high-level component perspective. sents the authorization server side of the  Authentication methods OAuth communication. An authorization  Server configurations endpoint is used by the client to obtain au- Client Tier: Policy enforcement point configurations thorization from the resource owner via user-  DirX Access Policy En- agent redirection. A token endpoint is used by  Federation endpoint configurations forcement Points and Ex- the client to exchange an authorization grant  Centralized component configuration param- plorers for an access token, typically with client au- eters such as user directory settings, tem- thentication. plates to construct or interpret SAML asser- PEPs are plug-in components that operate as a tions and other parameters DirX Access client and that provide policy en-  The OAuth client federation endpoint repre- forcement services (especially authorization sents the client side of the OAuth communi- and authentication). They process requests for cation and is able to create a session in DirX User management applications can be inte- resources and services, query the DirX Access Access. The OAuth client federation endpoint grated with the DirX Access Server via its provi- Server for authorization and authentication, and works with any OAuth 2.0 server such as sioning interface. provide the decisions back to their environ- Google, Facebook, etc. DirX Access can also use various LDAP servers ment. that are not part of the DirX Access product Resource explorers are optional components DirX Access Web Services delivery. that help in authoring authorization policies (see DirX Access provides the following off-the-shelf their description under the Administration Web services: Reliability, High Availabil- section of this document).  Authentication and SSO Web service ity and Scalability For integration purposes, DirX Access also  Authorization Web service To achieve maximum availability and failover supports the configuration of arbitrary LDAP security as well as scalability, multiple, redun- user objects that are injected into the HTTP  Policy Web service dant DirX Access Servers can be configured. header for further use of the secured applica-  Federation Web service DirX Access clients, for example, PEPs or federa- tion.  Provisioning Web service tion endpoints, can perform load-balanced

9 DirX Access V8.3 access to the servers. Therefore, the DirX Ac- pick up the session without compromising the For key management, DirX Access supports cess clients keep an internal connection pool security of the transaction. PKCS and X.509/PKIX. and a health index of the multiple servers. Load Whenever a user authenticates successfully, a For communications, DirX Access supports balancing is then handled internally using that new session is initiated, which creates a new HTTP, SOAP and WS-*. connection pool. To complete the fail-safe subject in the cache system. The subject con- For persistence and provisioning, DirX Access setup, the DirX Access Server supports primary tains the session token as a principal, along with supports LDAP, DSML and SPML. and secondary directory configuration for the list of attributes associated with the authen- In Java environments, DirX Access supports failover deployments. ticated user (for example, role assignments) and JAAS, JACC, JCA/JCE, JGSS, and JSSE. DirX Access uses a set of sophisticated mecha- additional information. Since the cache is dis- DirX Access supports both IPv4 and IPv6 Inter- nisms to recover from network component tributed, session states are immediately made net Protocol. failures and prevent down time for users, includ- available to all other servers. There is no con- ing: cept of object ownership among DirX Access  A distributed cache, allowing multiple DirX Servers. If for any reason a server goes down or Other DirX Products Access Servers to share security objects and becomes inaccessible, the load is transparently The following products also belong to the DirX configurations. redistributed over the remaining servers. product suite and can be ordered separately;  Load balancing between DirX Access Servers DirX provides the basis for totally integrated based on a round-robin scheduling algorithm LDAP Failover identity and access management: and server stickiness. Access to the LDAP directory configuration/ DirX Directory, the leading LDAP/ X.500 direc-  A state-of-the-art operation recovery process policy and user repository is crucial for DirX tory server, is the foundation for identity man- using retries, retry intervals and error thresh- Access and is ensured by switching to a secon- agement. olds. dary directory server instance if the primary DirX Identity provides a comprehensive, proc- server is unavailable. If a DirX Access Server ess-driven, customizable, cloud-ready, scalable Client Behavior receives a timeout in response to any directory and highly-available identity management operation, it will try using the secondary in- Every application acting as a DirX Access client solution for enterprises and organizations. It stance instead. in the system is expected to have a correspond- delivers overall identity and access governance ing entry in the DirX Access configuration store. functionality seamlessly integrated with auto- When a DirX Access client initiates communica- Supported Standards mated provisioning. Features include life-cycle management for users and roles, cross-platform tion with a DirX Access Server, it must provide DirX Access supports the relevant standards, an instance name. The configuration service and rule-based provisioning in real time, Web- protocols, and security frameworks to provide based user self-service and delegated admini- uses this instance name to determine the ap- its security functionality and services: propriate configuration entry in the configura- stration, request workflows, access certification, For authorization and privacy, DirX Access tion store. This includes the addresses of all DirX password management, metadirectory and supports XACML 1.x/2.0, SAML 1.x/2.0, OAuth 2.0 Access Servers in a network or a dedicated auditing and reporting. and RBAC. subset of these servers associated with this DirX Audit provides auditors, security compli- client in a specific way (along with more infor- DirX Access successfully passed the Liberty ance officers and audit administrators with mation, such as the maximum number of con- Alliance SAML 2.0 interoperability test in 2009 analytical insight and transparency in the iden- nections this client may initiate). when it participated in the third Liberty Interop- tity and access management processes. A erable full-matrix testing event for SAML 2.0. When an application sends requests to DirX ™ dashboard visualizes key performance indica- Access Servers, the underlying DirX Access For initial user authentication in Web environ- tors, statistics and metrics and allows drill-down client transparently performs load-balancing ments, DirX Access supports SSL/TLS, HTTP into the details of individual events. Filtering, over the configured DirX Access Servers. It also Basic, HTML Form-based authentication with analyzing, correlating and review of identity- automatically creates server connections as username/password and one-time-passwords related events allow answering the “what, when, required to process its message traffic, up to its based on IETF RFCs 2289, 4226 and 6238. where, who and why” questions of user access configured maximum. When this threshold is For initial user authentication in Web services and entitlements. reached, the DirX Access client continues to environments, DirX Access supports User- process its message traffic using the available nameToken and X509Token. servers and connections. For intra-domain SSO in Web environments, DirX Access supports Integrated Windows Session State Sharing Authentication (SPNEGO/ Kerberos, NTLM), Multiple DirX Access Servers in a network share authenticated subject identifiers transferred via a synchronized cache containing session ob- HTTP cookie headers, and URL rewriting. jects, policies, and configuration attributes. The For cross-domain SSO and identity federation in shared cache allows clients (PEPs, FEPs) to send Web environments, DirX Access supports SAML requests to arbitrary servers in a network and 1.x/2.0 especially SAML Web-SSO profiles and also improves performance by reducing the OAuth 2.0. number of read requests to the directory For cross-domain SSO and identity federation in server. Web services environments, DirX Access sup- This cache also enhances reliability and failover ports WS-Trust. mechanisms, since a session object created by For secure communication, DirX Access sup- one server and stored in the policy cache can ports SSL/TLS and WS-* security. be reused by any other server. Whenever one For object security, DirX Access supports XML server fails, the other servers can transparently signature.

DirX Access V8.3 10 System Requirements for DirX Access V8.3

Supported Policy Enforcement Points/Resource Explorer and Client SDK: The following combinations are supported. Other PEPs may be available on request.

Microsoft Windows Oracle Solaris 11 Red Hat Enterprise SUSE Linux Enter- Server 2008 R2, (Sparc) Linux 6 prise Server 11 2012, 2012 R2 Web Server PEPs and Explorers Apache httpd 2.2 Yes3) Yes1) Yes1) Yes1) Apache httpd 2.4 Yes4) Yes4) Yes4) Yes4) Reverse proxy (based on Yes3) Yes1) Yes1) Yes1) Apache httpd 2.2) Apache Tomcat 6.0/7.0/8.0 Yes5) Yes5) Yes5) Yes5) Microsoft IIS 7.0/7.5/8.0/8.5 Yes2) - - - Application Server PEPs JBoss Application Server 5.1.0GA Yes Yes Yes Yes SAP NetWeaver 7.0 Yes Yes Yes Yes Oracle/BEA Weblogic 10.3.2 Yes Yes Yes Yes IBM WebSphere 6.1 Yes Yes Yes Yes Servlet and Application-specific PEPs Servlet filter e.g. Tomcat, Jetty, Yes Yes Yes Yes etc. SOAP PEPs JAX-WS Yes Yes Yes Yes Microsoft WCF Yes - - - Client SDK support (Legacy application PEPs and Explorers) DirX Access Client SDK for Java Yes Yes Yes Yes 1.5 or higher (with samples for AOP PEPs and Tomcat Servlet container PEP)

1) Available as 32- and 64-bit PEP 2) Available as 32- and 64-bit PEP for Windows Server 2008/IIS 7.0, as 64-bit PEP for Windows Server 2008 R2/IIS 7.5, Windows Server 2012/IIS 8.0, Windows Server 2012 R2/IIS 8.5 3) Available as 32-bit PEP 4) Available as 64-bit PEP 5) Apache Tomcat 7.0 and 8.0 are supported via servlet filter PEP

11 DirX Access V8.3 System Requirements for DirX Access V8.3

Hardware Software User interface  Intel server platform for Microsoft Windows DirX Access Server Support English Server 2008 R2, Microsoft Windows Server DirX Access Server as a Java application is 2012, Microsoft Windows Server 2012 R2, supported on the following platforms with latest Linux patches/service packs for the selected platform: Documentation  Fujitsu PRIMEPOWER Sparc  Microsoft Windows Server 2008 R2 (x86-64)  Release Notes  Sparc processors for Oracle Solaris  Microsoft Windows Server 2012 (x86-64) (Textfile, English)  Microsoft Windows Server 2012 R2 (x86-64)  Installation Guide Memory Requirements:  Oracle Solaris 11 (Sparc) (Manual, English) Main memory: minimum 2 GB  Red Hat Enterprise Linux 6 AP (x86-64)  Administration Guide Disk Space: minimum 1 GB plus disk  SUSE Linux Enterprise Server 11 (x86-64) (Manual, English) space for data  Migration Guide Virtual Machine Support: (Manual, English) VMWare ESXi 5.1, in combination with guest  Integration Guide operating systems listed above that are sup- (Manual, English) ported by VMWare ESXi 5.1  Web Sample Scenario Guide (Manual, English) Supported LDAP Directories for Configura-  Web Services Sample Scenario Guide tion/Policy Data: (Manual, English) DirX Access supports the following LDAP direc-  Client SDK Documentation tories (others on request): (JavaDoc, English)  DirX Directory V8.1/V8.2  OpenDJ 2.5  Windows Server 2008/2012/2012 R2 Active Directory / Active Directory Lightweight Di- rectory Services (AD LDS)

Supported Directories for User Data: Arbitrary LDAPv3-compliant directory servers with user accounts based on the InetOrgPerson object class

Browser Support for the DirX Access Manag- er and Deployment Manager  Microsoft Internet Explorer 8 or newer  Firefox 17 or newer

Supported PEPs, Explorers and Application Servers: These components are listed on the previous page.

DirX Access V8.3 12 About Atos

Atos SE (Societas Europaea) is an international information technology services company with Legal remarks annual 2012 revenue of EUR 8.8 billion and 77,000 employees in 47 countries. Serving a On account of certain regional limitations of Note: Any technical data contained in this global client base, it delivers IT services in 3 sales rights and service availability, we can- document may vary within defined tolerances. domains, Consulting & Technology Services, not guarantee that all products included in Original images always lose a certain amount Systems Integration and Managed Services & BPO, this document are available through the Atos of detail when reproduced. and transactional services through Worldline. sales organization worldwide. Availability and With its deep technology expertise and industry packaging may vary by country and is subject knowledge, it works with clients across the to change without prior notice. Some/All of the following market sectors: Manufacturing, Retail & features and products described herein may Services; Public sector, Healthcare & Transport; not be available in the United States or Japan. Financial Services; Telecoms, Media & Technology; Energy & Utilities. The information in this document contains general technical descriptions of specifications Atos is focused on business technology that and options as well as standard and optional powers progress and helps organizations to features which do not always have to be pre- create their firm of the future. It is the Worldwide sent in individual cases. Atos reserves the right Information Technology Partner for the Olympic to modify the design, packaging, specifications and Paralympic Games and is quoted on the NYSE and options described herein without prior Euronext Paris market. Atos operates under the notice. Please contact your local Atos sales brands Atos, Atos Consulting & Technology representative for the most current information. Services, Worldline and Atos Worldgrid.

For more information, contact: [email protected]

Atos, the Atos logo, Atos Consulting, Atos Sphere, Atos Cloud, Atos Worldgrid and Worldline are registered trademarks of Atos SE. atos.net/identity All trademarks are the property of their respective owners. December 2013© 2013 Atos.