Upload
ibm-ims
View
288
Download
4
Tags:
Embed Size (px)
Citation preview
®
IMS, SVL
© 2013 IBM Corporation
IMS Connect /OTMA updates
and IMS TCP/IP Security
Shyh-Mei F. Ho, IBM Distinguished Engineer
IMS SOA Chief Architect
2
IMS 13 Connect Updates
� Support for ISC over TCP/IP
� XML Converter Enhancements
– Query support for XML Converters
– Ability to increase the number of Converters that can be loaded
� Auto-restart of the Language Environment (LE)
� Expanded Recorder Trace Records
� Use of RACF Event Notification Facility (ENF) Support for cached RACF
UserIDs (UID)
� Reporting of overall health to Workload Manager (WLM)
� Configurable TCP/IP backlog (queue) size
33
InterSystem Communication (ISC) Over TCP/IP
� New option that supports TCP/IP network connectivity for Intersystem
Communication (ISC) connections
– IMS TM - CICS
– Supports both static and dynamic terminals
– Leverages IMS Connect
– Uses Structured Call Interface (SCI) to communicate between IMS and IMS Connect
– Requires CICS Transaction Server for z/OS 5.1
• Available December 14, 2012
Benefits
– Provides a strategic protocol alternative to SNA/VTAM
• Allows an all inclusive TCP/IP solution for networks
44 4
IMS Connect Enhancements for SOAP Gateway
� Enhancements specifically for IMS SOAP Gateway users
� Query support for XML Converters
� to see when the converters were last used and how many times they have
been used.
� Ability to increase the number of Converters that can be loaded
� the maximum number of converters is increased to 2000
� Automatic restart of the Language Environment when an XML converter ABENDs
� Automatic refresh of the BPE User Exit for the XML Adapters after the ABEND limit (ABLIM) has been reached
� Benefits
– Provide better resiliency
– Improved efficiencies during error conditions
• Eliminates IMS Connect restart and user interactions
5
IMS 13 OTMA Updates
� Early Termination Notification
– Enhancement to allow OTMA to leave XCF group earlier in termination process
� Reduced TCO Enhancements
– More efficient hashing technique for control blocks
• IMPACT to an environment depends on volume of activity
– Code changes for efficiency
� Enhancements to OTMA Destination Descriptors for asynchronous callout
– Support for WebSphere MQ
– Simpler override for Exit Routines
� ICAL Enhancements
– Enhanced ICAL support for Truncated Messages
– New AIB field – AIBUTKN
• Ability to send a name to a remote ICAL destination that can be used for message
formatting or service identification purposes
� Support for Synchronous Program Switch
– New ICAL destination
6
IMS Synchronous Callout: DL/I ICAL
CALL 'AIBTDLI' USING ICAL, AIB, REQ-AREA, RESP-AREA.
where:
• ICAL is new call verb (available on AIBTDLI only) and SENDRECV is the
new sub-function code
• REQ-AREA is the Request data area for sync callout
• RESP-AREA is the Response data area for returned dataNote: REQ-AREA and RESP-AREA do not specify LLZZ, data can be > 32K
� IMS V13: Enhance ICAL support for Truncated Messages:
– Allow subsequent ICAL to receive response message when partial data was returned because the specified response area was not large enough
CALL 'AIBTDLI' USING ICAL, AIB, RESP-AREA.
where:
• RECEIVE would be a new sub-function code
• RESP-AREA is the Response data area for returned data
7
OTMA Destination Routing Descriptor
D destname keywords
Where:
destname is destination names and can be masked by ending in an *
keywords are: TYPE=IMSCONTMEMBER=name
TPIPE-name
SMEM=YES|NO
ADAPTER=adapname
CONVERTR=convname
SYNTIMER=timeout (If both ICAL & Descriptor specify timeout, the lower value is used)
� IMS 10 OTMA Destination Routing Descriptors externalize the routing definitions and
specifications for callout messages without IMS user exits. It is read and initialized at IMS
startup.
� IMS 13 provides Synchronous Program Switch with TYPE = IMSTRAN
� IMS 13 provides Asynchronous Callout to WebSphere MQ via MQBridge with TYPE = MQSERIES
D destname keywords
Where:
destname is destination names and can be masked by ending in an *
keywords are: TYPE=IMSTRAN or MQSERIES
88
Synchronous Program Switch
� Extend IMS Synchronous Callout to allow DL/I ICAL to invoke another IMS Application– DL/I ISRT continues to be used for asynchronous program switch
� OTMA Descriptor enhanced to recognize an IMS transaction destination� Java programs can use the Java Message Service (JMS) API for synchronous program
switch
Benefits– Provides a single DL/I call to request a synchronous service regardless of where that
service resides– Simplifies integration and improves usability
ICAL DEST1
ICAL TRANB
TRANAIMS CTL Region
IMS
Connect
WebSphere
IMS TMRA
IMS SOAP
Gateway
TCP/IP
RYO appl
OTMA
MSG-Q
Destination
Descriptor
TYPE(IMSCON)
TRANB
GU IOPCB
ISRT IOPCB
Destination
Descriptor
TYPE(IMSTRAN)
1
23
4
56
7
GU, IOPCB
Applications can issue multiple ICALs to different
destination TYPEs
Synchronous callout (IMSCON)
Synchronous program switch (IMSTRAN)
WebSphere
DataPower
99
Asynchronous Callout to WebSphere MQ via MQ Bridge
� OTMA Descriptor enhancements
– New TYPE=MQSERIES to define WebSphere MQ destination
• Provides asynchronous callout and messaging support (DL/I ISRT ALTPCB)
– New option to allow exits to be called to override descriptor
• Applies to all destination descriptors
Benefits
– Eliminates need to write an OTMA user exit to recognize an MQ destination
– Simplifies integration and improves usability
IMS
ApplicationWebSphere
MQ
IMS
OTMA
1010
Increase Number of Concurrent Application Threads
� Increase the limit of concurrent application threads to 4095
� Limit applies to the total number of combined:
– Dependent Regions
– CICS/DBCTL threads
– Open Database Access (ODBA) threads
� Change to MAXPST parameter on IMS control region
– MAXPST increased from 999 to 4095
Benefits
– Increased capacity and scalability for IMS systems
– Allows vertical growth
– More dependent regions for use with synchronous callout and program switch
4 Times More Applications!
11
IMS TM Connectivity via IMS Connect
IMS SOAP
Gateway
IMS Connect
WebSphere Application Server
IMS TM
Resource
Adapter
IMS OTMA
EJB/MDB
Web Services
Consumer
IMS Application
User Written
Application
WebSphere
DataPower
12
IMS DB Connectivity via IMS Connect
IMS Connect
WebSphere Application Server
IMS
Universal
DB Resource
Adapter
EJB/MDB
User Written
Application
WebSphere
DataPower
IMS ODBM
NewIMS Universal Resource Adapter
IMSDB
13
IMS Synchronous Callout via IMS Connect
IMS SOAP
Gateway
IMS Connect
OTMA
Descriptor
WebSphere Application Server
IMS TM
Resource
Adapter
IMS
EJB/MDB
Web Services
Provider
IMS Application
Synch Callout (ICAL)
User Written
Application
WebSphere
DataPower
New
14
IMS TCP/IP Security Overview
� Multiple levels of security
– OTMA• Validates whether an OTMA member (IMS Connect) can communicate with IMS• Implements transaction and command security
– Userid that flows in on a message against the IMS resource• Supports callout to web services
– ODBM• Passes security information to IMS for database access
– IMS Connect• Supports the authentication of userids, groups, passwords and passes the utoken to IMS with the message• Additionally extends the security authentication
– PassTicket support– Trusted User support
– Network – connection security and encryption• SSL – TLS• AT-TLS
15
Security scenarios
� IMS as a provider
– Transactions
• Synchronous and asynchronous
– Commands
– Database
• Open DB support and the universal drivers
� IMS as a consumer
– Transactions
• Synchronous callout
• Asynchronous callout
– Including Business Event processing
16
IMS Security
� Continues to be based on userid access to the IMS resource
– Transaction, command, PSB, DB, etc..
� OTMA to IMS TM
– OTMA Client Bid security
• Determines whether an OTMA client, e.g., IMS Connect, or MQ, can
connect to IMS
– OTMA Message security
• OTMA setting to determine the level of checking for each message
� ODBM to IMS DB
– APSB security and/or IMS RAS (Resource Access Security) security
17
IMS Connect Security
� Accessing IMS transactions from a remote client
– Remote TCP/IP Client
• Provides Userid, Password, Groupid in message header
– IMS Connect authenticates the userid/password
• Configuration values for IMS Connect (HWSCFGxx)
– RACF = Y | N and RACFID = userid (default)
– Issues RACROUTE calls to authenticate user if RACF=Y
• Message exits can also call a user-written routine which are called before any
SAF/RACF calls:
– IMSLSECX –security exit routine for transactions and commands
– HWSAUTH0 – security exit routine for DB requests
• Default RACFID
– Useful if the inbound request does not carry a userid value and a value needs
to be passed into IMS for authorizing access to resource
» Does not provide an override for requests that carry a blank userid from
the IMS TM resource adapter (e.g., WAS environment)
18
SSL, TLS and AT-TLS
� Secure sockets layer (SSL and Transport Layer Security (TLS)
SSL provides security for your interactions by securing the TCP/IP connection between SOAP Gateway and IMS Connect.
� System SSLSystem SSL, a feature of the Cryptographic Services base element of z/OS, provides a complete SSL/TLS implementation and a full set of APIs that allow z/OS client and server applications to enable SSL/TLS protection for their TCP network traffic.
� Security support through z/OS Communications Server Application Transparent Transport Layer Security (AT-TLS)
– Participation in AT-TLS is transparent to IMS Connect• IMS Connect can therefore be invoked by a remote client using TLS and • Rely on the z/OS TCPIP stack to perform the handshaking protocol to negotiate as well as perform all the require authentications and encryption
– Supports multiple ports• SSL support in IMS Connect is limited to a single port for the IMS Connect instance
– No additional configuration specifications in IMS Connect
19
IMS SOAP Gateway Security
Access to TXN
IMS
IMS
Connect
ICAL
SAF/RACF secure environment
IMS security:
User validation
to access IMS
resources
IMS Soap
GatewayAccess to
IMS/OTMA
AT/TLS
GU,IOP Userid/PW
Authentication
Exit routines
RACF=Y|N OTMASE=
(OTMA)SSLHTTPS
(http over
SSL/TLS)
Transport level
Authentication:
�Client
�Server
�Basic (callout)
(Userid/PW/group:
�Per web-svc
(connection bundle)
�Per web-msg
(WS-security)
WS-security
Msg-level
Resume TPIPE
securityISRT,ALT
Connection
bundle:
Resume TPIPE
for synch calloutCan pass userid
outbound
Connection
bundle:
Resume TPIPE
for business
event processing
20
IMS SOAP Gateway Security Q
� SOAP Gateway supports HTTPS communication with its clients, and SSL
communications with its host, IMS™ Connect.
� You can configure SOAP Gateway with standards that are specified by the
US Department of Commerce National Institute of Standards and
Technology (NIST) to define security requirements for encryption.
– Federal Information Processing Standards (FIPS) 140-2 requires that the Transport Layer Security (TLS) protocol and the cryptographic modules are certified.
– SP800-131a requires stronger cryptographic algorithms and key lengths that are used in FIPS 140-2 cryptographic modules.
21
IMS SOAP Gateway Security Notes
� Server authentication is the provision of server authentication information (digital certificate), from the server to the client, that binds the server identify to subsequent communications.
� Client authentication is the provision of authentication information from the client to the server. – Client authentication is also referred to as mutual authentication, because server authentication is required in order to support client authentication.
� Consumer scenarios only: Basic authentication where the server that hosts the web service requires SOAP Gateway, the client (i.e. IMS), to have appropriate basic authentication credentials in order to call a service.
� SOAP Gateway supports authentication of users on a per-web service or per-message basis. – When the user ID and password information is provided by the connection bundle, the authentication is performed on a per-web service basis. All requests use the same user ID to access IMS. Security certificates can be sent at the transport level for server authentication and client authentication.
– When users are authenticated on a per-message basis, user ID and password information is enclosed as tokens in the WS-Security header in each message. Requests might come from different user IDs. This feature is known as web service security or WS-Security.
22
IMS SOAP Gateway Security Notes Q
WS-Security (Web Services Security or WSS) is a published SOAP extension standard (XML-
based) that allows security (authentication and authorization) information to be exchanged in
support of web services. Its goal is to protect the integrity and confidentiality of a message as
well as the ability to authenticate the sender. The protocol specifies how to enforce integrity and
confidentiality on messages and supports a variety security token formats, e.g., UNTP, SAML,
x.509 certificates, kerberos tickets, etc Of the various security token formats supported, IMS
Soap Gateway allows UNTP and SAML.
Use of WS-Security supports a custom authentication module (CAM) that can perform additional checking by using a Java Authentication and Authorization Service (JAAS)
module.
Therefore, when WS-Security is enabled, you can provide your own custom authentication module to perform additional checking by using a JAAS module.
23
Summary IMS SOAP Gateway Security Support
� Provider– Key type
• Java keystore (JKS) • System Authorization Facility (SAF)
– SAF is for the z/OS® platform only. Use of SAF requires the AT-TLS feature in IBM® z/OS Communications Server
– Authentication type• Server authentication • Client authentication
– WS Security
• UsernameToken Profile 1.0 tokens (UNTP)– Use of server or client authentication is recommended.
» Without server or client authentication, user name and password are transmitted in clear text.
– Custom authentication module (CAM) for WS-Security » Server authentication or client authentication is required.
• SAML 1.1 unsigned & signed tokens– Custom authentication module (CAM) for WS-Security
» Client authentication is required.
• SAML 2.0 unsigned & signed tokens– Custom authentication module (CAM) for WS-Security
» Client authentication is required.
24
Summary IMS SOAP Gateway Security Support "
� Consumer
– Key type
• Java keystore (JKS)
– Authentication type
• Basic authentication • Server authentication • Client authentication
– WS Security for Synchronous Callout
• SAML 1.1 unsigned tokens– Custom authentication module (CAM) for WS-Security
» Client authentication is required. • SAML 2.0 unsigned tokens
– Custom authentication module (CAM) for WS-Security » Client authentication is required.
25
IMS TM Resource Adapter (IMS TMRA)
Access to TXN
Access to DB
IMSODBMIMS
Connect
Access to
PSB
Client-Bid
ICAL
SAF/RACF secure environment
IMS security:
User validation
to access IMS
resources
IMS TMRA
JEE
e.g., WAS
Access to
IMS/OTMA
AT/TLS
(Userid/PW/group):
EIS signon can be
�Container-managed
�Component-managed
GU,IOP
Can pass userid
outbound
- Userid/PW
Authentication
- PassTicket
-Trusted user
- Default User
Exit routines
RACF=Y|NOTMASE=
Message retrieval
Security (userid)
Resume TPIPE
Resume TPIPE
security
(OTMA)
SSL
Msg-level
IMS
universal
drivers
Userid/PW
JCA
Security
architecture
Transport level
Authentication
WS-security
...
ISRT,ALT
Authentication
and access to
Application,
EJB, service
...
26
JEE Environment & WAS
� A java platform based on a standard architecture for developing and running mainframe-scale software, including network and web services, and other large-scale, multi-tiered, scalable, reliable, and secure network applications– IBM WebSphere Application Server (WAS) implements this framework
• Supports transport-level (connection) security – HTTPS, SSL, etc.
» Client, Server, and Basic authentication • Hosts applications – EJBs, MDBs, servlets, JSPs,...• Provides the ability to authenticate credentials and ensure access to hosted components are authorized
• Provides secure connections from WAS applications to EIS systems, e.g., IMS– Secure connections using SSL, AT/TLS– Propagation of secure credentials to the EIS for each message
» IMS TM Resource Adapter can be deployed in WAS
� The JCA security architecture extends the end-to-end security model for JEE-based applications to include integration with EISs (e.g., IMS)
Note: a more comprehensive environment than the IMS Soap Gateway
27
WAS – IMS TM Resource Adapter
� IMS TM resource adapter (TM RA)
– Follows the Java EE Connector Architecture (JCA) security architecture, and works with the WebSphere Application Server (WAS) security manager
� Connectivity between IMS TMRA and IMS Connect
– Transport Level: recommendation is to use AT/TLS with IMS Connect
– Message Level: Supports passing the userid/password/groupid authentication credentials that are supported by IMS Connect
• Supplied either by
– The WAS application component (component-managed signon)
– Or by the application server (container-managed signon).
28
WAS – IMS TM RA
� IMS as a provider scenario
� Container-managed signon:
– Relies on the security manager in the application server to provide and manage the security information
• Uses the directive <res-auth>Container</res-auth> specified in the deployment
descriptor of the application to provide the userid, password, groupid
� Component-managed signon:
– Relies on the application (the component) in WAS to provide and manage the security information to be used for signing on to IMS Connect
• Uses the <res-auth> element in the resource reference of the deployment descriptor
of the application
• Provides the security information (user ID, password, and optional group name) in
IMSConnectionSpec object and passes it to IMS TMRA
– IMS TMRA passes this security information to IMS Connect for use in signing
on (authentication and authorization)
29
WAS - IMS TMRA Q
� IMS as a consumer scenario
– IMS callout requests (synchronous ICAL or asynchronous) are retrieved from IMS Connect by using the Resume TPIPE call• Resume TPIPE security ensures that the userid associated with the Resume TPIPE is authorized against the TPIPE • If security is enabled and the tpipe does not exist at the time the RESUME TPIPE call is issued, the call is rejected.
– For message-driven beans (MDBs)• SSL authentication is supported for communication with IMS• Security information is specified in the J2C activation specification (IMSActivationSpec) that is configured in WAS
– For non-MDB applications• Userid must be specified in the connection specification of the WAS application or the connection factory that is used by the application
30
Open DB Security
Access to TXN
Access to DB
IMSODBMIMS
Connect
Access to
PSB
Client-Bid
ICAL
SAF/RACF secure environment
IMS security:
User validation
to access IMS
resources
IMS TMRA
JEE
e.g., WAS
Access to
IMS/OTMA
AT/TLS
(Userid/PW/group):
EIS signon can be
�Container-managed
�Component-managed
GU,IOP
Can pass userid
outbound
- Userid/PW
Authentication
- PassTicket
-Trusted user
- Default User
Exit routines
RACF=Y|NOTMASE=
Message retrieval
Security (userid)
Resume TPIPE
Resume TPIPE
security
(OTMA)
SSL
Msg-level
IMS
universal
drivers
Userid/PW
JCA
Security
architecture
Transport level
Authentication
WS-security
...
ISRT,ALT
Authentication
and access to
Application,
EJB, service
...
31
Open Database Security
� IMS Connect can use the IMS Connect DB Security user exit routine
(HWSAUTH0), a security product such as RACF, or both to authenticate
a user.
� IMS does the authorization
� APSB security. A security check is performed to determine if the user is authorized to use the PSB. IMS checks the authority of a user to allocate a PSB by using APSB
� APSB security is enabled by specifying the ODBASE parameter.
� Or, Resource access security (RAS). A security check is performed by RACF to determine if the user is authorized to use the PSB. RACFdetermines authorization by looking at the RACF security class profile defined for the dependent region. IMS checks the authority of a user to access IMS resources by using RAS
� RAS security is specified by the ISIS parameter.
� ODBM does not perform any user authentication or authorization.
ODBM assumes the end client Userid associated with an allocate PSB
request has been authenticated, or userid associated with the ODBM
address space
®
IMS, SVL
© 2013 IBM Corporation
IMS Connectivity and Security
Consideration
33
System z
z/OS
IBM
Directory
Server
LDAPRACF
WebSphereApplication Server
DB 2
CICS
MQ
IMS
Propagation of identity for Improved auditability
Today’s distributed model:
End-user signs on to a distributed application, e.g. WAS, with distributed User ID
• Distributed applications often use a common RACF user-ID when invoking IMS, CICS, DB2
to process the request.
• This distributed User ID not passed to IMS, etc. and on to RACF, making end-user
accountability difficult to determine.
•Do you have a requirement of propagating original Network Identity?33
34
IMS Synchronous Callout Security
� IMS synchronous callout using enhanced IMS Resume TPIPE and Send Only protocols to retrieve synchronous callout requests and send responses
� Resume TPIPE authorization– Supports both the asynchronous callout and synchronous (ICAL) callout
– Authorization is performed by IMS OTMA when the message is retrieved from the hold queue
– RACF• Authorization is performed for each Resume TPIPE request.
– OTMA Resume TPIPE Security exit (DFSYRTUX)• Authorization is performed for each Resume TPIPE request.• Can accept RACF results, override RACF results, or enforce more restrictive rules.
External
Application
Server
IMS
Connect
IMS
Applications
35
Security Consideration for IMS Callout
� Propagating security information from IMS Synch Callout
– IMS user ID is included in the correlator token of the ICAL. However, it may not flow to the external applications or servers. And there is no password associated with the ICAL.
� Is there a requirement for passing security credentials with the Callout
request to the external server?
– What should be used for the identity passed ?
• User id & password ?
• a digital certificate ?
• SAML token ?
• Original network identity invoked the IMS application which in turn goes
outbound to external server?
– Which format(s) of credential would be required ?
– Would credentials be used just for authorization or authentication as well ?
36
IMS Synchronous Callout Security
� Propagating security information from IMS
– IMS application user ID (PSTUSID) is included in the correlator token (CORTKN) of the ICAL. However, it may not flow to the external application servers
• When IMS calls out to WAS, EJB can retrieve the user ID via the getter method, but the correlator token is not exposed to MDB, thus MDB does not have a way to retrieve the user ID
• Requirements: IMS TMRA needs to support JCA 1.6 to propagate security/transaction context inflow to WAS from IMS via ICAL
• Generic Work Context: A generic mechanism for Resource Adapter to propagate useful contextual information from EIS to end point during message delivery
• Security Inflow enables an end-to-end security model for Java EE application and EIS integration; provides a protocol to allow MDB to pickup security inflow
• IMS SOAP Gateway extracts the user ID and constructs a security token, e.g. SMAL token, to pass to external server via SOAP header
• DataPower FSH passes the correlator token in the header to DataPower to allow user ID to be extracted and constructed.
� Requirements: Propagate original network identity
37
Securing IMS Callout Request Flow (Current solution)
IMS
IMS application
:
ICAL
(synchronous)
IMS
Connect
DataPower
MPG policy configuration
Services / Application
Services / Application
Request
with security
token
Request
with
correlation
token
Response
with
correlation
token
SOAP Gateway
Extract ID
from correlation
token
Generate security
token,
LTPA, SAML,
pass ticket, etc.
IMS Callout FSH
Extract correlation
token
Response
WS policy configuration
Extract ID
from correlation
token
Generate SAML
token
Custom module
Additional
Security
(optional)
OTMA
Request
with SAML
token
Response
Credential: User IDCredential: security token
Corr
token
Generates
correlation
Token
(incl user ID)
Authenticated user
37
38
Think BIG with IMS Transactional Messages
� IMS Transactions with Large Messages and Large Attachments
– Do you foresee a need to drive IMS transactions with large messages?
– Do you foresee a need to invoke external application server with large IMS transactional messages?
– Do you foresee a need to drive IMS transactions with large attachments for both structured and non-structured data, e.g. XML documents, medical records (X-Ray or MRI images), and picture files, etc.?
– Do you have the need to propagate original network identity?
– Do you have the need to propagate original network identity when going outbound from IMS to external application server?
39
IMS Transactions and Large Attachments: Requirements
IMS
Connect
O
T
M
A
IMS
ApplicationWebSphere (e.g. WAS,
DataPower),IMS SOAP Gateway,RYO Application,
Etc.
Network Identity
Or
Images,
Picture files, etc.
z/OS
TCP/IP XCF
®
IMS, SVL
© 2013 IBM Corporation
Thank You