Abstract: Complexity is reduced and performance is improved when enforcing security restrictions on the execution of program code in a runtime environment. Units of executable code, such as methods or functions, are classified by “security level.” Code units belonging to a “trusted” security level may call any other code unit in the runtime environment, but other security levels are restricted in the code units they can call. Code units may also have “instance permissions” to allow them to have permission to call other individually-specified code units that they would normally be precluded from calling, due to their security level. The security level scheme described herein reduces the complexity of establishing permissions with respect to different code units in the runtime environment. This security level scheme also improves runtime performance by making it unnecessary to check individually-defined permissions in many cases.

Abstract: A first data processing system, which includes a first cryptographic device, is communicatively coupled with a second data processing system, which includes a second cryptographic device. The cryptographic devices then mutually authenticate themselves. The first cryptographic device stores a private key of a first asymmetric cryptographic key pair and a public key of a second asymmetric cryptographic key pair that is associated with the second data processing system. The second cryptographic device stores a private key of the second asymmetric cryptographic key pair and a public key of the first asymmetric cryptographic key pair that is associated with the first data processing system.

Abstract: A cluster system is treated as a set of resource groups, each resource group including a highly available application and the resources upon which it depends. A resource group may have between 2 and M data processing systems, where M is small relative to the cluster size N of the total cluster. Configuration and status information for the resource group is fully replicated only on those data processing systems which are members of the resource group. A configuration object/database record for the resource group has an associated owner list identifying the data processing systems which are members of the resource group and which may therefore manage the application.

Abstract: A cluster system is treated as a set of resource groups, each resource group including a highly available application and the resources upon which it depends. A resource group may have between 2 and M data processing systems, where M is small relative to the cluster size N of the total cluster. Configuration and status information for the resource group is fully replicated only on those data processing systems which are members of the resource group. A configuration object/database record for the resource group has an associated owner list identifying the data processing systems which are members of the resource group and which may therefore manage the application.

Abstract: An approach to handling integrated security roles is presented. An upstream application includes one or more role-mapping requirements that correspond to an upstream security role and a downstream security role. The upstream security role is expanded by adding an upstream security role identifier in a downstream application's role-mapping table or by adding upstream user-to-role mappings to a downstream application's role-mapping table. When an upstream security role is expanded, a user assigned to the upstream security role automatically has access to role-mapped downstream applications.

Abstract: A method for integrated security roles is presented. An upstream application includes one or more role-mapping requirements that correspond to an upstream security role and a downstream security role. The upstream security role is expanded by adding an upstream security role identifier in a downstream application's role-mapping table or by adding upstream user-to-role mappings to a downstream application's role-mapping table. When an upstream security role is expanded, a user assigned to the upstream security role automatically has access to role-mapped downstream applications.

Abstract: Objects on application servers may be defined into classes which receive different levels of security protection, such as definition of user objects and administrative objects. Domain-wide security may be enforced on administrative objects, which user object security may be configured separately for each application server in a domain. In a CORBA architecture, IOR's for shared objects which are to be secured on a domain-wide basis, such as administrative objects, are provided with tagged components during IOR creation and exporting to a name server. Later, when the IOR is used by a client, the client invokes necessary security measures such as authentication, authorization and transport protection according to the tagged components.

Abstract: Objects on application servers may be defined into classes which receive different levels of security protection, such as definition of user objects and administrative objects. Domain-wide security may be enforced on administrative objects, which user object security may be configured separately for each application server in a domain. In a CORBA architecture, IOR's for shared objects which are to be secured on a domain-wide basis, such as administrative objects, are provided with tagged components during IOR creation and exporting to a name server. Later, when the IOR is used by a client, the client invokes necessary security measures such as authentication, authorization and transport protection according to the tagged components.

Abstract: Run-as credentials delegation using identity assertion is presented. A server receives a request from a client that includes the client's user identifier and password. The server authenticates the client and stores the client's user identifier without the corresponding password in a client credential storage area. The server determines if a run-as command is specified to communicate with a downstream server. If a run-as command is specified, the server retrieves a corresponding run-as identity which identifies whether a client credential type, a server credential type, or a specific identifier credential type should be used in the run-as command. The server retrieves an identified credential corresponding to the identified credential type, and sends the identified credential in an identity assertion token to a downstream server.

Abstract: A cluster system is treated as a set of resource groups, each resource group including an highly available application and the resources upon which it depends. A resource group may have between 2 and M data processing systems, where M is small relative to the cluster size N of the total cluster. Configuration and status information for the resource group is fully replicated only on those data processing systems which are members of the resource group. A configuration object/database record for the resource group has an associated owner list identifying the data processing systems which are members of the resource group and which may therefore manage the application.

