WebSphere Enterprise Security Guidelines for Component Broker Edition ApplicationsIntroductionA fundamental concern in distributed systems in general is how to protect data and business assets available through the information system. This is no less true in distributed, object-oriented systems. Valuable information exists in business objects. This information can be manipulated and accessed remotely, and therefore must be protected from unauthorized use. WebSphere Application Server Enterprise Edition (WAS EE) Component Broker (CB) provides security services to help protect these assets. The security service is used primarily to prevent end users from accessing information and resources they're not authorized to use. This predominately covers distributed objects, but by extension includes any of the information and resources from other non-OO, or non-distributed sources, that those business objects use. In many cases CB is used to wrapper legacy information system resources business applications and enterprise data. Often, those resources have always been centralized resources held in a physically secure environment or with restricted access over controlled access channels. The security service must compensate for whatever protections may be otherwise lost due to the ease with which access can be gained to resources through the distributed object system. Likewise, the security service must not detract from the ease with which legitimate use of these resources can be made using the CB server. In other words, any benefit an application programmer receives by using CB should not be taken away by the security service, except to prevent un-authorized access to resources. By extension, this means that if security policies for a set of legacy resources have already been established and are in use in existing production systems, then it should be possible to use those same policies to protect resources in the object system it shouldn't be necessary to re-specify existing security policies or to keep two sets of policies in sync. An overview of the Component Broker security system is depicted in the following diagram. Figure 1 Overview of the Component Broker security system Object systems tend to introduce many more independent Objects then in equivalent procedural systems. In fact there aren't really, but procedural systems tend to wrap up individual objects into larger-grained artifacts, such as resources managers or database tables. The presence of so many objects introduces the potential for administrative scalability issues that present their own security exposures -- when administration becomes overwhelming, administrators just stop administering. Objects just remain unprotected. The security service guards against this threat by factoring security policies across all of the objects of a given type, and to the resources that are used by that server. Component Broker security provides support for authenticating users and using that to prevent un-authenticated access to secure servers. It can certify to business objects the principal on whose behalf any given method request is being made. The security service also provides support for protecting message traffic between clients and server, and between servers and servers. Finally, the security service provides support for delegating the credentials of an end user through cascaded method requests that span multiple servers. Contents
Terminology
Security systems are generally composed of several related concepts. This includes things like authorization, confidentiality, auditing and administration. While all security concepts are fundamentally built on the foundations of a cryptographic system, most security concepts are preconditioned by establishing who end-users are, and certifying that they are who they claim to be. This is known as authentication certifying that a person is authentic. Having authenticated the end-user we know their identity. We can use that identity then to determine what resources the end-user is allowed to access, and how. We can encrypt message traffic in a way that only that end-user can decipher. And we can determine who may be challenging the integrity of the security system. All security mechanisms are based on trust: trust in some service to properly confirm the authenticity of principals, trust in the security algorithms to perform as advertised, even trust in our own judgments when used to evaluate whether the person in front of us is who they claim and appear to be. The concept of trust is essential to striking the right level of protection for your information system. To achieve this level you need to be able to answer the question "Who can and should I trust?". Authenticating a person is the process of establishing trust in that person. One can authenticate a person based on a variety of techniques that challenge what that person possesses, what they know, or who they are, or any combination of the three. For instance, you can assert who a person is by the fact that they possess a key to your house or employee-badge to your enterprise. This is typically a weak authentication scheme as it can be easily defrauded by stealing the possession. Another technique is to base authentication on a secret that only that person should know, such as a password or your mother's maiden name. This is only as strong as it is difficult to guess the secret. However sufficiently obscure passwords can be reasonably difficult to guess making this technique quite strong. The last technique is to base authentication on something that biometrically defines the person such as their finger-print, voice-print, DNA-print, or signature. Typically biometric-based authentication can be very reliable, but can be somewhat intrusive who wants to provide a blood-sample for a DNA test each time they log-on to their workstation? They also typically require specialized hardware. Component Broker supports password-based authentication relying on a secret that only that end-user should know. Component Broker, in fact, authenticates more than just end-users. It also authenticates server processes and, at the discretion of the programmer, application-defined entities. The thing being authenticated the end-user, a server process, or other application-defined entity is referred to as a principal. To be authenticated, the principal must have been previously registered with an account in the user registry the DCE user registry and must have been assigned a password. Once a principal has been authenticated, the CB security system will create a Credentials object representing the authenticity of that principal. The presence of a Credentials object indicates that the principal it represents has been authenticated. The Credentials object also contains other credential information pertaining to that principal for instance, the principal's security name and the user groups to which that principal has been assigned by the security administrator in the user registry. The principal's security name and their user groups can be used to make authorization decisions. Authorization is the process of determining whether the principal is authorized to access a resource. Authorization decisions are made based on access control policies which grant a principal the permission to access a particular resource. The primary resources in CB are components such as Managed Business Objects (BOs) and EJBs. You can control access to these resources by specifying access control policies in Policy Director with the administrative tools provided there. For convenience, all component instances of the same type (having the same interface) share a common authorization policy. The authorization policy is established in an Access Control List (ACL) associated with the resource in Policy Director. All CB components are assigned required-rights (also referred to as required-permissions) that is, a label indicating the rights that you must possess to access a given method of that component. The assignment of required-rights is performed through a fixed algorithm derived from the name of the method (this is described further in fine-grained authentication). The authorization system operates by comparing the rights (also referred to as permissions) you have been granted in the ACL for the resource with the required right of the method you are invoking. Only if you have been granted the required permission are you then allowed to access the method. Once you have been granted access to a method, and that it on your behalf, it may be necessary for that method to invoke methods on other components (within CB's control) or to access data or functions located on another information system (outside of the control of CB). Access to the down-stream component can be performed either under the identity of the intermediate server, or under the identity of the requesting principal. This is referred to as the delegation policy and is established at the server-boundary all down-stream requests are either performed under the intermediate server's identity, or under the requesting principal's identity, by default, and depending on the setting of this policy. The delegation policy can be overridden programmatically. That is, you can set the credentials under which down-stream request will be performed (assuming the principal represented by that credential has the authority to access that method). To gain access to resources in a back-end data system outside of CB's control, it may be necessary for CB to convert the credential used to represent you to the WAS EE system to a form that will be recognized by that other system. This is referred to as credential mapping mapping the credential of the requesting principal to credential information that will represent that principal to the other system. CB can map credentials to a variety of back-end data systems, including RACF, TopSecret, ACF2 (used with IMS, CICS and DB2/ESA) on S/390, MQSeries, and SAP systems. As with authorization policies, credential mapping information is managed through Policy Director. You can use Policy Director to create and maintain the mapping information, and the CB runtime will automatically obtain the mapping information when creating a connection to the back-end data system on your behalf. Technologies
Component Broker uses a variety of technologies to accomplish an end-to-end security solution. The DCE security service forms the backbone of the CB security system today. DCE uses the Kerberos/V protocol as its primary authentication mechanism. The Kerberos protocol is used along with a mutually trusted third-party authentication server that assures the integrity of any credential tokens passed across the distributed system to represent a given principal. The DCE security service also enable message protection through the use of GSSAPI (General Security Service API). Message protection is accomplished using either 56-bit (exportable) or 128-bit (domestic) DES. Component Broker also supports authenticating principals from remote, small footprint Java clients. This is accomplished by forming an SSL (Secure Socket Layer) connection between the client and the targeted server over which credential information can be passed to authenticate the client principal. SSL is a protocol for authenticating public-key certificates certificates representing a principal that has been signed by a signing authority. WAS EE uses SSLv3 along with X.509v3 certificates. CB uses RSA for signing certificates, and can use MD5 or SHA cipher algorithms for message integrity protection and CMDF, RC4, or RC2 cipher algorithms for message confidentiality over the SSL connection. Interoperability
Component Broker employs a variety of industry standards including OMG's IIOP protocol, DCE security, GSS-API, Kerberos/V and SSLv3 to increase portability, compatibility, and to ensure the state-of-the-art in integrity. However, CB uses a proprietary interoperation protocol for secure associations over IIOP. This protocol is not, at this time, interoperable with other OMG vendor ORB products. IBM continues to work with other vendors to define a secure interoperability protocol over IIOP for use with both CORBA and EJB objects. CORBA Security Service OverviewThe Component Broker security system is based on the OMG security service. This standard service can be decomposed into two distinct elements the formation of secure associations between nodes in the distributed system, and a set of objects that represent abstract security artifacts with which programs can control the security system. As indicated previously, secure associations are formed with a proprietary GSS-based protocol over IIOP. The result is that a target, when invoked, can determine with a high degree of integrity who invoked the currently executing method. You can, within your object implementation, perform a test for who the invoking principal is with a great deal of certainty. This is accomplished primarily through the use of the DCE Kerberos/V security service which can prepare a credential token representing an authenticated principal, and validate the legitimacy of the credential as it is propagated between nodes. In addition, CB supports the formation of secure associations over SSL from thick Java client applications. This is achieved by forming an SSL connection with the target server, using the target's server-certificate, and using that secure connection to pass the client's DCE user id and password to the server to be authenticated with DCE there. The programmatic aspects of the CORBA security service are intended to enable the application to query the results of authentication and secure association by the underlying runtime, as well as to manipulate the security context of its execution where needed. An overarching assumption of the CB security system is that applications should not have to be programmatically aware of the security system. In other words, the security system should just simply work, under the cover and unbeknownst to the called objects. The underlying system ensures the requesting principal has been authenticated, and by automatically propagating the security context of the requesting principal to downstream objects it can ensure that only authorized principals gain access to protected objects. However, there are occasions where it is necessary for the application developer to encode explicit control over security. This can occur for at least three reasons:
To achieve these objectives the CORBA security service introduces the following security components:
In addition, CB introduces a LoginHelper that wraps the PrincipalAuthenticator, providing a simpler interface for end users. The security context on each thread of execution consists of three Credentials: the received-credentials, the own-credentials and the invocation-credentials. The received-credentials are the Credentials of the requesting principal. These credentials are formed as the result of completing a secure association with the requesting node. The presence of the received-credentials indicates that the request has been invoked securely, and that the requesting principal has been vouched for by the underlying system. The own-credentials represent the credentials of the object's owning principal the principal that 'owns' the invoked object. This is typically the principal associated with the server in which the object executes and is defined when you configure the presence of the server process through system management. The invocation-credential contains the Credentials under whose authority down-stream methods will be invoked. This can be the same as received-credentials indicating that down-stream requests will be performed under the same authority that invoked the currently executing method; delegation or may some other principal. By default, the invocation-credentials are set to either the received-credentials or the own-credentials depending on the delegation policy. If you want to determine which principals are associated with any of these three elements in the security context, you can obtain a SecurityCurrent from the ORB and from that get the received-credentials using the received_credentials attribute, or the own- or invocation-credentials using the get_credentials method of the SecurityCurrent. In addition, you can change the own- or invocation-credentials using the set_credentials method of the SecurityCurrent. This change only effects the current thread of execution, and only for the duration of the current method request. On subsequent method requests the credentials within the security context will be set back to their default values. If you want to set the own- or invocation-credentials to something other than what's available in the security context, you can form new Credentials objects that is, assuming you have access to the authentication information that is needed to prove the authenticity of the principal you are trying to authenticate. Remember that Credentials will only ever be formed if the principal they represent can be proven to be authentic. In CB this will require that you have that principal's DCE user id and password. You might obtain this directly from an end-user by prompting for it, or you may devise some other scheme for obtaining this information. Just remember that passwords are intended to be secret the integrity of their authenticity depends on being able to maintain their secrecy. You can form a Credentials by getting a PrincipalAuthenticator object from the SecurityCurrent, and then invoking the authenticate method. Alternately, you can create an instance of the LoginHelper and invoke the request_login method. The request_login method will both form the arguments of the authenticate method and invoke it, and also set the resulting Credentials as the invocation-credentials on the current thread of execution. Use of DCE in CBDistributed Computing Environment (DCE) serves as the security backbone for Component Broker. Component Broker users are registered as DCE users, in the DCE user registry. User authentication is performed using DCE security services. Other than where SSL is used between Java clients and application servers, DCE is used everywhere else to create secure associations between clients and servers, and between servers and other servers. DCE security is composed of the following two parts:
DCE is required in any Component Broker installation, even if SSL-based security is used with Java clients. You only have to install one DCE security server in your Component Broker network. You can install more than one and set them up to replicate all or parts of either the DCE user registry or the DCE Cell Directory Service (CDS) for use with the Naming service. However, only one security server is needed and setting up replicas, while improving availability, has additional administrative and performance implications. You have to install the DCE client at every client and server host in your CB network, with the exception of Java clients that use SSL-based authentication. If you do install the DCE client at your Java client you have the choice of either using DCE or SSL-based authentication. You control which is used through configuration attributes in the Client Style used by that Java client. (See Configured Clients for more information on setting configuration attributes that will be used at the Java client.) If you enable both DCE and SSL-based authentication, then DCE authentication is performed as that is slightly more secure in a Component Broker network. CB Functionality
CB provides support for authentication, delegation, credentials mapping and authorization, along with the corresponding requisite auditing and administration. AuthenticationDCE 3-Party AuthenticationDCE establishes authenticity by validating your user id and password against predefined information in the DCE user registry. This is known as knowledge-based authentication; you are deemed to be authentic by virtue of the knowledge you possess about your user id, and especially your password which is supposed to remain a secret between you and the user registry. Even system administrators are not supposed to ever know your password. If you keep your password secret, and if no one else is able to guess your password, then the system can assume your authenticity. DCE uses a 3-party authentication scheme; to establish the authenticity of a principal, a client or server uses the DCE security server. Once DCE has established your authenticity it forms a credential token which is maintained by CB on the thread(s) of execution to which it applies. This token can then be sent by the CB runtime to the target application server. The token can then be verified by the DCE server at the target application server, from which a secure association between the client and target application can be formed. The authentication and secure association process is depicted in the following diagram Figure 2 The authenication and secure association process In this way the server does not have to rely on the trustworthiness of the client software. Likewise, when clients need to verify the authenticity of their servers, the client does not have to rely on the trustworthiness of the server software. If the client host or server host is compromised, the other does not need to trust it to reliably represent the authenticity of the principals they define. Both the client and the server only rely on the trustworthiness of the 3rd-party DCE security server, and the Kerberos/V protocol used by DCE ensures that neither can falsely assert their authenticity. Further, because trust is isolated to only the DCE security server, that server can easily be secured physically; for example, by locking it in a closet or in a closely monitored computing center. By extension, this ensures the integrity of the rest of the computing system that relies on that trust. SSL-Based AuthenticationSSL establishes authenticity through the use of public-key certificates. Certificates represent a possession-based authentication scheme; you are deemed authentic by virtue of possessing a certificate that identifies you. On its own this would not be very secure as, presumably, anyone could manufacture a set of data in the required format that identifies you (or anyone else) and use that to masquerade as you. To prevent this, certificates must be digitally signed by a 3rd-party certificate authority that vouches for your authenticity. CB uses SSL only to establish trust in the target server, and from that to protect messages communicated between the client and target application server. CB then establishes trust in the client by forwarding the client's authentication information to the target application server. The server runtime then uses that information to authenticate the client principal with DCE. The secure association is only accepted if the client can be authenticated to DCE successfully. DelegationDelegation is the process of transferring the credentials of a requesting principal between server processes. In other words, if you invoke a method from your client process to a business object in a server process, that method is executed in the server under your credentials as the requesting principal. If the business object invokes a method on another business object on a different server, you probably want that downstream method to also execute under your credentials. We call the stream of method requests a method-cascade, and the process of transferring your credentials to the down-stream method credentials-delegation, or just delegation for short. Delegation can take on several forms. The two most common forms are the following:
Component Broker supports simple delegation. Your delegation policies can have a profound effect on authorization. In fact, your authorization policies and delegation policies can be strongly coupled, depending on what you are trying to achieve. Consider the case where a client invokes a method on a business object (BO1) in the application server (S1). Access to object BO1 is controlled by the authority (the set of permissions) granted to the client principal Pc. Now, consider the case where the object BO1 invokes a method on an object (BO2) in another server (S2). If delegation is enabled in server S1, then access to object BO2 is also controlled by the authority granted to the client principal Pc, as shown in the figure below. Figure 3 Delegation enabled in server S1 However, if delegation is disabled in server S1, then access to object BO2 is controlled by the authority granted to the principal (Ps1) for server S1, as shown in the figure below. Figure 4 Delegation disabled in server S1 So, if client principal Pc has been granted access to object BO2, but server principal Ps1 has not, the effect of delegation in server S1 is as follows:
Likewise, if the client application (with principal Pc) invoked a method on object BO2 directly, it would be allowed. Conversely, if principal Pc has been granted access to BO2, but principal Ps1 has not, the effect of delegation in server S1 is as follows:
Likewise, if the client application (with principal Pc) invoked a method on object BO2 directly, it would not be allowed. The value in this is that you can protect object BO2, for example, so that it can only be accessed by applications that you know you can trust. For example, if you have audited applications and know they can be trusted to handle the information retrieved from object BO2, you can do the following:
Credentials MappingBusiness objects in Component Broker application servers normally acquire their persistence from a data system; either on the local host, or more likely on a remote host; for example, CICS or DB2 on S/390. The Component Broker runtime (specifically the application adaptor to which the object is configured) is responsible for establishing the authenticity of any requests made on the data system for that object's persistent data. To enable this, you define a credential mapping between the Component Broker security credentials and those of an entity in the data system's security mechanism. When a business object in a Component Broker application server calls a method that accesses the backing data system, the credential mapping is used to authenticate and authorize the Component Broker credentials to the data system's security mechanism. In some cases, an application uses several backing data systems with different security mechanisms. Therefore, credential mapping can be used to map from one Component Broker principal to multiple different data system entities. You can configure an application server to provide the following types of credential mapping:
Multiple LoginsAs described in CORBA Security Service Overview, CB provides APIs for programmatically logging-in any principal of your choice. Using the PrincipalAuthenticator, or the LoginHelper, you can form a Credentials object for the principal that you authenticate. The Credentials object represents the authenticity of the principle. You can invoke the authenticate (or request_login) method multiple times, each for a different principal, and receive in return a distinct Credentials object for each of these principals. Later, you can use the set_credentials method on the SecurityCurrent to set any of these Credentials in the current security context -- for instance, to establish the principal under whose authority you want to invoke a particular method. Fine-Grained AuthorizationAuthorization controls access to business objects in application servers, by testing that the requesting principal has been granted the required permission to access the requested method on the target object. By default an application server has a coarse level of authorization, which means that any authenticated principal can access any method on any business object in the server. You can set a fine level of authorization on an application server, which means that an authenticated principal must have been granted special permission to access a method on a business object. To grant permissions to a principal, you create access control entries within access control lists for objects. Enabling a fine level of authorizationThe Component Broker authorization services enable you to control access to individual methods on business objects in application servers. The Component Broker authorization services are based on the IBM SecureWay Policy Director authorization services, so a fine level of authorization can be enabled only if the IBM SecureWay PolicyDirector has been installed in your Component Broker network. Installation of the IBM SecureWay PolicyDirector is described in the Component Broker Planning, Performance, and Installation Guide. The IBM SecureWay PolicyDirector gives a fine level of access control for applications (including Web-based applications and resources) without requiring any modifications to existing applications. It provides the authorization repository and administration tools for you to enable a fine level of authorization, as follows:
The Component Broker runtime controls access to business objects in an application server by testing whether a requesting principal has been granted the required permission to access the requested method on the target object.
The permissions (for that object) granted to the principal are compared to the permission required by the method they are invoking. If the principal has been granted the required permission, then the request is allowed to proceed. If not, the request is rejected with a NO_PERMISSION standard exception. Component Broker introduces six standard permissions:
Note: In all of the cases above where prefix values on a method name determine its required permission, the prefix is case-insensitive. These permissions are assigned automatically by Component Broker and can not be changed by end-users or administrators. Access control lists for objectsAn access control list (ACL) grants permissions to one or more principals and groups of principals. You can associate an ACL with one or more objects in the protected object space, to apply the same granted permissions in the ACL to all those objects. When associated with an object in the protected object space, the granted permissions in the ACL determine whether a principal can access that object. Each ACL is composed of one or more access control entries (more usually referred to as ACL entries). An ACL entry grants one or more permissions to a specific principal or group of principals. You can create ACL entries using the authorization management console. (IBM Policy Director also provides command line interfaces that allow you to create access control policies via shell scripts.) ACL entry typesYou assign each ACL entry one of the following ACL entry types, which defines the type of principal that uses the ACL entry:
Use of ACL entry typesThe ACL entry types are used as described below:
Note: Component Broker does not currently allow access to any method on any object in a secure server to unauthenticated users, irrespective of whether you have included the unauthenticated entry type in the ACL for objects within that server. The protected object spaceAn ACL can only be associated with a Component Broker object if you have created an entry for that object in the protected object space (POS). (You do this by registering the object in the authorization server of the IBM PolicyDirector.) The protected object space lists all of the objects to which ACLs can be assigned. In fact, individual Component Broker objects are not listed in the protected object space; instead, it registers the object types and their methods. POS entries consist of a hierarchical name composed of a module name (if any), other nested module names (if any), an interface name, and the method name. All of this is prefixed with the standard root path of /WebSphere/Components/CORBA. So a typical POS entry looks like the following:
An access control list (ACL) can be associated with any position within this hierarchical name, although ACLs are normally assigned at (or above) the interface name level. Note, the POS entries do not identify individual object instances, but rather their types. Consequently, authorization policies are set against objects types; the same policy applies to all objects of that type, regardless of which server the actual instance is created in. During runtime, the authorization service looks up authorization policies for application objects based on the target object's principal interface name, fully qualified by its modules and the standard root path. You should set authorization policies against these objects in the protected object space. Setting authorizations on classes and using ACL inheritanceFor an object in the protected object space, the entire object path all the way down to the method is registered. Therefore, you can choose to set ACLs on higher-level containers, such as the module or interface (object classes), or on methods. You are recommended to set ACLs on higher-level containers and let ACL inheritance work for you. Access is still controlled to object methods, based on the ACLs that the method inherits from its parent container object. This reaches a broader set of things in the POS tree and therefore reduces your administrative burden, and it is also less prone to misunderstanding. Each object in the tree inherits the ACLs of the object above it in the tree, unless specifically superseded by associating another ACL with the subordinate object. In this way, you do not have to introduce an ACL for every object that you register in the POS. In fact, you don't even have to register every object in a secure server in the POS. Any object not assigned a specific ACL, or not registered in the POS, inherits the authorization policy of the object above it in the POS tree. If you have not associated an ACL with any object in the path to a specific object, then that object inherits the default WebSphere root ACL. The default WebSphere root ACLThe default WebSphere root ACL grants the full set of WebSphere permissions to any authenticated users. This achieves, in effect, the same authorization enabled in previous releases of Component Broker (a coarse level of authorization). This effect can be overridden for specific objects in the protected object space by associating other ACLs with objects. AuditingAuditing in CB is accomplished primarily through the use of DCE authentication service and the PolicyDirector authorization service. Administration (System Management)Administering the CB security system is performed with a combination of administration tools provided by the underlying security services, and CB's own system management facilities. Users are administered using DCE's user registry tools -- dcecp or DCE Director. In addition, you can administer these same accounts through the PolicyDirector Intraverse administration console. Mapped credentials are administered using the PolicyDirector Global Sign-On (GSO) administration tool. Authorization policies are administered using the PolicyDirector Intravers administration console. Protected objects are registered with the Intraverse server using a set of batch utilities provided with CB. Server certificates are administered with your favorite X.509v3 conforming PKI tool, and stored in the server's keyring using the GSKit Keyman administration tool provided with CB. Basic security policies, including enabling security within individual server processes, specifying the level of message protection needed, and location of keyring and keytab files is performed through the CB system management facilities. Internet, Intranet, Extranet Access
Firewalls and DMZsComponent Broker uses OMG's CORBA standard IIOP protocol for communication between clients and servers, and between servers and other servers. Typically the IIOP protocol will dynamically assign ports to any new servers as they are started. However, doing so creates a problem when you want to direct this IIOP traffic through a firewall. The dynamicity of port values is un-bounded -- leading you to potentially have to open all ports to a given host. CB reduces the problem of firewall configuration by allowing you to assign specific port values to each application server. Whenever CB starts a server configured with a fixed port value, it will always assign that port value to that server. You can then configure your firewall to only allow traffic on that host to that port. In addition, you must also allow traffic to the ports (1-each) that the location daemon and bootstrap service are listening to. Finally, if you have configured these servers to also accept SSL based traffic (see SSL based authentication), then you will have to also authorize the SSL port for each of your application servers, and the location daemon itself. Servlet SupportCB can be accessed from Servlets hosted in the WebSphere Application Server Standard Edition or Advanced Edition JSP/Servlet engine. Servlets can access WAS EE through the use of the ServletLoginHelper provided as a sample with this JSP/Servlet engine. Reference
Component Broker, System Administration Guide This information is provided by IBM
Corporation © Copyright IBM Corporation 1999-2000
|
|
Rational Unified
Process |