Improving Access to EPA Servers Modernizing TSSMS

1. Improving Access to EPA ServersModernizing TSSMS Rebecca Astin EPA Web Workgroup April 15, 2010

2. Agenda • What Is TSSMS? • Types of TSSMS Users • Hosting Environments That Use TSSMS • How TSSMS Works • Current Request and Fulfillment Processes • How TSSMS Services Are Billed • Issues with Current System • Recommendations for Improvement • Next Steps Pg 1

3. TSSMS • Time Sharing Services Management System • Developed in the early 1980’s to manage users on EPA’s mainframe • Is a FOCUS application that runs on the Mainframe (unsupported by vendor) • Is a user and account registration system • Not an identity management and authentication system • Users do not authenticate log-in credentials against TSSMS • Types of “TSSMS” Accounts / IDs: • 3-character User ID • 8-character Account • 4-character Account Pg 2

4. TSSMS Accounts/ IDs • 3-Character TSSMS ID • “User Name” for an individual • A user must be associated with at least one TSSMS account • Free of charge for all servers except www.epa.gov (U03), intranet.epa.gov (U02), staging.epa.gov (U07) • User IDs are unique for only as long as the ID is active; UIDs can be reassigned if not used in 455 days • 8-Character TSSMS Account • Name of physical directory on the static Web and FTP servers • Used to allocate disk space on the static Web and FTP servers • Only Used for billing purposes on Oracle and OAS servers • Accounts belong to an “Account Owner”, usually the ADP Coordinator • 4-Character TSSMS Account • Name of physical directory on the mainframe Pg 3

5. Types of TSSMS Users • UNIX System Administrators • Server administrators who need access to the server • Users must change their password every 90 days • Other “Server Users” • Server login for Application and Web Site Developers • FTP or Telnet access • Users must change their password every 90 days • Sometimes misused for server-to-server communications • Application Users • Application user ID and password for a handful of applications and High Performance Computing (HPC) • e.g., AQS, ICIS, RCRA • Users must change their password every 90 days • Server-to-Server Communications • Unapproved use of TSSMS accounts/ IDs – but happens as a “work around” Pg 4

6. Hosting Environments that Use TSSMS • Static Web Servers • www.epa.gov (U03) • Intranet.epa.gov (U02) • Staging.epa.gov (U07) • Application Servers • Oasstage.epa.gov (U11) • Oasint.epa.gov (U12) • Oaspub.epa.gov (U13) • Oasext.epa.gov (U04) Pg 5

7. Hosting Environments that Use TSSMS • Database Servers • Oracle database (ORC) • FTP Servers • Inmoor.epa.gov (U15) • Exmoor.epa.gov (U16) • High Performance Computing • Amber (HPC) • Mainframe Pg 6

8. Hosting Environments that Do NOT Use TSSMS • ColdFusion • Domino • Windows-based Dedicated Environments • Developer access for Dedicated Unix Systems • Uses TSSMS ID, but not associated with a TSSMS Account on that server • RISKY, Potential Identity Conflicts Pg 7

9. Applications that Use TSSMS • RCRA • AQS • ICIS • TRIS • TMDL • IGOR • IRMS • WIS • All Mainframe Applications (including IFMS) • Possibly Others? Pg 8

10. How TSSMS Works - UNIX • One-to-one relationship between TSSMS Account and directory on the server • Log-in authentication against local password file • Feedback Loops • Failure to change password after 95 days will cause the user to be unable to log into the server • Users must log into their account at least every 455 days or they will be flagged for deletion from the system • If there are no more users associated with a TSSMS Account, the UNIX team will notify “Group TSSMS” to contact the ADP Coordinator responsible for that account • Files will be deleted after 30 days if no action is taken by the ADP Coordinator when notified that their TSSMS account will be deleted Pg 9

11. Non-IBM Flows Authentication Flows IBM Flows UNIX/ Mainframe Workflow

