为 CICS Web Service 提供程序设计安全性

CICS® 网络服务提供商可能会遇到两种主要情况：直接向 CICS 网络服务提供商发出请求，或通过使用第三方身份验证服务器的中间服务器发出请求。要保护这些场景中的每个场景，请考虑对安全性的不同方面的影响，并决定哪些选项最适合您。示例说明了一些建议的选项。

有关 Web Service 请求者应用程序的同等注意事项，请参阅为 CICS Web Service 请求者设计安全性。

CICS Web Service 提供程序的方案

在图 1中， Web Service 请求者将请求直接发送到 CICS Web Service 提供程序应用程序。

在图 2中， Web Service 请求者调用中间服务器，该中间服务器向第三方认证服务器认证请求，然后将客户机的身份传递给 CICS Web Service 提供程序。

为 CICS Web Service 提供程序方案设计安全性时，请考虑以下方面的含义:

本文件进一步探讨了这些考虑因素。

谁对 Web Service 请求者进行认证? 是 CICS 服务器还是中间服务器?

CICS 可以直接认证 Web Service 请求者，或者中间人可以向 CICS提供认证服务。在这种情况下，中间服务器会认证客户机，然后通过可信连接将客户机的身份传递给 CICS 。客户机的身份可以作为声明的用户标识或分布式身份传递到 CICS 。

您将使用基于传输的认证还是基于 SOAP 消息的认证?

对于不涉及中间服务器的点到点请求，建议使用传输安全性。如果您使用基于传输的认证，则可以配置 HTTP 基本认证或TLS客户端认证。

仅HTTPS 使用基本认证，因为凭据以明文形式发送，容易受到数据包嗅探的攻击。 TLS 客户机认证比基本认证更安全，因为已签署客户机证书。

当安全凭证需要在 SOAP 消息中流经多个中介时，请使用基于 SOAP 消息的认证 (WS-Security)。如果使用基于 SOAP 消息的安全性，那么可以配置 CICS 安全处理程序以使用下列其中一种类型的令牌进行认证:

从 CICS TS 6.3 开始，已移除对 WS-Security 功能的 X.509 6.3 身份验证的支持。

如果使用其他令牌类型，那么可以配置 CICS 安全处理程序以调用安全性令牌服务 (STS) ，也可以编写定制安全性处理程序以执行您自己的定制安全性处理。

建议: 使用 TLS 来保护与 STS 的连接。

有关可用于 CICS Web Service 的认证令牌类型的更多信息，请参阅 How it works: Authentication for CICS with SOAP message security 。

在第三方认证方案中， SOAP 消息认证通常与基于传输的认证一起使用。客户机的身份在 SOAP 安全性头中流动，中间服务器通过使用 TLS 客户机认证进行认证。

您是否需要针对不同服务或不同类型的客户机实施不同的认证机制?

可以针对特定服务确定认证机制的类型，而不是具有应用程序的一般规则。可能适合使用通用用户标识运行只读服务，其中更敏感的服务可能需要请求者进行认证。在 CICS中，可以通过在与非安全服务不同的管道上运行安全服务来进行此拆分。

您是否会将网络服务提供商中的 CICS 任务配置为以最终用户的 RACF® 用户 ID 运行？

以此方式配置 CICS 任务将启用细颗粒度授权和审计。

如果不使用任何中介，那么 CICS 授权处理可以基于用于认证的 RACF 用户标识或与用于认证的安全性令牌相关联的 RACF 用户标识。
在使用中介的情况下， CICS 授权处理可以基于断言的 RACF 用户标识或中介传递的分布式身份。 CICS 可以将 ICRX 身份令牌中包含的分布式身份解析为 RACF 用户标识。

使用代理安全性来确保中介具有代表已声明身份启动工作的正确权限。

要将对 CICS 资源的访问权限制为特定技术用户标识吗?

您可以在 URIMAP 中为管道别名事务指定 RACF 用户标识，而不是将 Web Service 提供程序中的 CICS 任务配置为使用最终用户的 RACF 用户标识运行。

如果不需要保护 Web Service ，那么可以允许请求在 CICS 缺省用户标识下运行。

6.16.2

TLS ， XML 签名和 XML 加密，还是非加密?: 通过使用 CICS 或 AT-TLS 中的 TLS 支持， TLS 可用于实现点到点连接的完整性和机密性。但是， TLS 不会确保端到端消息完整性或加密，因为消息在中间服务器中不受保护，如图 2中所示。; XML 签名和 XML 加密可用于确保端到端的完整性和机密性，包括在中间服务器中。但是，由于 CICS 中 XML 签名处理和 XML 加密的性能开销很大，因此很少使用此功能。作为替代方法，这些功能通常在中间服务器 (例如 IBM® DataPower® Gateway) 中实现。
建议: 如果需要 XML 签名处理或 XML 加密，请考虑在中间服务器 (例如 IBM DataPower Gateway) 中实现这些功能，而不是直接在 CICS中实现。; 如果SOAP消息不包含关键数据，或者仅在内部安全网络中传输，那么通过非加密的 HTTP传输请求是合理的。

从 CICS TS 6.3 开始，已移除对 WS-Security 功能签名和 6.3 SOAP 消息的支持。您仍然可以使用传输层安全（TLS）来保护 SOAP 消息的安全。因此， XML Toolkit for z/OS® 已不再需要。

如何确保中间服务器是可信服务器?: 可以使用 TLS 客户机认证，以便中间服务器提供由 CICS验证的客户机证书。成功的客户机认证要求签署客户机证书的认证中心 (CA) 被 CICS视为可信。要被视为可信， CA 的证书必须位于 CICS 密钥环中。

如何确保认证令牌可信?: 可以对认证令牌 (例如 SAML 令牌) 进行签名。该签名用于验证 SAML 令牌的签发者并确保令牌的完整性。
从 CICS TS 6.3 开始，已移除对使用 CICS 安全令牌服务 6.3 SAML 的支持。

是否需要在 CICS中审计 Web Service 请求?: 通常，您需要捕获用于运行 CICS 任务的 RACF 用户标识。此信息记录在类型 110 子类型 01 记录的 CICS SMF 中。使用身份传播时，还会记录来自 ICRX 的分布式身份。
您将在 CICS 和/或中间服务器中创建审计跟踪吗?: 您可能需要处理请求所涉及的所有服务器中的审计跟踪。 IBM DataPower Gateway 是捕获审计信息的理想场所，因为它提供了可配置的解决方案，支持可以存储在设备上或传输到设备外的多种格式日志记录。

查看这些提供不同配置的设计示例。