Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "TWSd - Security Workshop Part I of III T302 Tuesday, 4/20/2010 TWS Distributed & Mainframe User Education April 18-21, 2010  Carefree Resort  Carefree,"— Presentation transcript:

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

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

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

4 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.

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

6 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.

7 What is Single Sign-On? TDWC TWS (Prod) TWS (QA) TWS (Dev) LTPA Token User authenticates to TDWC

8 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.

9 TWS AUTHENTICATION JSC, TDWC, CLI, and RDBMS

10 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.

11 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.

12 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.

13 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.

14 LDAP/AD AUTHENTICATION Configuring TDWC/TWS for LDAP/AD

15 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

16 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.

17 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.

18 TDWC/TWS SINGLE SIGN-ON Configuring eWAS instances for SSO

19 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.

20 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


Download ppt "TWSd - Security Workshop Part I of III T302 Tuesday, 4/20/2010 TWS Distributed & Mainframe User Education April 18-21, 2010  Carefree Resort  Carefree,"

Similar presentations


Ads by Google