module secu security - pudn.com

BEA Tuxedo Application Administration SECU

SECU-1Copyright © BEA Systems, Inc.All Rights Reserved. Unauthorized Duplication Prohibited.

© BEA Systems, Inc.SECU-1BEA Tuxedo Application Administration

Module

SECU

Security

At the end of this module you will be able to� understand the Tuxedo model for security� configure security for a Tuxedo application� understand the Link Level Encryption security option




Road Map

� Security Overview and Configuration� Security Administration� Link Level Encryption� Lab Workshop




Section

1 Security Overview and Configuration

At the end of this section you will be able to• list the security features available in Tuxedo• add the necessary parameters to the UBBCONFIG file to implement security




The Basic Tuxedo Security Model

&OLHQW�

DXWKHQWLFDWLRQ

��

��

��

6HUYLFH�

UHTXHVW��

FUHGHQWLDOV3ULYLOHJHG�DJHQW��VHUYHU�

SHUIRUPV�VHUYLFH�

RQ�EHKDOI�RI�FOLHQW

$FFHVV�SHUIRUPHG�XQGHU�7X[HGR¶V

XVHU�,'�ZLWK�GDWDEDVH�DFFHVV�SULYLOHJHV

��

&OLHQW

&UHGHQWLDOV

&KHFN�$XWKRUL]DWLRQWR�DFFHVV�6HUYLFH�IRU�HDFK�5HTXHVW

&KHFN�&OLHQW,'�SDVVZRUG�V

The Tuxedo Security Model

Typical security implementations by databases and other middleware products are based on authenticating a user, and granting privilege credentials based on the user’s database id.

BEA Tuxedo uses the privileged agent security model (shown graphically on the slide), in which the authority to perform business transactions is vested in the software, not the person. In this model, an authorized user still could effect transactions by using the approved software, but any attempt to modify the database using an alternate mechanism would fail. In this way, you can assure that all business rules are always enforced.

The notion of an “authorized user” is still needed, but because the approved software transacts under a privileged account ID, you no longer can distinguish an authorized user at the database level. For this reason, an additional level of security is needed to regulate access to the transaction services. This additional level of security is provided by BEA Tuxedo.

To complete the big picture of the model, we are interested in determining two things about a client and it’s request:

• Authentication (who are you and are you really who you say you are)

• Authorization (having correctly identified yourself, what are you permitted to do)

It is important to understand that BEA Tuxedo security will enhance, not replace, your current database security.




The Tuxedo Security Model extended� Message-based digital signature and

encryption based on public keys» Authenticates originating user; verifies message

integrity; message time-stamp for replay resistance; end-to-end, time-independent verification

» Data privacy; access restricted to the designated recipient(s); end-to-end, time independent

� Requires a 3rd Party Security Package plug-in; Tuxedo only provides the infrastructure

� Extended features are not supported in Tuxedo 6.5; only in Tuxedo 7.1, 8.0

Extended Security Features

BEA Tuxedo 7.1 and 8.0 also offer features for additional security including use of :

• Public/private key encryption

• Digital signatures

These features require a 3rd Party security package plug-in and enable the data (message buffer) sent between client and the server (service) to be encrypted or verified on a per-message level (as opposed to the link level with the LLE software). This can provide a very high degree of security from visibility or tampering of the message data. It also ensures that messages are received from authenticated clients or servers.




Using Extended Security� Tuxedo provides the

� Tuxedo API for application developers; for example, calls to sign and/or encrypt request (data) buffer before making a service request

� Service Provider Interface (SPI) for security package vendors to integrate with Tuxedo

� To use features, need a third-party security plug-in package that implements the SPIIn this module we will only be discussing the basic security features that are common to Tuxedo releases 6.5, 7.1, and 8.0.

In this module, we’ll look mainly at the basic security features offered by all versions of BEA Tuxedo.

SPI stands for Service Provider Interface. It is a published interface through which security vendors may integrate their products. Both BEA Tuxedo and BEA WebLogic Enterprise share the same SPI.




Basic Tuxedo Security