12. How TSSMS Works - Mainframe • A new users contacts their ADP Coordinator to obtain a 3-character user ID on the mainframe • ADP Coordinator creates the ID and associates it with an account on the IBM hardware code • Nightly TSSMS processes add the user to the RACF database • Users must contact their RSA to “claim ownership” of them in the RACF database • RSA must associate the user with an account in the RACF database • IDs associated with the IBM hardware code are flagged for deletion after 365 days of inactivity • Users logging into the mainframe, authenticate against the RACF database Pg 11

13. How TSSMS Works – OAS • New TSSMS Accounts for a new application must be obtained by contacting the application owner’s ADP coordinator • OAS administrators receive nightly reports that show all new TSSMS accounts on U11, U12, U13, U04 • The TSSMS account name is given to the OAS team during the ADC process • The OAS team notifies the billing team to associate the application with the name of the TSSMS account in the WLC database • The OAS team receives nightly reports showing all users added to or removed from each TSSMS account • The OAS team adds/ removes users to/from the authentication database based on these reports • The OAS team also add/s removes users based on individual request or requests during the ADC process (i.e., bypassing TSSMS) • Users logging into the staging server are authenticated against an Oracle database on the server • There are no automatic feedback loops to notify TSSMS when a user or account is removed from the authentication database or server Pg 13

14. How TSSMS Works – ORC • New TSSMS Accounts for a new database must be obtained by contacting the application owner’s ADP coordinator • Oracle DBAs receive nightly reports that show all new TSSMS accounts registered to hardware code ORC • The TSSMS account name is given to the Oracle team during the ADC process • The Oracle DBAs notify the billing team to associate the database with the name of the TSSMS account in the WLC database • The Oracle DBAs receive nightly reports showing all users added to or removed from each TSSMS account • The Oracle DBAs add/ remove users to/from the local authentication database based on these reports • The Oracle DBAs also add/ remove users based on individual requests or requests during the ADC process (i.e., bypassing TSSMS) • Users logging into their database are authenticated against an Oracle database on the server • There are no automatic feedback loops to notify TSSMS when a user or account is removed from the authentication database or server Pg 13

15. How TSSMS Works - Databases • The Oracle DBAs receive nightly reports showing all users added to or removed from each TSSMS account • The Oracle DBAs add/ remove users to/ from the local authentication database based on these reports - • The Oracle DBAs “just know”, based on experience, which TSSMS account goes to which application • Users logging into their database are authenticated against an Oracle database on the server • There are no automatic feedback loops to notify TSSMS when a user or account is removed from the authentication database or server • Applications use TSSMS differently, i.e., RCRAInfo registers users to hardware code SVC while ICIS registers users to ORC. HPC takes the word of the user and does not require them to register to the HPC hardware code if they already have a TSSMS ID associated to another hardware code Pg 14

16. Funding Registration, Record Keeping Manage Request Call Center Billing Provisioning, De-provisioning, Administration Requests Updating Records Administer Requests Push-back Updates NCC Services Server Queries / Reports Charges Overview of Current Processes (All Platforms)

17. Manage Request Call Center Requests Administer Requests Push-back Updates Server Queries / Reports Charges Overview of Current Processes (All Platforms)

18. Request and Fulfillment Processes • Funding • Users must request new IDs and Accounts via their ADP Coordinator • Registration Record Keeping • The ADP Coordinator accesses the TSSMS system to add, delete, and modify accounts and users • A user must be associated with at least one TSSMS account in order to obtain and ID • Each TSSMS Account must have at least one registered user • Updates to TSSMS are batch processed nightly Pg 17

