|
|
Security Compatibility
For an application running BEA Tuxedo Release 7.1 or later software, it is possible to have any combination of default or custom authentication, authorization, auditing, and public key security. In addition, any combination of these four security capabilities is compatible with link-level encryption.
Mixing Default/Custom Authentication and Authorization
It is possible to have default authentication and custom authorization, or custom authentication and default authorization, as long as the application developer is aware of the following restriction: the authorization security token must carry at a minimum (1) an authenticated user name, or principal name, and (2) an application key value as defined in Application Key.
Authorization decisions are based partly on user identity, which is stored in an authorization token. Because authorization tokens are generated by the authentication security plug-in, providers of authentication and authorization plug-ins need to ensure that these plug-ins work together. (See Authentication and Authorization for more detail.)
Mixing Default/Custom Authentication and Auditing
It is possible to have default authentication and custom auditing, or custom authentication and default auditing, as long as the application developer is aware of the following restriction: the auditing security token must carry at a minimum (1) an authenticated user name, or principal name, and (2) an application key value as defined in Application Key.
Auditing decisions are based partly on user identity, which is stored in an auditing token. Because auditing tokens are generated by the authentication security plug-in, providers of authentication and auditing plug-ins need to ensure that these plug-ins work together. (See Authentication and Auditing for more detail.)
Compatibility Issues for Public Key Security
Public key security is compatible with all features and processes supported by BEA Tuxedo Release 7.1 or later software except the compression feature. Encrypted message buffers cannot be compressed using the compression feature. But, because the public key software compresses the message content just before it encrypts the message buffer, any size savings are still achieved.
This topic describes the compatibility/interaction of public key security with the following BEA Tuxedo features and processes:
Compatibility/Interaction with Data-dependent Routing
Central to the data-dependent routing feature is the ability of a process to examine the content of incoming message buffers. If an incoming message buffer is encrypted, a process configured for data-dependent routing must have opened a recipient's private key so that the public key software can use that key to decrypt the message buffer. For data-dependent routing, the public key software does not verify digital signatures.
If a decryption key is not available, the routing operation fails. The system generates an ERROR userlog(3c) message to report the failure.
If a decryption key is available, the process makes a routing decision based on a decrypted copy of the encrypted message buffer. The chain of events is as follows:
The system then transmits the original encrypted message buffer in accordance with the routing decision.
Compatibility/Interaction with Threads
Public-private keys are represented and manipulated via handles. A handle has data associated with it that is used by the public key application programming interface (API) to locate or access the item named by the handle. A process opens a key handle for digital signature generation, message encryption, or message decryption.
A key handle is a process resource; it is not bound to any specific thread or context. Any BEA Tuxedo communication necessary to open a key is performed within the thread's currently active context. Thereafter, the key is available to any context in the process, whether or not the context is associated with the same BEA Tuxedo application.
A key's internal data structures are thread safe. As such, a key may be accessed concurrently by multiple threads.
Compatibility/Interaction with the EventBroker
In general, a TMUSREVT(5) system server handles encrypted message buffers without decrypting them, that is, both digital signatures and encryption envelopes remain intact as messages flow through the BEA Tuxedo EventBroker component. However, the following cases require that the EventBroker component decrypt posted message buffers:
If the EventBroker does not have access to a suitable decryption key, the subscription's filter expression is assumed to be false, and the subscription is not considered a match.
If the EventBroker does not have access to a suitable decryption key, the subscription's notification action fails, and the system generates an ERROR userlog(3c) message to report the failure.
If the EventBroker does not have access to a suitable decryption key, the subscription's notification action fails, and the system generates an ERROR userlog() message to report the failure.
For a transactional subscription, the system also marks the transaction as rollback-only.
If the EventBroker does not have access to a suitable decryption key, the tppost(3c) operation fails, and the system generates an ERROR userlog() message to report the failure.
If the EventBroker does not have access to a suitable decryption key, the tppost(3c) operation fails, and the system generates an ERROR userlog() message to report the failure.
Compatibility/Interaction with /Q
In general, a TMQUEUE(5) or TMQFORWARD(5) system server handles encrypted message buffers without decrypting them, that is, both signatures and encryption envelopes remain intact as messages flow through the BEA Tuxedo /Q component. However, the following cases require that the /Q component decrypt enqueued message buffers:
If TMQFORWARD does not have access to a suitable decryption key, the forward operation fails. The system returns the message to the queue and generates an ERROR userlog(3c) message to report the failure.
After a number of periodic retry attempts, TMQFORWARD might place the unreadable message on an error queue.
If the /Q component does not have access to a suitable decryption key, the tpenqueue(3c) operation fails, and the system generates an ERROR userlog() message to report the failure.
If the /Q component does not have access to a suitable decryption key, the tpenqueue(3c) operation fails, and the system generates an ERROR userlog() message to report the failure.
A non-transactional tpdequeue(3c) operation has the side effect of destroying an encrypted queued message if the invoking process does not hold a valid decryption key.
If a message with an invalid signature is placed in a queue (or if the message is corrupted or tampered with while on the queue), any attempt to dequeue it fails. A non-transactional tpdequeue() operation has the side effect of destroying such a message. A transactional tpdequeue() operation causes transaction rollback, and all future transactional attempts to dequeue the message will continue to fail.
Compatibility/Interaction with Transactions
Public key security operations-opening and closing keys, requesting a digital signature, or requesting encryption-are not transactional, and are not undone by transaction rollback. However, transactions might rollback due to failure conditions associated with the following public key operations:
Compatibility/Interaction with Domain Gateways
Domain gateway (GWTDOMAIN) processes connecting two BEA Tuxedo applications running BEA Tuxedo Release 7.1 or later software preserve digital signatures and encryption envelopes. In addition, the domain gateway processes verify digital signatures and enforce administrative system policies regarding digital signatures and encryption.
The following diagram is an aid to understanding how domain gateway processes interact with local and remote BEA Tuxedo applications. The table following the diagram describes how Release 7.1 or later domain gateway processes handle digitally signed and encrypted message buffers.
Communication Between BEA Tuxedo Applications
Compatibility/Interaction with Other Vendors' Gateways
A domain gateway (GWTDOMAIN) process connecting a Release 7.1 or later BEA Tuxedo application to another vendor's gateway process operates on outbound message buffers as follows:
In addition, the domain gateway process enforces the administrative system policies regarding encryption and digital signatures for the BEA Tuxedo application. As an example, if encryption and/or digital signatures are required at the domain level for the BEA Tuxedo application, the local domain gateway process rejects any message coming from the other vendor's gateway process.
See Also
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|