� Four levels of basic security available with all BEA Tuxedo versions� native operating system security� application-wide BEA Tuxedo password� user-provided authentication server� access Control Lists (ACLs)

Basic Tuxedo Security

BEA Tuxedo has four different levels of security, each one progressively more secure than the one before it. The four levels of security are:

• Native Operating System - limited to what is provided by the native operating system, such as file access permissions and user logon passwords

• Application-wide BEA Tuxedo password (same for all clients)

• Authentication Server - uses an application-specific authentication server for user-defined security (for example, written by the application programmer)

• Access Control Lists (ACLs) - defines which user is allowed access to a particular service, event, or disk-based queue




Native Operating System Security

� Relies on native operating system security, if applicable

� In the UBBCONFIG file, the following parameter is set (or the default if not defined) in the RESOURCES section

*RESOURCESSECURITY NONE

...

UBBCONFIG

Native Operating System Security

Native operating system security is attained by:

• Not entering any security attributes in the UBBCONFIG file

or

• Entering the keyword SECURITY with the value of NONE in the *RESOURCES section of the UBBCONFIG file.




Application-Wide Password Security

� UBBCONFIG *RESOURCES section

� tmloadcf will prompt the administrator for a password

� This password must be supplied by a client program when joining this application/domain� All clients must supply the password� Password is the same for all clients

*RESOURCESSECURITY APP_PW

...

UBBCONFIG

Application-Wide Password Security

Application-level security requires all users to enter the same password to be allowed access to the application.

Using Application-Wide Passwords

To use an application-level password, configure the *RESOURCES section by entering theSECURITY attribute with the value of APP_PW.

Establishing the Initial Password

Once the UBBCONFIG file is updated, it can be turned into a binary TUXCONFIG file by running the tmloadcf(1) utility. That utility will, in turn, prompt the administrator for an initial application-wide password. Invoke the tmadmin(1) utility and use its passwd subcommand to change the password, if desired. The maximum number of characters in the password is 30.

Client Processing

All clients will need to provide this password to access the application.

Use of an application-wide password means client processes may join the application if and only if they know the one password currently in use. The password is supplied by the client application when joining the BEA Tuxedo domain.

If the password supplied by the client matches the application-wide password currently in effect, the client will be allowed to join the application, and all subsequent service requests made by that client will be honored unless other security measures are in effect (such as ACLs).




AUTHSVR

� A Tuxedo-provided authentication server that provides two security services� AUTHSVC, for user authentication� ..AUTHSVC, for access control to resources

� The AUTHSVR services validate the username and password against a Tuxedo-maintained list of users� On success, AUTHSVR provides an

application key to the client � On failure, a security violation is logged in

the userlog file

Tuxedo Authorization Server

BEA Tuxedo provides a user authentication and authorization server - AUTHSVR.

AUTHSVR provides per-user authentication based on a Tuxedo-maintained database of users and passwords. When the client process calls tpinit(3) to join the application, the AUTHSVR validates the username, client name, and password. If the tpinit(3)call fails for security reasons, a security violation is logged in the userlog, and posted as a system event. On success, the AUTHSVR provides an application key to the client which cannot be forged. The application key is attached to each service request performed by the client, “unseen” by the user.

AUTHSVR uses the tpusr file in $APPDIR (UNIX) or %APPDIR% (Windows NT). This file is set up with Tuxedo-supplied utilities as we will see later.




AUTHSVRConfiguration

� In the RESOURCES section of the UBBCONFIG file, define the� security level with the SECURITY parameter� security service with the AUTHSVC parameter

� Configure AUTHSVR in the SERVERS section

�*RESOURCESSECURITY USER_AUTHAUTHSVC AUTHSVC

...*SERVERS

AUTHSVR SRVID=100 SRVGRP=AdminGroup RESTART=Y CLOPT=”-A”

...

UBBCONFIG

A Sample Authentication Server continued

Authentication Server Security

The authentication server security model provides a method for incorporating a user-defined (written) security methodology into the BEA Tuxedo application.

