CA Strong Authentition Installation Guide
Strong Authentication is a trusted service that verifies and protects the identity of your end users by securing passwords (either in clear or encrypted form) over the network, enabling you to select the authentication method that best suits the security and convenience of different users, and using CA Auth ID and CA Auth ID OTP, which are based on the patented Cryptographic Camouflage technique to protect keys. In Cryptographic Camouflage, a series of keys are generated which look valid enough to fool an attacker. This method protects a user's private key against dictionary attacks and Man-in-the-Middle (MITM) attacks, as a smartcard does, but entirely in the software format.
Advertisement
Advertisement
CA Strong Authentication
Installation Guide for Microsoft Windows
8.0
This Documentation, which includes embedded help systems and electronically distributed materials (hereinafter referred to as the “Documentation”), is for your informational purposes only and is subject to change or withdrawal by CA at any time. This
Documentation is proprietary information of CA and may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA.
If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy.
The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY
KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE,
DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST
INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE
POSSIBILITY OF SUCH LOSS OR DAMAGE.
The use of any software product referenced in the Documentation is governed by the applicable license agreement and such license agreement is not modified in any way by the terms of this notice.
The manufacturer of this Documentation is CA.
Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or their successors.
Copyright © 2014 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Contact CA Technologies
Contact CA Support
For your convenience, CA Technologies provides one site where you can access the information that you need for your Home Office, Small Business, and Enterprise CA
Technologies products. At
http://ca.com/support
, you can access the following resources:
■
Online and telephone contact information for technical assistance and customer services
■
Information about user communities and forums
■
Product and documentation downloads
■
CA Support policies and guidelines
■
Other helpful resources appropriate for your product
Providing Feedback About Product Documentation
If you have comments or questions about CA Technologies product documentation, you can send a message to
[email protected]
.
To provide feedback about CA Technologies product documentation, complete our short customer survey which is available on the CA Support website at
http://ca.com/docs
.
Contents
Chapter 1: Introduction 9
Chapter 2: Plan the Deployment 23
Chapter 3: System Requirements 37
Chapter 4: How to Configure the Database Server 39
Contents 5
Chapter 5: Pre-Installation Checklist 44
Chapter 6: Deploy Strong Authentication on a Single System 49
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 74
Chapter 8: How to Run a Silent Mode Installation 97
Chapter 9: Uninstall Strong Authentication 104
6 Installation Guide for Microsoft Windows
Chapter 10: Configure UTF-8 Support on Client Systems 107
Appendix A: Changing HSM Configurations
Chapter 11: Requirements for Java-Dependent Components
109
111
Chapter 12: Requirements for HSM 111
Chapter 13: Strong Authentication Configuration for Oracle RAC 112
Appendix B: Additional Configurations for CA Adapter 2.2.7 117
Appendix C: Deploy Administrative Console on IBM WebSphere 121
Appendix D: Troubleshooting Strong Authentication Issues 123
Contents 7
Chapter 1: Introduction
With the exponential increase in cases of Internet-based fraud over the last few years, relying on user names and passwords for authentication is no longer sufficient.
Organizations want to increase the security of their authentication processes by reducing complexity. Organizations also want to reduce the risk of financial losses or brand damage while increasing customer and partner access to applications and data.
Strong Authentication is a trusted service that verifies and protects the identity of your end users by:
■
Securing passwords (either in clear or encrypted form) over the network.
■
Enabling you to select the authentication method that best suits the security and convenience of different users.
■
Using CA Auth ID and CA Auth ID OTP, which are based on the patented
Cryptographic Camouflage technique to protect keys.
In Cryptographic Camouflage, a series of keys are generated which look valid enough to fool an attacker. This method protects a user's private key against dictionary attacks and Man-in-the-Middle (MITM) attacks, as a smartcard does, but entirely in the software format.
See "How Cryptographic Camouflage Works" for more information.
This guide provides information for planning the deployment of Strong Authentication based on different solution requirements. Each solution consists of multiple components that interact with each other and other systems in an enterprise or multiple-network systems.
Strong Authentication enables upgrade to CA Auth ID for authentication, without changing the user login experience or critical business processes. Strong
Authenticationis also a Versatile Authentication Server (VAS) because it supports the implementation of a wide range of proprietary and open authentication mechanisms. In addition to supporting authentication by using Public Key Infrastructure (PKI) and one-time password (OTP/Activation Code), it is also designed to plug in any existing authentication methods.
The VAS functionality enables you to select the authentication method that best suits the needs of your end users. You can choose to:
■
Integrate with a variety of standard authentication interfaces.
■
Implement standards-based hardware or software authentication methods.
■
Add new authentication methods, such as CA Auth ID, while continuing to support legacy technology, such as OTP/Activation Code tokens.
■
Extend Strong Authentication VAS through plug-ins to perform proprietary authentication.
Chapter 1: Introduction 9
System Architecture
Important! This documentation contains the terms Arcot, WebFort , RiskFort, WebFort,
RiskMinder, and AuthMinder in some of its code objects and other artifacts. The term
ArcotID is now called as CA Auth ID. In addition, some of the topics in this guide do not follow the standard formatting guidelines.
This section contains the following topics:
System Architecture
Plug-ins
User Authentication
CA Auth ID Key Concepts
System Architecture
You can install Strong Authentication on a single system or distribute its components across multiple systems. To ensure maximum security of transactions, implement the architecture that is shown in the following figure:
■
Web Tier
■
Application Tier
■
Data Tier
The following subsections discuss the Strong Authentication components in each of these layers.
10 Installation Guide for Microsoft Windows
Web Tier
System Architecture
The web tier comprises of static (HTML) content and interacts directly with the user over a network or the Internet.
CA Auth ID Client (Java, Flash, or Native) is directed to the end user’s browser through web tier. CA Auth ID Client interacts with Strong AuthenticationServer for user authentication. It collects the CA Auth ID password, signs the challenge, and sends the signed challenge to the Strong AuthenticationServer for verification.
Note: See the CA CA Auth ID Client Reference Guide for information about the CA Auth
ID Client.
Chapter 1: Introduction 11
System Architecture
Application Tier
This layer constitutes Strong Authentication Server, your application that uses Strong
Authentication SDKs, and the application servers where the Administrative UI and the
User Data Service (UDS) reside.
Note: All components in this layer can be installed on one system or can be distributed across multiple systems.
■
Strong Authentication Server
Server component that processes issuance and authentication requests from your application through Strong AuthenticationSDKs.
■
■
CA Advanced Authentication
Web-based console for configuring server instances, communication mode between Strong Authentication components, authentication policies, credential profiles, managing credentials, and for managing organizations, administrators, and users.
User Data Service
■
■
■
■
The abstraction layer that provides access to user- and organization-related data from different types of user repositories, such as Relational Database Management
Systems (RDBMSs) and directory servers (LDAPs).
Authentication API
Java APIs invoked by your application to forward authentication requests to Strong
AuthenticationServer.
Credential Management API
Java APIs invoked by your application to forward issuance requests to Strong
AuthenticationServer to create and manage user credentials in Strong
Authentication.
User Management API
Web Services client invoked by your application to forward issuance requests to
UDS to create and manage users in Strong Authentication.
Sample Application
Sample Application demonstrates the usage of Strong Authentication Java APIs and how your application integrates with Strong Authentication. It also verifies if Strong
Authenticationwas installed successfully, and performs issuance and authentication operations.
12 Installation Guide for Microsoft Windows
Data Tier
System Architecture
The data tier comprises of RDBMSs that Strong Authentication uses to store configurations, credential information, and user data if other user repositories are not configured.
Hardware Security Module (HSM) is a part of this tier if it is used to encrypt user sensitive data.
Chapter 1: Introduction 13
Plug-ins
Plug-ins
Strong Authentication provides the following out-of-the-box authentication methods:
■
CA Auth ID
CA Auth ID is a CA-proprietary secure software credential that provides two-factor authentication. An CA Auth ID is a small data file that by itself can be used for strong authentication to a variety of clients such as, Web or Virtual Private
Networks (VPNs).
■
See "CA Auth ID Key Concepts" for more information about CA Auth ID.
Password
The user is issued a username and a password to log in to the system.
■
■
■
One-Time Password OTP/Activation Code
One-time password is another credential generated by Strong Authentication
Server. An OTP/Activation Code can be numeric or an alpha-numeric string. It can be configured as many times it is used.
OATH-Compliant One-Time Password
One-time passwords that are complaint to Open Authentication (OATH) standards.
Strong Authentication supports both counter-based OATH OTP Tokens (HOTPs) and time-based OATH OTP Tokens (TOTPs).
Question and Answer
■
■
Question and Answer (also known as QnA) is a challenge-response authentication mechanism. Users authenticate to Strong Authentication Server by providing correct answers for the questions they are asked. These Questions and Answers are set by the users themselves during registration.
CA MobileOTP
CA Auth ID OTP is compliant to OATH, Europay, MasterCard, and VISA (EMV) standards. If your application is integrated with CA Auth ID OTP, then it accepts the user’s password as an input and generates passwords (also known as passcodes) on the users’ device. The user submits this passcode to authenticate to your Web application. Based on the authentication result, user is granted or denied access to the protected application.
Passcode generation is an offline process, which means that your application need not be connected to Strong Authentication for generating passcodes.
LDAP Username-Password
Strong Authentication supports LDAP authentication, where the user credentials in the directory service are used to authenticate users.
You can issue one or more of these credentials to your users. You can also issue multiple credentials of the same type.
14 Installation Guide for Microsoft Windows
User Authentication
To extend the default authentication mechanisms, write Plug-Ins.
User Authentication
A user trying to access the web application protected by Strong Authentication can be authenticated using any of the out-of-the-box credentials supported by Strong
Authentication.
In all the authentication mechanisms, the client is provided with an authentication token after every successful authentication. The token proves the client's authentication to the server and is valid for an interval and subject to re-authentication.
All password type credentials namely, password, OTP/Activation Code, CA Auth ID OTP, and OATH OTP Token are based on the single-step authentication model. The credentials are passed by the client to the user and the server verifies the user credentials.
The following figure illustrates the typical authentication workflow.
However, CA Auth ID and QnA are based on the challenge-response authentication model. These authentication mechanisms include multiple steps to authenticate users.
Chapter 1: Introduction 15
User Authentication
Challenge-Response Authentication Workflow
Authentication using CA Auth ID is a PKI-based challenge-response mechanism. The client obtains an authentication token by providing the private key of the user. The client-server interactions during authentication are as follows:
1. Get User Credentials
Your application or the resource that is protected by Strong Authentication obtains the user credentials. For example, if the user’s CA Auth ID is not available on the system.
2. Get Appropriate Challenge
Your application request for a challenge.
Strong Authentication Server prepares a unique challenge and sends it to your application to authenticate the user.
3. Generate Signature
The user enters the correct CA Auth ID password to uncover the CA Auth ID. The client signs this challenge with the user’s private key that is available as a result of uncover. The challenge can either be pre-loaded on the client machine or downloaded from the server.
4. Verify Signed Challenge
The signed challenge is sent to the Strong Authentication Server for verification. If the signature is verified successfully, the user can login or access your protected resource. For every successful transaction, Strong Authentication also returns an authentication token for a user.
The following figure illustrates the CA Auth ID authentication flow.
16 Installation Guide for Microsoft Windows
CA Auth ID Key Concepts
CA Auth ID Key Concepts
This section introduces the key concepts of CA Auth ID, which is a prime credential that
Strong Authentication supports.
■
Introduction to CA Auth ID
■
CA Auth ID File Structure
■
How Cryptographic Camouflage Works
■
Support Roaming Download
■
CA Auth ID as a Secure Container (Key Authority)
■
CA Auth ID Client
Introduction to CA Auth ID
An CA Auth ID offers capabilities similar to physical smartcard for authentication, digital signing, encryption, and decryption for PKI-enabled applications, without requiring any end-user hardware. The CA Auth ID authenticates to any web application, even if that application does not support PKI-based authentication.
The following figure illustrates the use cases for CA Auth ID.
Chapter 1: Introduction 17
CA Auth ID Key Concepts
An CA Auth ID is a data file that is saved on an end user's computer, USB drive, or downloaded remotely for secure on-demand authentication. An CA Auth ID is not vulnerable to phishing attacks like brute force password attacks and man-in-middle attacks.
An CA Auth ID is used for strong authentication with a variety of applications, such as the Web or Virtual Private Networks (VPNs).
The CA Auth ID is a configurable solution that bridges the gap between simple-but-insecure username-password-authentication and expensive-difficult-to-deploy, but very secure smartcard and USB token solutions.
The CA Auth ID is based on industry standards and CA-patented Cryptographic
Camouflage technology to provide software-only, strong authentication that is protected against brute force attacks.
Although an CA Auth ID is protected by a password, it supports the following features to provide strong authentication:
■
Only the correct CA Auth ID password can access an CA Auth ID.
■
A plausible response is generated for every CA Auth ID password entered, even if it is incorrect. Offline identification of the CA Auth ID password is prevented.
■
The CA Auth ID authentication is a challenge-response authentication protocol, which ensures the user’s password is only used locally and never transmitted or verified at the server end.
■
Repeated incorrect CA Auth ID password entries locks out CA Auth ID depending on the maximum authentication attempts configured.
■
Is valid only in the domain that issued the CA Auth ID.
■
CA Auth IDs is only used online and the user must be connected to Strong
Authentication Server to validate their CA Auth ID password.
18 Installation Guide for Microsoft Windows
CA Auth ID Key Concepts
CA Auth ID File Structure
An CA Auth ID contains the following components:
1. A standard X.509v3 digital certificate with a CA-specific extension.
2. A second pair of public and private keys generated for authenticating to Strong
Authentication Server. It is not used for general signing or encryption.
The public key is stored in the encrypted format. It is encrypted using the Domain
Key, which is used to create and authenticate CA Auth IDs. You can configure a domain key at the global-level or at the organization-level. An CA Auth ID issued with the organization-specific domain key cannot be used across organizations.
The private key is cryptographically camouflaged by using the CA Auth ID password.
3. A section to store the user’s Open PKI keys and certificates to sign, encrypt and decrypt. See "CA Auth ID as a Secure Container (Key Authority)" for more information.
How Cryptographic Camouflage Works
The use of public key cryptographic signatures and authentication protocols is becoming more common with the advent of support for public key cryptography in Web browsers.
The security of the private key, however, remains a problem. The most basic threat is the theft of a private key that is stored on a disk. Usually such a key is stored in a software key container, a file, wherein the keys are encrypted by using a password. An attacker who steals the container can try to guess the password using a dictionary attack.
To overcome such problems, Strong Authentication provides a method for secure storage of private keys in software, using cryptographic camouflage. Attacks on the key container are inherently supervised. The key container embeds the user’s private key among spurious private keys. An attacker who tries to crack the key container will recover many plausible private keys. The attacker will not be able to distinguish the correct private key from the spurious decoys until they use the keys to sign the challenge and send it to Strong Authentication Server. Strong Authentication Server notices the multiple authentication failures and suspends the user’s access.
Chapter 1: Introduction 19
CA Auth ID Key Concepts
Roaming Download
CA Auth ID can be downloaded using any device while traveling. This feature is known as
Roaming. Strong Authentication Server offers roaming capabilities to enable the user to securely download the CA Auth ID and authenticate from any system. Roaming facility provides instant access to critical data and services whenever required, keeping data safe from unauthorized access.
A roaming user can be authenticated using QnA, OTP, or any customized third-party solutions.
CA Auth ID as a Secure Container (Key Authority)
CA Auth ID can also be used as a secure container to store digital certificates and private keys that can be used for different applications or operations such as, email signing
(S/MIME), document signing, certificate-based authentication (open PKI). This process of managing private key storage in the CA Auth ID is performed by Key Authority (KA).
An unsigned attribute referred to as Key Bag or Key Vault, is created in the CA Auth ID to store these credentials. The digital certificates are stored in an unencrypted format in the Key Bag. The private keys are encrypted using a key called Key Authority key, stored in the Strong Authentication database.
To use the private keys that are stored in a Key Bag, the CA Auth ID Client (see "CA Auth
ID Client") makes a request for the KA key to Strong Authentication Server by signing the request with the user’s private key. The Strong Authentication Server authenticates the incoming request and sends the KA key to the client, to open the Key Bag and access the private keys.
The following figure illustrates how to use CA Auth ID as an open PKI container.
20 Installation Guide for Microsoft Windows
CA Auth ID Key Concepts
CA Auth ID Client
The CA Auth ID Client software is used with Strong Authentication Server. The CA Auth
ID Client enables an end user to use an CA Auth ID in a web browser to authenticate to a website, VPN, or other online resources.
To support a wide variety of application environments (operating systems, browsers,
JVMs), the CA Auth ID Client is available in a variety of flavors, such as:
■
Native Client
■
Flash Client
■
Java Signed Applet
■
Java Unsigned Applet
■
JavaScript Client
Note: See the CA CA Auth ID Client Reference Guide for more information about these client types.
Chapter 1: Introduction 21
Chapter 2: Plan the Deployment
This chapter helps you to select a deployment model, and determine the components and prerequisite software to install on each system.
Note: In this guide, system refers to a physical device and server refers to the software that is run on the system.
The chapter covers the following topics:
■
Deployment Overview for Fresh Install
■
Choose a Deployment Model
Chapter 2: Plan the Deployment 23
Deployment Overview for Fresh Install
Deployment Overview for Fresh Install
This section briefly outlines the steps for deploying Strong Authentication:
Deployment of Strong Authentication involves the steps as outlined in this illustration:
24 Installation Guide for Microsoft Windows
Deployment Overview for Fresh Install
Chapter 2: Plan the Deployment 25
Deployment Overview for Fresh Install
1. Choose a deployment model that suits your business needs. Strong Authentication can be installed on a single system or across multiple systems.
See "Deployment Model" for more information.
2. Configure the database server where you plan to seed the Strong Authentication schema:
■
See "Configuring Microsoft SQL Server" for more information about configuring the MS SQL Server database.
■
See "Configuring Oracle Database" for more information about configuring the
Oracle Database.
■
See "Configuring IBM DB2 Universal Database" for more information about configuring the IBM DB2 database.
■
See "Configuring MySQL" for more information about configuring the MySQL database.
3. Install Strong Authentication:
■
See "Deploying Strong Authentication on a Single System" for single-system deployment.
■
See "Deploying Strong Authentication on Distributed Systems" for distributed-system deployment.
4. Run SQL scripts in the database to create the Strong Authentication schema and set initial configuration values:
■
■
See "Running Database Scripts" for single-system deployment.
See "Running Database Scripts" for distributed-system deployment.
5. Copy required files and JARs on your application server. CA Advanced
Authentication and the User Data Service use these files for proper functioning:
■
See "Preparing Your Application Server" for more information about copying the files for single-system deployments.
■
See "Preparing Your Application Server" for more information about copying the files for distributed deployments.
6. Deploy CA Advanced Authentication:
■
See "Deploying CA Advanced Authentication" for more information about deploying CA Advanced Authentication for single-system deployments.
■
See "Deploying CA Advanced Authentication" for more information about deploying CA Advanced Authentication for distributed-system deployments.
7. Log in to CA Advanced Authentication as Master Administrator and initialize Strong
Authentication:
■
See "Logging In to CA Advanced Authentication" and "Bootstrapping the
System" for more information about initializing CA Advanced Authentication for single-system deployments.
26 Installation Guide for Microsoft Windows
Deployment Overview for Fresh Install
■
8. Start the Strong Authentication Server and verify that the service has coming up correctly:
■
See "Starting Strong Authentication Server" and "Verifying the Installation" for more information about starting the Strong Authentication Server for single-system deployments.
■
See "Logging In to CA Advanced Authentication" and "Bootstrapping the
System" for more information about initializing CA Advanced Authentication for distributed-system deployments.
See "Starting Strong Authentication Server" and "Verifying the Installation" for more information about starting the Strong Authentication Server for distributed-system deployments.
9. Deploy and run the Sample Application to test Strong Authentication installation:
■
See "Deploying Sample Application" and "Using Sample Application" for more information about doing this in a single-system environments.
■
See "Deploying Sample Application", "Configuring Sample Application for
Communication with Strong Authentication Server", and "Using Sample
Application" for more information about doing this in a distributed environment.
10. (Optional) Deploy User Data Service (UDS) only if you want to use directory service as user repository:
■
See "Deploying User Data Service" for more information about deploying and starting UDS for single-system deployments.
■
See "Deploying User Data Service" for more information about deploying and starting UDS for distributed deployments.
Chapter 2: Plan the Deployment 27
Deployment Models
Deployment Models
Strong Authentication Server is the primary component that you install to authenticate users during deployment. Your applications on Strong Authentication Server can integrate with it by using Java SDKs or Web Services shipped with it.
An SQL database is required for storing server configuration data, user-specific preferences, and usage data.
Typically, all Strong Authentication components are installed on a single system for development and simple testing. However, in production deployments and staging environments, we recommended that Strong Authentication server be installed on its own system. The shipped SDKs or Web Services are installed on a different system or on systems that contain the application that users log in to.
Strong Authentication is also shipped with Sample Application to verify if it is installed properly and is able to perform user authentication. Sample Application also serves as a code sample for integrating Strong Authentication with existing application(s).
The high-level deployment types supported by Strong Authentication are:
■
Single-System Deployment - For development or testing
■
■
See "Deploy on a Single System" for more information.
Distributed-System Deployment - For production or staging environments
See "Deploy on Distributed Systems" for more information.
High-Availability Deployment - For high availability and scalability, production, or staging environments
See "Deploy in High-Availability Environment" for more information.
Single System Deployment
In a single-system deployment, all components of Strong Authentication and the Web applications are installed on a single system. The database can be on the same system where Strong Authentication is installed, or on a different system. This deployment model is typically used for development, proof of concept, or initial testing.
It is possible to use both Java SDKs and Web services in a single-system deployment.
To deploy Strong Authentication on a single system, choose the Complete option during
Strong Authentication installation.
28 Installation Guide for Microsoft Windows
Deployment Models
Component Diagrams
The component diagrams depict a few deployment options for prerequisite software and Strong Authentication components. If you perform a Complete install, then both
Java SDKs and Web services are on the system. You can use any of these methods for integrating Strong Authentication with your Web application.
■
Deploying Java SDKs
■
Deploying Web Services
Decision Points
If you plan to perform a single-system deployment, make the following decisions:
■
Install a database server on the system which has Strong Authentication Server, or use an existing database on a separate system.
■
Use Sample Application or write my own Web application.
Important! Sample Application must not be used in production deployments. We recommend that you build your own Web application by using Sample Application as a code-reference.
■
Use Java SDKs or Web services to integrate with your own Web application.
Deploying Java SDKs
The following sections are designed to help you achieve your deployment decision.
The following figure illustrates deployment of Strong Authentication Server and Java
SDKs on a single system.
Chapter 2: Plan the Deployment 29
Deployment Models
Note: The use of a Web server to deliver HTML pages for the application server is optional and is transparent to Strong Authentication . In production deployments, this approach is used to improve Application Server performance and security. See the documentation of your Application Server for detailed information.
Deploying Web Services
If you plan to deploy Web services, then the following figure illustrates Strong
Authentication Server and Web Services on a single system.
Note: Because all Web Services are now built into the Strong Authentication server module itself, you need to install the Strong Authentication server on the target system and generate the requisite client stubs. No further configuration is required.
Distributed Systems Deployment
In a distributed-system deployment, Strong Authentication components are installed on different systems to increase security and performance. This model is typically used for production deployments or staging environments.
The most common deployment is to install Strong Authentication server on one system and one or more Web applications on additional systems. To deploy Strong
Authentication on distributed systems, you must choose the Custom option during
Strong Authentication installation. See chapter, "Deploying Strong Authentication on
Distributed Systems" for more information about the installation and post-installation steps.
30 Installation Guide for Microsoft Windows
Deployment Models
Component Diagrams
The diagrams in this section depict the options where prerequisites and Strong
Authentication components can be installed on multiple systems:
■
Deploying Single Application with Java SDKs
■
Deploying Multiple Applications with Java SDKs
■
Deploying Single Application with Web Services
The following sections will help you to achieve your deployment decision.
Deploying Single Application with Java SDKs
The following figure illustrates deployment of Strong Authentication using Java SDKs on a single application.
Chapter 2: Plan the Deployment 31
Deployment Models
Deploying Multiple Applications with Java SDKs
The following figure illustrates Strong Authentication deployment using Java SDK on multiple applications.
32 Installation Guide for Microsoft Windows
Deployment Models
Deploying Single Application with Web Services
The following figure illustrates Strong Authentication deployment using Web Services on a single application.
High-Availability Deployment
In a high-availability deployment, Strong Authentication components are installed on more than one servers to provide high availability and scalability.
Chapter 2: Plan the Deployment 33
Deployment Models
Component Diagrams
The diagrams in this section depict the options for which prerequisites and Strong
Authentication components can be installed on multiple systems for a high-availability deployment.
Decision Points
■
■
When do I add a new server instance?
Typically, when your transaction rate exceeds the allowable threshold (as decided by your organizational policies), then you need to add a new server instance.
How many Strong Authentication server, CA Advanced Authentication, UDS, and
SDK instances can I have?
■
Strong Authentication Servers: Multiple instances are supported. The number depends on the transaction rate you want to achieve.
■
CA Advanced Authentication: Multiple instances are supported. The number depends on the number of administrators in the system who log in to the
Console simultaneously.
■
UDS Servers: Currently, only one is supported. But if you need multiple instances of UDS, then you need to put them behind a Load Balancer. However,
UDS failover is not supported.
■
SDKs: Multiple instances are supported. This number depends on the number of your application instances that you plan to support.
The following sections will help you to achieve your deployment decision.
■
High-Availability Deployment Using Java SDK
■
High-Availability Deployment Using Web Services
34 Installation Guide for Microsoft Windows
Deployment Models
High-Availability Deployment Using Java SDK
The following figure illustrates multiple-instance deployment of Strong Authentication using Java SDK.
High-Availability Deployment Using Web Services
The following figure illustrates multiple-instance deployment of Strong Authentication using Web Services.
Chapter 2: Plan the Deployment 35
Hardware Requirements
Hardware Requirements
The minimum hardware requirements for installing include:
■
Requirements for Strong Authentication and Risk Authentication with database on a single system:
■
■
RAM: 2 GB
Hard Drive Space: 10 GB
■
■
■
■
Processor: 2.4 GHz
Requirements for Strong Authentication and Risk Authentication with database on a separate system:
■
RAM: 1 GB
Hard Drive Space: 300 MB
Processor: 2.4 GHz
Note: Hardware resource requirements vary substantially for different applications and usage patterns. it is recommended that you load-test your site to determine the optimal memory that is required for the installation. While load-testing, keep in mind that some operating system utilities for monitoring memory can overstate memory usage (partially because of the representation of shared memory.) The preferred method for determining memory requirements is by monitoring the improvement in performance after adding more RAM/physical memory in the load test. See your platform vendor documentation for information about how to configure memory and processor resources for testing purposes.
36 Installation Guide for Microsoft Windows
Chapter 3: System Requirements
This section contains the following topics:
Hardware Security Module (HSM) Requirements
Software Requirements
Hardware Security Module (HSM) Requirements
You can now store sensitive keys either in the database or in an HSM. Currently, you can store the various encryption keys and the Strong Authentication Server listener SSL key in the HSM. The following table lists the requirements for the supported HSM modules.
HSM Module
Java Cryptography Extension
(JCE)
PKCS #11
Thales nCipher netHSM
(or nCipher netHSM)
SafeNet High Availability HSM
(or Luna HSM)
JCE framework provided with the 32-bit versions of JDK 5.0,
JDK 6.0, and JDK 7.0 pkcs11v2.01
Note: The decision to use and configure an HSM, if required, must be made while you are still in the planning and preparation stages. Otherwise, you will need to re-initialize the database later, because all your current encryption would use keys in software.
Software Requirements
The following sections provide information about software requirements:
Chapter 3: System Requirements 37
Hardware Requirements
Strong Authentication Component-Specific Prerequisites
The prerequisite software is determined by the Strong Authentication components that will be installed on a system.
The following table indicates the prerequisite software that is required by each Strong
Authentication component:
Prerequisite
Component
Database
Server
JDK
Application
Server
Strong Authentication Server
+
Administration Console +*
+
User Data Service +*
+
Authentication Java SDK +*
Credential Management Java SDK
User Management Web Service
Authentication Web Service
Credential Management Web
Service
Sample Application
+*
+*
+*
+*
+*
The following 32-bit binaries are required for Strong Authentication to function on an
RHEL 6.x 64-bit computer. If you are planning to install Strong Authentication, you can use the yum utility to install these binaries.
■ ibgfortran-4.4.5-6.el6.i686.rpm
■ libstdc++-4.4.5-6.el6.i686.rpm
■ libgomp-4.4.5-6.el6.i686.rpm
■ libstdc++-devel-4.4.5-6.el6.i686.rpm
■ compat-libtermcap-2.0.8-49.el6.i686.rpm
■ ncurses-libs-5.7-3.20090208.el6.i686.rpm
■ ncurses-5.7-3.20090208.el6.i686.rpm
* The JDK depends on the application server that you use.
+
+
+
+
+
+
+
+
38 Installation Guide for Microsoft Windows
Hardware Requirements
Chapter 4: How to Configure the Database
Server
Before you install Strong Authentication, set up a database to store user information, server configuration data, audit log data, and other information.
Strong Authentication supports a primary database and a backup database that can be used during failover and failback in high-availability deployments. Database connectivity can be configured in either of the following ways:
■
Automatically during installation, when the Installer edits the arcotcommon.ini file with the database information you supply.
■
Manually by:
■
Creating the Data Source Name (DSN)
■
■
Editing the arcotcommon.ini file.
Updating securestore.enc using the dbutil tool
There are specific configuration requirements for each supported database. Use the following information to set up the database server yourself, or provide this information to your database administrator (DBA) when you request a database account.
Note: For JBoss Application Server, follow the below steps while configuring a backup database: a. Edit module.xml in
<JBOSS_HOME>\modules\system\layers\base\sun\jdk\main with the following statements
<path name="com/sun/rowset"/>
<path name="com/sun/rowset/internal"/>
<path name="com/sun/rowset/providers"/>
Restart the application server.
Important! To protect the database, it is recommended that you ensure that the database server is protected with firewall or other access control mechanisms and is set to the same time-zone as all related products.
■
Configuring Microsoft SQL Server
■
Configuring Oracle Database
■
Configuring IBM DB2 Universal Database
■
Configuring MySQL
Chapter 4: How to Configure the Database Server 39
SQL Server Configuration
SQL Server Configuration
This section provides the following configuration information for Microsoft SQL Server.
Important! Verify that Microsoft SQL Server is configured to use the SQL Server
Authentication authentication method.
Note: See Microsoft SQL Server documentation for detailed information about performing the tasks that are listed in this section.
Use the following criteria to configure the database:
1. The recommended name is arcotdb.
2. The database size must be configured to grow automatically.
3. Create a Database User
Create a Database User
Perform the following steps to create a database user:
Follow these steps:
1. In the SQL Server Management Studio, go to <SQL_Server_Name>, expand the
Security folder, and then click Logins.
Note: The <SQL_Server_Name> refers to the host name or IP address of the SQL
Server where you created your database.
2. Right-click the Logins folder, and click New Login.
3. Enter the Login name. The recommended name is arcotuser.
4. Set the following parameters: a. Authentication to SQL Server Authentication. b. Specify Password and Confirm password for the login.
Ensure that you specify other password settings on this page according to your organization’s password policies. c. Default database to the database (arcotdb) you created. d. User Mapping for the login (in the Users mapped to this login section). e. User Mapping (SQL 2005) for the default database to db_owner (in the
Database role membership for: <db_name> section).
40 Installation Guide for Microsoft Windows
Oracle Database Configuration
Oracle Database Configuration
This section provides the configuration information for Oracle Database and Strong
Authentication Server.
Note: See the Oracle Database documentation for details about performing the tasks that are listed in the following sections.
Running Strong Authentication on Oracle requires two tablespaces:
■
The first tablespace is used for configuration data, audit logs, and user information.
This tablespace can be the default user tablespace.
■
See "Creating a New Database" for creating a database.
The second tablespace is used to run reports. For high performance, it is recommended that you use a separate tablespace.
If the database user running the script has sufficient permissions to create a tablespace, the database configuration script (arcot-db-config-for-common-8.0.sql) automatically creates the reports tablespace. If the user does not have the required permissions, a
DBA can manually create the reports tablespace and delete the section in this script that creates this tablespace.
If a tablespace with that name already exists, then it is removed and re-created.
Important! The parameters for creating the reports tablespace in the arcot-db-config-for-common-8.0.sql database script can be changed according to the
DBA's preferences. However, ensure that the tablespace name is ARReports.
Chapter 4: How to Configure the Database Server 41
Oracle Database Configuration
Create a Database
Create a database to store information in the UTF-8 character set. This allows Strong
Authentication to use international characters including double-byte languages.
Follow these steps:
1. Log in to the Oracle database server as SYS or SYSTEM.
2. Run the following command:
Update sys.props$ set value$='UTF8' where name='NLS_NCHAR_CHARACTERSET' Or name = 'NLS_CHARACTERSET';
3. Restart the database, and check whether the character set is configured to UTF-8.
4. Create a user (the recommended name is arcotuser) in the new database arcotdb.
5. Set the quota of user to at least 5 to 10 GB for a development or test deployment, which is primarily used for audit logs.
Note: If the deployment is for production, staging, or other intensive testing, see appendix, "Database Reference" to determine the quota required for a user.
6. Grant the user the following privileges:
CREATE TABLE
CREATE INDEX
CREATE SEQUENCE
CREATE PROCEDURE
CREATE SESSION
DML PRIVILEGES
RESOURCE PRIVILEGES
CONNECT PRIVILEGES
ALTER TABLE
■
Additional privileges for upgrade only:
ALTER EXTENT PARAMETERS
CREATE TABLESPACE
■
Additional privileges for working with reports:
UNLIMITED TABLESPACE
(Optional) DROP TABLESPACE
42 Installation Guide for Microsoft Windows
IBM DB2 Universal Database Configuration
IBM DB2 Universal Database Configuration
This section provides the following configuration information for IBM DB2 Universal
Database (UDB):
Create a database (the recommended name is arcotdb) to store information in the
UTF-8 character set. This allows Strong Authentication to use international characters including double-byte languages.
1. Log in to the IBM DB2 UDB database server.
2. Run the following command to enable UTF-8 support: create db <DB-NAME> using codeset utf-8 territory us;
3. Set the tablespace page size to 16K. Default is 4K.
See the vendor documentation for more information about changing the tablespace page size.
4. If your data volume is high, then the default size of the transaction log file may be insufficient. Therefore, it is recommended that you increase the log file size.
See the vendor documentation for more information about changing the log file size.
5. Ensure that the configuration changes have been applied.
If you plan to use an alternate schema, then see appendix, "Configuring Alternate
Schema for IBM DB2 Universal Database" for more information.
6. Create a user (recommended name is arcotuser), with a schema in the new database arcotdb.
7. Grant the user the following privileges:
CREATE TABLE
CREATE INDEX
CREATE SEQUENCE
CREATE PROCEDURE
CREATE SESSION
DML PRIVILEGES
CONNECT PRIVILEGES
ALTER TABLE
■
Additional privileges for upgrade only:
CREATE TABLESPACE (with AUTORESIZE = yes)
■
Additional privileges for working with reports:
DROP TABLESPACE
Chapter 4: How to Configure the Database Server 43
MySQL Database Configuration
MySQL Database Configuration
This section provides the following configuration information for MySQL database.
Strong Authentication uses the InnoDB storage engine of MySQL. To check whether this storage engine is supported by your MySQL installation, use the SHOW ENGINES command. If the output of this command shows that InnoDB is not supported, enable support for InnoDB.
Note: For information about the procedure to enable support for InnoDB, see MySQL documentation.
1. Open a MySQL command window.
2. Run the following command to create the database schema:
CREATE SCHEMA '<schema-name>' DEFAULT CHARACTER SET utf8;
3. Run the following command to create the database user:
CREATE USER '<user-name>' identified by '<user-password>';
4. Create a user (recommended name is arcotuser) in the new database arcotdb.
5. Grant the following privileges to the user:
Objects rights:
SELECT
INSERT
UPDATE
DELETE
EXECUTE
DDL rights:
CREATE
ALTER
CREATE ROUTINE
ALTER ROUTINE
DROP
Other rights:
GRANT OPTION
Chapter 5: Pre-Installation Checklist
44 Installation Guide for Microsoft Windows
MySQL Database Configuration
It is recommended that you complete this checklist before you proceed with the installation and setup of Strong Authentication.
Note: The items and values in the following checklist are samples. Before you begin installation, modify this checklist so that it meets the requirements of your operating environment.
Your Information Example Entry Your Entry
HARDWARE
Processor Intel Xeon X5450 3
GHz
2 GB
20 GB
RAM
Disk Space
SOFTWARE
Operating System
Distribution
Service Pack (or Patch)
DATABASE
Type
Database Name (MS SQL and DB2
Only)
DSN Name
Host Name (or Server IP Address)
Port
Service ID (Oracle Databases Only)
Database User
Database Login Password
Configured Privileges:
Note: For all CREATE privileges, the corresponding DROP privilege is implied.
Windows Server 2003
Enterprise Edition
SP3
Oracle arcotdb arcotdsn
51.100.25.24
1521 oradb1 arcotuser password1234!
Oracle Database
CREATE TABLE
CREATE INDEX
CREATE SEQUENCE
CREATE PROCEDURE
Chapter 5: Pre-Installation Checklist 45
MySQL Database Configuration
Your Information
CREATE SESSION
DML PRIVILEGES
RESOURCE PRIVILEGES
CONNECT PRIVILEGES
ALTER TABLE
(For Upgrade Only)
ALTER EXTENT PARAMETERS
CREATE TABLESPACE
(For Reports)
UNLIMITED TABLESPACE
(For Reports, Optional)
DROP TABLESPACE
MS SQL Server
Note: The user performing these actions must belong to the ddladmin role.
CREATE TABLE
CREATE INDEX
CREATE PROCEDURE
REFERENCES
DML PRIVILEGES
CONNECT PRIVILEGES
ALTER
(For Upgrade Only)
DB2 Database
CREATE TABLE
CREATE INDEX
CREATE SEQUENCE
CREATE PROCEDURE
CREATE SESSION
DML PRIVILEGES
CONNECT PRIVILEGES
Example Entry
46 Installation Guide for Microsoft Windows
Your Entry
MySQL Database Configuration
Your Information
ALTER TABLE
(For Upgrade Only)
CREATE TABLESPACE (with
AUTORESIZE = yes)
(For Reports )
DROP TABLESPACE
MySQL
SELECT
INSERT
UPDATE
DELETE
EXECUTE
CREATE
ALTER
CREATE ROUTINE
ALTER ROUTINE
DROP
GRANT OPTION
APPLICATION SERVER
Type
Host Name
Port
JDK
DIRECTORY SERVICE (OPTIONAL)
Host Name
Port
Schema Name
Base Distinguished Name
User Name
Password
Example Entry
Apache Tomcat 5.5 localhost
8080
1.5.0_10 ds.myldap.com
389 inetorgperson or user dc=myldap,dc=com cn=admin,cn=Adminis trators,cn=dscc mypassword1234!
Your Entry
Chapter 5: Pre-Installation Checklist 47
MySQL Database Configuration
Your Information
WEB SERVER (OPTIONAL)
Type
Host Name
Port
Example Entry
IIS 6 mywebserver.com
443
Your Entry
48 Installation Guide for Microsoft Windows
Chapter 6: Deploy Strong Authentication on a Single System
Use the Strong Authentication 8.0 InstallAnywhere Wizard to install Strong
Authentication components. This Wizard supports Complete and Custom installation types. However, to install and configure Strong Authentication on a single computer, use the Complete option when you run the installer.
The following list provides a quick overview of the process:
1. Execute the Strong Authentication installer to add Strong Authentication components to your file-system and configure them to access your SQL database.
See "Performing Complete Installation" for install instructions.
2. Execute the database scripts to create schema and database tables. Verify that the database setup was successful.
See "Running Database Scripts" and "Verifying the Database Setup" for more information.
3. Prepare the application server to copy the files that CA Web components use.
See "Preparing Your Application Server" for more information.
4. Deploy CA Advanced Authentication on the application server and verify the deployment.
See "Deploying CA Advanced Authentication" and "Verifying CA Advanced
Authentication" for more information.
Chapter 6: Deploy Strong Authentication on a Single System 49
MySQL Database Configuration
5. Log in to CA Advanced Authentication as the Master Administrator to initialize
Strong Authentication.
See "Logging In to CA Advanced Authentication" and "Bootstrapping the System" for more information.
6. Start the Strong Authentication Server and verify if the service starts successfully.
See "Starting Strong Authentication Server" and "Verifying the Installation" for more information.
7. Deploy User Data Service on the application server and verify the deployment.
See "Deploying User Data Service" for more information.
8. Deploy and use Sample Application to test Strong Authentication configuration.
Note: Sample Application is automatically installed as a part of Complete installation.
See "Deploying Sample Application" and "Using Sample Application" for more information.
9. (Optional) To ensure secure communication between Strong Authentication components, you can configure them to support SSL (Secure Socket Layer) transport mode.
See appendix, "Configuring SSL" in Strong Authentication Administration Guide for more information.
10. Complete the installation checklist.
See "Post-Installation Checklist" for more information.
Important Notes Related to the Installation
Keep the following points in mind while installing Strong Authentication either on a single system or in a distributed environment:
■
Ensure that the <install_location> must not contain any special characters (such as ~
! @ # $ % ^ & * ( ) _ + = , -* + ’ ").
■
Currently, you cannot modify or repair Strong Authentication components by using the installer. Uninstall the component and then re-install it.
■
Do not close the installer window, if the installation is in progress. If at any time during installation (especially during the last stages), if you click the Cancel button to abort the installation, then the installer might not remove all the directories it has created so far. Manually clean up the installation directory,
<install_location>\Arcot Systems\ and its subdirectories.
■
If you run the installer on a system that already contains an instance of an existing
%ARCOT_HOME%, then:
■
You will not be prompted for an installation directory.
50 Installation Guide for Microsoft Windows
Perform Complete Installation
■
■
You will not be prompted for the database set up. The Installer will use the existing database.
You will also not be prompted to set up encryption.
The Strong Authentication installer supports the following types of installation. Use the
Complete installation for single-system deployment.
1. Complete - Installs all Strong Authentication components on a single system.
2. Custom - Installs the Strong Authentication components that you select.
Perform Complete Installation
To install Strong Authentication the user account for installation must belong to the
Administrators group.
To install all Strong Authentication components on a single system, use the Complete option. Custom installation, recommended for advanced users, allows installation of only the selected components from the package.
Follow these steps:
1. Locate the Strong Authentication installer Strong
Authentication-Windows-Installer.exe file in the installation package.
2. Double-click the installer file and click Next.
3. Accept the terms of the license agreement option, and click Next.
The installer checks if any other CA product is installed on the computer.
If it does not find an existing CA product installation, then you are prompted for an installation directory. In this case, the Installation Location screen appears.
If the installer detects an existing CA product installation, then you are not prompted for an installation directory. The following screen appears when an existing ARCOT_HOME is located on the computer.
4. Accept the default directory specified by the installer to install Strong
Authentication. You can also click Choose to navigate and to specify a different directory.
5. Click Next to install in the specified directory.
6. Select the Complete option to install all components and click Next.
The Database Type screen appears.
Chapter 6: Deploy Strong Authentication on a Single System 51
Perform Complete Installation
7. Select the database type, and click Next.
The corresponding Database Details screen appears.
Note: Strong Authentication supports Oracle Real Application Clusters (Oracle RAC).
To use Oracle RAC with your Strong Authentication Installation, select Oracle
Database in this step, and then perform the steps in Configuring CA Strong
Authentication for Oracle RAC.
■
Enter the following details for the database that you are using:
MS SQL database access: a. Enter the required information as described in the following table:
Field Description
Primary ODBC DSN The installer creates an ODBC connection that Strong
Authentication uses to connect to the database.
The recommended value to enter is arcotdsn.
Server The host name or IP address of the database server. If
SQL server is deployed in Named Instance mode, then you must also enter a slash "\" followed by the instance name, refer to vendor documentation for more information on this.
Default Instance
Syntax: <Server Name>
Example: demodatabase
Named instance
Syntax: <Server Name>\<instance name>
Example: demodatabase\instance1
User Name
Password
Database
The User Name that Strong Authentication uses to access the database (SQL Server refers to this as login).
This name is specified by the database administrator.
Note: The User Name for the Primary and Backup DSN must be different.
The password that Strong Authentication uses to access the database. This password is specified by the database administrator.
The name of the database that Strong Authentication will access.
Port Number The port on which the database server listens to the incoming requests.
52 Installation Guide for Microsoft Windows
Perform Complete Installation
■ b. Test for successful database connection by clicking Test Data Source. c. Click Next. d. Go to Step 8.
IBM DB2 (UDB) Database Details a. Enter the required information as described in the following table:
Field Description
Primary ODBC DSN
Server
User Name
Password
Port Number
Database
The installer creates an ODBC connection that Strong
Authentication uses to connect to the database.
The recommended value to enter is arcotdsn.
The host name or IP address of the database server.
If the database is deployed in Named Instance mode, then you must also enter a slash "\" followed by the instance name, refer to vendor documentation for more information on this.
Default Instance
Syntax: <Server Name>
Example: demodatabase
Named instance
Syntax: <Server Name>\<instance name>
Example: demodatabase\instance1
The User Name that Strong Authentication uses to access the database. This name is specified by the database administrator.
Note: The User Name for the Primary and Backup
DSN must be different.
The password that Strong Authentication uses to access the database. This password is specified by the database administrator.
The port on which the database server listens to the incoming requests.
The name of the database that Strong
Authentication will access. a. Click Next to proceed. b. Go to Step 8.
Chapter 6: Deploy Strong Authentication on a Single System 53
Perform Complete Installation
■
Oracle Database Details a. Enter the required information as described in the following table:
Field Description
Primary ODBC
DSN
The installer creates an ODBC connection that Strong
Authentication uses to connect to the database.
The recommended value to enter is arcotdsn.
User Name The User Name that Strong Authentication uses to access the database. This name is specified by the database administrator.
Note: The User Name for the Primary and Backup DSN must be different.
Password The password that Strong Authentication uses to access the database. This password is specified by the database administrator.
Service ID
Port Number The port on which the database server listens to the incoming requests.
Host Name
The Oracle System Identifier that refers to the instance of the
Oracle database running on the Oracle server.
The host name or the IP address of the computer where the
Oracle server is available.
Syntax: <Server Name>
Example: demodatabase
■ b. Test for successful database connection by clicking Test Data Source. c. After completing the test, click Next to proceed.
MySQL Database Details a. Enter the required information as described in the following table:
Field Description
Primary ODBC DSN The installer creates an ODBC connection that Strong
Authentication uses to connect to the database.
The recommended value to enter is arcotdsn.
54 Installation Guide for Microsoft Windows
Perform Complete Installation
Field
Server
User Name
Password
Database
Port Number
Description
The host name or IP address of the database server. If
SQL server is deployed in Named Instance mode, then you must also enter a slash "\" followed by the instance name, refer to vendor documentation for more information on this.
Default Instance
Syntax: <Server Name>
Example: demodatabase
Named instance
Syntax: <Server Name>\<instance name>
Example: demodatabase\instance1
The User Name that Strong Authentication uses to access the database (SQL Server refers to this as login).
This name is specified by the database administrator.
Note: The User Name for the Primary and Backup DSN must be different.
The password that Strong Authentication uses to access the database. This password is specified by the database administrator.
The name of the database that Strong Authentication will access.
The port on which the database server listens to the incoming requests. b. Test for successful database connection by clicking Test Data Source. c. After completing the test, click Next to proceed. d. Go to Step 8.
The Encryption Configuration screen appears. This screen is used to select the encryption mode and set the information used for encryption.
Chapter 6: Deploy Strong Authentication on a Single System 55
Perform Complete Installation
1. Enter the following information in this screen:
■
Master Key: Enter the master key, which will be used to encrypt the data stored in the database. By default, the value of master key is set to MasterKey.
This key is stored in the securestore.enc file located at <install_location>\Arcot
Systems\conf.
■
If you want to change the value of the master key after the installation, then regenerate the securestore.enc file with a new master key value. For more information, see the CA Strong Authentication Administration Guide.
Configure HSM: Select this option only if you want to use a Hardware Security
Module (HSM) to encrypt the sensitive data. Otherwise, the software mode is used by default to encrypt the data.
■
Note: The following options are enabled only if you choose to Configure HSM.
PIN: Enter the password that is used to connect to the HSM.
■
Choose Hardware Module: Choose the HSM that you plan to use. Following are the HSMs that Strong Authentication supports:
■
Luna HSM
■ nCipher netHSM
■
HSM Parameters: Set the following HSM information:
■
Shared Library: The absolute path to the PKCS#11 shared library corresponding to the HSM.
For Luna (cryptoki.dll) and for nCipher netHSM (cknfast.dll), specify the absolute path and name of the file.
■
Storage Slot Number: The HSM slot where the 3DES keys used for encrypting the data are present. The default value for Luna is 0, and for nCipher netHSM the default value is 1.
Note: The HSM parameter values that you provide here are recorded in the arcotcommon.ini file located at <install_location>\Arcot Systems\conf. To change these values after installation, you must edit the arcotcommon.ini file, as discussed in appendix, "Configuration Files and Options".
2. Click Next to continue.
3. Click Install.
The Microsoft Visual C++ 2010 x86 Redistributable Setup screen appears. This screen appears only if the current system where you are installing Strong
Authentication does not have Microsoft Visual C++ 2010 x86.
4. Select the I have read and accept the license terms option, and click Install.
The Installation Progress screen appears. This might take a few seconds. After some time the Installation Is Complete screen appears.
56 Installation Guide for Microsoft Windows
Post-Installation Tasks
5. Click Finish to close the Microsoft Visual C++ 2010 x86 Redistributable Setup dialog box and continue with Strong Authentication installation.
The Installing Strong Authentication screen appears. This might take several minutes. After some time the Installation Complete screen appears.
6. Click Done to exit the installation wizard.
Post-Installation Tasks
This section guides you through the post-installation tasks that you must perform after installing Strong Authentication. These steps are required for configuring Strong
Authentication correctly and must be performed in the following order:
1. Running Database Scripts
2. Verifying the Database Setup
3. Preparing Your Application Server
4. Deploying CA Advanced Authentication
5. Verifying CA Advanced Authentication
6. Logging In to CA Advanced Authentication
7. Bootstrapping the System
8. Starting Strong Authentication Server
9. Verifying the Installation
10. Deploying User Data Service
11. Deploying Sample Application
12. Using Sample Application
Note: After completing these post-installation tasks, perform the Java SDKs and Web services configuration as discussed in chapter, "Configuring Strong Authentication Java
SDKs and Web Services".
Chapter 6: Deploy Strong Authentication on a Single System 57
Post-Installation Tasks
Run the Database Script
Strong Authentication includes with database scripts that create the schema and set initial configuration values in the Strong Authentication database.
Follow these steps::
1. Locate the folder with the scripts for your database type. The default location is:
(for Microsoft SQL Server) <install_location>/arcot/dbscripts/mssql
(for Oracle Database) <install_location>/arcot/dbscripts/oracle
(for IBM DB2 UDB) <install_location>/arcot/dbscripts/db2
(for MySQL) <install_location>/arcot/dbscripts/mysql
2. Run the scripts in the following order by using the database vendor tools: a. arcot-db-config-for-common-8.0.sql
Important! If you have installed Risk Authentication 8.0, then do not run arcot-db-config-for-common-8.0.sql because you have already run it while installing Risk Authentication 8.0. b. arcot-db-config-for-webfort-8.0.sql
Note: If you encounter any errors while executing the scripts, then check with your database administrator whether you have the required privileges.
58 Installation Guide for Microsoft Windows
Post-Installation Tasks
Verify the Database Setup
After you run the database scripts, use the arwfutil tool verify that the schema was seeded correctly:
Follow these steps:
1. Open a command prompt window.
2. Navigate to the following location:
<install_location>/arcot/sbin
3. At the command prompt enter the following command:
./arwfutil vdb
The preceding command creates the arcotwebfort-vdb-<dd>-<mmm>-<yy>.txt file in the <install_location>/arcot/logs directory.
4. Open the arcotwebfort-vdb-<dd>-<mmm>-<yy>.txt file in a text editor, and check for entries of the following type:
ARWF* FOUND
These lines indicate that your database setup has been successful.
5. Close the arcotwebfort-vdb-<dd>-<mmm>-<yy>.txt file.
How to Prepare the Application Server
Two components of Strong Authentication, User Data Service (UDS) and CA Advanced
Authentication, are web-based and support the following supported application servers:
■
Apache Tomcat
■
IBM WebSphere Application Server
■
Oracle WebLogic Server
■
JBoss Application Server
Before you deploy the UDS and CA Advanced Authentication WAR files on the application server, copy the Strong Authentication files and JDBC JAR file to the appropriate location on your application server.
■
Step 1: Setting Java Home
■
Step 2: Copying Files to Your Application Server
■
Step 3: Copying JDBC JARs to Your Application Server
■
Step 4: (Mandatory for Oracle WebLogic 10.1) Creating Enterprise Archive File
Chapter 6: Deploy Strong Authentication on a Single System 59
Post-Installation Tasks
Step 1: Set Java Home
Before you deploy the UDS and CA Advanced Authentication on the application server verify that you set the JAVA_HOME environment variable. For Apache Tomcat, set
JAVA_HOME to the Java home directory corresponding to the JDK that you are using.
In addition, include $JAVA_HOME/bin in the PATH environment variable. If you fail to do so, then CA Advanced Authentication and other JDK-dependent components may fail to start.
Step 2: Copy Database Access Files to the Application Server
UDS and CA Advanced Authentication use the following files to access the database securely:
■ libArcotAccessKeyProvider.so available at:
<install_location>/arcot/native/<platform
name>/<32bit-or-64bit>/
■ arcot-crypto-util.jar available at:
<install_location>/arcot/java/lib/
■
You must copy the files to the application server where you have deployed Strong
Authentication.
Copy Database Access Files on Apache Tomcat
Follow these steps:
1. Copy the libArcotAccessKeyProvider.so file to the following directory:
■
For RHEL: <JAVA_HOME used by Apache Tomcat>/jre/bin
2. Copy the arcot-crypto-util.jar file to the following directory:
<JAVA_HOME used by Apache Tomcat>/jre/lib/ext
3. Set and export the LD_LIBRARY_PATH to the directory where the libArcotAccessKeyProvider.so file is copied.
4. Restart the application server.
Note: An application server restart is required as part of some of the remaining installation tasks. To minimize the number of times you restart the application server, restart it once after performing the last task that requires a restart.
60 Installation Guide for Microsoft Windows
Post-Installation Tasks
Copy Database Access Files on IBM WebSphere
Follow these steps:
1. Log in to IBM WebSphere Administration Console.
2. Click Environment, and then click Shared Libraries. a. From the Scope drop-down, select a valid visibility scope. The scope must include the target server/node on which the application is deployed. b. Click New. c. Enter the Name, for example, ArcotJNI. d. Specify the Classpath. This path must point to the location where the arcot-crypto-util.jar file is present and must also include the file name. For example, <install_location>/arcot/java/lib/arcot-crypto-util.jar. e. Enter the JNI library path. This path must point to the location where the
ArcotAccessKeyProvider.dll file is present. For example,
<install_location>/arcot/java/native/linux/<32bit-or-64bit>. f. Click Apply.
3. Configure server-level class loaders. a. Navigate to Servers, Server Types, WebSphere Application Servers. b. Under Application Servers, access the settings page of the server for which the configuration has been performed. c. Click Java and Process Management, and then click Class Loader. d. Click New. Select default Classes loaded with parent class loader first and click
OK. e. Click the auto-generated Class Loader ID. f. In the class loader Configuration page, click Shared Library References. g. Click Add, select the shared library that you created earlier in this procedure
(for example, ArcotJNI), and then click Apply. h. Save the changes.
4. Copy libArcotAccessKeyProvider.so file to the following directory:
■
For RHEL: <JAVA_HOME used by IBM WebSphere>/jre/bin
5. Restart the application server.
Note: An application server restart is required as part of some of the remaining installation tasks. To minimize the number of times you restart the application server, restart it once after performing the last task that requires a restart.
Chapter 6: Deploy Strong Authentication on a Single System 61
Post-Installation Tasks
Copy Database Access Files on Oracle WebLogic
Follow these steps:
1. Copy libArcotAccessKeyProvider.so to the following directory:
■
For RHEL: <JAVA_HOME used by Oracle WebLogic instance>/jre/bin
2. Set and export the LD_LIBRARY_PATH to the directory where the libArcotAccessKeyProvider.so file is copied.
3. Copy arcot-crypto-util.jar to the <JAVA_HOME used by Oracle WebLogic
instance>/jre/lib/ext directory.
4. Log in to WebLogic Administration Console.
5. Navigate to Deployments.
6. Enable the Lock and Edit option.
7. Click Install and navigate to the directory that contains the arcot-crypto-util.jar file.
8. Click Next.
The Application Installation Assistant screen appears.
9. Click Next.
The Summary page appears.
10. Click Finish.
11. Activate the changes.
12. Restart the application server.
Note: An application server restart is required as part of some of the remaining installation tasks. To minimize the number of times you restart the application server, restart it once after performing the last task that requires a restart.
62 Installation Guide for Microsoft Windows
Post-Installation Tasks
Copy Database Access Files on JBoss
Follow these steps:
1. Copy libArcotAccessKeyProvider.so to:
■
For RHEL: JBoss_JAVA_HOME/jre/bin/
Here, JBoss_JAVA_HOME represents the JAVA_HOME used by your JBoss
Application Server instance.
2. Create a folder structure as <JBOSS_HOME>\modules\advauth-admin-libs\main\ and copy the following JARs from <ARCOT_HOME>\java\lib to this folder:
■ arcot-crypto-util.jar.
■ bcprov-jdk15-146.jar
3. Create a file with the name module.xml in the same folder location
(<JBOSS_HOME>\modules\advauth-admin-libs\main\) with the following codes:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="advauth-admin-libs">
<resources>
<resource-root path="arcot-crypto-util.jar"/>
<resource-root path="bcprov-jdk15-146.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
</dependencies>
</module>
4. Restart the application server.
Chapter 6: Deploy Strong Authentication on a Single System 63
Post-Installation Tasks
Step 3: Copy JDBC JARs to the Application Server
The CA Advanced Authentication, UDS, and Sample Application, are the Java-dependent components that use JDBC JAR files to connect to the database. You copy these files to the application server.
Note: Before proceeding with the steps mentioned in the following sections, verify that you have downloaded the JDBC JAR file. See chapter, "Preparing for Installation" for more information about the supported JDBC JAR files.
Copy JDBC JARs to Apache Tomcat
Follow these steps:
1. Navigate to the location where you have downloaded the JDBC JAR file.
2. Copy the JDBC JAR file and paste it in the following directory:
■
■
For Apace Tomcat 5.5.x: <TOMCAT-HOME>\common\lib
For Apace Tomcat 6.x and 7.x: <TOMCAT-HOME>\lib
Alternatively, add the path that contains the JDBC JAR file to the Classpath environment variable.
3. Restart Apache Tomcat.
Copy JDBC JARs to IBM WebSphere
Follow these steps:
1. Log in to IBM WebSphere Administration Console.
2. Click Environment, and then click Shared Libraries. a. From the Scope drop-down, select a valid visibility scope. The scope must include the target server/node on which the application is deployed. b. Click New. c. Enter the Name, for example, JDBCJAR. d. Specify the Classpath. This path must point to the location where the JDBC JAR file is present and must also include the file name. e. Click Apply.
3. Configure server-level class loaders.
64 Installation Guide for Microsoft Windows
Post-Installation Tasks
Note: You can create a class loader or use the one that you created while performing the procedure described in Step 2: Copying Database Access Files to
Your Application Server. a. Navigate to Servers, Server Types, WebSphere Application Servers. b. Under Application Servers, access the settings page of the server for which the configuration is performed. c. Click Java and Process Management, and then click Class Loader. d. Click New. Select default Classes loaded with parent class loader first and click
OK. e. Click the auto-generated Class Loader ID. f. In the class loader Configuration page, click Shared Library References. g. Click Add, select JDBCJAR and then click Apply. h. Save the changes.
4. Restart IBM WebSphere.
Copy JDBC JARs to Oracle WebLogic
Follow these steps:
Note: If you are using Oracle Database, then you need not perform the procedure that is described in this section because Oracle WebLogic Server supports Oracle Database by default.
1. Copy the JDBC JAR file to the following directory:
<JAVA_HOME used by Oracle WebLogic instance>/jre/lib/ext
2. Log in to WebLogic Administration Console.
3. Navigate to Deployments.
4. Enable the Lock and Edit option.
5. Click Install and navigate to the directory that contains the JDBC JAR file.
6. Click Next.
The Application Installation Assistant screen appears.
7. Click Next.
The Summary page appears.
8. Click Finish.
9. Activate the changes.
10. Restart the Oracle WebLogic server.
Chapter 6: Deploy Strong Authentication on a Single System 65
Post-Installation Tasks
Copy JDBC JARs to JBoss
Follow these steps:
1. Download the required JAR from any source, and then navigate to the location where you have downloaded it..
2. Create a folder structure as <JBOSS_HOME>\modules\advauth-jdbc-driver\main\ and copy JDBC Jar file in this folder location.
3. Create a file as ‘module.xml’ in the same location
(<JBOSS_HOME>\modules\advauth-jdbc-driver\main\) with the following codes:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="advauth-jdbc-driver">
<resources>
<resource-root path="<JDBC Jar Name>"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
Note: Edit the tag ‘<JDBC Jar Name>’with JDBC Jar file name.
Example: sqljdbc.jar
4. Restart the application server.
Step 4: Create Enterprise Archive File
Valid on Weblogic 10.1
Strong Authentication provides WAR files to deploy CA Advanced Authentication and
User Data Service. You can change the format of these files to EAR and then deploy the
EAR file.
Follow these steps:
1. Open the command prompt window.
2. Navigate to the <install_location>/arcot/tools/common/bundlemanager directory.
3. Run the bundlemanager tool to create the EAR file by using the following command: java -jar bundle-manager.jar -ear <filename.ear> -warList
<war_file_name>
Note: In the preceding command, replace the <war_file_name> with arcotadmin.war for generating the EAR file for the CA Advanced Authentication, and arcotuds.war for generating the EAR file for UDS.
This command generates the EAR file at <install_location>/arcot/java/webapps.
66 Installation Guide for Microsoft Windows
Post-Installation Tasks
Deploy the CA Advanced Authentication
Note: If you plan to deploy CA Advanced Authentication on WebSphere 7.0, 8.0 and 8.5, then see the instructions that are provided in appendix, Deploy CA Advanced
Authentication on IBM WebSphere.
You need the file arcotadmin.war to deploy the Strong Authentication CA Advanced
Authentication. This file is available at:
<install_location>/arcot/java/webapps/
Note: To manage Strong Authentication Server by using CA Advanced Authentication, ensure that CA Advanced Authentication can access the system where Strong
Authentication Server is installed by its hostname.
Follow these steps:
1. Deploy arcotadmin.war in the appropriate directory on the application server.
Note: The deployment procedure depends on the application server that you are using. See your application server vendor documentation for detailed instructions.
For example, in the case of Apache Tomcat, you must deploy the WAR file at
<APP_SERVER_HOME>\webapps\.
2. Ensure that the application is restarted.
Log In to CA Advanced Authentication
When logging in to CA Advanced Authentication for the first time, use the Master
Administrator credentials that are created automatically in the database during installation.
Follow these steps::
1. Start CA Advanced Authentication in a Web browser window, by using the following
URL:
http://<host>:<app_server_port>/arcotadmin/masteradminlogin.htm
Note: The host and port information that you specify in the preceding URL must be of the application server where CA Advanced Authentication is deployed.
2. Log in to CA Advanced Authentication as a Master Administrator with the default
Master Administrator account credentials. The credentials are:
■
User Name: masteradmin
■
Password: master1234!
Chapter 6: Deploy Strong Authentication on a Single System 67
Post-Installation Tasks
How to Bootstrap the System
Default Organization
Before you can start using the CA Advanced Authentication to manage Strong
Authentication, first perform the following steps to initialize the system:
■
Change the default Master Administrator password
■
Specify the Global Key label
■
Specify the authentication mechanism for the Default organization
Bootstrapping is a wizard-driven process that walks you through these setup tasks.
Other administrative links are enabled after you perform these tasks.
Before you proceed with Performing the Bootstrapping Tasks, you must learn about the related concept of Default Organization.
When you deploy the CA Advanced Authentication, an organization is created by default. This organization is referred to as Default Organization (DEFAULTORG). As a single-organization system, the Default Organization itself can be used without creating any organizations.
68 Installation Guide for Microsoft Windows
Post-Installation Tasks
Perform the Bootstrapping Tasks
When you first log in to CA Advanced Authentication as the Master Administrator (MA), the Summary screen for the Bootstrap wizard screen appears.
To bootstrap the system using the wizard:
1. Click Begin.
The Change Password screen appears.
2. Specify the Old Password, New Password, Confirm Password, and click Next.
The Configure Global Key Label screen appears.
3. Specify the Global Key Label, and click Next.
Strong Authentication enables you to use hardware- or software-based encryption for your sensitive data. Irrespective of hardware or software encryption, the Global
Key Label is used for encrypting user and organization data.
If you are using hardware encryption, then this label serves only as a reference (or pointer) to the actual 3DES key stored in the HSM device, and therefore the key label must match the HSM key label. However, in the case of software-based encryption, this label acts as the reference to the actual software key in the database.
Important! After you complete the bootstrapping process, you can not update this key label.
The Storage Type field indicates whether the encryption key is stored in the database (Software) or the HSM (Hardware).
The Configure Default Organization screen appears.
4. Under the Default Organization Configuration section, specify the following parameters for the Default Organization:
■
Display Name: The descriptive name of the organization. This name appears on all other CA Advanced Authentication pages and reports.
■
Administrator Authentication Mechanism: The mechanism that is used to authenticate administrators belonging to the Default Organization. CA
Advanced Authentication supports three types of authentication methods for the administrators to log in:
■
Basic
If you choose this option, then the inbuilt authentication method provided by CA Advanced Authentication is used for authenticating the administrators.
■
LDAP User Password
If you choose this option, then the administrators are authenticated using their credentials that are stored in the directory service.
Chapter 6: Deploy Strong Authentication on a Single System 69
Post-Installation Tasks
Note: If this mechanism is used for authenticating administrators, then you must deploy UDS, as discussed in the "Deploying User Data Service" section.
■
Strong Authentication User Password
If you select the Strong Authentication User Password option here, then the credentials are issued and authenticated by the Strong Authentication
Server.
Book: Refer to CA Strong Authentication Administration Guide for more information on how to do this.
5. Under the Key Label Configuration section of the Configure Default Organization screen, specify the following:
■
Use Global Key: This option is selected by default. Deselect this option if you want to override the Global Key Label you specified in the preceding step and specify a new encryption label.
■
Key Label: If you deselected the Use Global Key option, then specify the new key label that you want to use for the Default Organization.
■
Storage Type: This field indicates whether the encryption key is stored in the database (Software) or the HSM (Hardware).
6. Click Finish to complete the bootstrapping process.
CA Advanced Authentication initialization is completed, as indicated in the Finish screen.
7. Click Continue to proceed with other configurations using CA Advanced
Authentication.
Start Strong Authentication
Perform the following steps to start Strong Authentication Server:
1. On the task bar, click Start.
2. Click Settings, and then point to Control Panel, Administrative Tools, and Services.
3. Select Strong Authentication Service.
4. Click Start.
70 Installation Guide for Microsoft Windows
Post-Installation Tasks
Verify the Installation
You can verify that the Strong Authentication Server and the web applications have started successfully by performing the following procedures:
■
Using Log files
■
Using arwfserver Utility
■
Checking the Ports
Using Log files
Perform the following steps to verify that Strong Authentication Server has started correctly:
1. Navigate to the following location:
<install_location>\Arcot Systems\logs
2. Open the arcotwebfortstartup.log file in any editor and locate the following lines:
INSTANCE_VER.................................: [8.0]
Strong Authentication Service READY
These lines indicate that Strong Authentication Server is installed successfully.
Note: Verify that the log files do not contain any FATAL and WARNING messages.
Chapter 6: Deploy Strong Authentication on a Single System 71
Post-Installation Tasks
Using arwfserver Utility
The arwfserver tool enables you to check the release of Strong Authentication that you have installed. For more information about this tool, see the Strong Authentication
Administration Guide.
Follow these steps:
1. Navigate to the following location:
<install_location>\Arcot Systems\bin
2. Execute arwfserver.exe with the following option to start the tool in interactive mode: arwfserver -i
3. Enter version at the prompt.
The webfort-ver-<dd>-<mmm>-<yy>.txt file is created in the
<install_location>\Arcot Systems\logs folder.
4. Open this file and check for the following lines to ensure that you are using the current release:
■
■
The version of Strong Authentication library files in the bin section is 8.0.
The version of the UDS library file (arwfuds.dll) in the bin section is 2.0.3.
5. Close the file.
Checking the Ports
To verify if the Strong Authentication Server is listening to different protocols on the default ports, perform the following steps :
1. Navigate to the following location:
<install_location>\Arcot Systems\logs
2. Open the arcotwebfortstartup.log file in any editor and search for the protocol names to verify if they are listening on the correct port, as shown in the following snippet.
PROTOCOLNAME : [Administration-WS]
PORTNO : 9745
PROTOCOLID : [Transaction-Native]
PORTNO : 9742
PROTOCOLID : [ServerManagement-WS]
PORTNO : 9743
PROTOCOLID : [Transaction-WS]
PORTNO : 9744
See appendix, "Default Port Numbers and URLs" for information about default ports and protocols.
72 Installation Guide for Microsoft Windows
Post-Installation Tasks
Deploy User Data Service
Strong Authentication can access user data either from a relational database (RDBMS) or directly from an LDAP server:
You need the file arcotuds.war to deploy the User Data Service (UDS). This file is available at:
<install_location>/arcot/java/webapps/
Follow these steps:
1. Install arcotuds.war in the appropriate directory on the application server.
Note: The deployment procedure depends on the application server that you are using. See your application server vendor documentation for detailed instructions.
For example, in the case of Apache Tomcat, deploy the WAR file at
<APP_SERVER_HOME>/webapps/.
2. (WebSphere Only) Configure to reload the UDS class when the application files are updated. a. Navigate to Applications, Application Types, WebSphere Enterprise
Applications; and access the UDS settings page. b. Under Class loader order, select the Classes loaded with local class loader first
(parent last) option. c. Under WAR class loader policy, select the Single class loader for application. d. Click Apply.
3. Restart the application server.
4. Perform the following steps to verify if UDS started correctly: a. Navigate to the following location:
<install_location>/arcot/logs b. Open the arcotuds.log file in any editor and locate the following lines:
User Data Service (Version: 2.0.3) initialized successfully.
This line indicates that UDS was deployed successfully
Note: Check and resolve if there are any FATAL and ERROR messages, and review all the
WARNING messages for unexpected conditions.
Chapter 6: Deploy Strong Authentication on a Single System 73
Post-Installation Tasks
Deploy the Sample Application
Sample Application can be used to verify if Strong Authentication was installed and configured properly. In addition, it demonstrates:
■
The typical Strong Authentication workflows
■
The tasks that you can perform using the Strong Authentication Java APIs
■
Integration of your application with Strong Authentication
Important! Do not use Sample Application in production deployments. It is recommended that you build your own web application by using Sample Application as a code-reference.
Follow these steps:
1. Deploy the sample application war file from the following location:
<install_location>/arcot/samples/java
2. Start Sample Application.
3. Access the Sample Application using the following URL:
http://<host>:<app_server_port>/sample-application/
Chapter 7: How to Deploy Strong
Authentication on Distributed Systems
74 Installation Guide for Microsoft Windows
Post-Installation Tasks
Use the lnstallAnywhere Wizard to install Strong Authentication components. This
Wizard supports Complete and Custom installation types. However, to install and configure Strong Authentication in a distributed environment, use the Custom option when you run the installer.
The following steps provide a quick overview of the process:
1. Run the Strong Authentication installer to install Strong Authentication Server and
CA Advanced Authentication and to configure them to access your SQL database.
Web Services can also be installed on the same system.
See "Installing on the First System" for installation instructions.
2. Execute the database scripts. Verify that the database setup was successful.
See "Running Database Scripts" and "Verifying the Database Setup" for more information.
3. Prepare the application server to copy the files that CA Web components use.
See "Preparing Your Application Server" for more information.
4. Deploy CA Advanced Authentication on the application server and verify the deployments.
See "Deploying CA Advanced Authentication" and "Verifying the CA Advanced
Authentication" for more information.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 75
Post-Installation Tasks
5. Log in to CA Advanced Authentication with the Master Administrator credentials to initialize Strong Authentication.
See "Logging In to CA Advanced Authentication" and "Bootstrapping the System" for more information.
6. Start the Strong Authentication Server and verify that the service starts successfully.
See "Starting Strong Authentication Server" and "Verifying the Installation" for more information.
7. Deploy User Data Service on the application server and verify the deployment.
See "Deploying User Data Service" for more information.
8. Install the Java SDKs and Web Services on one or more systems.
See "Installing on the Second System" for more information.
9. Deploy, configure, and use Sample Application to test Strong Authentication configuration.
Note: To install the Sample Application only, select only the SDKs and Sample
Application option and proceed with the installation.
See "Deploying Sample Application", "Configuring Sample Application for
Communication with Strong Authentication Server", and "Using Sample
Application" for more information.
10. (Optional) To ensure secure communication between Strong Authentication components, configure them to support SSL (Secure Socket Layer) transport mode.
See appendix, "Configuring SSL" in Strong Authentication Administration Guide for more information.
11. Complete the installation checklist.
See "Post-Installation Checklist" for more information.
76 Installation Guide for Microsoft Windows
Install the First System
Note the following:
■
Ensure that the <install_location> contains no special characters (such as ~ ! @ # $
% ^ & * ( ) _ + = , -* + ’ ").
■
You cannot modify or repair Strong Authentication components by using the installer. Uninstall the component and then re-install it.
■
Do not close the installer window, if the installation is in progress. If at any time during installation (especially during the last stages), if you click the Cancel button to abort the installation, then the installer might not remove all the directories it has created so far. Manually clean up the installation directory,
<install_location>\Arcot Systems\ and its subdirectories.
■
If you run the installer on a system that already contains an instance of an existing
%ARCOT_HOME%, then:
■
You are not prompted for an installation directory.
■
You are not prompted for the database set up. The Installer uses the existing database.
■
You are not prompted to set up encryption.
Install the First System
To install Strong Authentication the user account that you plan to use for installation
must belong to the Administrators group.
In a distributed scenario you install Strong Authentication Server on the first system.
Custom installation allows you to install only the selected components from the package. This option is recommended for advanced users.
Follow these steps:
1. Double-click the installer Strong
Authentication-<version_number>-Windows-Installer.exe.
2. Click the Next button to proceed.
The License Agreement screen appears.
3. Accept the license agreement carefully and click the Next.
The installer now checks if any other CA product is installed on the computer.
If it does not find an existing CA product installation, you are prompted for an installation directory. In this case, the Installation Location screen appears.
If the installer detects an existing CA product installation, you are not prompted for an installation directory. The Installation Location Screen: Previous Installation
Detected screen appears when an existing ARCOT_HOME was located on the computer.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 77
Install the First System
4. Accept the default directory specified by the installer or click Choose to navigate and to specify a different directory.
Click Next to install in the specified directory.
The Installation Type screen appears.
5. Select the Custom option to install the selected components and click Next.
The Component Selection screen appears.
6. Deselect the components that are not required. By default, all components are selected for installation.
The following table describes all available components:
Component Description
Strong Authentication
Server
This option installs the core Processing engine (Strong
Authentication Server) that serves the following requests from SDKs, CA Advanced Authentication, and web services:
■
Credential Issuance Configurations
■
Credential Authentication Configurations
■
Server Configurations
In addition, this component also enables you to access the following Web services:
■
Authentication and Authorization Web service -
Provides the programming interface for authenticating and authorizing users.
■
■
Issuance SDK and Web Services - Provides the programming interface for creating, reading, and updating user credential information in the Strong
Authentication database.
Authentication Web Service - Provides the programming interface for authenticating users.
■
Credential Management Web Service - Provides the programming interface for creation and management of user credentials.
■
Administration Web Service - Provides the programming interface used by the Strong
Authentication Administration Console.
■
Bulk Operations Web Service: Provides the programming interface for uploading and fetching
OATH tokens.
78 Installation Guide for Microsoft Windows
Install the First System
Component
Java SDK and WS
Sample Application
CA Advanced
Authentication
User Data Service
Description
This option provides programming interfaces (in form of
APIs and Web Services) that can be invoked by your application to forward authentication and user credential issuance requests to the Strong
Authentication Server. This package comprises the following sub-components:
■
Authentication Java SDK and Web Services-
Provides the programming interface for authentication with Strong Authentication Server.
■
Credential Management Java SDK and Web
Services - Provides the programming interface for creation and management of user credentials.
■
Administration Web Service - Provides the programming interface for creating configurations.
■
Bulk Operations Web Service: Provides the programming interface for uploading and fetching
OATH tokens.
Refer to chapter, "Configuring Strong Authentication
Java SDKs and Web Services" for more information on configuring these components.
This option provides Web-based interface for demonstrating the usage of the Java APIs. In addition it is able to perform credential management and authentication requests.
This option provides the Web-based interface for managing Strong Authentication Server and authentication-related configurations.
This option installs UDS that acts as an abstraction layer for accessing different types of user repositories, such as relational databases (RDBMSs) and directory servers
(LDAPs.)
1. After you have selected all the desired components for installation, click Next.
The Database Type screen appears.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 79
Install the First System
2. Select the database type, and then click Next to proceed.
■
Depending on the database you selected, the corresponding Database Details screen appears.
Note: Strong Authentication supports Oracle Real Application Clusters (Oracle RAC).
To use Oracle RAC select Oracle Database in this step, and then perform the steps in
Configuring Strong Authentication for Oracle RAC.
Depending on the database that you selected, perform one of the following steps:
Microsoft SQL Server Database Details a. Enter the required information as described in the following table:
Field Description
ODBC DSN Strong Authentication Server uses the ODBC DSN to connect to the database. The recommended value to enter is
arcotdsn. The installer creates the DSN using this value.
Server The host name or IP address of the database server. If SQL server is deployed in Named Instance mode, then you must also enter a slash "\" followed by the instance name, refer to vendor documentation for more information on this.
Default Instance
Syntax: <Server Name>
Example: demodatabase
Named instance
Syntax: <Server Name>\<instance name>
Example: demodatabase\instance1
User Name The user account that is used to access the database (SQL
Server refers to this as login). This name is specified by the database administrator.
Note: The User Name for the Primary and Backup DSN must be different.
Password
Database
The password that that is associated with the user account.
This password is specified by the database administrator.
The name of the database that.
Port Number The port on which the database server listens to the incoming requests. b. Test for successful database connection by clicking Test Data Source. c. After completing the test, click Next to proceed. d. Go to Step 10.
80 Installation Guide for Microsoft Windows
Install the First System
■
IBM DB2 (UDB) Database Details a. Enter the required information as described in the following table:
Field Description
ODBC DSN
Server
User Name
Password
Strong Authentication Server uses the ODBC DSN to connect to the database. The recommended value to enter is
arcotdsn. The installer creates the DSN using this value.
The host name or IP address of the database server. If the database is deployed in Named Instance mode, then you must also enter a slash "\" followed by the instance name, refer to vendor documentation for more information on this.
Default Instance
Syntax: <Server Name>
Example: demodatabase
Named instance
Syntax: <Server Name>\<instance name>
Example: demodatabase\instance1
The user account that is used to access the database (SQL
Server refers to this as login). This name is specified by the database administrator.
Note: The User Name for the Primary and Backup DSN must be different.
The password that is associated with the user account. This password is specified by the database administrator.
Port Number The port on which the database server listens to the incoming requests.
Database The name of the database that Strong Authentication will access.
■ b. Click Next to proceed. c. Go to Step 10.
Oracle Database Details a. Enter the required information as described in the following table:
Field Description
ODBC DSN Strong Authentication Server uses the ODBC DSN to connect to the Strong Authentication database. The recommended value to enter is arcotdsn. The installer creates the DSN using this value.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 81
Install the First System
Field Description
User Name The User Name that Strong Authentication uses to access the database. This name is specified by the database administrator.
Note: The User Name for the Primary and Backup DSN should be different.
Password The password that Strong Authentication uses to access the database. This password is specified by the database administrator.
Service ID The Oracle System Identifier that refers to the instance of the
Oracle database running on the Oracle server.
Port Number The port on which the database server listens to the incoming requests.
Host Name The host name or the IP address of the computer where the
Oracle server is available.
Syntax: <Host Name or IP address>
Example: demodatabase
■ b. Test for successful database connection by clicking Test Data Source. c. After completing the test, click Next to proceed.
MySQL Database Details a. Enter the required information as described in the following table:
Field Description
ODBC DSN
Server
Strong Authentication Server uses the ODBC DSN to connect to the Strong Authentication database. The recommended value to enter is arcotdsn. The installer creates the DSN using this value.
The host name or IP address of the database server. If SQL server is deployed in Named Instance mode, then you must also enter a slash "\" followed by the instance name, refer to vendor documentation for more information on this.
Default Instance
Syntax: <Server Name>
Example: demodatabase
Named instance
Syntax: <Server Name>\<instance name>
Example: demodatabase\instance1
82 Installation Guide for Microsoft Windows
Install the First System
Field Description
User Name The User Name that Strong Authentication uses to access the database (SQL Server refers to this as login). This name is specified by the database administrator.
Note: The User Name for the Primary and Backup DSN must be different.
Password The password that Strong Authentication uses to access the database. This password is specified by the database administrator.
Database The name of the database that Strong Authentication will access.
Port Number The port on which the database server listens to the incoming requests. b. Test for successful database connection by clicking Test Data Source. c. After completing the test, click Next to proceed. d. Go to Step 10.
The Encryption Configuration screen appears. This screen is used to select the encryption mode and set the information used for encryption.
1. Enter the following information in this screen:
■
Master Key: Enter the master key, which will be used to encrypt the data stored in the database. By default, the value of master key is set to MasterKey.
This key is stored in the securestore.enc file located at <install_location>\Arcot
Systems\conf.
■
■
If you want to change the value of the master key after the installation, then you must regenerate the securestore.enc file with a new master key value. For more information, see the Strong Authentication Administration Guide.
Configure HSM: Select this option only if you want to use a Hardware Security
Module (HSM) to encrypt the sensitive data. If not selected, the default software mode is used to encrypt the data.
Note: The following options are enabled only if you choose to Configure HSM.
PIN: Enter the password that is used to connect to the HSM.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 83
Install the First System
■
■
Choose Hardware Module: Choose the HSM that you plan to use. Following are the HSMs that Strong Authentication supports:
■
Luna HSM
■ nCipher netHSM
HSM Parameters: Set the following HSM information:
■
Shared Library: The absolute path to the PKCS#11 shared library corresponding to the HSM.
For Luna (cryptoki.dll) and for nCipher netHSM (cknfast.dll), specify the absolute path and name of the file.
■
Storage Slot Number: The HSM slot where the 3DES keys used for encrypting the data are present. The default value for Luna is 0, and for nCipher netHSM the default value is 1.
Click Next to continue.
The Pre-Installation Summary screen appears.
2. If you want to change any of the installation settings, then click the Previous button or click the Install button to proceed with the installation.
The Microsoft Visual C++ 2010 x86 Redistributable Setup screen appears. This screen appears only if the current system where you are installing Strong
Authentication does not have Microsoft Visual C++ 2010 x86.
3. Select the I have read and accept the license terms option, and click Install.
The Installation Progress screen appears. This might take a few seconds. After some time the Installation Is Complete screen appears.
4. Click Finish.
5. Click Done to exit the installation wizard.
84 Installation Guide for Microsoft Windows
Post-Installation Tasks on the First System
Post-Installation Tasks on the First System
The following post-installation steps are discussed in this section:
1. Running Database Scripts
2. Verifying the Database Setup
3. Preparing Your Application Server
4. Deploying CA Advanced Authentication
5. Verifying the CA Advanced Authentication
6. Logging In to CA Advanced Authentication
7. Bootstrapping the System
8. Starting Strong Authentication Server
9. Verifying the Installation
10. Deploying User Data Service
Note: After completing these post-installation tasks, perform the Java SDKs and Web
Services configuration that is discussed in chapter, "Configuring Strong Authentication
Java SDKs and Web Services".
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 85
Post-Installation Tasks on the First System
Create the Database Schema
Strong Authentication comes with SQL scripts that create the schema and set initial configuration values in the Strong Authentication database.
Follow these steps::
1. Locate the folder with the scripts for your database type. The default location is:
(For Microsoft SQL Server) <install_location>/arcot/dbscripts/mssql
(For Oracle Database) <install_location>/arcot/dbscripts/oracle
(For IBM DB2 UDB) <install_location>/arcot/dbscripts/db2
(For MySQL) <install_location>/arcot/dbscripts/mysql
2. Run the scripts in the following order by using the database vendor tools: a. arcot-db-config-for-common-8.0.sql
Important! If you have installed Risk Authentication 8.0, do not run arcot-db-config-for-common-8.0.sql because you have already run it while installing Risk Authentication 8.0. b. arcot-db-config-for-webfort-8.0.sql
Note: If you encounter any errors while running the scripts, then check whether you have the required privileges.
Verify the Database Setup
After running the required database scripts, verify that the schema was seeded correctly by using the arwfutil tool.
Follow these steps:
1. Open a command prompt window.
2. Navigate to the following location:
<install_location>/arcot/sbin
3. At the command prompt enter the following command:
./arwfutil vdb
The preceding command creates the arcotwebfort-vdb-<dd>-<mmm>-<yy>.txt file in the <install_location>/arcot/logs directory.
4. Open the arcotwebfort-vdb-<dd>-<mmm>-<yy>.txt file in a text editor, and check for entries of the following type:
ARWF* FOUND
These lines indicate that your database setup has been successful.
5. Close the arcotwebfort-vdb-<dd>-<mmm>-<yy>.txt file.
86 Installation Guide for Microsoft Windows
Post-Installation Tasks on the First System
How to Prepare the Application Server
User Data Service (UDS) and CA Advanced Authentication are web based application that support the following application servers:
■
Apache Tomcat
■
IBM WebSphere Application Server
■
Oracle WebLogic Server
■
JBoss Application Server
Before you deploy the UDS and CA Advanced Authentication WAR files on the application server, copy the Strong Authentication files and JDBC JAR file to the appropriate location on your application server.
■
Step 1: Setting Java Home
■
Step 2: Copying Database Access Files to Your Application Server
■
Step 3: Copying JDBC JARs to Your Application Server
■
Step 4: (Mandatory for Oracle WebLogic 10.1) Creating Enterprise Archive File
Set Java Home
Before you deploy the WAR files for UDS and CA Advanced Authentication on the application server of your choice, ensure that you set the JAVA_HOME environment variable. For Apache Tomcat, set JAVA_HOME to the Java home directory corresponding to the JDK that you are using.
In addition, include $JAVA_HOME/bin in the PATH environment variable. If you fail to do so, then CA Advanced Authentication and other JDK-dependent components may fail to start.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 87
Post-Installation Tasks on the First System
Copy Database Access Files to the Application Server
UDS and CA Advanced Authentication use the following files to access the database :
■ libArcotAccessKeyProvider.so available at:
<install_location>/arcot/native/<platform
name>/<32bit-or-64bit>/
■ arcot-crypto-util.jar available at:
<install_location>/arcot/java/lib/
You must copy these files to the appropriate location on the application server where you have deployed Strong Authentication.
Tomcat
Follow these steps:
1. Copy the libArcotAccessKeyProvider.so file to the following directory:
■
For RHEL: <JAVA_HOME used by Apache Tomcat>/jre/bin
2. Copy the arcot-crypto-util.jar file to the <JAVA_HOME used by Apache
Tomcat>/jre/lib/ext directory.
3. Set and export the LD_LIBRARY_PATH to the directory where the libArcotAccessKeyProvider.so file is copied.
4. Restart the application server.
Note: An application server restart is required as part of some of the remaining installation tasks. To minimize the number of times you restart the application server, restart it once after performing the last task that requires a restart.
88 Installation Guide for Microsoft Windows
Post-Installation Tasks on the First System
IBM WebSphere
Follow these steps:
1. Log in to WebSphere Administration Console.
2. Click Environment, and then click Shared Libraries. a. From the Scope drop-down, select a valid visibility scope. The scope must include the target server/node on which the application is deployed. b. Click New. c. Enter the Name, for example, ArcotJNI. d. Specify the Classpath. This path must point to the location where the arcot-crypto-util.jar file is present and must also include the file name. For example, <install_location>/arcot/java/lib/arcot-crypto-util.jar. e. Enter the JNI library path. This path must point to the location where the libArcotAccessKeyProvider.so file is present. For example, the
<install_location>/arcot/java/native/linux/<32bit-or-64bit> directory. f. Click Apply.
3. Configure server-level class loaders. a. Click Servers, Server Types, WebSphere Application Servers. b. Under Application Servers, access the settings page of the server for which the configuration has been performed. c. Click Java and Process Management, and then click Class Loader. d. Click New. Select default Classes loaded with parent class loader first and click
OK. e. Click the auto-generated Class Loader ID. f. In the class loader Configuration page, click Shared Library References. g. Click Add, select the shared library that you created earlier in this procedure
(for example, ArcotJNI), and then click Apply. h. Save the changes.
4. Copy libArcotAccessKeyProvider.so file to the following directory:
■
For RHEL: <JAVA_HOME used by IBM WebSphere>/jre/bin
5. Restart the application server.
Note: An application server restart is required as part of some of the remaining installation tasks. To minimize the number of times you restart the application server, restart it once after performing the last task that requires a restart.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 89
Post-Installation Tasks on the First System
WebLogic
Follow these steps:
1. Copy libArcotAccessKeyProvider.so to the following directory:
■
For RHEL: <JAVA_HOME used by Oracle WebLogic instance>/jre/bin
2. Set and export the LD_LIBRARY_PATH to the directory where the libArcotAccessKeyProvider.so file is copied.
3. Copy arcot-crypto-util.jar to the <JAVA_HOME used by Oracle WebLogic
instance>/jre/lib/ext directory.
4. Log in to WebLogic Administration Console.
5. Navigate to Deployments.
6. Enable the Lock and Edit option.
7. Click Install and navigate to the directory that contains the arcot-crypto-util.jar file.
8. Click Next.
The Application Installation Assistant screen appears.
9. Click Next.
The Summary page appears.
10. Click Finish.
11. Activate the changes.
12. Restart the application server.
Note: An application server restart is required as part of some of the remaining installation tasks. To minimize the number of times you restart the application server, restart it once after performing the last task that requires a restart.
90 Installation Guide for Microsoft Windows
Post-Installation Tasks on the First System
JBoss Application Server
Follow these steps:
1. Copy libArcotAccessKeyProvider.so to:
■
For RHEL: JBoss_JAVA_HOME/jre/bin/
Here, JBoss_JAVA_HOME represents the JAVA_HOME used by your JBoss
Application Server instance.
2. Create a folder structure as <JBOSS_HOME>\modules\advauth-admin-libs\main\ and copy the following JARs from <ARCOT_HOME>\java\lib to this folder:
■ arcot-crypto-util.jar.
■ bcprov-jdk15-146.jar
3. Create a file with the name module.xml in the same folder location
(<JBOSS_HOME>\modules\advauth-admin-libs\main\) with the following codes:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="advauth-admin-libs">
<resources>
<resource-root path="arcot-crypto-util.jar"/>
<resource-root path="bcprov-jdk15-146.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
</dependencies>
</module>
Restart the application server.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 91
Post-Installation Tasks on the First System
Copy JDBC JARs to the Application Server
CA Advanced Authentication, UDS, and Sample Application, which are the
Java-dependent components of Strong Authentication, need JDBC JAR files to connect to the database. Copy these files to the application server.
Note: Before proceeding with the steps mentioned in the following subsections, ensure that you have downloaded the JDBC JARs, see chapter, "Preparing for Installation" for more information about supported JDBC JARs.
The following sections walk you through the steps for copying the JDBC JAR required for your database to one of the following application servers:
■
Apache Tomcat
■
IBM WebSphere
■
Oracle WebLogic
■
JBoss Application Server
Apache Tomcat
To copy the JDBC JAR file to the Apache Tomcat installation directory:
1. Navigate to the location where you have downloaded the JDBC JAR file.
2. Copy the JDBC JAR file and paste it in the following directory:
■
■
For Apace Tomcat 5.5.x: <TOMCAT-HOME>\common\lib
For Apace Tomcat 6.x and 7.x: <TOMCAT-HOME>\lib
Alternatively, add the path that contains the JDBC JAR file to the Classpath environment variable.
3. Restart Apache Tomcat.
IBM WebSphere
To copy the JDBC JAR file to the IBM WebSphere:
1. Log in to WebSphere Administration Console.
2. Click Environment, and then click Shared Libraries. a. From the Scope drop-down, select a valid visibility scope. The scope must include the target server/node on which the application is deployed. b. Click New. c. Enter the Name, for example, JDBCJAR. d. Specify the Classpath. This path must point to the location where the JDBC JAR file is present and must also include the file name. e. Click Apply to save the changes.
92 Installation Guide for Microsoft Windows
Post-Installation Tasks on the First System
Oracle WebLogic
3. Configure server-level class loaders.
Note: You can either create a class loader or use the one that you created while
performing the procedure described in
Step 2: Copying Database Access Files to
Your Application Server
a. Navigate Servers, Server Types, WebSphere Application Servers. b. Under Application Servers, access the settings page of the server for which the configuration is performed. c. Click Java and Process Management, and then click Class Loader. d. Click New. Select default Classes loaded with parent class loader first and click
OK. e. Click the auto-generated Class Loader ID. f. In the class loader Configuration page, click Shared Library References. g. Click Add, select JDBCJAR and then click Apply. h. Save the changes.
4. Restart IBM WebSphere.
To copy the JDBC JAR file to Oracle WebLogic Server:
Note: If you are using Oracle Database, then you need not perform the configuration described in this section because Oracle WebLogic Server supports Oracle Database by default.
1. Copy the JDBC JAR file to the following directory:
<JAVA_HOME used by Oracle WebLogic instance>/jre/lib/ext directory.
2. Log in to WebLogic Administration Console.
3. Navigate to Deployments.
4. Enable the Lock and Edit option.
5. Click Install and navigate to the directory that contains the JDBC JAR file.
6. Click Next.
The Application Installation Assistant screen appears.
7. Click Next.
The Summary page appears.
8. Click Finish.
9. Activate the changes.
10. Restart Oracle WebLogic Server.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 93
Post-Installation Tasks on the First System
JBoss Application Server
Follow these steps:
1. Download the required JAR from any source, and then navigate to the location where you have downloaded it..
2. Create a folder structure as <JBOSS_HOME>\modules\advauth-jdbc-driver\main\ and copy JDBC Jar file in this folder location.
3. Create a file as ‘module.xml’ in the same location
(<JBOSS_HOME>\modules\advauth-jdbc-driver\main\) with the following codes:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="advauth-jdbc-driver">
<resources>
<resource-root path="<JDBC Jar Name>"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
Note: Edit the tag ‘<JDBC Jar Name>’with JDBC Jar file name.
Example: sqljdbc.jar
Restart the application server.
Step 4: Create Enterprise Archive File
Valid on Weblogic 10.1
Strong Authentication provides WAR files to deploy CA Advanced Authentication and
User Data Service. You can change the format of these files to EAR and then deploy the
EAR file.
Follow these steps:
1. Open the command prompt window.
2. Navigate to the <install_location>/arcot/tools/common/bundlemanager directory.
3. Run the bundlemanager tool to create the EAR file by using the following command: java -jar bundle-manager.jar -ear <filename.ear> -warList
<war_file_name>
Note: In the preceding command, replace the <war_file_name> with arcotadmin.war for generating the EAR file for the CA Advanced Authentication, and arcotuds.war for generating the EAR file for UDS.
This command generates the EAR file at <install_location>/arcot/java/webapps.
94 Installation Guide for Microsoft Windows
Post-Installation Tasks on the First System
Deploy User Data Service
Strong Authentication access user data either from a relational database or directly from an LDAP server:
You must deploy the arcotuds.war file to use User Data Service (UDS). This file is available at:
<install_location>/arcot/java/webapps/
Follow these steps:
1. Deploy arcotuds.war in the appropriate directory on the application server.
Note: The deployment procedure depends on the application server that you are using. See your application server vendor documentation for detailed instructions.
For example, in case of Apache Tomcat, deploy the WAR file at
<APP_SERVER_HOME>/webapps/.
2. (WebSphere Only) Configure to reload the UDS class when the application files are updated. a. Navigate to Applications, Application Types, WebSphere Enterprise
Applications and access the UDS Settings screen. b. Under Class loader order, select the Classes loaded with local class loader first
(parent last) option. c. Under WAR class loader policy, select the Single class loader for application. d. Click Apply.
3. Restart the application server.
4. Perform the following steps to verify whether the UDS started correctly: a. Navigate to the following location:
<install_location>/arcot/logs b. Open the arcotuds.log file in any editor and locate the following lines:
User Data Service (Version: 2.0.3) initialized successfully.
This line indicates that UDS was deployed successfully.
Note: Check and resolve if there any FATAL and ERROR messages, and review all the
WARNING messages for unexpected conditions.
Chapter 7: How to Deploy Strong Authentication on Distributed Systems 95
How to Deploy Strong Authentication on Additional Servers
How to Deploy Strong Authentication on Additional Servers
After you install Strong Authentication Server and CA Advanced Authentication you install the other components on an additional system in this distributed-system deployment.
1. Locate the Strong Authentication installer Installer.bin file.
2. Run the installer using the following command: sh Strong Authentication-version_number-<platform
name>-Installer.bin
The installer starts preparing for the installation.
3. Complete the steps in the Installing on the First System, until you reach the Choose
Product Features screen.
4. Select the components that you want to install.
5. Follow steps 12 through 19 to complete the installation.
Deploy Sample Application
You can use the Sample Application to verify a successful installation of Strong
Authentication. In addition, Sample Application demonstrates the following features:
■
The typical workflows
■
The tasks that you can perform using the Java APIs
■
Integration of your application with Strong Authentication
Follow these steps:
1. Deploy the Strong Authentication version_number-sample-application.war file from the following location:
<install_location>/arcot/samples/java
2. Start Sample Application.
3. Access Sample Application by using the following URL:
http://<host>:<app_server_port>/Strong
Authentication-version_number-sample-application/
96 Installation Guide for Microsoft Windows
How to Deploy Strong Authentication on Additional Servers
Configure Sample Application Communication Server
If you installed the Sample Application and Strong Authentication Server on different systems, you must configure the communication settings.
Follow these steps:
Access the Sample Application in a Web browser window.
1. In the navigation pane, click Setup -> Server Connectivity to open the Strong
Authentication Server Connectivity page.
2. Specify the values for the connection parameters that are listed in the following table:
Note: The configurations that are made using these parameters are valid for the current session. Set these values again if you restart Sample Application or the application server.
Field
Default
Value
Description
IP Address
Port
Maximum Active
Connections localhost The host name or the IP address where the
Strong Authentication Server is available.
9742
64
The port on which the Authentication and the
Issuance service is available.
The maximum number of database connections maintained by the Sample
Application.
3. Click Set Up to save the connection.
Chapter 8: How to Run a Silent Mode
Installation
Chapter 8: How to Run a Silent Mode Installation 97
Silent Mode Installation Guidelines
After you install a Strong Authentication, you can install the component again using the silent installation method. A silent installation completes the installation without user interaction.
Complete the following:
1. Review the silent installation guidelines.
2. Copy the Strong Authentication properties file from the Strong Authentication host system.
3. Copy the Strong Authentication installation media to the same location as the properties file.
4. Modify the Strong Authentication installer properties file.
5. Run the Strong Authentication installer.
Silent Mode Installation Guidelines
Review the following guidelines before starting a silent installation:
■
Back up the default properties file before modifying it.
■
Do not add extra spaces between a parameter name, the equal sign (=), and the parameter value.
■
Save the file after you change it.
Important! Do not use “-r” option with the installer executable to generate a response file to be used for silent installation. Only the default properties file that comes with initial installation should be used.
98 Installation Guide for Microsoft Windows
Default Properties Files
Default Properties Files
To modify the parameters in a default properties file, use a text editor. The default parameters reflect the information that was entered during the initial installation. The default properties file has the parameters that are associated with sensitive information. For example, parameters related to database password, Master Key and
HSM pin. Fill them with appropriate values.
Strong Authentication Property file
The Strong Authentication properties file has the following default name and location:
Name installer.properties
Location strong_auth_home\
strong_auth_home
Specifies the Strong Authentication installation path
Chapter 8: How to Run a Silent Mode Installation 99
Default Properties Files
Modify the Strong Authentication Installer Properties Files
Modify the Strong Authentication installer properties file to define installation variables.
The following default parameters specify the information that you entered during the initial Strong Authentication installation:
CHOSEN_FEATURE_LIST
Specifies a comma-separated list of features that are installed.
Valid values:
WFSRV - Strong Authentication Server
Strong Authentication Server - Server that authenticates, provisions, manages configuration and server instance.
WFSDK - Strong Authentication Java SDK and WS
Java SDK and Web Services that enables issuance, authentication, and configuration requests to the Strong Authentication Server.
WFAPP - CA Strong Authentication Sample Application
Web-based application that demonstrates the usage of Java SDK.
ADMIN - Administration Console - CA Advanced Authentication
Web-based console for managing server configurations.
UDS: User Data Service
The abstraction layer for accessing different types of user repositories, such as relational databases (RDBMSs) and directory servers (LDAPs).
USER_INSTALL_DIR_SILENT
Specifies the location of Strong Authentication installation.
ARCOT_DBTYPE_SILENT
Specifies the type of the database configured.
Valid values: Oracle, Mssqlserver, db2, Mysql.
Primary Database Details
Primary Database has the following database related details:
ARCOT_CONFIG_PRIMARY_DB_SILENT
Specifies that the primary database is configured or not.
Valid values: true, false
ARCOT_PRIMARY_DSN_NAME_SILENT
Specifies the Data Source Name for the database.
100 Installation Guide for Microsoft Windows
Default Properties Files
ARCOT_PRIMARY_DATABASE_SILENT
Specifies the name of the database instance.
ARCOT_PRIMARY_SID_SILENT
Specifies the SID for an Oracle database. For other database types, leave this blank.
ARCOT_PRIMARY_TNS_SERVICE_NAME_SILENT
Specifies the TNS Service name for an Oracle database. For other database types, leave this blank.
ARCOT_PRIMARY_HOST_NAME_SILENT
Specifies the hostname of the Database server.
ARCOT_PRIMARY_PORT_SILENT
Specifies the port number of the given database instance.
ARCOT_PRIMARY_USER_NAME_SILENT
Specifies the database username.
ARCOT_PRIMARY_PASSWORD_SILENT
Specifies the password for the given database username.
ARCOT_CONFIG_BACKUP_DB_SILENT
Specifies that the backup database is configured or not.
Valid values: true, false
Chapter 8: How to Run a Silent Mode Installation 101
Default Properties Files
Backup Database Details
Backup Database has the following database related details:
ARCOT_BACKUP_DSN_NAME_SILENT
Specifies the Data Source Name for the database.
ARCOT_BACKUP_DATABASE_SILENT
Specifies the name of the database instance.
ARCOT_BACKUP_SID_SILENT
Specifies the SID for an Oracle database. For other database types, leave this blank.
ARCOT_BACKUP_TNS_SERVICE_NAME_SILENT
Specifies the TNS Service name for an Oracle database. For other database types, leave this blank.
ARCOT_BACKUP_HOST_NAME_SILENT
Specifies the hostname of the Database server.
ARCOT_BACKUP_PORT_SILENT
Specifies the port number of the given database instance.
ARCOT_BACKUP_USER_NAME_SILENT
Specifies the database username.
ARCOT_BACKUP_PASSWORD_SILENT
Specifies the password for the given database username.
102 Installation Guide for Microsoft Windows
Encryption Details
The encryption details for the database are as follows:
Encryption method: software/hardware
ARCOT_ENC_TYPE_SILENT
Specifies the method of encryption.
Valid values: software, nfast, chrysalis.
ARCOT_ENC_DEVICE_NAME_SILENT
Specifies the device name for hardware encryption.
ARCOT_KEY_LABEL_SILENT
Specifies the Master Key Label.
ARCOT_HSM_PIN_SILENT
Specifies the HSM pin.
ARCOT_HSM_SHARED_LIBRARY_SILENT
Specifies the full path for HSM shared library.
ARCOT_HSM_STORAGE_SLOT_SILENT
Specifies the Storage Slot Number for HSM.
Default Properties Files
Chapter 8: How to Run a Silent Mode Installation 103
How to Perform Silent Installation
How to Perform Silent Installation
Run an unattended installation to install the Strong Authentication without user interaction.
Follow these steps:
1. Review the unattended installation guidelines.
2. Copy the Strong Authentication properties file from the Strong Authentication host system.
3. Copy the Strong Authentication installation media to the same location as the properties file.
4. Modify the Strong Authentication installer properties file.
5. Run the Strong Authentication installer.
Run the following command from the directory to which you copied the Strong
Authentication installation executable and the properties file: installation_media -f installer.properties -i silent
Installation_media
Specifies the Strong Authentication installation executable.
Note: If the properties file is not in the same directory as the installation media, specify its location. Use double quotes if the argument contains spaces.
-i silent
Specifies that the installer run silently.
Example: installation_media -f "C:\Program Files\CA\Arcot Systems
\installer.properties" -i silent
The installation begins. The installer uses the parameters that you specified in the properties file to install the Strong Authentication.
6. Verify the Strong Authentication installation.
Chapter 9: Uninstall Strong Authentication
104 Installation Guide for Microsoft Windows
How to Perform Silent Installation
This procedure guides you through the steps to uninstall Strong Authentication and related components.
Follow these steps::
1. Based on the database type you are using, navigate to the folder:
(for MS SQL) <install_location>\Arcot Systems\dbscripts\mssql
(for Oracle) <install_location>\Arcot Systems\dbscripts\oracle
(for DB2) <install_location>\Arcot Systems\dbscripts\db2
(for MySQL) <install_location>\Arcot Systems\dbscripts\mysql
2. Run the scripts in the following order: a. drop-webfort-8.0.sql
Note: (For MYSQL), Safe Updates should be disabled when running drop-webfort-8.0.sql b. drop-arcot-common-8.0.sql
This deletes all the database tables.
Chapter 9: Uninstall Strong Authentication 105
Post-Uninstallation Steps
3. Stop Strong Authentication Server.
4. Delete the DSN entry by using the following steps: a. Go to Control Panel, and then open Administrative Tools. b. Open Data Sources (ODBC). c. Click the Select System DSN tab. d. Select the required DSN, and click Remove.
5. Navigate to sh <install_directory>/arcot/"Uninstall_CA Strong
Authentication"/Uninstall CA Strong Authentication directory.
6. Double-click the Uninstall Strong Authentication.exe file.
7. Select one of the following options:
■
Select Complete Uninstall to uninstall all the components.
■
Select Uninstall Specific Features to uninstall the selected components, and click Next to display the Choose Product Features screen.
8. Deselect the components you wish to uninstall and click Uninstall.
Important! To Uninstall Specific Features, you must follow the reverse sequence in which you performed the installation. For example, if you have installed the Strong
Authentication Authentication Server followed by CA Advanced Authentication, then you must first uninstall CA Advanced Authentication and then the
Authentication Server.
9. The Uninstallation Complete screen appears at the end of successful uninstallation.Done to exit the installation wizard.
Post-Uninstallation Steps
The following are the post-uninstallation steps:
1. Delete the <install_location>\Arcot Systems folder.
2. Uninstall the following Web applications from the application server:
■ arcotadmin - CA Advanced Authentication
■
■ arcotuds - User Data Service webfort-7.1.01-sample-application - Sample Application
3. Ensure that the Zero G Registry folder is deleted. This hidden folder is copied during the installation into the %ARCOT_HOME% folder.
Note: If you have performed distributed-system deployment, then locate these files on the system where you have deployed the particular application.
106 Installation Guide for Microsoft Windows
Post-Uninstallation Steps
Chapter 10: Configure UTF-8 Support on
Client Systems
Enable UTF-8 support on the systems where you plan to install the Strong
Authentication components that communicate with the database. For example, Strong
Authentication Server, CA Advanced Authentication, and User Data Service. This section walk you through the steps to do so.
To enable UTF-8 support on your UNIX platforms, set the following environment variables:
■
NLS_LANG=en_US.UTF-8
■
LC_CTYPE=en_US.UTF-8
Chapter 10: Configure UTF-8 Support on Client Systems 107
Appendix A: Changing HSM Configurations
This appendix lists the steps that you must perform, if you want to change the Hardware
Security Module (HSM) configurations that you have specified during installation.
Note: Before proceeding with the configurations explained in this section, ensure that you have set up the HSM server and client, and generated the 3DES key in the HSM.
Refer to "(Optional, Only If You are Using HSMs) Requirements for HSM" for more information.
As mentioned in "Hardware Security Module (HSM) Requirements", Strong
Authentication now supports Hardware Security Module (HSM) to secure your data. If you choose to encrypt the data using HSM, then the data that is stored in the database is encrypted with the key that resides in the HSM.
Strong Authentication supports Luna and nCipher netHSM for data encryption using hardware. The configurations for the HSMs are available in the arcotcommon.ini file.
This file provides separate sections for configuring the required HSM, which in the current release are:
■
Luna HSM ([crypto/pkcs11modules/chrysalis])
■ nCipher netHSM ([crypto/pkcs11modules/nfast])
Based on the HSM you are configuring, specify the sharedLibrary parameter in the corresponding section. After specifying the HSM information, re-create the securestore.enc file with the HSM key label, initialize the HSM, and then initialize Strong
Authentication to use the HSM key.
Appendix A: Changing HSM Configurations 109
Post-Uninstallation Steps
To change the HSM information that Strong Authentication needs:
1. Navigate to the following location:
<install_location>\Arcot System\conf
2. Take a backup of securestore.enc.
3. Delete the existing securestore.enc file from <install_location>\Arcot System\conf.
4. To change the HSM information that Strong Authentication needs: a. Navigate to the following location:
<install_location>\Arcot System\conf b. Open arcotcommon.ini in a text editor. c. Ensure the HSMDevice parameter in the [arcot/crypto/device] section is set to the HSM that you plan to use:
■ chrysalis for Luna HSM. or
■ nfast for nCipher netHSM. d. Depending on the HSM that you are configuring, set the sharedLibrary parameter to the location where the HSM library file is located.
For Luna (cryptoki.dll) and for nCipher netHSM (cknfast.dll), specify the absolute path and name of the file.
Note: See "arcotcommon.ini" for more information about the other HSM configuration parameters available in this section. e. Save and close the arcotcommon.ini file.
5. Navigate to the following location, where the DBUtil tool is available:
<install_location>\Arcot Systems\tools\win
6. Run the DBUtil tool with the following commands: a. dbutil -init <HSM_key_label>
Note: The <HSM_key_label> corresponds to the 3DES key that resides in the
HSM.
The preceding command creates a securestore.enc file with the specified key label. The generated file in stored in the <install_location>\Arcot System\conf location. b. dbutil -i <HSM_module_name> <HSM_password>
Note: The <HSM_module_name> is chrysalis for Luna HSM, and nfast for nCipher netHSM.
The preceding command initializes the HSM. c. dbutil -pi <DSN_Name> <Database_password> -h <HSM_password> -d
<HSM_module_name>
110 Installation Guide for Microsoft Windows
Post-Uninstallation Steps
Note: <DSN_NAME> refers to the ODBC DSN that Strong Authentication Server uses to connect to the Strong Authentication database. <Database_password> refers to password used to connect to the database.
The preceding command initializes the Strong Authentication Server data to be encrypted using HSM. d. dbutil -pi <Database_Username> <Database_password> -h <HSM_password>
-d <HSM_module_name>
Note: <Database_Username> refers to the user name used to connect to the
Strong Authentication database. The database user name is case-sensitive, therefore ensure that you provide the correct value. <Database_password> refers to password used to connect to the database.
The preceding command initializes the CA Advanced Authentication and the
User Data Service data to be encrypted by using HSM.
Chapter 11: Requirements for
Java-Dependent Components
Install the components that are required by CA Advanced Authentication, Strong
Authentication Java SDKs, and Web Services:
■
JDK
Note: If you perform a fresh installation of JDK, then set the JAVA_HOME environment variable. The PATH variable must point to $JAVA_HOME/bin/. And ensure that the application server uses the same JAVA_HOME. If you fail to do so, then CA Advanced Authentication and other JDK-dependant components may fail to start.
■
Application Server
■
UDS
Chapter 12: Requirements for HSM
Chapter 11: Requirements for Java-Dependent Components 111
Post-Uninstallation Steps
If you are planning to use HSM to store encryption keys, then set up the following before you proceed:
1. HSM Server
2. HSM Client
3. At least one 3DES key in HSM
Important! Write down the labels of these 3DES keys which are used while encrypting information in the database.
See your platform vendor documentation for detailed information about how to install and configure your HSM Server and Client components and generate the required keys.
Chapter 13: Strong Authentication
Configuration for Oracle RAC
Perform the steps in this section only if you want to use Oracle RAC with Strong
Authentication.
112 Installation Guide for Microsoft Windows
Modify the Database Script
Modify the Database Script
You run the database scripts as a post-installation task in the Strong Authentication installation procedure. Before you run this script, modify it for Oracle RAC.
Follow these steps:
1. To determine the Oracle RAC shared datafile path, log in to the database and run the following command:
SELECT file_name, tablespace_name FROM dba_data_files
The following is sample output of this command:
+DATA/qadb/datafile/users.259.797224649 USERS
+DATA/qadb/datafile/undotbs1.258.797224649 UNDOTBS1
+DATA/qadb/datafile/sysaux.257.797224647 SYSAUX
2. Open the arcot-db-config-for-common-8.0.sql file. This file is in the install_location/arcot/dbscripts/oracle/ directory.
3. Search for the following line in the file: filename varchar2(50) := 'tabspace_arreports_'|| to_char(current_timestamp,
'YYYY-MM-DD-HH24-MI-SS') || '.dat';
4. Replace that line with the following line: filename varchar2(100) :=
'+shared_location/service_name/datafile/tabspace_arreports_'|| to_char(current_timestamp, 'YYYY-MM-DD-HH24-MI-SS') || '.dat';
In the new line:
■
Replace shared_location with the shared datafile path that you determined by running the command given in the first step.
■
Replace service_name with the service name of the Oracle RAC installation.
The following is a sample line: filename varchar2(100) := '+DATA/forwardinc/datafile/tabspace_arreports_'|| to_char(current_timestamp, 'YYYY-MM-DD-HH24-MI-SS') || '.dat';
5. Save and close the script file, and then run it.
Chapter 13: Strong Authentication Configuration for Oracle RAC 113
Configure the JDBC URL
Configure the JDBC URL
Specify the JDBC URL in the format supported by Oracle RAC in the arcotcommon.ini file.
Follow these steps:
1. Open the arcotcommon.ini file in a text editor. This file is in the install_location/arcot/conf/ directory.
2. Specify a value for the URL parameter in the [arcot/db/primarydb] section and, if required, in the [arcot/db/backupdb] section of the INI file. Enter the URL in the following format:
URL.1=jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HO
ST=host_name)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=service_name)(SERVER=DE
DICATED)))
For example:
URL.1=jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HO
ST=172.30.250.18)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=forwardinc)(SERVER=
DEDICATED)))
Note: If Oracle RAC is client configured, then include all the nodes in this format.
3. If the database user that you specified while running the Strong Authentication installer is different from the database user in Oracle RAC, then: a. Change the database user credentials in the arcotcommon.ini file. b. Use DBUtil to change the database user credentials in the securestore.enc file.
DBUtil is available in the ARCOT_HOME/tools/<platform_name> directory.
Instructions on using DBUtil are given in Updating the securestore.enc File and
Setting the TrustStore Password.
4. Save and close the arcotcommon.ini file.
114 Installation Guide for Microsoft Windows
Update the odbc.ini File
Update the odbc.ini File
The odbc.ini file contains connection parameters. For Oracle RAC, you must specify values pertaining to the Oracle RAC installation in the odbc.ini file.
Follow these steps:
1. Create a *.ora file on the system on which you have installed Strong Authentication.
For example, /var/opt/tns.ora.
2. Enter the following lines in the file: section_name =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = host_name_or_IP_address)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = service_name)
)
)
For example: fwdincrac =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.30.250.18)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = forwardinc)
)
)
Note: If Oracle RAC is client configured, then include all the nodes in this format.
3. Save the file.
4. Open the ARCOT_HOME/odbc32v60wf/odbc.ini file in a text editor.
5. For the required DSN sections, comment out the lines containing the following parameters:
■
■
■
HostName
PortNumber
SID
For example:
#HostName=172.30.251.251
#PortNumber=1521
#SID=an
6. Add the following parameters:
Chapter 13: Strong Authentication Configuration for Oracle RAC 115
Update the odbc.ini File
TNSNamesFile=ARCOT_HOME/ora_file_name
ServerName=section_name
For example:
TNSNamesFile=/var/opt/tns.ora
ServerName=fwdincrac
7. Save and close the file.
116 Installation Guide for Microsoft Windows
Appendix B: Additional Configurations for
CA Adapter 2.2.7
To integrate Strong Authentication with your Adapter 2.2.7 instance, you must first perform certain additional configurations. Perform the steps in this section only after all the Strong Authentication components are installed and running properly.
This section contains the following topics:
Update the CA Adapter 2.2.7 Instance
LDAP Plugin Registration
Update the CA Adapter 2.2.7 Instance
Strong Authentication includes the Arcot-Adpater-2.2.7-Compatibility-Package.zip file.
You copy the contents of this file to your existing Adapter installation.
Follow these steps:
1. Extract the contents of the Strong
Authentication-Adpater-2.2.7-Compatibility-Package.zip file to a temporary location.
You see the following structure: arcotsm
WEB-INF
lib
arcot-common.jar
log4j-1.2.15.jar arcotafm
client
arcotjsclient_jso.js
vpn
controller_vpn.jsp
WEB-INF
classes
jspStrings_en.properties dbscripts
mssql
arcot-db-config-for-adapter-statemanager.sql
drop-adapter-statemanager.sql
oracle
arcot-db-config-for-adapter-statemanager.sql
drop-adapter-statemanager.sql
Appendix B: Additional Configurations for CA Adapter 2.2.7 117
LDAP Plugin Registration
2. Update State Manager as follows: a. Navigate to the location on the application server where you deployed State
Manager 2.2.7, and delete the arcot-common-1.0.9.jar file.
For example, in Apache Tomcat this location is
TOMCAT_HOME/arcotsm/WEB-INF/lib. b. From the extracted file structure, copy the files arcot-common.jar and log4j-1.2.15.jar to this location. c. Restart the application server.
3. Update Authentication Flow Manager as follows: a. From the extracted file structure, copy the arcotjsclient_jso.js file to the arcotafm/client folder on the application server where you deployed
Authentication Flow Manager 2.2.7.
For example, in Apache Tomcat this location is
TOMCAT_HOME/arcotafm/client. b. From the extracted file structure, copy the jspStrings_en.properties file to the arcotafm/WEB-INF/classes folder on the application server where you deployed Authentication Flow Manager 2.2.7. For example, in Apache Tomcat this location is TOMCAT_HOME/arcotafm/WEB-INF/classes.
4. Perform the following steps on the database schema: a. If the State Manager and Strong Authentication instances are using different databases, then drop the table ARCMNDBERRORCODES in the database that is used by State Manager. b. Run the part of the script that creates ARCMNDBERRORCODES table and inserts rows into it.
LDAP Plugin Registration
Perform the steps in this section only in the following scenarios:
■
You performed a new installation of Strong Authentication and want to use it with
Adapter 2.2.7.
■
You upgraded from versions 6.2.x to 7.x, did not register the LDAP plugin, and then upgraded.
■
You upgraded from 6.2.x to 7.1.01, but did not register the LDAP plugin in the previous releases.
CA Adapter 2.2.7 uses a plugin to enable LDAP authentication using Strong
Authentication. To verify that the LDAP plugin used in Adapter 2.2.7 works with Strong
Authentication, you must register it.
118 Installation Guide for Microsoft Windows
LDAP Plugin Registration
Register the LDAP Plugin
Register the LDAP plugin using CA Advanced Authentication.
Follow these steps:
1. Log in to CA Advanced Authentication as a master administrator.
2. Click the Services and Server Configurations tab.
3. Click the Strong Authentication subtab, and on the left pane, under Extensible
Configurations, select Plug-In Registration.
The Register Plug-In screen appears in the right pane.
4. Provide appropriate values for the following fields:
■
■
Name: A name for the plugin.
Handler Path: arwfldapauthplugin.dll.
■
■
Configuration template: Select the path to the file ldapauthplugin-config.xml in the file system. Typically, this file is located in the
Install_Location/arcot/samples/xml/webfort directory.
Move UP_AUTH from the Available Events list to the Supported Events list.
5. Click the Register button.
Appendix B: Additional Configurations for CA Adapter 2.2.7 119
LDAP Plugin Registration
Configure the Plugin for an Organization
You can now configure the registered plugin for different organizations.
Follow these steps:
1. Log in to the CA Advanced Authentication as a global administrator.
2. Click the Organizations tab, and search for the organization for which you want to use the plugin.
Note: The organization that you select here must be mapped to LDAP in the AFM
Wizard.
The Organization information screen appears.
3. Click the Strong Authentication Configuration subtab, and on the left pane, under
Extensible Configurations, select Plug-In Configurations.
The Configure Plug-In screen appears.
4. Select the registered LDAP authentication plugin from the Name list.
5. Move UP_AUTH from the Supported Events list to the Selected Events list.
6. Click Submit.
A message appears indicating that the plugin was configured successfully.
120 Installation Guide for Microsoft Windows
Appendix C: Deploy Administrative Console on IBM WebSphere
To deploy the CA Advanced Authentication on IBM WebSphere 7.0, 8.0 and 8.5, perform the following steps:
1. Change the working directory to:
<install_location>/arcot/sbin
2. Type source arwfenv and press Enter to set the $ARCOT_HOME environment variable.
3. Restart the application server for the changes to take effect.
4. Navigate to the following location where the CA Advanced Authentication WAR file is located:
<install_location>/arcot/java/webapps
5. Copy the arcotadmin.war file to a temporary directory. For example, opt/arcot_temp.
6. Extract the arcotadmin.war file contents.
Of the JARs that are extracted to the /opt/arcot_temp/WEB_INF/lib directory, the following JARs are used to create the shared library in IBM WebSphere:
■
■
■ axiom-api-1.2.10.jar axiom-impl-1.2.10.jar axis2-java2wsdl-1.5.2.jar
■
■
■ backport-util-concurrent-3.1.jar commons-httpclient-3.1.jar commons-pool-1.5.5.jar
■ axiom-dom-1.2.10.jar
■
■
■ axis2-adb-1.5.2.jar axis2-kernel-1.5.2.jar commons-codec-1.3.jar
■
■
■ commons-logging-1.1.1.jar log4j-1.2.16.jar axis2-transport-http-1.5.2.jar
■ axis2-transport-local-1.5.2.jar
7. Log in to IBM WebSphere Administration Console.
Appendix C: Deploy Administrative Console on IBM WebSphere 121
LDAP Plugin Registration
8. Click Environment, and then click Shared Libraries. a. From the Scope drop-down, select a valid visibility scope. The scope must include the target server/node on which the application is deployed. b. Click New. c. Enter the Name, for example, ArcotAdminSharedLibrary. d. Specify the Classpath. Enter the path and file name for all the JAR files that are extracted in Step 3.
For example, /opt/arcot_temp/WEB_INF/lib/axiom-api-1.2.10.jar e. Click Apply to save the changes.
9. Navigate to the following location where CA Advanced Authentication WAR file is located:
<install_location>/arcot/java/webapps
10. Deploy arcotadmin.war in the application server.
11. Configure shared library, as follows: a. Click Applications, Application Types, WebSphere Enterprise Applications. b. Click arcotadmin_war. c. In the References section, click Shared library references. d. Select arcotadmin_war and click Reference shared libraries. e. Select the ArcotAdminSharedLibrary from the Available list and move it to the
Selected list. f. Click OK to save the configurations.
12. Configure the class loader order and policy as follows: a. Click Applications, Application Types, and then click WebSphere enterprise applications. b. Click arcotadmin_war. c. Click Class loading and update detection link. d. In the Class loader order section, select the Classes loaded with local class loader first (parent last) option. e. In the WAR class loader policy section, select the Single class loader for application option. f. Click OK to save the configurations.
13. Ensure that the application is restarted.
122 Installation Guide for Microsoft Windows
Appendix D: Troubleshooting Strong
Authentication Issues
Appendix D: Troubleshooting Strong Authentication Issues 123
LDAP Plugin Registration
This appendix describes the troubleshooting steps, which will help you resolve the errors that you might face while using Strong Authentication. The troubleshooting topics are classified based on different Strong Authentication components, as follows:
■
Installation Errors
■
Database-Related Errors
■
Strong Authentication Server Errors
Before you perform any troubleshooting tasks, check the log files to see if there were any errors. By default, all the log files are saved in the <install_location>\Arcot
Systems\logs\ directory. The following table lists the default log file names of the components.
Component Name File Name Description
CA Advanced
Authentication
User Data Service o n i a t i t c h e n v e r
S e r arcotwebfortstartup
S t r
A u t o n g arcotwebfort.log arcotadmin.log
This file records all the start-up (or boot) actions. The information in this file is very useful in identifying the source of the problems if the Strong
Authentication service does not start up.
This file records all requests processed by the server.
This file records the CA Advanced
Authentication operations. arcotuds.log This file records the User Data Service operations.
124 Installation Guide for Microsoft Windows
Installation Errors
Installation Errors
Problem:
When I download the CA Auth ID in IE browser on the server with Strong Authentication installed, it gives the following error:
Your security settings have blocked an application signed with an expired or not-yet-valid certificate from running.
Solution:
Change Java Settings by navigating to Control Panel and click on Java. Select the Security option as Medium (Instead of High). Default option is High which gives the exception.
Then download CA Auth IDusing "Arcot Applet Client" & "Arcot Flash Client" on IE or
Firefox or Chrome.
Problem:
When I download the CA Auth ID in Chrome browser on the server with Strong
Authentication installed, it gives the following error:
Permanent storage in the Flash player is disabled.
Solution:
Enable HTTPS instead of HTTP to download using "Arcot Flash Client". Then download the CA Auth ID on IE or Firefox or Chrome.
Problem:
I do not find arcotadmin.war in <install_location>\Arcot Systems\java\webapps directory.
Cause:
The file may not have been created during installation.
Solution:
Perform the following steps to create the arcotadmin.war file:
1. Open command window.
2. Ensure ARCOT_HOME environment variable is set.
Appendix D: Troubleshooting Strong Authentication Issues 125
Installation Errors
3. Navigate to <install_location>\Arcot Systems\tools\common\bundlemanger directory.
4. Run bundlemanager with the following command: java -jar bundle-manager.jar
The preceding command generates the arcotadmin.war file in
<install_location>\Arcot Systems\java\webapps directory.
Problem:
I cannot start the Strong Authentication Server (Strong Authentication Service). I see the following error in arcotwebfortstartup.log:
126 Installation Guide for Microsoft Windows
Cause:
Solution:
Problem:
Cause:
Solution:
Installation Errors
Failed to initialize DB Pool Manager or
Data source name not found and no default driver specified
The possible causes for this issue are:
■
The DSN for your database was not created as System DSN.
■
You are using a 64-bit platform. As a result, the DSN was created by using the 64-bit
ODBC Manager.
You can verify the DSN-related issues in the arcotcommon.ini file. If the problem is
DSN-related, then:
1. To resolve the first issue, ensure that the DSN is a System DSN. To do so: a. Open the Control Panel, navigate to Administrative Tools, and Data Sources
(ODBC). b. Activate the System DSN tab, and verify that your DSN exists here. If not, then you must re-create the DSN with the same name as earlier. c. Restart the service.
2. To resolve the second issue (if you are using a 64-bit platform), use the 32-bit version of the ODBC Manager. On Windows, you will find the 32-bit version at
C:\Windows\SysWOW64.
Note: For detailed information about arcotcommon.ini and other configuration files, see appendix, "Configuration Files and Options" in the Strong Authentication
Installation and Configuration Guide.
I cannot start the Strong Authentication Server (Strong Authentication Service). The error message indicates that the service starts and stops automatically.
A possible cause for this issue might be that you specified details for a Database during installation, but the data source was not created successfully.
To resolve this issue:
Appendix D: Troubleshooting Strong Authentication Issues 127
Installation Errors
1. Verify if there is a corresponding entry for the DSN in arcotcommon.ini.
■
If entry not found, manually create the DSN.
2. If you found the entry, then clean up the database (see "Uninstalling Strong
Authentication Schema") and reseed the database, as described in section,
"Running Database Scripts".
3. Restart the Strong Authentication Server.
Problem:
When I launch CA Advanced Authentication for the first time (section, "Performing the
Bootstrapping Tasks") as the Master Administrator, I see the following message:
The server encountered an internal error that prevented it from fulfilling this request."
I see the following error in the arcotadmin.log file: adminLog: java.lang.UnsatisfiedLinkError: no ArcotAccessKeyProvider in java.library.path
Cause:
The JAVA library does not include the path to one of the following files:
■
ArcotAccessKeyProvider.dll
■ arcot-crypto-util.jar
Solution:
Do the following:
1. Ensure that the PATH variable includes the absolute path to the following files:
■
ArcotAccessKeyProvider.dll
■ arcot-crypto-util.jar
2. Restart the application server.
Problem:
I do not see the log file (arcotadmin.log, arcotuds.log, or webfortserver.log) in the logs directory in ARCOT_HOME.
Cause:
Some of the probable causes for this issue might be:
128 Installation Guide for Microsoft Windows
Solution:
Problem:
Cause:
Solution:
Problem:
Cause:
Installation Errors
■
■
ARCOT_HOME might not be set correctly during installation.
The application server JAVA HOME might be pointing to JRE instead of the JDK
HOME.
To resolve these issues, you must:
■
Ensure that you reset the ARCOT_HOME to point to the correct location. Typically, this is <installation_location>\Arcot Systems\.
■
As a result of this, when you use the cd %ARCOT_HOME% command in the command prompt window, your current directory must change to
<installation_location>\Arcot Systems\.
Ensure that you copy the ArcotAccessKeyProvider.dll and arcot-crypto-util.jar files in the application server JAVA HOME location.
I deployed the UDS, but it is not coming up.
One of the possible causes might be that the application server JAVA HOME might be pointing to JRE instead of the JDK HOME.
Ensure that you have copied the ArcotAccessKeyProvider.dll and arcot-crypto-util.jar files in the application server JAVA HOME location.
Connection to the UDS fails. I see the following error message:
Unable to contact User Data Service
The possible causes might be:
■
You might not have specified the UDS Host, Port, and Application Context information for UDS correctly.
■
The UDS service might not be initialized.
Appendix D: Troubleshooting Strong Authentication Issues 129
Installation Errors
Solution:
To resolve this issue:
Verify whether the UDS information that you have provided in the "User Data Service
Configuration" page of CA Advanced Authentication is correct. The details in Host, Port, and Application Context fields must be correct.
1. Check the UDS log file to ensure that the service was initialized successfully.
130 Installation Guide for Microsoft Windows
Database-Related Errors
Database-Related Errors
Problem:
Connection to the database fails with the following entry in the Server log file:
ReportError: SQL Error State:08001, Native Error Code: 30FD, ODBC
Error: [DataDirect][ODBC Oracle driver][Oracle]ORA-12541: TNS:no listener
Solution:
Check for the following:
■
Listener service on your database server.
■
The TNSnames.ora file settings on the system where Server is installed.
Problem:
Connection to the database fails with the following entry in the Server log file:
TNS:listener could not resolve SERVICE_NAME given in connect descriptor
Solution:
Check for the following:
■
Database is started. If it is not, you will get the above message.
■
If the database is running, probably the database has not registered yet with the listener. This occurs when the database or listener just starts up. Normally this problem should be solved by waiting a minute or so.
■
If you are using static registration, ensure the SERVICE_NAME entry used in the connection string (TNSNAMES.ORA, NAMES, OID, ...) matches a valid service know by the listener.
■
You can use C:>tnsping SERVICE_NAME - to check the status or C:>lsnrctl services - to verify all the services known to listener.
Problem:
Connection to the database fails with the following entry in the Server log file:
Database password could not be obtained from securestore.enc
Cause:
The database details might not be available in securestore.enc file.
Solution:
Appendix D: Troubleshooting Strong Authentication Issues 131
Database-Related Errors
Use the DBUtil tool to update the securestore.enc file with the database details. See CA
Strong Authentication Administration Guide for more information about how to use
DBUtil.
Problem:
Connection to the database fails with the following entry in the Server log file:
RA-03113: end-of-file on communication channel
Cause:
This is a generic error that indicates that the connection has been lost. This can be caused by many reasons such as:
■
Network issues or problems
■
Forceful disconnection of a Server session
■
Oracle Database crash
■
Database Server crash
■
Oracle internal errors, such as ORA-00600 or ORA-07445, causing aborts
■
Oracle Client or TNS layer inability to handle the connections
Solution:
Check for the possible causes mentioned in the preceding list.
132 Installation Guide for Microsoft Windows
Strong Authentication Server Errors
Strong Authentication Server Errors
Problem:
I am trying to start Server, but it is not coming up. The last lines in arcotwebfortstartup.log shows the following error:
WARN STARTUP -161388848 00WFMAIN - [11]: Protocol module
[SVRMGMT_WS] received portType error [bind: Address already in use]
Cause:
The possible cause for this issue is that the Server Management Port (Default Port
Number: 9743) is already open on the host by some other process. While, Server requires a minimum of Server Management port to start up.
Solution:
Do the following:
1. Open the command prompt window.
2. Navigate to %ARCOT_HOME%\bin.
3. Run the following command: arwfserver -i
4. Enter setsvrmgmtport <new_port_number>
After the Server Management port is set, the Master Administrator can log in to CA
Advanced Authentication and can configure the other ports.
Problem:
RADIUS requests fail with the "Access-Reject" message.
Cause:
Check for the following:
■
Shared secret is configured correctly.
■
Server logs for any errors.
Solution:
Log in to as Global Administrator or Organization and set the shared secret using the
RADIUS Configuration page.
CA Advance d Authenti cation
Appendix D: Troubleshooting Strong Authentication Issues 133
Strong Authentication Server Errors
Problem:
CA Auth ID authentication fails with the following entry in the Server log file:
[Arcot Exception,No valid issuer certificate is available for this certificate: unknown or invalid certificate issuer in ArcotVerifier],
Challenge verification failed -
Cause:
The Domain Key may have expired.
Solution:
Log in to as Global Administrator or Organization and configure the Domain Key using the Credential Key Management Configuration CA Advanced Authentication page.
134 Installation Guide for Microsoft Windows
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.
Document public link
Advertisement
Key features
Secures passwords
Provides flexible authentication methods
Uses CA Auth ID and CA Auth ID OTP
Protects against brute force attacks
Supports various deployment models
Offers a user-friendly administrative console
Provides Java APIs for integration
Supports various databases
Can be deployed on single or distributed systems
Includes a Sample Application for testing
Frequently asked questions
Strong Authentication supports single-system, distributed-system, and high-availability deployment models. Choose the model that best suits your business needs.
The installation process involves configuring the database server, installing Strong Authentication components, running database scripts, preparing the application server, deploying CA Advanced Authentication, logging in to CA Advanced Authentication, starting the Strong Authentication Server, and deploying the Sample Application. Follow the steps outlined in the installation guide.
CA Auth ID is a secure software credential that provides two-factor authentication. It is based on CA-patented Cryptographic Camouflage technology, which protects the user's private key against dictionary attacks and Man-in-the-Middle (MITM) attacks.
