GB2365561A

GB2365561A - Conditional access control

Info

Publication number: GB2365561A
Application number: GB0030228A
Authority: GB
Inventors: Richard H Guski; Donna N Dillenberger; Walter B Farrell; Amir Herzberg; Lawrence Koved; Anthony J Nadalin; Duane F Reller; John H Shin; Anat S Shmueli; Thomas J Szczygielski; John M Thompson; Joseph A Williams
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-12-14
Filing date: 2000-12-12
Publication date: 2002-02-20
Anticipated expiration: 2020-12-12
Also published as: GB2365561B; GB0030228D0

Abstract

In a multi-user application environment with Java, both codesource access checking and verification of the user who is executing code are employed for access checking. An end user uses a Web browser to access a Web server. An execution thread is established for an end user. The HTTP page and function requested by the user cause the Web application server to invoke a Java Virtual Machine (JVM) which in turn invokes a requested Java servlet. When the Secure Class Loader loads a Java class into the JVM, the code base Uniform URL and the Digital Certificate that was used to sign the class are used by the Secure Class Loader to create the codesource Java object. The JVM includes a Java Security Manager (JSM) class that invokes classes that invoke an underlying system security manager. Conditional access checking includes the capability to control access to resources based on the user and on the Java servlet classes being executed. If the codesource indicated by a Conditional Access List matches the codesource specified in the profile, the system security manager will allow access.

Description

<Desc/Clms Page number 1> CONDITIONAL ACCESS CONTROL This invention relates to resource access control security checking, and, more particularly, to conditional access checking for authorisation to resources in multi-user application environments.

The use of Java (Java is a registered trademark of Sun Microsystems Inc.) software in an Internet environment is well known, particularly Java's use in web browsers to run Java "applets". Also, well known is the use of Java code running on servers, often referred to as "servlets". Typically, multiple applets or servlets run concurrently in a single Java Virtual Machine (JVM). Security of trusted Java code (applets, servlets, or standalone Java applications) is not a concern. However, security of Java code originating from a remote host, untrusted vendor or purveyor of Java code, is of considerable concern. For example, when applets are downloaded from an open network for execution on an individual workstation, the workstation is vulnerable to being compromised if access controls are not placed on workstation resources.

The Java Virtual Machine has incorporated a number of safety features: a bytecode verifier to ensure type safety of Java classes loaded into the JVM, a SecurityManager to restrict resource access, and a C1assLoader to safely load Java code into the JVM. The SecurityManager is used to allow or deny access to system resources, such as files, sockets, and other Java runtime resources. Access is specified via access control lists.

Code signing (i.e., digital signatures) is employed to identify the originator and/or purveyor of the Java code. After the digital signature on the Java code is verified, a Codesource is constructed. The CodeSource is the tuple (CodeBase Uniform Resource Locator (URL), digital signatures). That is, based on the tuple {from where the Java code was loaded, the digital signatures on the Java code}, the Securitymanager checks its authorisation table to determine whether the code is authorised to access restricted resources. However, in the current version of Java, the user (or principle) executing the code is not considered in the authorisation decision.

In a multi-user application environment with the implementation of Java on, for example, an IBM OS/390 operating system, the aforementioned security checking techniques may not be sufficient. Java applets when used

within server applications, again such as on 0S/390, are referred to herein as "servlets". Such applications typically support multiple concurrent users and the Java servlets act upon information that is owned by individual users. Both codesource access checking and verification of the user who is executing code are employed for access checking; such would be classified as a type of combinatorial access checking as multiple conditions must be satisfied before access is granted. This is particularly advantageous in a multi-user application environment. The present invention could also support applications that expect only codesource access checking by granting a11 users access to a Java resource, thereby eliminating a requirement that separate security software be provided for systems not requiring this additional level of security.

The present invention provides, in a first aspect, a method of controlling access of computer users based on computer code to resources on a computer system comprising: receiving a request from a requester for the computer code, the computer code being executable code whereby the computer code when run by the computer system will attempt to access the computer system; verifying identification at the computer system of the requester of the computer code; verifying a codesource of the computer code at the computer system; and allowing the computer code access to resources on the computer system when said identification of said requester is verified and authorised and said codesource is verified and authorised.

