1. Technical Field
The present invention is directed to a method and apparatus for preventing rogue implementations of a security sensitive class interface. More specifically, the present invention provides a mechanism for validating instantiated credentials in a server runtime environment to verify that the credential was instantiated by the server runtime environment.
2. Description of Related Art
One main purpose of an object oriented programming language interface, such as a Java interface, is to act as a contract that determines what method signatures a class must implement. When a class of this interface type is instantiated, the interface can be used as a way to pass the instance of the class, i.e. an object, into and out of methods with the runtime environment or to access methods on the instance of the class. The use of the interface helps to prevent the user of the interface from having to have knowledge of the instantiated object. Typically, the interface is a desirable feature in object oriented programming languages such as Java.
However, there are times when it is necessary to ensure that instantiated objects that implement an interface can be trusted. In the way of explanation of the use of the terms “implementation” and “instantiated object” or “instantiation”, an “implementation” of an interface is a class that contains those methods defined by the interface and the implementation of those methods while an “instantiation” of this implemented class refers to a real object in the runtime environment that represents the implementation.
Trusting an object's implementation of an interface is typically done by securing the class loading environment so that any rogue implementations of the interface cannot be loaded in the process space. However, with the advent of web application servers, web applications run side-by-side with other web applications within the same Java process. In such an environment, the concern for in-process security is increasing and securing the class loading environment is not by itself a sufficient mechanism for ensuring that object implementations of an interface have not been impersonated and thus may be trusted.
To address this issue, some technologies, such as Java 2 Security, have been provided to prevent access to methods. However, this implies that the object implementation of the interface be preserved or trusted. For example, one can put a Java2 Security permission check at the beginning of a method within an implementation. This allows only those processes with permission to access the method to be able to actually invoke the method. This can only prevent access to methods when the Java 2 Permission checks are defined in a method within the implementation. If someone overrides the implementation, then these checks are no longer there. Thus, a problem arises in that there is no known way to prevent a person from implementing the interface and passing an impersonated object through the runtime as though it was the actual runtime object.
This is especially a problem with security-sensitive classes that are used to handle private or secure information. For example, in the security runtime environment of an application server, a credential is a class which contains very sensitive information about a user of the system. The credential can be used to grant a user access to an application resource, such as a banking application or other application which is to remain secure. In such an application, it is vital that a credential be trusted completely.
Typically, a credential is an object implementation of an interface. There may be multiple types of the credential for different authentication mechanisms. For methods that are common to all the types of credentials, it is desirable to reference the credentials using the same interface. The danger resides in having someone implement their own credential, i.e. a rogue credential not generated by the server runtime environment, which meets all the requirements of the credential interface.
Therefore it would be beneficial to have an apparatus and method that prevents rogue implementations of a security sensitive class interface from being used with a server runtime environment to gain access to secure resources. Moreover, it would be beneficial to have an apparatus and method that can be used to validate that an object implementation of an interface belongs to the server runtime and is not an impersonation by a rogue application.
USPTO Backgrounds
USPTO Backgrounds