[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] J2SE Use Cases
Attached is the J2SE Use Case. I did not have time to complete it by COB Friday. -- Sekhar
XACML Use Cases J2SE (Java 2 Standard Edition) Author: Sekhar Vajjhala Date : Dec 17, 2001 1. Introduction This note contains the use cases for J2SE (Java 2 Standard Edition). that is being submitted to the XACML Policy Model Sub Committee. J2SE security architecture allows security policy for an application to be configured external to a J2SE application. J2SE architecture allows different security policy providers to be plugged into the J2SE platform. The policy language depends upon the J2SE policy policy ( for e.g. XACML). The rest of this note describes the issues and requirements that a J2SE XACML policy provider may impose on XACML policy language. Unlike the policy language which depends upon the policy provider, the contract between the policy provider and the J2SE platform is well specified. 2. Use Cases Two use cases are considered for use of XACML in J2SE platform. 2.1 Use Case 1 Note: In this use case, SAML is not used. A J2SE application is configured to use an XACML policy provider. The XACML policy provider implementation allows the configuration of all the J2SE permissions but using the XACML syntax. In this scenario, J2SE XACML policy provider acts as a PDP and the JRE (Java Runtime Environment) acts as a PEP. The calls between JRE and the J2SE XACML policy provider are made according to well defined contract between the two. In short, this use case uses XACML syntax only for expression of security policies but SAML is not used. This use case imposes requirements on XACML as noted in the section "Requirements" of this note. 2.2 Use Case 2 Note: In this case, SAML is used. A J2SE application is configured to use a J2SE policy provider which acts as a front end to a PDP. The J2SE policy provider implements the J2SE Policy class as required by the J2SE platform. So J2SE policy provider provides a policy decision interface for JRE and acts as a translator which uses uses SAML interactions (which include SAML authorization queries) to interact with the PDP. The advantage of this use model is it allows third party XACML PDPs to be integrated into the J2SE platform. This use case imposes requirements on XACML and SAML as noted in the "Requirements" section of this document. 3. Access Control Model in J2SE This section contains a brief summary of the access control model in J2SE and is intended for those on the XACML policy model sub committee who might not be familiar with J2SE. Access control in J2SE is based on granting of permissions. A permission represents access to a system resource. For a resource access to be allowed, the corresponding permission must be explicitly granted. ***** NOTE: J2SE supports only positive permissions ***** A J2SE permission consists of a. target ("resource" in XACML terminology ) b. action (optional) c. permission_class_name which represents the permission being granted. d. the signer of of a permission (optional) An example of a permission is permission java.io.FilePermission "/tmp/*", "read,write"; which grants java.io.FilePermission for reading and writing all files in /tmp/*. J2SE permissions can be granted based on a. where the code originated from (URL) and/or the certificate of the signer of the code. The two together are referred to as CodeSource. b. principal which is an authenticated identity. c. both principal and a CodeSource. 4. Examples of J2SE permissions This section contains several short examples of J2SE policies which grant permissions. The syntax used is that of the default policy provider for the J2SE platform. Each permission entry begins with the keyword "grant" as shown below: grant [SignedBy "signer_names"] [, CodeBase "URL"] [, Principal [principal_class_name] "principal_name"] [, Principal [principal_class_name] "principal_name"] ... { permission permission_class_name [ "target_name" ] [, "action"] [, SignedBy "signer_names"]; permission ... } The contents in [...] are optional. For a more detailed information on the default policy syntax, go to: http://java.sun.com/j2se/1.4/docs/guide/security/spec/security-spec.doc3.html#20131 4.1 Permission Example 1 Code signed by a principal "Duke" is granted read/write access to all files in /tmp. The default policy file syntax for expressing the above policy file is grant signedBy "Duke" { permission java.io.FilePermission "/tmp/*", "read,write"; }; 4.2 Permission Example 2 Grant everyone the following permissions. grant { permission java.util.PropertyPermission "java.vendor"; }; 4.3 Permission Example 3 The following represents a principal-based entry. grant principal javax.security.auth.x500.X500Principal "cn=Alice" { permission java.io.FilePermission "/home/Alice", "read, write"; }; This permits any code executing as the X500Principal, "Alice", permission to read and write to "/home/Alice". 4.4 Permission Example 4 The following example shows a grant statement with both codesource and principal information. grant codebase "http://www.games.com", signedBy "Duke", principal javax.security.auth.x500.X500Principal "cn=Alice" { permission java.io.FilePermission "/tmp/games", "read, write"; }; This allows code downloaded from "www.games.com", signed by "Duke", and executed by "Alice", has permissions to read and write into the "/tmp/games" directory. 4.5 Permission Example 5 The following example shows an example of a signed permission entry. grant { permission Foo "foobar", signedBy "Alice" } The permission of type foo is granted if Foo.class implementation has been signed by the "Alice". This is designed to prevent spoofing of permission classes which are not resident in the JVM but are instead downloaded from a remote site. 5. Policy evaluation and Policy Class A J2SE policy provider is required to implement the abstract class java.security.Policy class. There is also a javax.security.auth.Policy specified by JAAS. But since issues with respect to XACML are similar, only java.security.Policy class is used in the remainder of this note. The methods in java.security.Policy class perform policy evaluation are invoked by the JRE (Java Runtime Environment) which performs policy enforcement. The methods are (method signatures vary among J2SE releases but the concept remains the same ). a. PermissionCollection getPermission(CodeSource codesource) This method must be implemented by a J2SE policy provider. This method evaluates the global policy and returns a PermissionCollection object specifying the set of permissions allowed for the code from the specified codesource. The key point here is that the result of policy evaluation by this method is a mini policy consisting of a set of permissions for the codesource and not a boolean value. This is referred to as "Partial evaluation". JRE maintains a mapping of class ----> protectiondomain ----> permissions This mapping along with other attributes such as principal associated with a thread is used by JRE to perform policy enforcement using the stack walk mechanism. (Details have been omitted here) b. boolean implies(ProtectionDomain protectiondomain, Permission permission) This method evaluates the global policy for the permissions granted to the ProtectionDomain and tests whether the permission is granted. 5. Requirements The requirements noted here are derived from the use cases illustrated above. 5.1 Partial Evaluation This requirement is derived from Use Case 2 to support the getPermission() method in the java.security.Policy class. In the current model, a. PEP sends an saml:AuthorzationQuery to the PDP. b. PDP sends a saml:AuthorizationResponse back to the PEP. Both the AuthorizationQuery and AuthorizationResponse will need to be evaluated to ensure that the query/queries and response(s) to ensure that getPermission() call can be supported. 5.2 XACML Requirements 1. Sufficient support to make an efficient evaluation of policy in the getPermission() method possible. 2. XML Schema support for CodeSource. There must be a way to express CodeSource (i.e. URL from where the code originated from and/or the certificates used to sign the code). It has been suggested that one of the existing XACML attributes - environment, resource, principal attributes could be used. Of the three the most logical one seems to be principal attribute. But overloading of a principal attribute for both principals and signers makes the authorization rules less clear. There must be a way in the policy language to express both a signer as well as a principal within a rule. 3. XML Schema Support for signed permissions There must be a way in the language to express signed permissions. A signer for a permission could be considered a resource attribute but probably should be typed.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC