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.