Preferably said verifying identification comprises verifying identification of the requester when the computer code attempts to access the computer system; and said verifying said codesource comprises verifying said codesource when said identification of said requester is verified.

Preferably, the computer system comprises a local computer system and the computer code originally resides at a remote computer system. Preferably, said receiving comprises: receiving the computer code at a local computer system from a remote computer system, in response to said request.

Preferably, said generating a request comprises generating a request over an Internet.

Preferably, the computer code comprises Java code.

Preferably, the Java code comprises server code.

Preferably, the computer system comprises an operating system capable of supporting multi-user applications.

Preferably, at least one of said steps of verifying comprises verifying with the computer system security manager.

Preferably, the computer system security manager comprises a Resource Access Control Facility (RACF).

Preferably, said verifying said codesource comprises: verifying a source of origin of the computer code; and verifying a digital signature associated with the computer code.

Preferably, said codesource comprises a list of permissions related to execution of the computer code by the computer system.

Preferably, said codesource digital signature is cryptographically encoded.

Preferably, said verifying identification of the requester comprises comparing information indicative of the requester to an access list. Preferably, said verifying identification of the source of origin of the computer code comprises comparing information indicative of the source of origin of the computer code to an access list.

In a second aspect, the present invention provides a network environment comprising: a computer system having stored computer code, "said computer code being executable code whereby said computer code when run by a computer system will attempt to access resources on the computer system; a client for generating a request from a requester for said computer code; an authorisation system for processing said computer code to verify identification of the requester of said computer code and to verify a codesource of said computer code, said authorisation system allowing said computer code access to said resources on the computer system when the identification of the requester is verified and said codesource is verified.

Preferably, said computer system comprises a local computer system and said computer code originally resides at a remote computer system.

Preferably, said client comprises a Web Browse, whereby said request comprises a request over an Internet.

Preferably, said computer code comprises Java code.

Preferably, said server includes a Java virtual machine to invoke said Java code.

Preferably, the Java code comprises server application code or middleware code.

Preferably, said computer system comprises an operating system capable of supporting multi-user applications.

Preferably, said authorisation system comprises a computer system security manager.

Preferably, the computer system security manager comprises a Resource Access Control Facility (RACE).

Preferably, said codesource includes information indicative of a source of origin of the computer code.

Preferably, said codesource comprises a list of permissions related to execution of said computer code by said computer system.

Preferably, said codesource digital signature is cryptographically encoded.

In a third aspect, the present invention provides a computer program comprising computer program instructions to, when loaded into a computer system and executed, cause the computer system to perform the steps of a method according to the first aspect.

In an exemplary embodiment of the invention, an end user uses a Web browser to access (via the Internet) a Web server executing on, for example an IBM 0S/390 operating system. Web server initialisation and control logic establishes an individual execution thread for the particular end user.

Associated with the individual user thread is an authenticated security context for the user. The result is any code executing under this thread will be associated with this particular user for access control checking purposes. The HTTP page and function requested by the user cause the web application server to invoke a Java Virtual Machine (JVM) which in turn invokes a requested Java servlet. Java servlets are loaded in the form of Java "classes" by a Java Secure Class Loader. When the Secure Class Loader loads a Java class into the JVM, the code base Internet Uniform Resource Locator (URL) and the Digital Certificate that was used to sign the class are used by the Secure Class Loader to create the codesource for the Java class. This is how the identity of servlet code is established.

The JVM includes a Java Security Manager (JSM) class that invokes classes that invoke an underlying system security manager. Conditional access checking includes the capability to control access to resources based on the Java servlet classes) being executed as identified by associated codesources. Conditional Access Checking is initiated by the system security manager when a Conditional Access List has been associated with a particular resource through the execution of a security manager administration function. When such a resource is accessed and the Conditional Access List indicates that a codesource-identified Java servlet class is to be considered in determining whether to allow access, the system security manager will verify that the executing codesource matches the codesource specified in the Conditional Access List. If this verification is successful, then the system security manager will allow access to the resource.

A preferred embodiment of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a block diagram of a Java servlet-processing environment of a preferred embodiment of the present invention; Figure 2 is a block diagram illustrating a relationship between the Java Virtual Machine (JVM) and Java servlets, of a preferred embodiment of the present invention; Figure 3 is a block diagram illustrating resources that may be accessed by a Java servlet class object in a JVM environment, of a preferred embodiment of the present invention;

Figure 4A is a block diagram illustrating flow of control relating to resource access control checking with a Java object resource, of a preferred embodiment of the present invention; and Figure 4B is a block diagram illustrating flow of control relating to resource access control checking with an OS/390 DASD data set, of a preferred embodiment of the present invention.

Referring to Figure 1, a Java servlet-processing environment in accordance with an exemplary embodiment of the present invention is generally shown at 10. An end user 12 is using a Web browser (client) 14, such as Netscape Navigator or Microsoft Internet Explorer, to access (via the Internet, not shown) a HTTP server 16 executing on, for example an IBM OS/390 operating system 17. It will be appreciated by one skilled in the art that any system capable of supporting multi-user applications may be employed, whereby the choice of embodiments is not limited to the IBM OS/390 operating system environment described in this exemplary embodiment nor is it limited to a web browser client. Web server initialisation and control logic 18 establishes an individual execution thread 20 for the particular end user 12. Associated with the individual execution thread 20 is an authenticated security context 22 for user 12. The result is any code executing under this thread 20 will be associated with this particular user 12 for resource access control checking purposes. The HTTP page and function requested by the user 12 causes the Web application server 24 to invoke a Java Virtual Machine (JVM) 26 which in turn invokes a requested Java servlet 28 (in a security domain). Within OS/390, the JVM 26 is implemented via support shipped with the OS/390 base operating system as the Java Development Kit (JDK). The JVM 26 and servlets running within it may be invoked via JDK function from a variety of environments running on the OS/390 operating system platform. As end-users invoke business function implemented with Java servlets (server application or middleware code), the servlets, under the control of the JVM 26 and the underlying operating system, will access business information, programs and computing resources. Resource access controls of the present invention determine whether the code requested by the user, considered in combination with the identity of the user, is allowed to access secured resources.

A Java servlet can be designed and written to work alone to address a very specific functional requirement, or multiple independent Java servlets can be implemented in aggregate as individual components of a larger Java function. Such components can be designed so as to be reusable in differing

combinations as "building blocks" of other larger Java functions. Either way, Java servlets can be stored locally as part of an execution library or they can be dynamically located and loaded from "the network" by the JVM 26 "on demand" of some mainline Java servlet.

In order to provide protection against the inadvertent invocation of "Trojan horse" code in the distributed processing environment that is possible with Java, the JVM contains a function that allows servlets to be cryptographically signed by the author and subsequently validated when the servlet is used. Cryptographic signatures can be utilized by the users of Java servlets to verify that such servlets have originated from only the expected author and that the servlets have not been modified, accidentally or otherwise, since they were signed.

In addition to the signature of the servlet code, the codesource will also be associated with a list of "permissions" (key), to resources at the execution location, that the servlet will require (from the perspective of the author of the servlet) in order to accomplish its designed function. When the servlet is loaded by the JVM 26, this so-called "codesource" is processed and the origin and integrity of the servlet are validated. When multiple servlets with differing codesources (and permission lists) are aggravated into a larger Java function, the permission lists are effectively merged into an aggregate permission list, and all component servlets are validated for origin and integrity.

Java codesource signatures provide a way to effectively "identify" a particular Java servlet with an identity that consists of a cryptographic binding of the servlet author's identity, the cryptographic signature of the code itself, and any "permissions" that the servlet will need to execute and complete its intended function.

Ref erring .to Figure 2, a relationship between the Java Virtual Machine (JVM) 26 and Java servlets that execute within it is generally shown. An initial request 30 for servlet execution can come from various sources such as the WebSphere Web Server 16 (Figure 1). Other such sources include, but are not limited to, a component Broker object oriented class method, a database (e.g., DB2) stored procedure, CICS (IBM general-purpose online transaction processing software) or IMS (hierarchical database management services, data communications services and transaction management services) transaction, or even an 0S/390 batch job, such being readily apparent to one of ordinary skill in the art. In the present

