A Division of Transaction Systems Architects, Inc. Insession Technologies Andrew Price SafeTGate Product Manager CTUG November 2003 SafeTGate Product Suite:

A Division of Transaction Systems

Architects, Inc.

Insession Technologies

Andrew PriceSafeTGate Product Manager

CTUG November 2003

SafeTGate Product Suite:A Comprehensive NonStop

Security SolutionTransport Security,

Web services security and Single Sign On


Architects, Inc.

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


Architects, Inc.

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”!


Architects, Inc.

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


Architects, Inc.

SafeTGate

• Authentication and Encryption– SafeTGate:SSL/SafeTGate:FTP

• Authentication, Authorisation and Resource Protection– SafeTGate:AF (Application Firewall)

• Single Sign On– SafeTGate SSO


Architects, Inc.

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

SSL Provides


Architects, Inc.

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!


Architects, Inc.

SafeTGate:SSL – Securing TCP/IP Apps

Server Software(e.g TOP Server)

SafeTGate:SSL

Receives clear data

SafeTGate:SSLHandles Server-side

Security

Client Software (e.g TOP)With SafeTGate:SSL

Client

Client establishes “Clear” Connection,

STG Client intercepts

SSL TCP/IP Session


Architects, Inc.

SafeTGate:SSL – Securing Websphere MQ

MQ V5.1Receiver

SafeTGate:SSL

Sender (Client) initiates secure

Channel

MQ V5.3Sender

UNIXNT orS/390

Receiver (Server)Receives clear

data

SafeTGate:SSLHandles Security for

Secure Channel

Secure MQ Channel


Architects, Inc.

SafeTGate:FTP – Securing File Transfers

TandemFTPSERV

SafeTGate:FTP

Receives clear data

SafeTGate:FTPEstablishes secure

connections

Client SoftwareWS-FTP, etc

FTP Client establishes secure

connection

FTP Data Session (Secure)

FTP Control Session (Secure)

Data Session (Clear)

Control Session (Clear)


Architects, Inc.

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)

Once “transport level” security is in place, need to consider “Do I need ‘granular’ security?”


Architects, Inc.

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.


Architects, Inc.

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


Architects, Inc.


• 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


Architects, Inc.


• 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


Architects, Inc.

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


Architects, Inc.

SafeTGate:AF – Protecting Web Pages

32

SafeTGate:AF

Credentials Database

HTTPS WebGate

WebFSFile

File protected?

1

HTTP “Get”/samples/

Confidential.html

4

HTTP Error 401 Returned, User Prompted for UserName, password


Architects, Inc.

SafeTGate:AF – Protecting Web Pages

WebFSFile

76

SafeTGate:AF


WebGate

5

HTTPS

HTTP “Get”/samples/

Confidential.html+ Username and

Password

UserAuthenticated/Authorised?

8

9

File returned to User


Architects, Inc.

43

SafeTGate:AF


HTTPS WebGate

1

SOAP Request (Web Service +

Operation) + Username and

Password

7

Result of Web service returned to User

WebGateSOAPTP

Web serviceProtected,

User authenticated/

authorized?

2

6

PathwayOr

Base245

SafeTGate:AF – Web Services Security


Architects, Inc.

5

HTTPS WebGate

1

SQL Query+ User name and

Password

9

Result of SQL QueryReturned to User

WebGateSQL Distributor

SQL TableProtected,

User authenticated/

authorized?

2

8

WebGate SQL WorkerProcesses

4

SafeTGate:AF

WebGate SQL WorkerProcesses

3

SafeTGate:AF – Protecting WebGate SQL


7

NonStop SQL Data

6


Architects, Inc.

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


Architects, Inc.

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


Architects, Inc.

SafeTGate:SSO


HTTP/XML/SOAP

User logs on towww.travel.com, makes a purchase, then indicates they wish to navigate to

www.carrental.com

www.travel.com

www.carrental.com

Token included in HTTP redirect

Encrypted token returned

SafeTGate:SSO – A Single Sign On Example Web site requests

token for user from SafeTGate:SSO


Architects, Inc.

SafeTGate:SSO


HTTP/XML/SOAP

www.travel.com

www.carrental.com

Token included in HTTP redirect

Web site requests SafeTGate:SSO to

validate token

Token authenticated,Local UserID

returned

User is considered logged on to

www.carrental.com

SafeTGate:SSO – A Single Sign On Example


Architects, Inc.

All determined by customer preference

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


Architects, Inc.

More information?

• Insession Website– www.insession.com/safetgate

– White papers, product briefs, etc

• Email– [email protected]


Architects, Inc.

Questions?


Architects, Inc.

Documents

A Division of Transaction Systems Architects, Inc. Insession Technologies Andrew Price SafeTGate Product Manager CTUG November 2003 SafeTGate Product Suite: