Server Side Security
On the server side transport security is enabled by simply switching a non-secure socket implementation with the GSISocket implementation. In addition to this change some code was added to propagate authentication information and message protection settings to the relevant security handlers, in particular the authorization and security policy handlers.
On the client side transport security is similarly enabled by switching a non-secure socket implementation with the GSISocket implementation and registering a protocol handler for HTTPS that uses the secure socket implementation. In practice this means that any messages targeted at a HTTPS endpoint will, irregardless of any stub properties, be authenticated and protected. It also means that any messages sent to a HTTP endpoint will not be secured, again irregardless of any stub properties. Stub properties are only used to communicate the desired message protection level, i.e. either integrity only or integrity and privacy.
This section aims to describe the message flow and processing that occurs for a security-enabled service. The figure below shows the JAX-RPC handlers that are involved in security related message processing on a server.
GT4 provides two mechanisms, GSI Secure Conversation and GSI Secure Message security, for authentication and secure communication.
In the GSI Secure Conversation approach the client establishes a context with the server before sending any data. This context serves to authenticate the client identity to the server and to establish a shared secret using a collocated GSI Secure Conversation Service. Once the context establishment is complete the client can securely invoke an operation on the service by signing or encrypting outgoing messages using the shared secret captured in the context.
The GSI Secure Message approach differs in that no context is established before invoking an operation. The client simply uses existing keying material, such as an X509 to secure messages and authenticate itself to the service.
Securing of messages in the GSI Secure Conversation approach, i.e. using a shared secret, requires less computational effort than using existing keying material in the GSI Secure Message approach. This allows the client to trade off the extra step of establishing a context to enable more computationally efficient messages protection once that context has been established.
When a message arrives from the client the SOAP engine invokes several security related handlers.
The first of these handlers, the WS-Security handler, searches the message for any WS-Security headers. From these headers it extracts any keying material, which can be either in the form of an X509 certificate and associated certificate chain or a reference to a previously established secure conversation session. It also checks any signatures and/or decrypts elements in the SOAP body. The handler then populates a peer JAAS subject object with principals and any associated keying material whose veracity was ascertained during the signature checking or decryption step.
The next handler that gets invoked, the security policy handler, checks that incoming messages fulfill any security requirements the service may have. These requirements are specified, on a per-operation basis, as part of a security descriptor during service deployment. The security policy handler will also identify the correct JAAS subject to associate with the current thread of execution. Generally this means choosing between the peer subject populated by the WS-Security handler, the subject associated with the hosting environment and the subject associated with the service itself. The actual association is done by the pivot handler, a non-security handler not shown in the figure that handles the details of delivering the message to the service.
The security policy handler is followed by an authorization handler. This handler verifies that the principal established by the WS-Security handler is authorized to invoke the service. The type of authorization that is performed is specified as part of a deployment descriptor.
Once the message has passed the authorization handler it is finally handed off to the actual service for processing (discounting any non security related handlers, which are outside the scope of this document). Replies from the service back to the client are processed by two outbound handlers: the GSI Secure Conversation message handler and the GSI Secure Message handler. The GSI Secure Conversation message handler deals with encrypting and signing messages using a previously established security context, whereas the GSI Secure Message handler deals with messages by signing or encrypting the messages using X509 certificates. The operations that are actually performed depend on the message properties associated with the message by the inbound handlers, i.e. outbound messages will have the same security attributes as inbound messages. That being said, a service has the option of modifying the message properties if so desired. These handlers are identical to the client side handlers described in the following section.
This section describes the security related message processing for Java-based GT4 clients. In contrast to the server side, where security is specified via deployment descriptors, client side security configuration is handled by the application. This means that a client side application has to explicitly pass information to the client side handlers on what type of security to use. This is also true for the case of services acting as clients. The below figure shows the JAX-RPC handlers that are involved in security related message processing on a server.
The client side application can specify the use of either the GSI Secure Conversation security approach or the GSI Secure Message security approach. It does this by setting a per message property that is processed by the client side security handlers.
There are three outbound client side security handlers:
The secure conversation service handler is only operational if GSI Secure Conversation mode is in use. It establishes a security session with a secure conversation service collocated with the service with which the client aims to communicate. When the client sends the initial message to the service with a property indicating that session based security is required, this handler intercepts the message and establishes a security session. It will also authorize the service by comparing the service's principal/subject obtained during session establishment with a value provided by the client application. Once the session has been established the handler passes on the original message for further processing.
The next handler in the chain, the secure message handler, is only operational if GSI Secure Message mode is in use. It signs and/or encrypts messages using X.509 credentials.
The third outbound handler is operational only if GSI Secure Conversation mode is in use. It handles signing and/or encryption of messages using a security session established by the first handler.
The client side inbound handler (the WS-Security client handler) deals with verifying and decrypting any signed and/or encrypted incoming messages. In the case of GSI Secure Message operation it will also authorize the remote side in a similar fashion to the outbound secure conversation service handler.
1 comment:
Thankful for sharing, for instance, important data, Its assistance me to fathom about computerized security. All things considered, it fuses composes on a very basic level equivalent to best managed cybersecurity services. Its moreover give you extraordinary information about Cybersecurity, distributed storage, cloud game plans.
Post a Comment