19. Request and Fulfillment Processes • Nightly Reports • Five reports uploaded nightly to the mainframe (a.k.a. Public Files) • NCC Services • UNIX administrators add and remove users/ accounts based on the printed reports • Mainframe (decentralized): RSA connects and disconnects users in RACF and claims ownership in the ownership database; ADP adds and deletes accounts, assigns account managers and RSAs • OAS administrators Oracle DBAs add and remove users from Oracle and applications that use TSSMS based on TSSMS reports and direct communication from users • Billing • eBusiness creates billing registrations for new accounts based on the public files • eBusiness creates “end dates” for deleted TSSMS accounts based on the public files • CSC submits monthly “workload” to eBusiness (UC: Registration ID, disk space) (U3: Registration ID, # Users) based on data aggregated from various sources in the WLC database Pg 18

20. WCF Costs and Billing Associated with TSSMS • Disk Space (WCF Code UC) • $7.26 per gigabyte per month • WCF Code UC is used to bill disk space on the following servers: U03, U02, U07, U11, U12, U13, U04, ORC, U15, U16 • Disk space allocation is read on the last day of the month • Disk space is billed based on allocation, not on actual usage • Servers that do not utilize UC billing, utilize UC-DED billing (due to a limitation in auto processing between TSSMS and eBusiness) • Association between applications and TSSMS accounts are stored in the WLC database • User Registration (WCF Code U3) • $15.03 per user per month • WCF Code U3 is used to bill for the number of users per month on the following servers: U03, U02, U07 • Number of users registered in TSSMS is read on the last day of the month Pg 19

21. IBM Oracle Unix Common Billing Processes

22. Issues with TSSMS as a Cross-Platform Registration System • One-size does not fit all • Not all requests for server access are received through TSSMS • Not all platforms use TSSMS Accounts in the same manner (OAS and ORC do not use TSSMS as a directory on the server, rather only use it for “billing purposes”) • Different systems use different identities (e.g., Domino LDAP, WAM ID, AD, TSSMS ID) • No feedback loops for expired User IDs and Accounts on some hosting environments • Does not work well for server-to-server communications since TSSMS accounts must have at least one TSSMS User ID associated with it or it will be deleted • HPC does not accurately register users to HPC hardware code, thus has issues with expiring User IDs Pg 21

23. Issues with the Process • Users must find their ADP in order to request an account or access to a server • Generally a verbal conversation or e-mail to ADP • Often takes a long time to get a request initiated • Users often don’t know which hardware codes on which servers to request access (and why they need access on multiple accounts or servers) • ADPs often register users incorrectly • Transferring ownership of an account is cumbersome • Undocumented business rules / practices incorporated into the current systems can cause restrictions that may no longer be valid Pg 22

24. Proposed Improvements • Self-service request for access and Web directory account creation • Single point of reference for requesting server access for ALL hosting platforms • Migrate identities to Web Access Manager (WAM) • Authenticate against the Oracle Identity Directory (as opposed to local authentication) • Better integrate ordering and billing of disk space and user access with eBusiness Pg 23

25. App Owner Call Center Manage Request Requests Users Approval Decision Manage Request Push-back Updates Administer Requests Server Queries / Reports Charges Improved Access Processes

26. Features of New System • Web-based Interface • Extranet access • Reporting interface • Use WAM ID to validate identity of requestor • Authorization and approval workflow • Relational database integrated with OID, eBusiness, and the ADC system • Service Repository Pg 25

27. Benefits • Reduce phone calls to support contractors to add or remove users • Eliminate the role of ADP Coordinator • eBusiness Account Managers would approve funding • “Account” or Application owner would create and manage access to accounts or servers • Users could self-request access • Reduce time to deploy databases or applications in the NCC • Real-time reporting and management of server access • No need to reset passwords on each server on which a user has an account (LDAP authentication with single password) Pg 26

28. Challenges to Modernization • Interdependency of User ID and Account • Complexity of billing processes for data storage (WCF Service UC – Disk Space) and user account registration (WCF Service U3) • Application dependencies on TSSMS ID (must migrate to WAM or other user registration system before TSSMS decommission) • 8-character UID limitation on UNIX systems • Multiple identity stores across hosting platforms • Where to Start: Chicken and Egg syndrome Pg 27

29. Modernization Milestones • Migrate to a relational database – Oracle • Develop Web Interface/ Evaluate third-party software • Change processes to authenticate log-in attempts against OID instead of local files or database on server • Remove shared Oracle database access and disk space billing from TSSMS • Develop interim guidance for NCC application hosting Points of Contacts (POC) to assist in obtaining TSSMS accounts and IDs until self-registration system is available Pg 27

30. Contact Rebecca Astin NCC Hosting and Operations Astin.rebecca@epa.gov 919-541-3074 Pg 29