Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Security   |   Topic List   |   Previous   |   Next   |   Contents

   Using BEA Tuxedo Security

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.

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.)

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.)

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:

• Data-dependent routing

• Threads

• EventBroker

• /Q

• Transactions

• Domain gateways (GWTDOMAINs)

• Other vendors' gateways

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:

1. The public key software makes a copy of the encrypted message buffer and uses the decryption key to decrypt the buffer.

2. The process reads the resulting plaintext (unencrypted text) message content to make the routing decision.

3. The public key software overwrites the plaintext message content with zero values to preserve privacy.

The system then transmits the original encrypted message buffer in accordance with the routing decision.

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.

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:

• To evaluate subscription filter expressions based on message content.

  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.

• To perform subscription notification actions that require access to message content: userlog(3c) processing or system command execution.

  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.

• To perform subscription notification actions that, based on system configurations, need to access message content for data-dependent routing.

  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.

• To comply with an administrative system policy requiring encryption (as explained in Setting Encryption Policy).

  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.

• To verify that a posted encrypted message has a valid digital signature attached, if required to do so by an administrative system policy requiring digital signatures (as explained in Setting Digital Signature Policy).

  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:

• To perform TMQFORWARD operations that, based on system configurations, need to access message content for data-dependent routing.

  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.

• To comply with an administrative system policy requiring encryption (as explained in Setting Encryption Policy).

  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.

• To verify that an enqueued encrypted message has a valid signature attached, if required to do so by an administrative system policy requiring digital signatures (as explained in Setting Digital Signature Policy).

  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.

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:

• If a transactional request or reply message cannot be decrypted, its associated transaction is rolled back.

• If a transactional request or reply message is discarded because of an invalid or missing digital signature, its associated transaction is rolled back.

• If a transactional request or reply message is rejected because it violates an administrative system policy requiring encryption or digital signatures, its associated transaction is rolled back.

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.

Operation of Release 7.1 or Later Domain Gateway (GWTDOMAIN) Processes

Message Type	Condition	Resulting Operation
Inbound message-originating from a remote process and received over a network connection	Has encryption envelope and may or may not have digital signature	The domain gateway process accepts the message and forwards it in encrypted form. If the data-dependent routing feature applies and the domain gateway process does not have a suitable decryption key, the gateway process rejects the message. (See Compatibility/Interaction with Data-dependent Routing for clarification.)
Inbound message	Does not have encryption envelope or digital signature	If the domain gateway process is running within a domain, machine, or group requiring encryption, the gateway process rejects the message. If a service advertised by the domain gateway requires encryption, the gateway process rejects the message. (See Setting Encryption Policy for clarification.) If the domain gateway does not require encryption, the gateway process accepts and forwards the message.
Inbound message	Has digital signature but is not encrypted	The domain gateway process verifies the digital signature and forwards the message with digital signature attached.
Inbound message	Does not have digital signature and is not encrypted	If the domain gateway process is running within a domain, machine, or group requiring digital signatures, the gateway process rejects the message. If a service advertised by the domain gateway requires digital signatures, the gateway process rejects the message. (See Setting Digital Signature Policy for clarification.) If the domain gateway does not require digital signatures, the gateway process accepts and forwards the message.
Outbound message-originating from a local process and transmitted over a network connection	Has encryption envelope and may or may not have digital signature	The domain gateway process accepts the message and forwards it in encrypted form over the network. If the data-dependent routing feature applies and the domain gateway process does not have a suitable decryption key, the gateway process rejects the message. (See Compatibility/Interaction with Data-dependent Routing for clarification.) If the encrypted message is destined for a process running BEA Tuxedo pre-Release 7.1 (6.5 or earlier) software, the domain gateway process rejects the message. (See Interoperating with Pre-Release 7.1 Software and Interoperability for Public Key Security for clarification.)
Outbound message	Does not have encryption envelope or digital signature	If the domain gateway process is running within a domain, machine, or group requiring encryption, the gateway process rejects the message. If a service advertised by the domain gateway requires encryption, the gateway process rejects the message. (See Setting Encryption Policy for clarification.) If the domain gateway does not require encryption, the gateway process accepts the message and forwards it over the network.
Outbound message	Has digital signature but is not encrypted	The domain gateway process verifies the digital signature and forwards the message with digital signature attached over the network. If the message is destined for a process running BEA Tuxedo pre-Release 7.1 software and assuming interoperability with BEA Tuxedo pre-Release 7.1 software is allowed, the domain gateway process verifies and then removes the digital signature before forwarding the message over the network. (See Interoperating with Pre-Release 7.1 Software and Interoperability for Public Key Security for clarification.)
Outbound message	Does not have digital signature and is not encrypted	If the domain gateway process is running within a domain, machine, or group requiring digital signatures, the gateway process rejects the message. If a service advertised by the domain gateway requires digital signatures, the gateway process rejects the message. (See Setting Digital Signature Policy for clarification.) If the domain gateway does not require digital signatures, the gateway process accepts the message and forwards it over the network.

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:

1. Decrypts encrypted messages.

2. Verifies digital signatures (if any) and then removes digital signatures.

3. Transmits messages in plaintext format over the network to the vendor's gateway process.

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.

• Security Interoperability

• Mandating Interoperability Policy

• Setting Digital Signature Policy

• Setting Encryption Policy