An authentication server, $TUXDIR/bin/AUTHSVR (%TUXDIR%\bin\AUTHSVR) on Windows), is supplied with the Tuxedo product. Although this was meant to be an example only, it is sometimes used in user applications as an added level of security. We will discuss how to set up users for AUTHSVR later in this module.

There is also sample source code in <TUXDIR>/lib/AUTHSVR.c.

To add the AUTHSVR to an application, define it as a server in the UBBCONFIG file. Add the following lines to the *RESOURCES and *SERVERS sections of the UBBCONFIG file, as shown:

*RESOURCESSECURITY USER_AUTHAUTHSVC “AUTHSVC”

*SERVERSAUTHSVR SRVID=100 SRVGRP=AdminGroup RESTART=Y CLOPT=”-A”




Access Control Lists (ACLs)� Provides group-based access control to

application entities (services, events, and /Q queues)

� Access control is administered at the group level to provide � easier system administration� increased performance

� Limitations of ACLs� A user can only be associated with one group

at a time� User identification aging is not supported

Access Control Lists (ACLs)

Access Control Lists (ACLs) provide group based access control to application entities (services, events, and store and forward queues).

Access control is done at the group level because:

• System administration is much easier. It is easier to give a group of people access to a new service than to give each individual user access to the service.

• Performance is better. Since access permission must be checked for each invocation of an entity, permission should be resolved quickly. Since there are fewer groups than users, it is faster to search through a list of privileged groups than it is to search through a list of privileged users.

Limitations of ACLs

A user only can be associated with one group at a time. To be a member of more than one group, a user must be assigned multiple user id’s.

User identification aging is not supported. If a user is removed from the system, it is up to the administrator to decide when it is appropriate to add another user with the same ID to the application.




ACL Configuration

� Two levels of ACL-based security; configured in the RESOURCES section� ACL� MANDATORY_ACL

*RESOURCESSECURITY ACL # or MANDATORY_ACLAUTHSVC �..AUTHSVC�

...*SERVERS

AUTHSVR SRVID=100 SRVGRP=AdminGroup RESTART=Y CLOPT=�-A�

...

UBBCONFIG

Access Control Lists (ACLs) continued

Implement user-level ACLs, if needed, by creating a group for each user, then setting up the group to have the desired permissions for its single member. Be aware that this method may make system administration more difficult and may impact performance.

There are two levels of ACL-based security:

ACL if there is no ACL security rule entry for a service, event, or queue, access is allowed

MANDATORY_ACL if there is no ACL security rule entry for a service, event, or queue, no access is allowed

At the ACL level, if a service, event, or store and forward queue does not have an ACL Security Rule (note that it will not have an entry in the $APPDIR/tpacl file on UNIX platforms or the%APPDIR%\tpacl file on Windows NT, discussed later), then any user who passes the authentication level has the ability to use it. If the MANDATORY_ACL is used, then the opposite occurs. If there is no ACL entry for a service, event, or store and forward queue, then no one is able to gain access to it. The latter method, although more secure, might require significant administrative overhead if many services exist in a given application.




Review

In this section, we discussed� the security features in Tuxedo� the security-related parameters in the Tuxedo

configuration file




Road Map





Section

2 Security Administration

At the end of this section you will be able to• list the files used by the authorization server AUTHSVR provided with Tuxedo• use the Tuxedo utility programs to generate the above files and to define users and access control lists




Some Definitions related to ACL Use

�� username ��

��client_name ��

��UID ��

� �� !"�groupname �� #$��

��GID %��

�� &"�entity_name

��ACLNAME

�� '��(��'�� #� ��$��

ACL Parameters

The commands used to administer ACL-based security for users and groups accept the following parameters:

username A character string that is the name of a BEA Tuxedo user

client_name A character string that is the name of a client. The maximum number of characters is 30. Two commonly used client names are tpsysadm for administrator, and tpsysop for operator. In the client TPINIT structure, this is referred to as CLTNAME.

UID An integer between 0 and 128k, which is used internally by the application to refer to the user

groupname A character string which is the name of a group. The maximum number of characters is 30.

GID An integer between 0 and 16k, which is used internally by the application to refer to the group