example, the requested servlet 28 has invoked two additional servlets 28a and 28b. The initial servlet 28 and invoked servlet 28a have been loaded from a local servlet library 32 which is maintained by a local installation and presumably can be considered more trustworthy in the eyes of local security management. Servlet 28b, on the other hand, has been loaded from some remote Internet location (remote servlet library 34) via an X.500 Directory Distinguished Name of the servlet object. Trust policy associated with the execution of servlets (both locally and remotely loaded), will dictate whether or not any particular servlet needs to be identified and validated via an associated Java codesource signature. More specifically, Java servlets are loaded in the form of Java "classes" by a Java Secure Class Loader, as is known. When the Secure Class Loader (also known) loads a Java class into the JVM 26, the code base Internet Uniform Resource Locator (URL) and the Digital Certificate that was used to sign the class are used by the Secure Class Loader to create the codesource for the Java class. This process is well known and is described in detail in a paper entitled The Evolution of Java Security, by Koved, Nadalin, Neal, Lawson, IBM Systems Journal, Vol. 37, Num. 3, 1998. This describes how the identity of a servlet is established.

Referring to Figure 3, examples of resources that may be accessed by a Java servlet class object when a servlet executes within an OS/390 JVM environment is generally shown. In a first example, an executing Java servlet class object may access other Java servlet class object(s). In another example, these objects can include other servlet classes and Java classes that engage system resources outside of the JVM 26, such as system Direct Access Storage Device (DASD) storage and printers 36. In still another example, such resources may be owned and/or accessible by the JVM 26 itself or by individual system users or groups as defined and authenticated by a local security manager (authorisation system) 38, such as IBM's Resource Access Control Facility (RACF) on the OS/390. RACF on the 0S/390 presently supports combinatorial access checking for user access to certain OS/390 resources such as data sets in which access is granted if the user is in the access list for the data set and the user is executing a particular program. In an exemplary embodiment of the invention, code in Java is implemented to invoke the services of the 0S/390 Security Server RACE existing combinatorial access control checking function to perform the access checking of the present invention.

Referring to Figure 4A, a flow of control relating to resource access control checking that will occur when a Java servlet attempts to access a

resource is generally shown. The JVM 26 includes a Java Security Manager (JSM) class 40 that invokes "wrapper" classes (not shown) that invoke the underlying system security manager 38 (RACE). The resource that is accessed is another Java servlet class. The access control checking function that occurs in RACY 38 may or may not involve Conditional Resource Access Control checking. Whether or not conditional checking is involved is determined by RACF 38 according to the access control profile access control list (ACL) for the resource. This profile would have been created by the installation Security Administrator if access to the resource is to be controlled (and/or audited). The existence of the Conditional Access List in the RACF profile for the resource indicates that Condition Resource Access Control checking is to occur. The Conditional Access List will indicate the conditions that must exist in order for access to the resource to be allowed. Various environmental conditions may currently be specified in a RACF Conditional Access List. The Conditional Access List preferably includes the specification of one or more Java codesources, which (as described hereinbefore) are cryptographically bound to a particular or particular set of Java servlet class objects. In accordance with an important feature of the invention, conditional access checking includes the capability to control access to resources based on the Java servlet classes) being executed as identified by the associated codesources. When the Conditional Access List indicates that a codesource- identified Java servlet class is to be considered in determining whether to allow access, RACF 38 will verify that the executing codesources matches the codesources specified in the RACE Conditional Access List. If this verification is successful, then RACF 38 will allow access to the resource.

Referring to Figure 4B, another flow of control relating to resource access control checking that will occur when a Java servlet attempts to access a resource is generally shown. Again, the JVM 26 includes a Java Security Manager (JSM) class 40 that invokes "wrapper" classes (not shown) that invoke the underlying system security manager 38 (RACF). The resource, unlike the example provide with reference to Figure 4A, is not a Java object resource being accessed through JVM 26, but rather an OS/390 DASD data set 41. In this example, the Java servlet requests access to the OS/390 data set 41 via the services of OS/390 Data Management component (DFSMS) 42. Data Management component 42 invokes RACF 38 to check the requester's access authority to the data set. RACE 38 references a profile for the data set. Since the profile indicates conditional Access Checking is in effect for the data set and that a particular Java servlet object class or set of classes (as identified by the associated codesources) are

required to be the currently executing process in order for the data set access to be allowed, RACF 28 determines what codesource(s) are in effect, and allows access accordingly.

