Insession Technologies

1. SafeTGate Product Suite: A Comprehensive NonStop Security Solution Insession Technologies Andrew Price SafeTGate Product Manager CTUG November 2003 Transport Security, Web services security and Single Sign On

2. Agenda • Introduction • Web services inroads into NonStop base • SafeTGate:SSL/SafeTGate:FTP • The need for Encryption • Usage examples • SafeTGate:AF • The need for Authentication and Authorization • Usage examples • SafeTGate:SSO • Bringing it all together • Usage examples • Future Plans

3. Why Web services? • Simplify access to NonStop current business logic (legacy applications) • Preserve investment in NonStop server environment • Capitalize on the best platform for OLTP processing, in a modern way • Remove the “stigma” associated with NonStop server – proprietary, expensive to develop for, etc etc…. and transition to “open”!

4. Why not Web services? • Perception of Web services as immature • Key issue here is security • SafeTGate addresses this issue – more later • Perception that Web services may be difficult/complex to implement on NSK • “SOAP is supposed to be simple!” • Some NonStop Web services implementations are simply “ports” of “Open Source” projects • Not necessarily developed with NonStop fundamentals (fault tolerance, scalability) in mind • Generally require OSS – may create operational overhead • WebGate: SOAPTP based on the ICE kernel – code that has been proven in the most critical production environments

5. SafeTGate • Authentication and Encryption • SafeTGate:SSL/SafeTGate:FTP • Authentication, Authorisation and Resource Protection • SafeTGate:AF (Application Firewall) • Single Sign On • SafeTGate SSO

6. SSL Provides SafeTGate:SSL • Transport level encryption • Encrypted data is safe from “prying” eyes • “Simple” authentication • Optionally ensures that remote entity has a valid X.509 certificate • No authorization • In other words, I may know who the client is, but what resources is he/she authorized to access? Strongly recommended as a basis for other security

7. SafeTGate:SSL • Supports all standard SSL functionality, including client and server authentication, and a range of encryption algorithms • Provides proxy capability (or “Relay” process), meaning that existing sockets applications do not need to be modified • Works with all NonStop sockets applications • Tested with GoldenGate, IBM WebSphere MQ, Pathway iTS • Now includes FTP support • Supports SSL/TLS Draft Standard • Available Q4, 2003 New!

8. SafeTGate:SSL Client Software (e.g TOP) With SafeTGate:SSL Client Client establishes “Clear” Connection, STG Client intercepts SafeTGate:SSL – Securing TCP/IP Apps SafeTGate:SSL Handles Server-side Security SSL TCP/IP Session Server Software (e.g TOP Server) Receives clear data

9. SafeTGate:SSL SafeTGate:SSL Handles Security for Secure Channel SafeTGate:SSL – Securing Websphere MQ UNIX NT or S/390 Secure MQ Channel MQ V5.3 Sender MQ V5.1 Receiver Sender (Client) initiates secure Channel Receiver (Server) Receives clear data

10. SafeTGate:FTP Client Software WS-FTP, etc FTP Client establishes secure connection SafeTGate:FTP – Securing File Transfers SafeTGate:FTP Establishes secure connections FTP Control Session (Secure) FTP Data Session (Secure) Data Session (Clear) Control Session (Clear) Tandem FTPSERV Receives clear data

11. Once “transport level” security is in place, need to consider “Do I need ‘granular’ security?” SafeTGate:AF – The Challenge • The user now has the right to access my secure TCP/IP port(s), but how do I control what he/she does once they’re in? • Need the ability to examine incoming requests, and authorise accordingly, based on requested “resource” and attempted “action” • Analogous to a typical “Perimeter Firewall” - where a perimeter firewall examines each packet and determines authorisation based on “network level” information (IP address, port etc), the Application Firewall examines each request at an application level (transaction type, application UserID etc)

12. SafeTGate:AF • Authenticates • Against Guardian UserID • Future releases via X.509 Certificates and third party access control applications (e.g Baltimore SelectAccess) • Authorises • Determines if the user has the authority to perform the attempted action against the requested resource • Resources and actions totally configurable • Audits • All access requests audited • Information logged includes UserID, attempted action, attempted resource, outcome of authentication and authorisation decisions.

13. SafeTGate:AF Highlevel (1 of 3) • Allows applications to “delegate” their security to SafeTGate • All requests for resource access are passed to SafeTGate, via SafeTGate API • SafeTGate determines if the requested resource is “protected” • If so, indicates to the application the type of credentials (UserID/password, X.509 certificate etc) required to access that resource

