[xacml] J2SE Use Cases

[Sekhar Vajjhala - Sun Microsystems <sekhar.vajjhala@sun.com>]

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.