TWSd - Security Workshop Part I of III

T302Tuesday, 4/20/2010

TWS Distributed & Mainframe

User Education April 18-21, 2010 Carefree Resort Carefree, AZ

Agenda

Security OverviewTWS Authentication

JSC TDWC CLI Database

Configuring TWS/TDWC for LDAP/ADConfiguring TWS/TDWC for Single Sign-On

Security Overview

Authentication Versus AuthorizationTWS Security ArchitectureWhy use LDAP as User Registry?What is Single Sign-On?Interactive Users versus Job Users

Authentication versus Authorization

Authentication Verifying who you say you are. Performed through a User Registry. Registries: LDAP, AD, Local OS, Custom

Authorization Verifying requested actions are allowed. Qualified using TDWC (i.e. eWAS) roles

and TWS Security file rules.

TWS Security Architecture

TDWC TWS

LDAP Local OS

CustomRegistry

LDAP Local OS

CustomRegistry

TWS Database

Client Browser

JSC and CLI

Single Sign-On orUser Credentials

TWS SecurityFile

DatabaseCredentials

UserCredentials

UserCredentials

Why use LDAP as User Registry?

LocalOS requires administration of separate accounts for each TDWC/TWS user. Optionally create local groups for TWS roles. Create and maintain local accounts for all TWS user on each server hosting a

TDWC or eWAS instance. Pluggable Authentication Module (PAM) can support centrally managed users and

groups. Uses Custom registry to authenticate TDWC/TWS users via PAM. Default for Linux servers. PAM can be configured to reference any number of user registries, including

LocalOS and LDAP servers. Configuration supports the use of TDWC/TWS Single Sign-On.

LDAP takes advantage of centrally managed user registry. Optionally create LDAP groups for TWS roles. No additional user administration. Configuration supports the use of TDWC/TWS Single Sign-On.

What is Single Sign-On?

TDWC

TWS(Prod)

TWS(QA)

TWS(Dev)

LTPA Token

LTPA Token

LTPA TokenUser authenticates to TDWC

Interactive Users versus Job Users

Interactive Users employ the TDWC, JSC, or CLI to work with TWS. Authenticated via the eWAS configured User Registry. All actions checked for authorization against TWS Security File.

Job Users are documented as the “Login” user for one or more jobs. No authentication required to start UNIX/Linux job processes as the

documented user. Windows job processes authenticated using credential specified in

a TWS “Windows User” definition. No authorization check needed against TWS Security File to launch

jobs. Assumes jobs are defined by an authorized Interactive User. If job script uses TWS CLI for any actions that require Database

access, job user must authenticate to target TWS eWAS.

TWS AUTHENTICATIONJSC, TDWC, CLI, and RDBMS

Authentication – JSC

Authenticates users through a TWS eWAS instance.

Users create a separate Scheduling Engine definition for any required TWS environments. User’s credentials specified in each Scheduling

Engine definition. User password changes require updates to each

Scheduling Engine.

Single Sign-On is not available through JSC.

Authentication - TDWC

Authenticates users through TDWC eWAS or WAS instance. For Single Sign-On configurations:

TWS Scheduling Engine credentials are not required. Allows sharing of Engine definitions, which reduces TWS Scheduling

Engine administration. Simplifies user password changes.

For other configurations: TWS Engine credentials must be specified for each Scheduling

Engine definition. Typically requires each user to create their own Scheduling Engine

definitions. TWS Reporting Database credentials are required for any

configuration.

Authentication – TWS CLI

CLI Commands, requiring database access, must authenticate to a TWS eWAS instance. Connects to eWAS using http or https protocols. Local and Remote (i.e. from FTAs and DMs)

connections are supported. User ID and Password required for connection.

CLI Commands only requiring plan access do not require authentication.

Single Sign-On is not available through CLI.

RDBMS Authentication

TWS Scheduling Object Database. RDBMS credentials stored in TWS eWAS

configuration. Modified using scripts in wastools directory.

• showSecurityProperties.sh• changeSecurityProperties.sh

TWS Reporting Database. Specified in TWS Engine definitions. Recommend defining “Read Only” database user

for reporting.

LDAP/AD AUTHENTICATIONConfiguring TDWC/TWS for LDAP/AD

LDAP Overview

LDAP security support for TDWC, JSC GUI and remote CLI.

Users can be authenticated thru external LDAP Servers.

IBM Tivoli Directory Server 5.1, 5.2, or 6.0 IBM z/OS® Security Server 1.4, 1.5, or 1.6 IBM z/OS.eSecurity Server 1.4, 1.5, or 1.6 Windows Active Directory 2003 Sun ONE DS

Planning TWS/TDWC for LDAP/AD

Request LDAP/AD Bind User for TWS/TDWC. Request LDAP/AD “TWS Admin” User. Collect LDAP/AD Server Information:

LDAP Server type LDAP Server host LDAP Server port Base Distinguished Name (DN) for User searches Is SSL required for LDAP/AD server connections?

Optionally, request new LDAP/AD Groups for each unique TWS role and assign users to appropriate groups.

Configuring TWS/TDWC for LDAP or Active Directory

Backup eWAS configuration using wastools/backupConfig.sh script.

Add LDAP/AD Server’s “Signer Certificate” to eWAS nodeDefaultTrustStore for SSL connections.

Update TDWC administrative role definitions for LDAP/AD User IDs or Groups.

Update eWAS security properties for LDAP/AD authentication.

Update TWS security file to qualify users by LDAP User IDs or LDAP Group.

TDWC/TWS SINGLE SIGN-ONConfiguring eWAS instances for SSO

Configuring Single Sign-On

Single Sign-On Requirements. Common LDAP Repository or Custom Repository for all

TDWC and TWS eWAS instances. Shared LTPA token-key.

Configuration Steps. Export LTPA token-key from one eWAS instance. Import LTPA token-key from above step into other eWAS

instances. Disable automatic LTPA token-key generation on key expiry. Stop/Start all eWAS instances. Test SSO Configuration.

REMINDER!

Please complete the session evaluation card included in your registration envelope.

Place the evaluation card in the basket on your way out of the session.

TWS Distributed & Mainframe

User Education April 18-21, 2010 Carefree Resort Carefree, AZ