TWS Distributed Mainframe User Education April 18 21

TWS Distributed & Mainframe User Education April 18 -21, 2010 8 Carefree Resort 8 Carefree, AZ TWSd - Security Workshop Part I of III T 302 Tuesday, 4/20/2010

Agenda l Security Overview l TWS Authentication JSC u TDWC u CLI u Database u l Configuring TWS/TDWC for LDAP/AD l Configuring TWS/TDWC for Single Sign-On

Security Overview l Authentication Versus Authorization l TWS Security Architecture l Why use LDAP as User Registry? l What is Single Sign-On? l Interactive Users versus Job Users

Authentication versus Authorization l Authentication u Verifying who you say you are. u Performed through a User Registry. u Registries: LDAP, AD, Local OS, Custom l Authorization u Verifying requested actions are allowed. u Qualified using TDWC (i. e. e. WAS) roles and TWS Security file rules.

TWS Security Architecture User Credentials JSC and CLI User Credentials TDWC TWS Single Sign-On or User Credentials Client Browser TWS Security File Database Credentials TWS Database LDAP Local OS Custom Registry

Why use LDAP as User Registry? l l l Local. OS requires administration of separate accounts for each TDWC/TWS user. u Optionally create local groups for TWS roles. u Create and maintain local accounts for all TWS user on each server hosting a TDWC or e. WAS instance. Pluggable Authentication Module (PAM) can support centrally managed users and groups. u Uses Custom registry to authenticate TDWC/TWS users via PAM. u Default for Linux servers. u PAM can be configured to reference any number of user registries, including Local. OS and LDAP servers. u Configuration supports the use of TDWC/TWS Single Sign-On. LDAP takes advantage of centrally managed user registry. u Optionally create LDAP groups for TWS roles. u No additional user administration. u Configuration supports the use of TDWC/TWS Single Sign-On.

What is Single Sign-On? l Permits TDWC access to all Schedulers or Agents where user has authorization , without the need to enter multiple passwords. TWS (Prod) LTPA Token User authenticates to TDWC LTPA Token TWS (QA) TWS (Dev)

Interactive Users versus Job Users l Interactive Users employ the TDWC, JSC, or CLI to work with TWS. Authenticated via the e. WAS configured User Registry. u All actions checked for authorization against TWS Security File. l Job Users are documented as the “Login” user for one or more jobs. u No authentication required to start UNIX/Linux job processes as the documented user. u Windows job processes authenticated using credential specified in a TWS “Windows User” definition. u No authorization check needed against TWS Security File to launch jobs. Assumes jobs are defined by an authorized Interactive User. u If job script uses TWS CLI for any actions that require Database access, job user must authenticate to target TWS e. WAS. u

JSC, TDWC, CLI, and RDBMS TWS AUTHENTICATION

Authentication – JSC l Authenticates users through a TWS e. WAS instance. l Users create a separate Scheduling Engine definition for any required TWS environments. User’s credentials specified in each Scheduling Engine definition. u User password changes require updates to each Scheduling Engine. u l Single Sign-On is not available through JSC.

Authentication - TDWC l Authenticates users through TDWC e. WAS or WAS instance. l For Single Sign-On configurations: u TWS Scheduling Engine credentials are not required. u Allows sharing of Engine definitions, which reduces TWS Scheduling Engine administration. u Simplifies user password changes. l For other configurations: u TWS Engine credentials must be specified for each Scheduling Engine definition. u Typically requires each user to create their own Scheduling Engine definitions. l TWS Reporting Database credentials are required for any configuration.

Authentication – TWS CLI l CLI Commands, requiring database access, must authenticate to a TWS e. WAS instance. Connects to e. WAS using http or https protocols. u Local and Remote (i. e. from FTAs and DMs) connections are supported. u User ID and Password required for connection. u l CLI Commands only requiring plan access do not require authentication. l Single Sign-On is not available through CLI.

RDBMS Authentication l TWS Scheduling Object Database. RDBMS credentials stored in TWS e. WAS configuration. u Modified using scripts in wastools directory. u • show. Security. Properties. sh • change. Security. Properties. sh l TWS Reporting Database. Specified in TWS Engine definitions. u Recommend defining “Read Only” database user for reporting. u

Configuring TDWC/TWS for LDAP/AD AUTHENTICATION

LDAP Overview l LDAP security support for TDWC, JSC GUI and remote CLI. l Users can be authenticated thru external LDAP Servers. u u u 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. e. Security Server 1. 4, 1. 5, or 1. 6 Windows Active Directory 2003 Sun ONE DS

Planning TWS/TDWC for LDAP/AD l Request LDAP/AD Bind User for TWS/TDWC. l Request LDAP/AD “TWS Admin” User. l Collect LDAP/AD Server Information: u u u LDAP Server type LDAP Server host LDAP Server port Base Distinguished Name (DN) for User searches Is SSL required for LDAP/AD server connections? l 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 l Backup e. WAS configuration using l l wastools/backup. Config. sh script. Add LDAP/AD Server’s “Signer Certificate” to e. WAS node. Default. Trust. Store for SSL connections. Update TDWC administrative role definitions for LDAP/AD User IDs or Groups. Update e. WAS security properties for LDAP/AD authentication. Update TWS security file to qualify users by LDAP User IDs or LDAP Group.

Configuring e. WAS instances for SSO TDWC/TWS SINGLE SIGN-ON

Configuring Single Sign-On l Single Sign-On Requirements. u u Common LDAP Repository or Custom Repository for all TDWC and TWS e. WAS instances. Shared LTPA token-key. l Configuration Steps. u u u Export LTPA token-key from one e. WAS instance. Import LTPA token-key from above step into other e. WAS instances. Disable automatic LTPA token-key generation on key expiry. Stop/Start all e. WAS instances. Test SSO Configuration.

TWS Distributed & Mainframe User Education April 18 -21, 2010 8 Carefree Resort 8 Carefree, AZ REMINDER! l Please complete the session evaluation card included in your registration envelope. l Place the evaluation card in the basket on your way out of the session.