entity_name or ACLNAME The name of an entity that can have restricted access through anAccess Control List (for example, services, events, and /Q queues). The maximum number of characters is 30.

Note: The colon character (“:”) and the newline (“\n”) are illegal for all character string parameters.




User and Group Administration Files

� Two files are used for Tuxedo application user and group administration� tpusr

� tpgrp

� Similar format to the UNIX /etc/passwdand /etc/group files� multiple values o a line separated by “:”� flat ASCII files� readable only by application administrator

� Reside in <APPDIR>

User and Group Administration Files

The two files used for user and group administration are:

• tpusr

• tpgrp

These files have essentially the same format as the UNIX system files /etc/passwd and /etc/group but are created and maintained by Tuxedo administration utility programs. They are colon delimited, flat ASCII files that are only readable by the application administrator.

The files are kept in the application directory indicated by the environment variable $APPDIR on UNIX platforms or %APPDIR% on Windows NT. These files should never be modified with any tool other than the commands given. Modifying these files may destroy the concurrent DB which BEA Tuxedo maintains. The format of the files is not discussed here because they can be fully administered with the commands discussed on the following pages.

Warning : Never modify these files with any tool such as an editor; use only the Tuxedo utilities to do so.




Adding, Deleting, and Modifying Groups

�� tpgrpadd(1)

tpgrpadd [-g GID] groupname

�� tpgrpdel(1)

tpgrpdel groupname

!��"�� tpgrpmod(1)

tpgrpmod [-g GID] [-n new_groupname] groupname

Adding, Deleting, and Modifying Groups

tpgrpadd(1) : To add a group

tpgrpadd [-g GID] groupname

Parameter

GID The group ID for the groupname

tpgrpdel(1): To delete a group

tpgrpdel groupname

Parameter

groupname The name of the group to be deleted

tpgrpmod(1):- To modify a group

tpgrpmod [-g GID] [-n new_groupname] groupname

Parameters

GID The group ID for the groupname

new_groupname The new name of the group

groupname The name of the group to be modified




Adding, Deleting, and Modifying Users

�� tpusradd(1)

tpusradd [-u UID] [-g GID | groupame] [-c clientname] username

�� tpusrdel(1)

tpusrdel username

!��"��tpusrmod(1)

tpusrmod [-u UID] [-g GID | groupame] [-c clientname] [-l new_username] [-p] username

Adding, Deleting, and Modifying Users

tpusradd(1) : To add a user (When tpusradd(1) is executed, the administrator is prompted for a password to be assigned to this username.)

tpusradd [-u UID] [-g GID] [-c clientname] username

Parameters

UID The user ID for the user

GID The group ID for the user

clientname The client name associated with the user; default is the wildcard “*”

username The name by which this user is identified (tied to UID)

tpusrdel(1) : To delete a user

tpusrdel username

Parameter

username The name of the user to be deleted

tpusrmod(1): To modify a user

tpusrmod [-u UID] [-g GID] [-c clientname] [-l new_username] [-p] username

Parameters

new_username The new name to be assigned to this user

-p The administrator is prompted for a new password

Other parameters as for tpusradd




ACL Administration� ACL entries are stored in the file: $APPDIR/tpacl or %APPDIR%\tpacl

� Use tpacladd, tpacldel, and tpaclmod to add, delete, and modify ACL entries:

tpacladd [-g GID | groupname][,GID | group_name...]

[-t type] entity_name

tpacldel [-t type] entity_name

tpaclmod [-g GID | groupname][,GID | group_name...]

[-t type] entity_name

ACL Administration

ACLs are stored in the file $APPDIR/tpacl (for UNIX) or %APPDIR%\tpacl (for Windows). Only the application administrator can read or write to this ASCII file. To administer this file, use the add, delete, and modify commands for the ACLs:

tpacladd(1): To Add an ACL entry

tpacladd [-g GID | groupname][,GID | group_name...] [-t type] entity_name

-g GID Allows the specification of a group or a list of groups to be added to the ACL

entity_name The name of the service, event, or /Q queue for which the ACL is created

