Abstract: Exposure of sensitive information to users is controlled using a first security token containing user identity and user credentials to represent the user who requests services, and a second security token containing two other identities, one identifying the token issuer and the other identifying the owning process. When requesting services, the token-owning process sends a security token to indicate who is making the request, and uses its key to digitally sign the request. The token-owning process signs the request to indicate that it endorses the request.

Abstract: Exposure of sensitive information to users is controlled using a first security token containing user identity and user credentials to represent the user who requests services, and a second security token containing two other identities, one identifying the token issuer and the other identifying the owning process. When requesting services, the token-owning process sends a security token to indicate who is making the request, and uses its key to digitally sign the request. The token-owning process signs the request to indicate that it endorses the request.

Abstract: A mobile device implements a state machine with full authentication, continuous authentication, and invalidation states. To access the device, the full authentication state requires the user to confirm his or her identity using some robust authentication technique. Upon success, the state machine transitions to the continuous authentication state wherein data samples are captured as the user interacts with the device and compared with stored exemplary fingerprints. Preferably, the state machine enforces a negative identification technique to determine whether the individual currently interacting with the touchscreen is not the user from which the exemplary fingerprints were generated. Upon such negative authentication, the state machine transitions to the invalidation state. In this state, operations (e.g., screen lock) are performed to secure the device against an unauthenticated use.

Abstract: A mechanism is provided for establishing a trust relationship between two products. A resource device receives a registration request from an application device to access a resource on the resource device by an application and users of the application on the application device. The resource device sends a registration response using a redirection uniform resource identifier (URI) provided with the registration request, where the registration response includes an authorization code and a symmetric key in response to authenticating the registration request. The resource device receives an access token request that includes the symmetric key, verifiable authentication data, and the redirection URI. The resource device sends an access token to the application device in response to validating the access token request, where the access token allows for access to the resource on the resource device thereby establishing the trust relationship between the resource device and the application device.

Abstract: Exposure of sensitive information to users is controlled using a first security token containing user identity and user credentials to represent the user who requests services, and a second security token containing two other identities, one identifying the token issuer and the other identifying the owning process. When requesting services, the token-owning process sends a security token to indicate who is making the request, and uses its key to digitally sign the request. The token-owning process signs the request to indicate that it endorses the request.

Abstract: A mechanism is provided for establishing a trust relationship between two products. A resource device receives a registration request from an application device to access a resource on the resource device by an application and users of the application on the application device. The resource device sends a registration response using a redirection uniform resource identifier (URI) provided with the registration request, where the registration response includes an authorization code and a symmetric key in response to authenticating the registration request. The resource device receives an access token request that includes the symmetric key, verifiable authentication data, and the redirection URI. The resource device sends an access token to the application device in response to validating the access token request, where the access token allows for access to the resource on the resource device thereby establishing the trust relationship between the resource device and the application device.

Abstract: Exposure of sensitive information to users is controlled using a first security token containing user identity and user credentials to represent the user who requests services, and a second security token containing two other identities, one identifying the token issuer and the other identifying the owning process. When requesting services, the token-owning process sends a security token to indicate who is making the request, and uses its key to digitally sign the request. The token-owning process signs the request to indicate that it endorses the request.

Abstract: A cloud deployment appliance (or other platform-as-a-service (IPAS) infrastructure software) includes a mechanism to deploy a product as a “shared service” to the cloud, as well as to enable the product to establish a trust relationship between itself and the appliance or IPAS. The mechanism further enables multiple products deployed to the cloud to form trust relationships with each other (despite the fact that each deployment and each product typically, by the nature of the cloud deployment, are intended to be isolated from one another). In addition, once deployed and provisioned into the cloud, a shared service can become part of a single sign-on (SSO) domain automatically. SSO is facilitated using a token-based exchange. Once a product registers with a token service, it can participate in SSO. This approach enables enforcement of consistent access control policy across product boundaries, and without requiring a user to perform any configuration.

Abstract: A cloud deployment appliance includes a mechanism to enable permitted users to move event records reliably from an internal event log of the appliance to a data store located external to the appliance while ensuring the integrity of event records. The mechanism ensures that the event records are not tampered with in storage or during download. Further, the approach ensures that no event records can be removed from the appliance internal storage before being successfully downloaded to the external data store.

Abstract: Exposure of sensitive information to users is controlled using a first security token containing user identity and user credentials to represent the user who requests services, and a second security token containing two other identities, one identifying the token issuer and the other identifying the owning process. When requesting services, the token-owning process sends a security token to indicate who is making the request, and uses its key to digitally sign the request. The token-owning process signs the request to indicate that it endorses the request.

Abstract: A cloud deployment appliance includes a key stored internally and that is used during restore to decrypt encrypted backup images. That key is not available to an administrator of the appliance; instead, the administrator receives a “value” that has been generated externally to the appliance and, in particular, by applying a public key of a public key pair to the key. The value is possessed by the administrator, but it does not expose the key. Upon a given occurrence, such as a disk failure in the appliance, the administrator uses the value to obtain” the key, which is then used to restore an encrypted backup image. The key is obtained by having the administrator provide the value to an entity, e.g., the appliance manufacturer, who then recovers the key for the administrator (by applying the private key of the public key pair).

Abstract: A cloud deployment appliance includes a key stored internally and that is used during restore to decrypt encrypted backup images. That key is not available to an administrator of the appliance; instead, the administrator receives a “value” that has been generated externally to the appliance and, in particular, by applying a public key of a public key pair to the key. The value is possessed by the administrator, but it does not expose the key. Upon a given occurrence, such as a disk failure in the appliance, the administrator uses the value to obtain” the key, which is then used to restore an encrypted backup image. The key is obtained by having the administrator provide the value to an entity, e.g., the appliance manufacturer, who then recovers the key for the administrator (by applying the private key of the public key pair).

Abstract: A cloud deployment appliance includes a mechanism to enable permitted users to move event records reliably from an internal event log of the appliance to a data store located external to the appliance while ensuring the integrity of event records. The mechanism ensures that the event records are not tampered with in storage or during download. Further, the approach ensures that no event records can be removed from the appliance internal storage before being successfully downloaded to the external data store.

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

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 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 data processing method 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 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.