14. SafeTGate:AF Highlevel (2 of 3) Application’s responsibility to obtain credentials Done in the way that makes most sense for the application – e.g prompting user via dialog box, consult configuration etc Note that Credentials may be included in the original request also, meaning that Step 1 is skipped Once credentials obtained, passed back to SafeTGate again requesting access to protected resource SafeTGate authenticates user based on credentials

15. SafeTGate:AF Highlevel (3 of 3) Once authenticated, SafeTGate authorizes the user (determines whether they have the access rights to perform the requested action against the protected resource) Based on two important Credentials Database entities The “RESOURCE”, e.g “/samples/confidential.html” The “ACTION”, e.g HTTP “GET” SafeTGate returns an indication of the success or failure of the operation to application If successful, a token is also returned, to be used for subsequent resource access requests

16. SafeTGate:AF – Securing WebGate SafeTGate:AF Works today with: WebGate to secure all Web page access WebGate:SOAPTP to secure all Web services Only NonStop Web service vendor to provide fully granular Web service security WebGate:SQL Secures all SQL table access Can secure on SQL table, or even down to the individual column

17. HTTP “Get” /samples/ Confidential.html 1 SafeTGate:AF WebGate 4 HTTP Error 401 Returned, User Prompted for UserName, password 2 3 SafeTGate:AF – Protecting Web Pages WebFS File HTTPS File protected? Credentials Database

18. HTTP “Get” /samples/ Confidential.html + Username and Password 5 8 HTTPS SafeTGate:AF WebGate 9 File returned to User 6 7 SafeTGate:AF – Protecting Web Pages WebFS File User Authenticated/ Authorised? Credentials Database

19. SafeTGate:AF – Web Services Security SOAP Request (Web Service + Operation) + Username and Password 1 2 Pathway Or Base24 5 6 SafeTGate:AF WebGate 7 Result of Web service returned to User 3 4 Web service Protected, User authenticated/ authorized? WebGate SOAPTP HTTPS Credentials Database

20. SafeTGate:AF – Protecting WebGate SQL SQL Query + User name and Password 1 2 3 SafeTGate:AF WebGate 7 8 9 Result of SQL Query Returned to User 4 6 5 NonStop SQL Data SQL Table Protected, User authenticated/ authorized? WebGate SQL Worker Processes WebGate SQL Worker Processes WebGate SQL Distributor HTTPS Credentials Database

21. SafeTGate:SSO – The Challenge • Now that a security infrastructure is in place, how to ensure that the secure systems are useable??? • Secure systems need to be able to “interact”, both within the enterprise, and between enterprises • Single Sign On is part of the solution • Ensures that once users are logged on to part of the SSO environment (or “Circle of Trust”), they needn’t log on again within that environment

22. SafeTGate:SSO • “Lightweight” Liberty Alliance implementation • www.project-liberty.org • Allows SSO involvement with minimal application enhancement • Allows SafeTGate-secured applications to participate in Single Sign On (SSO) environments • Within the enterprise • Between enterprises • NonStop platform is ideal for SSO • SSO systems must be continuously available, otherwise access to “backend” systems disabled • First customer is major Canadian NonStop user

23. SafeTGate:SSO – A Single Sign On Example Web site requests token for user from SafeTGate:SSO www.travel.com User logs on to www.travel.com, makes a purchase, then indicates they wish to navigate to www.carrental.com Encrypted token returned Token included in HTTP redirect SafeTGate:SSO HTTP/XML/SOAP Credentials Database www.carrental.com

24. SafeTGate:SSO – A Single Sign On Example www.travel.com SafeTGate:SSO HTTP/XML/SOAP Web site requests SafeTGate:SSO to validate token Credentials Database Token included in HTTP redirect User is considered logged on to www.carrental.com Token authenticated, Local UserID returned www.carrental.com

25. SafeTGate Future Plans More “authenticators” IP-based, SecurID Token, X.509 Certificates (locally, and via LDAP lookup) WS-Security Support for emerging Web services security standard Single Sign On Will move towards full support for the Liberty Alliance standard as required All determined by customer preference

26. More information? • Insession Website • www.insession.com/safetgate • White papers, product briefs, etc • Email • pricea@insession.com

27. Questions?

28. Thank You