-t type Specifies the type of ACL (for example, SERVICE, ENQ, DEQ, or POSTEVENT)

tpacldel(1): To Delete an ACL entry

tpacldel [-t type] entity_name

tpaclmod(1): To Modify an ACL entry

tpaclmod [-g GID | groupname][,GID | group_name...] [-t type] entity_name




Example: Add a Group, User, and ACL

#$%&�� tmloadcf myUBBCONFIG ...

tpgrpadd -g 801 Beatlestpusradd -g Beatles Ringotpusradd -g Beatles Paultpusradd -g Beatles Georgetpusradd -u 9 Fredtpacladd -g Beatles -t SERVICE TOUPPER

'�� tmloadcf myUBBCONFIG ...

tpgrpadd -g 801 Beatlestpusradd -g Beatles Ringotpusradd -g Beatles Paul tpusradd -g Beatles Georgetpusradd -u 9 Fredtpacladd -g Beatles -t SERVICE TOUPPER

&UHDWH�WKH�JURXS�%HDWOHV�

$GG�XVHU�)UHG��GRHV�QRWEHORQJ�WR�WKH�%HDWOHV�JURXS�

$GG�XVHU�3DXO�WR�WKH�JURXS�

$OORZ�XVHUV�LQ�WKH�%HDWOHV�JURXSDFFHVV�WR�WKH�VHUYLFH�72833(5�

)LUVW�FUHDWH�WKH�78;&21),*�ILOH�

Example: How to Add a Group, User, and ACL

The examples on the slide show the generation of the TUXCONFIG, addition of a group, users, and ACL.




Change Application Password

� tmadmin command: passwd� Prompts the user for the new password

� Verifies new password with a second promptto re-enter the new password

Change Application Password

Using the tmadmin->passwd subcommand, you can change the password on an application configured for security. When the command is entered, the administrator is prompted for the new password and then prompted a second time for verification. Clients that join the application after this command is executed must connect with the new password.




Review

In this section, we discussed� the Tuxedo utility programs to create security

files for use by the Tuxedo AUTHSVR server� the use of the administration programs to add

groups, users, and access control permissions




Road Map





Section

3 Link Level Encryption

At the end of this section you will be able to• understand the link level encryption security feature available with the Tuxedo product




Link-Level Encryption (LLE)

� Allows for encryption of data transferred over BEA Tuxedo network links

� Provides data privacy� With Tuxedo 6.5 and 7.1 releases, LLE is a

separately licensed add-on “product”� In Tuxedo 8.0, LLE usage is included with

the Tuxedo product license

Link-Level Encryption (LLE)

Link-Level Encryption (LLE) allows encryption of data flowing over Tuxedo network links. The objection is to ensure data privacy, so a network-based eavesdropper cannot learn the content of Tuxedo messages or application-generated messages. Link-Level Encryption (LLE) is a BEA Tuxedo add-on “product” but the software is actually distributed with the Tuxedo product. A separate license is required to use the LLE feature with Tuxedo 6.5 and 7.1. The LLE license cost is included with the Tuxedo 8.0 product license.




LLE Examples

Client/Server

LLE LLE

