Transcript Insession Powerpoint Icons

Insession Technologies
SafeTGate Product Suite:
A Comprehensive NonStop
Security Solution
Transport Security,
Web services security and
Single Sign On
Andrew Price
SafeTGate Product Manager
CTUG November 2003
A Division of Transaction Systems 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
A Division of Transaction Systems 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”!
A Division of Transaction Systems 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
A Division of Transaction Systems Architects, Inc.
SafeTGate
• Authentication and Encryption
– SafeTGate:SSL/SafeTGate:FTP
• Authentication, Authorisation and
Resource Protection
– SafeTGate:AF (Application Firewall)
• Single Sign On
– SafeTGate SSO
A Division of Transaction Systems Architects, Inc.
SafeTGate:SSL
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.
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
A Division of Transaction Systems Architects, Inc.
New!
SafeTGate:SSL – Securing TCP/IP Apps
Client establishes
“Clear” Connection,
STG Client intercepts
SafeTGate:SSL
Handles Server-side
Security
SafeTGate:SSL
SSL TCP/IP Session
Client Software (e.g TOP)
With SafeTGate:SSL
Client
Server Software
(e.g TOP Server)
Receives clear data
A Division of Transaction Systems Architects, Inc.
SafeTGate:SSL – Securing Websphere MQ
SafeTGate:SSL
Handles Security for
Secure Channel
UNIX
NT or
S/390
Secure MQ Channel
SafeTGate:SSL
MQ V5.3
Sender
MQ V5.1
Receiver
Sender (Client)
initiates secure
Channel
A Division of Transaction Systems Architects, Inc.
Receiver (Server)
Receives clear data
SafeTGate:FTP – Securing File Transfers
FTP Client establishes
secure connection
SafeTGate:FTP
Establishes secure
connections
FTP Control Session (Secure)
SafeTGate:FTP
FTP Data Session (Secure)
Client Software
WS-FTP, etc
Data
Session
(Clear)
Control
Session
(Clear)
Tandem
FTPSERV
Receives clear data
A Division of Transaction Systems Architects, Inc.
SafeTGate: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 UserID etc)
A Division of Transaction Systems 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.
A Division of Transaction Systems 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
A Division of Transaction Systems Architects, Inc.
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
A Division of Transaction Systems Architects, Inc.
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
A Division of Transaction Systems 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
A Division of Transaction Systems Architects, Inc.
SafeTGate:AF – Protecting Web Pages
HTTP “Get”
/samples/
Confidential.html
1
WebFS
File
HTTPS
WebGate
4
2
HTTP Error 401
Returned, User
Prompted for
UserName,
password
3
File
protected?
SafeTGate:AF
Credentials
Database
A Division of Transaction Systems Architects, Inc.
SafeTGate:AF – Protecting Web Pages
HTTP “Get”
/samples/
Confidential.html
+ Username and
Password
5
8
HTTPS
WebFS
File
WebGate
9
6
7
File returned to
User
User
Authenticated/
Authorised?
SafeTGate:AF
Credentials
Database
A Division of Transaction Systems Architects, Inc.
SafeTGate:AF – Web Services Security
SOAP Request
(Web Service +
Operation) +
Username and
Password
Web service
Protected,
User
authenticated/
authorized?
1
HTTPS
7
2
WebGate
SOAPTP
WebGate
5
Pathway
Or
Base24
6
3
4
Result of Web service
returned to User
SafeTGate:AF
Credentials
Database
A Division of Transaction Systems Architects, Inc.
SafeTGate:AF – Protecting WebGate SQL
SQL Table
Protected,
User
authenticated/
authorized?
SQL Query
+ User name and
Password
1
HTTPS
2
WebGate
SQL Distributor
WebGate
7
8
9
WebGate
WebGate
SQL Worker
SQLProcesses
Worker
Processes
3
4
5
Result of SQL Query
Returned to User
6
SafeTGate:AF
Credentials
Database
A Division of Transaction Systems Architects, Inc.
NonStop
SQL Data
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
A Division of Transaction Systems 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
A Division of Transaction Systems Architects, Inc.
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
www.carrental.com
A Division of Transaction Systems Architects, Inc.
Credentials
Database
SafeTGate:SSO – A Single Sign On Example
www.travel.com
SafeTGate:SSO
HTTP/XML/SOAP
Token included in
HTTP redirect
Web site requests
SafeTGate:SSO to
validate token
User is considered
logged on to
www.carrental.com
www.carrental.com
A Division of Transaction Systems Architects, Inc.
Token
authenticated,
Local UserID
returned
Credentials
Database
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
A Division of Transaction Systems Architects, Inc.
More information?
• Insession Website
– www.insession.com/safetgate
– White papers, product briefs, etc
• Email
– [email protected]
A Division of Transaction Systems Architects, Inc.
Questions?
A Division of Transaction Systems Architects, Inc.
A Division of Transaction Systems Architects, Inc.