Insession Technologies Safe TGate Product Suite A Comprehensive

Insession Technologies Safe. TGate Product Suite: A Comprehensive Non. Stop Security Solution Transport Security, Web services security and Single Sign On Andrew Price Safe. TGate Product Manager CTUG November 2003 A Division of Transaction Systems Architects, Inc.

Agenda • Introduction – Web services inroads into Non. Stop base • Safe. TGate: SSL/Safe. TGate: FTP – The need for Encryption – Usage examples • Safe. TGate: AF – The need for Authentication and Authorization – Usage examples • Safe. TGate: SSO – Bringing it all together – Usage examples • Future Plans A Division of Transaction Systems Architects, Inc.

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

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

Safe. TGate • Authentication and Encryption – Safe. TGate: SSL/Safe. TGate: FTP • Authentication, Authorisation and Resource Protection – Safe. TGate: AF (Application Firewall) • Single Sign On – Safe. TGate SSO A Division of Transaction Systems Architects, Inc.

Safe. TGate: SSL Provides - 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 A Division of Transaction Systems Architects, Inc.

Safe. TGate: 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 Non. Stop sockets applications - - - Tested with Golden. Gate, IBM Web. Sphere MQ, Pathway i. TS Now includes FTP support - Supports SSL/TLS Draft Standard Available Q 4, 2003 A Division of Transaction Systems Architects, Inc. New!

Safe. TGate: SSL – Securing TCP/IP Apps Client establishes “Clear” Connection, STG Client intercepts SSL TCP/IP Session Safe. TGate: SSL Handles Server-side Security Safe. TGate: SSL Client Software (e. g TOP) With Safe. TGate: SSL Client Server Software (e. g TOP Server) Receives clear data A Division of Transaction Systems Architects, Inc.

Safe. TGate: SSL – Securing Websphere MQ Safe. TGate: SSL Handles Security for Secure Channel UNIX NT or S/390 Secure MQ Channel Safe. TGate: SSL MQ V 5. 3 Sender MQ V 5. 1 Receiver Sender (Client) initiates secure Channel A Division of Transaction Systems Architects, Inc. Receiver (Server) Receives clear data

Safe. TGate: FTP – Securing File Transfers FTP Client establishes secure connection Safe. TGate: FTP Establishes secure connections FTP Control Session (Secure) FTP Data Session (Secure) Client Software WS-FTP, etc Safe. TGate: FTP Data Session (Clear) Control Session (Clear) Tandem FTPSERV Receives clear data A Division of Transaction Systems Architects, Inc.

Safe. TGate: AF – The Challenge Once “transport level” security is in place, need to consider “Do I need ‘granular’ security? ” - 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 User. ID etc) A Division of Transaction Systems Architects, Inc.

Safe. TGate: AF • Authenticates – Against Guardian User. ID – Future releases via X. 509 Certificates and third party access control applications (e. g Baltimore Select. Access) • 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 User. ID, attempted action, attempted resource, outcome of authentication and authorisation decisions. A Division of Transaction Systems Architects, Inc.

Safe. TGate: AF Highlevel (1 of 3) • Allows applications to “delegate” their security to Safe. TGate • All requests for resource access are passed to Safe. TGate, via Safe. TGate API • Safe. TGate determines if the requested resource is “protected” • If so, indicates to the application the type of credentials (User. ID/password, X. 509 certificate etc) required to access that resource A Division of Transaction Systems Architects, Inc.

Safe. TGate: 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 Safe. TGate again requesting access to protected resource • Safe. TGate authenticates user based on credentials A Division of Transaction Systems Architects, Inc.

Safe. TGate: AF Highlevel (3 of 3) • Once authenticated, Safe. TGate 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” • Safe. TGate 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 A Division of Transaction Systems Architects, Inc.

Safe. TGate: AF – Securing Web. Gate Safe. TGate: AF Works today with: • Web. Gate – to secure all Web page access • Web. Gate: SOAPTP – to secure all Web services – Only Non. Stop Web service vendor to provide fully granular Web service security • Web. Gate: SQL – Secures all SQL table access – Can secure on SQL table, or even down to the individual column A Division of Transaction Systems Architects, Inc.

Safe. TGate: AF – Protecting Web Pages HTTP “Get” /samples/ Confidential. html 1 HTTPS Web. FS File Web. Gate File protec ted? 4 2 HTTP Error 401 Returned, User Prompted for User. Name, password 3 Safe. TGate: AF Credentials Database A Division of Transaction Systems Architects, Inc.

Safe. TGate: AF – Protecting Web Pages HTTP “Get” /samples/ Confidential. html + Username and Password 5 8 HTTPS Web. Gate 9 6 7 File returned to User Web. FS File User Authe nticate d/ Autho rised? Safe. TGate: AF Credentials Database A Division of Transaction Systems Architects, Inc.

Safe. TGate: AF – Web Services Security SOAP Request (Web Service + Operation) + Username and Password 1 HTTPS 7 2 Web. Gate SOAPTP Web. Gate 5 6 3 Web service Protected, User authenticat ed/ authorized Pathway ? Or Base 24 4 Result of Web service returned to User Safe. TGate: AF Credentials Database A Division of Transaction Systems Architects, Inc.

Safe. TGate: AF – Protecting Web. Gate SQL Table Protected, User authenticat ed/ authorized ? SQL Query + User name and Password 1 HTTPS 2 Web. Gate SQL Distributor Web. Gate 7 8 9 Web. Gate SQL Worker SQLProcesses Worker Processes 3 4 5 Result of SQL Query Returned to User 6 Safe. TGate: AF Credentials Database A Division of Transaction Systems Architects, Inc. Non. Stop SQL Data

Safe. TGate: 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 A Division of Transaction Systems Architects, Inc.

Safe. TGate: SSO • “Lightweight” Liberty Alliance implementation – www. project-liberty. org – Allows SSO involvement with minimal application enhancement • Allows Safe. TGate-secured applications to participate in Single Sign On (SSO) environments – Within the enterprise – Between enterprises • Non. Stop platform is ideal for SSO – SSO systems must be continuously available, otherwise access to “backend” systems disabled • First customer is major Canadian Non. Stop user A Division of Transaction Systems Architects, Inc.

Safe. TGate: SSO – A Single Sign On Example Web site requests token for user from Safe. TGate: 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 Safe. TGate: SSO HTTP/XML/SOAP www. carrental. com A Division of Transaction Systems Architects, Inc. Credentials Database

Safe. TGate: SSO – A Single Sign On Example www. travel. com Safe. TGate: SSO HTTP/XML/SOAP Token included in HTTP redirect Web site requests Safe. TGate: SSO to validate token User is considered logged on to www. carrental. com A Division of Transaction Systems Architects, Inc. Token authenticated, Local User. ID returned Credentials Database

Safe. TGate Future Plans • More “authenticators” – IP-based, Secur. ID 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 A Division of Transaction Systems Architects, Inc.

More information? • Insession Website – www. insession. com/safetgate – White papers, product briefs, etc • Email – pricea@insession. com A Division of Transaction Systems Architects, Inc.

Questions? A Division of Transaction Systems Architects, Inc.

A Division of Transaction Systems Architects, Inc.