The present invention can be embodied in the form of computer-implemented processes and apparatus for practising those processes. The present invention can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other computer- readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practising the invention. The present invention can also be embodied in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fibre optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practising the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.

Claims

CLAIMS 1. A method for controlling access of computer users based on computer code to resources on a computer system comprising: receiving a request from a requester for the computer code, the computer code being executable code whereby the computer code when run by the computer system will attempt to access the computer system; verifying identification at the computer system of the requester of the computer code; verifying a codesource of the computer code at the computer system; and allowing the computer code access to resources on the computer system when said identification of said requester is verified and authorised and said codesource is verified and authorised.
2. A method as claimed in claim 1 wherein: said verifying identification comprises verifying identification of the requester when the computer code attempts to access the computer system; and said verifying said codesource comprises verifying said codesource when said identification of said requester is verified.
3. A method as claimed in claim 1 or claim 2 wherein the computer system comprises a local computer system and the computer code originally resides at a remote computer system.
4. A method as claimed in any preceding claim wherein said receiving comprises: receiving the computer code at a local computer system from a remote computer system, in response to said request.
5. A method as claimed in any preceding claim wherein said generating a request comprises generating a request over an Internet.

<Desc/Clms Page number 12>
6. A method as claimed in any preceding claim wherein the computer code comprises Java code.
7. A method as claimed in claim 6 wherein the Java code comprises server code.
8. A method as claimed in any preceding claim wherein the computer system comprises an operating system capable of supporting multi-user applications.
9. A method as claimed in claim 8 wherein at least one of said steps of verifying comprises verifying with the computer system security manager.
10. A method as claimed in claim 9 wherein the computer system security manager comprises a Resource Access Control Facility (RACF).
11. A method as claimed in any preceding claim wherein said verifying said codesource comprises: verifying a source of origin of the computer code; and verifying a digital signature associated with the computer code.
12. A method as claimed in claim 11 wherein said codesource comprises a list of permissions related to execution of the computer code by the computer system.
13. A method as claimed in claim wherein said codesource digital signature is cryptographically encoded.
14. A method as claimed in any preceding claim wherein said verifying identification of the requester comprises comparing information indicative of the requester to an access list.
15. A method as claimed in claim 14 wherein said verifying identification of the source of origin of the computer code comprises comparing information indicative of the source of origin of the computer code to an access list.

<Desc/Clms Page number 13>
16. A network environment comprising: a computer system having stored computer code, said computer code being executable code whereby said computer code when run by a computer system will attempt to access resources on the computer system; a client for generating a request from a requester for said computer code; an authorisation system for processing said computer code to verify identification of the requester of said computer code and to verify a codesource of said computer code, said authorisation system allowing said computer code access to said resources on the computer system when the identification of the requester is verified and said codesource is verified.
17. A network environment as claimed in claim 16 wherein said computer system comprises a local computer system and said computer code originally resides at a remote computer system.
18. A network environment as claimed in claim 17 wherein said client comprises a web Browse, whereby said request comprises a request over an Internet.
19. A network environment as claimed in claim 16 wherein said computer code comprises Java code.
20. A network environment as claimed in claim 19 wherein said server includes a Java Virtual machine to invoke said Java code.
21. A network environment as claimed in claim 19 wherein the Java code comprises server application code or middleware code.
22. A network environment as claimed in any of claims 16 to 21, wherein said computer system comprises an operating system capable of supporting multi-user applications.
23. A network environment as claimed in claim 22 wherein said authorisation system comprises a computer system security manager.

<Desc/Clms Page number 14>
24. A network environment as claimed in claim 23 wherein the computer system security manager comprises a Resource Access Control Facility (RACE).
25. A network environment as claimed in claim 16 wherein said codesource includes information indicative of a source of origin of the computer code.
26. A network environment as claimed in any of claims 16 to 25 wherein said codesource comprises a list of permissions related to execution of said computer code by said computer system.
27. A network environment as claimed in any of claims 16 to 26 wherein said codesource digital signature is cryptographically encoded.
28. A computer program comprising computer program instructions to, when loaded into a computer system and executed, cause the computer system to perform the steps of a method as claimed in any of claims 1 to 15.