Abstract: A method, system, apparatus, and computer program product is presented for plugging in a standard authorization system in a manner such that legacy applications can use the authorization APIs and backend remote interfaces of a legacy authorization system. When a legacy application makes a call intended for a routine within the legacy authorization system, the call is redirected to make the appropriate calls to the APIs of the standard authorization system.

Abstract: A mechanism that allows enterprise authorities to be informed when security-sensitive decisions or actions have been or are attempting to be made by users of untrusted code executing in the trusted computing base. The mechanism may be implemented as an abstract class that is part of the trusted computing base. The class provides a framework abstract enough to permit multiple possible notifications (e.g., providing an e-mail to a system operator, sending an Simple Network Management Protocol (SNMP) alert, making an entry in an online database, or the like) in the event that a given action is taken by a user of untrusted code. The abstract class may provide a default notification, or the class may be extended to enable an authority to provide its own set of customized notifications.

Abstract: An apparatus and method for managing keystores is implemented. A distributed keystore is established by aggregating individual. The distributed keystore may, be organized in a multi-level structure, which may be associated with an organizational structure of an enterprise, or other predetermined partitioning. Additionally, a centralized management of certificates may be provided, whereby the expiration or revocation of the certificates may be tracked, and expired or revoked certificates may be refreshed. The keystore may be updated in response to one or more update events.

Abstract: A framework for processing signed applets that are distributed over the Internet. Using the framework, an applet that is packaged as a Netscape- or JDK-signed jar file, or as an Internet Explorer-signed cab file, is processed within the same Java runtime environment irrespective of the browser type (i.e. Netscape Communicator, Internet Explorer or JDK) used to execute the applet. When the applet is executed, the framework verifies one or more applet signatures using the same algorithm that was used to sign the applet, verifies the signer(s) of the applet, and stores information about the signers so that they can be honored by a security policy when permissions for the applet are determined.

Abstract: A method is provided for determining an identity of a browser in an Java environment in which an intermediary program masks the browser's identity. The method begins by querying an operating system process table for information identifying the browser. Thereafter, a Java properties table including the information from the process table is set. In response to a request from a calling program (e.g., an applet class) for the browser identity, a getProperty method is then called to retrieve the browser identity from the properties table. The browser identity is then returned to the calling program.

Abstract: An architecture for extending the Java security model to allow a user or administrator to explicitly deny permissions. By itself, the Java 2 security model does not allow additions to the collections of policy permissions after they have been loaded from the Java policy file. The inventive architecture allows Java applets and applications to dynamically prompt the user to deny a permission that does not exist in the Java policy file. If the user denies the permission, the present invention denies the permission for the ProtectionDomain to which the class asking for the permission belongs. Attributes for the denied permission may be set during runtime and saved across browser sessions.

Abstract: An architecture for extending the Java security model to allow a user or administrator to grant permissions dynamically. By itself, the Java 2 security model does not allow additions to the collections of policy permissions after they have been loaded from the Java policy file. The inventive architecture allows Java applets and applications to dynamically prompt the user to grant a permission that does not exist in the Java policy file. If the user grants the permission, the present invention grants the permission for the ProtectionDomain to which the class asking for the permission belongs. Attributes for the dynamic permission may be set during runtime and saved across browser sessions.

Abstract: A test/run program receives as input a list of identifiers for source pages referencing applets to be tested or run. The test/run program creates an array of the identifiers, together with parameters for each identifier, web browser to run the test under, and a number of times the source page is to be reloaded and the applets re-run. For each source page, and for each reload of a given source page, the test/run program starts the specified web browser process, loads the designated source page, and starts a fresh runtime environment for the applet. Support for a test class within the test/run program allows the applets to write success, failure, or informational results to an output file and to exit the web browser process when complete. Where a native implementation of the test class is employed, special security permissions need not be specified and the test/run program need not necessarily be run locally.

Abstract: An apparatus and method for managing keystores is implemented. A distributed keystore is established by aggregating individual. The distributed keystore may, be organized in a multi-level structure, which may be associated with an organizational structure of an enterprise, or other predetermined partitioning. Additionally, a centralized management of certificates may be provided, whereby the expiration or revocation of the certificates may be tracked, and expired or revoked certificates may be refreshed. The keystore may be updated in response to one or more update events.