6WDQGDUG�7X[HGR�³/LQN�/HYHO�(QFU\SWLRQ´

Server

/LQN�/HYHO�(QFU\SWLRQ��//(��HQFU\SWV�DOO�GDWD�EHWZHHQ�WZR�PDFKLQHV

/WS Client

LLE LLE

6WDQGDUG�7X[HGR�³/LQN�/HYHO�(QFU\SWLRQ´

WSL

//(�HQFU\SWV�DOO�GDWD�EHWZHHQ�WKH��:6�&OLHQW�PDFKLQH�DQG�:6/�PDFKLQH Server

Link Level EncryptionLink Level Encryption (LLE) software is distributed with Tuxedo product; encrypts data sent over network links. In Tuxedo 6.5 and 7.1, use of the LLE is a separately licensed software option; LLE usage is included in the Tuxedo 8.0 license.




Connection Types Supported

� Types of links that can have data encrypted are� Machine to Machine (BRIDGE to BRIDGE)� /WS workstation client to WorkStation

Handler (WSH)� Administrative utilities (tmboot, tmshutdown, ...) to tlisten

� Domain Gateway to Domain Gateway

Link-Level Encryption (LLE) Connection Types

LLE can be used on the following types of Tuxedo connections:

• /Workstation client to WSH

• BRIDGE to BRIDGE

• Administrative utilities (tmboot(1), tmshutdown(1), tmadmin(1), etc.) totlisten(1)

• /Domain gateway to /Domain gateway




LLE between Machines

� Connecting process attempts to setup the communication session; accepting process receives the initial connection

� Connecting processes negotiate encryption level for the link base on two configured parameters in the *NETWORK section� MINENCRYPTBITS: Minimum encryption

level - (0, 56, or 128 bit key size)� MAXENCRYPTBITS: Maximum encryption

level - (0, 56, or 128 bit key size)

How LLE Works

LLE control parameters and underlying communication protocols are different for various link types, but there are some common themes:

• Connecting process begins the communication session

• Accepting process receives the initial connection

• Both connecting and accepting processes are aware of the link-level encryption feature, and have two configuration parameters. These parameters are configured in the NETWORK section:

• MINENCRYPTBITS: Minimum (min) encryption level - expressed as 0, 56, or 128 bit key size

• MAXENCRYPTBITS: Maximum (max) encryption level - expressed as 0, 56, or 128 bit key size

The sending and receiving processes negotiate the encryption level that both can support, which is the highest common level of encryption.

LLE is point-to-point, which means that your data may be encrypted/decrypted many times as it flows over network links.




LLE between WSL and /WS Client

'�(�)(*� ��[-z [0|40|56|128] �� (�� )�� "�� "��

��*��"�� *��"�� +� ��,�)��$$-�.��

[-Z [0|40|56|128] ��(��$� "/$�(��- �� 0$$-1��)�� "�� "�� *��"�� *��"�� +� ��,�)��$$-�.��

+'��) ��,�-��. �TMMINENCRYPTBITS �� 2*.��

�� (�� TMMAXENCRYPTBITS �� 2*.��

�� (�� 128 ��$� "/$�(��- �� 0$$-1'�� 40��3 �� $$-�

WSL CLOPT parameters

[-z [0|40|56|128]]

When establishing a network link between a Workstation client and the Workstation Handler, require at least this minimum level of encryption. 0 means no encryption, while 40, 56, and 128 specify the length (in bits) of the encryption key. If this minimum level of encryption cannot be met, link establishment will fail. The default value is 0.

[-Z [0|40|56|128]]

When establishing a network link between a Workstation client and the Workstation Handler, allow Link-Level Encryption (LLE) up to this level. Valid values are 0 or 40 for International Link Level Encryption (LLE), and 0, 40 or 128 for Domestic LLE. The default is 128 for Domestic LLE, and 40 for International LLE.

Note: The -z and -Z options are available only with Tuxedo LLE licensed if appropriate for the Tuxedo version.

/WS Client Environment Variables

TMMINENCRYPTBITS

The minimum number of encryption bits that the /WS client will permit for use in its server connection. If the server is not capable of providing this level of encryption, the connection will fail. Default is 0.

TMMAXENCRYPTBITS

The number of encryption bits that the /WS client would like to use if possible. Valid values are 0or 40 for International Link Level Encryption (LLE), and 0, 40 or 128 for Domestic LLE. The default is 128 for Domestic LLE, and 40 for International LLE.




Review

In this section, we discussed� additional security features for encrypting

data over network links using LLE software




Review

In this module, we discussed� Security features available in Tuxedo� A brief overview of the extended security

features available in Tuxedo� How to configure an authorization server� How to set up groups, users, and ACLs� Link Level Encryption (LLE) use and

configuration




Lab Workshop

Please refer to the Lab Exercises guide and do lab SECU.The suggested time for this lab is 30 minutes.

The Instructor will determine when it is appropriate to stop.

module secu security - pudn.com

Documents