Abstract: A data processing system accepts a removable storage media, which becomes electrically engaged with a system unit within the data processing system, after which the removable storage media and the hardware security unit mutually authenticate themselves. The removable storage media stores a private key of a first asymmetric cryptographic key pair and a public key of a second asymmetric cryptographic key pair that is associated with the hardware security unit, and the hardware security unit stores a private key of the second asymmetric cryptographic key pair and a public key of the first asymmetric cryptographic key pair that is associated with the removable storage media. In response to successfully performing the mutual authentication operation between the removable storage media and the hardware security unit, the system unit is enabled to invoke cryptographic functions on the hardware security unit while the removable storage media remains engaged with the system unit.

Abstract: A method and apparatus for preventing rogue implementations of a security-sensitive class interface are provided. With the method and apparatus, a unique identifier (UID) is created by a server process when the server process is started. Anytime the server process, i.e. a server runtime environment, instantiates a new credential object following start-up of the server process, the encrypted UID is placed into a private field within the new credential object. In addition, the UID is encrypted and stored in a private class of the server runtime environment. A verification class is provided within the server runtime environment which includes one or more methods that receive the credential object as a parameter and return true or false as to the validity of the credential object.

Abstract: Systems, methods and media for managing and generating encryption keys are disclosed. In one embodiment, a processor executes encryption key processing computer code to receive requests for keys from an application program. The processor determines whether the requesting application program executes on a node or server that is within the scope of machines authorized to receive the requested keys. If authorized, the processor produces a key map and sends the key map to the application program, enabling the application program to access one or more keys in the key map. The keys are updated automatically according to a specifiable schedule.

Abstract: A method and apparatus for preventing rogue implementations of a security-sensitive class interface are provided. With the method and apparatus, a unique identifier (UID) is created by a server process when the server process is started. Anytime the server process, i.e. a server runtime environment, instantiates a new credential object following start-up of the server process, the encrypted UID is placed into a private field within the new credential object. In addition, the UID is encrypted and stored in a private class of the server runtime environment. A verification class is provided within the server runtime environment which includes one or more methods that receive the credential object as a parameter and return true or false as to the validity of the credential object.

Abstract: A method and apparatus for preventing rogue implementations of a security-sensitive class interface are provided. With the method and apparatus, a unique identifier (UID) is created by a server process when the server process is started. Anytime the server process, i.e. a server runtime environment, instantiates a new credential object following start-up of the server process, the encrypted UID is placed into a private field within the new credential object. In addition, the UID is encrypted and stored in a private class of the server runtime environment. A verification class is provided within the server runtime environment which includes one or more methods that receive the credential object as a parameter and return true or false as to the validity of the credential object.

Abstract: Methods, systems, and computer program products are disclosed for securing access to a service data object that include providing a service data object having an embedded security policy, and enforcing by the object the security policy of the object. Securing access to a service data object may include establishing a trust relationship with a trusted environment, transmitting the object to the trusted environment, and enforcing by the object the security policy of the object in the trusted environment. Securing access to a service data object may include exposing an interface to provide access to the object in dependence upon an authorization policy of the security policy for an authenticated user. Securing access to a service data object may include exposing attributes of the object in dependence upon an authorization policy of the security policy for an authenticated user.

Abstract: A method for assuring event record integrity including registering at least one callback function, the callback function being associated with a first callback function identifier, receiving an event having a second callback function identifier, identifying the callback function based on matching the second callback function identifier to the first callback function identifier, and calling the identified registered callback function to validate authenticity of the event.

Abstract: Embodiments of the present invention address deficiencies of the art in respect to access control and provide a method, system and computer program product for access control management for a collection of heterogeneous application components. In a first embodiment, a data processing system for role-based access control management for multiple heterogeneous application components can include at least one business role descriptor associating a business role with multiple, different application roles for corresponding, disparate application components. The system also can include at least one access policy associating a user with the business role. Finally, the system can include policy deployment logic include program code enabled to process the access policy to assign the user to the different application roles in the disparate application components.

Abstract: Provided is a method for providing Java modularity class loader protection by controlling the visibility of WebSphere, service provider, library and utility code interfaces. Interface access authorization is checked once, during class loading to effectively protect vulnerable programming interfaces, eliminating repeating permission checking during execution. Code in a WebSphere Application server (WAS) computing environment is categorized into a finite number of sets in which one permission zone is assigned to each set and the code in each set runs at the same privilege zone. Each set exposes programming interfaces to provide functional service and code in a particular set can only access code in the same or a lower security zone set. Also provided is a technique for explicitly providing to specific modules in lower security zones access to modules or designated interfaces of modules in higher security zones.

Abstract: Provided is a method for providing Java modularity class loader protection by controlling the visibility of WebSphere, service provider, library and utility code interfaces. Interface access authorization is checked once, during module and class loading to effectively protect vulnerable programming interfaces, eliminating permission checking during execution. Code in a WebSphere Application server (WAS) computing environment is categorized into a finite number of sets in which one permission type is assigned to each set and the code in each set runs at the same privilege zone. Each set exposes programming interfaces to provide functional service and code in a particular set can only access code in the same or a lower security zone set. Also provided is a technique for explicitly providing to specific modules in lower security zones access to modules or designated interfaces of modules in higher security zones.