|
|
|
|
|
|
Authorization
Authorization allows administrators to control access to BEA Tuxedo applications. Specifically, an administrator can use authorization to allow or disallow principals (authenticated users) to use resources or facilities in a BEA Tuxedo application.
Authorization Plug-in Architecture
A fanout is an umbrella plug-in to which individual plug-in implementations are connected. As shown in the following diagram, the authorization plug-in interface is implemented as a fanout.
Authorization Plug-in Architecture
The default authorization implementation consists of a fanout plug-in and a default authorization plug-in. A custom implementation consists of the fanout plug-in, the default authorization plug-in, and one or more custom authorization plug-ins.
In a fanout plug-in model, a caller sends a request to the fanout plug-in. The fanout plug-in passes the request to each of the subordinate plug-ins, and receives a response from each. Finally, the fanout plug-in forms a composite response from the individual responses, and sends the composite response to the caller.
The purpose of an authorization request is to determine whether a client operation should be allowed or whether the results of an operation should be kept unchanged. Each authorization plug-in returns one of three responses: permit, deny, or abstain. The abstain response gives writers of authorization plug-ins a graceful way to handle situations that are not accommodated by the original plug-in, such as names of operations that are added to the system after the plug-in is installed.
The authorization fanout plug-in forms a composite response as described in the following table. For default authorization, the composite response is determined solely by the default authorization plug-in.
As an example of custom authorization, consider a banking application in which a user is identified as a member of the Customer group, and the following conditions are in effect:
So, if a user in the Customer group attempts to withdraw $500.00 on Monday at 10 AM, the operation is allowed. If the same user attempts the same withdrawal on Saturday morning, the operation is not allowed.
Many other custom authorization scenarios are possible. Feel free to improvise; define the conditions that best serve the needs of your business.
How the Authorization Plug-in Works
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.
A BEA Tuxedo system process or server (such as /Q server TMQUEUE(5) or EventBroker server TMUSREVT(5)) calls the authorization plug-in when it receives a client request. In response, the authorization plug-in performs a pre-operation check and returns whether the operation should be allowed.
If the client operation is allowed, the BEA Tuxedo system process or server may call the authorization plug-in after the client operation completes. In response, the authorization plug-in performs a post-operation check and returns whether the results of the operation are acceptable.
These calls are system-level calls, not application-level calls. A BEA Tuxedo application cannot call the authorization plug-in.
The authorization process is somewhat different for (1) users of the default authorization plug-in provided by the BEA Tuxedo system and (2) users of one or more custom authorization plug-ins. The default plug-in does not support post-operation checks. If the default authorization plug-in receives a post-operation check request, it returns immediately and does nothing.
The custom plug-ins support both pre-operation and post-operation checks.
Default Authorization
When default authorization is called by a BEA Tuxedo process to perform a pre-operation check in response to a client request, the authorization plug-in performs the following tasks.
Because the authorization token is created by the authentication plug-in, the authorization plug-in has no record of the token's content. This information is necessary for the authorization process.
The authorization plug-in determines whether that operation should be allowed by examining the client's authorization token, the BEA Tuxedo access control list (ACL), and the configured security level (optional or mandatory ACL) of the application.
The authorization fanout plug-in receives a decision (permit or deny) from the default authorization plug-in and operates on its behalf.
Custom Authorization
Users of one or more custom authorization plug-ins may take advantage of additional functionality offered by the BEA Tuxedo system. Specifically, the custom plug-ins may perform an additional check after an operation occurs.
When custom authorization is called by a BEA Tuxedo process to perform a pre-operation check in response to a client request, the authorization plug-in performs the following tasks.
The authorization plug-in determines whether the operation should be allowed by examining the operation, the client's authorization token, and associated data. "Associated data" may include user data and the security level of the application.
If necessary, in order to satisfy authorization requirements, the authorization plug-in may modify the user data before the operation is performed.
The authorization fanout plug-in makes the ultimate decision by checking the individual responses (permit, deny, abstain) of its subordinate plug-ins.
If the client operation is allowed, custom authorization may be called by the BEA Tuxedo process to perform a post-operation check after the client operation completes. If so, the authorization plug-in performs the following tasks.
The authorization plug-in determines whether the operation results are acceptable by examining the operation, the client's authorization token, and associated data. "Associated data" may include user data and the security level of the application.
The authorization fanout plug-in makes the ultimate decision by checking the individual responses (permit, deny, abstain) of its subordinate plug-ins.
A post-operation check is useful for label-based security models. For example, suppose that a user is authorized to access CONFIDENTIAL documents but performs an operation that retrieves a TOP SECRET document. (Often, a document's classification label is not easily determined until after the document has been retrieved.) In this case, the post-operation check is an efficient means to either deny the operation or modify the output data by expunging any restricted information.
Implementing Custom Authorization
You can provide authorization for your application by using the default plug-in or adding one or more custom plug-ins. You choose a plug-in by configuring the BEA Tuxedo registry, a tool that controls all security plug-ins.
If you want to use the default authorization plug-in, you do not need to configure the registry. If you want to add one or more custom authorization plug-ins, however, you must configure the registry for your additional plug-ins before you can install them. For more detail about the registry, see Setting the BEA Tuxedo Registry.
See Also
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|