XACML J2SE[TM] Platform Policy Profile
XACML J2SE[TM] Platform Policy Profile
Version: 1.28
Updated: 03/07/21 (yy/mm/dd)
Author: Anne Anderson
Previous published version:
http://lists.oasis-open.org/archives/xacml/200207/msg00028.html
Source: /lab/east/info/projects/isrg/xacml/docs/JAVA/SCCS/s.J2SEProposal.html
This document is a proposal for supporting use of OASIS
eXtensible Access Control Markup Language (XACML) Version 1.0 [2] policies with the Java[TM] 2 Platform,
Standard Edition (J2SE[TM] Platform). This proposal is not a
commitment from or endorsement by Sun Microsystems or any Java
Community Process(SM) group, and does not necessarily represent
any official Sun or JCP(SM) position. Comments to the author, Anne Anderson, are
welcomed.
This document assumes the reader is familiar with the syntax
and semantics of XACML. An introduction is available in
A Brief Introduction to XACML [10].
For still more details, see the XACML Specification and schemas
[2,3,4].
This document also assumes the reader is familiar with the
J2SE Policy API and the use of Permissions in J2SE
applications. For more details, see [7].
-
Introduction
-
Proposal
-
New J2SE-Specific DataTypes and Functions
-
New J2SE-Specific DataTypes
-
New J2SE-Specific Functions
-
AttributeIds
-
Existing AttributeIds
-
New J2SE-Specific AttributeIds
-
XACML Policy Provider Implementation
-
Internal Structure
-
PDP Interface Module
-
J2SE-Specific Attribute Finder Module
-
Policy API Support
-
implies
-
getPermissions
-
refresh
-
PolicyFile to XACML Translator
-
Issues and Rationale
-
getPermissions
-
Overlapping Permissions
-
KeyStores
-
Multiple Actions
-
Property Expansion
-
General Expansion
References
Contributors
Appendices
-
Example of a Translated Simple PolicyFile
-
Example of a Translated Full PolicyFile
-
Mappings for Standard J2SE Permission Subclasses
-
Notices
This document contains a proposed profile for supporting use
of OASIS eXtensible Access Control Markup Language (XACML)
Version 1.0 [2] policies for applications
written for the Java[TM] 2 Platform, Standard Edition (J2SE[TM]).
This proposal has the following objectives.
- Allow J2SE applications to obtain the full benefits of XACML policies.
- OASIS Standard policy language, written in XML.
- Ability to reference external attributes, such as time of
day or attribute certificates stored in an LDAP
database.
- Ability to support role based access control.
- Ability to reference distributed policies.
- Allow a shared resource accessed by J2SE and non-J2SE
applications to be controlled using a single standard XACML
policy.
- Fully support the J2SE Policy API.
- Allow J2SE application policy writers to write, manage,
analyze, and debug policies using 3rd-party policy tools that
support XACML.
- Support translation of existing PolicyFile policies into
XACML.
The proposal recommends creation of a J2SE Policy Provider that
accepts XACML policies as its policy input. The Policy Provider
accepts standard XACML policies, but also supports new XACML
extensions to deal with J2SE-specific objects and concepts.
XACML is designed to be extensible, and the proposed extensions
are fully in the spirit of those intended.
The profile defines mappings between certain Java Class
objects and standard XACML Attributes. Such mappings allow Java
applications to use standard XACML policies that protect
resources accessed by multiple applications, not all of which are
written using the Java programming language. These mappings are
as follows:
- requesting ProtectionDomain Principal[] array: XACML
subject-id Attribute with SubjectCategory access-subject
- requesting ProtectionDomain CodeBase URL: XACML subject-id
Attribute with SubjectCategory codebase
- requested Permission: XACML resource-id and action-id
Attributes.
Details of the mappings are described below in the
Existing AttributeIds
Section and in
Appendix 3: Mappings for Standard J2SE Permission
Subclasses.
In order to support the full functionality of the Java Policy
API, the proposal also defines a set of new XACML Attributes and
associated new XACML DataTypes and Functions. These new
Attributes allow XACML policies to refer to Java objects that are
part of the J2SE Policy API. The objects are not translated into
an XACML Request, but are referenced as native Java objects.
These Attributes, DataTypes, and Functions are described in the
New J2SE-Specific DataTypes,
New J2SE-Specific Functions, and
New J2SE-Specific AttributeIds Sections below.
The proposal then outlines how the XACML Policy Provider can
be
implemented using Sun's XACML Implementation, and how this
implementation supports the methods in the
J2SE Policy API .
The proposal concludes with a description of a tool for translating
existing PolicyFile policies into XACML policies, intended to
facilitate migration. Appendices provide
simple and
full examples of PolicyFiles translated into XACML policies
according to this proposal.
A discussion of the design choices made follows the proposal
itself in the Issues and
Rationale section.
Certain URIs starting with the prefix
http://sunlabs.east.sun.com/projects/isrg/xacml/names# are
defined and used in this profile. This namespace has been
reserved, and can be used for prototyping. These URIs are not
defined by XACML, and are being used as a placeholder for a final
J2SE-specific prefix. If this proposal is implemented, the final
URIs will probably be different.
In the examples and explanatory text in this profile, various URIs and URNs are
abbreviated to make them more readable. J2SE-specific URIs use
the prefix j2se# in place of the full
provisional prefix
http://sunlabs.east.sun.com/projects/isrg/xacml/names#. XACML
standard URIs and URNs omit the prefix altogether.
This section describes the details of the proposed J2SE-specific
extensions to XACML, the Policy Provider that supports
XACML, the Policy API method support, and the tool that
translates PolicyFile policies into XACML policies.
This proposal recommends extending XACML with the following
new DataTypes and FunctionIds. These
DataTypes and FunctionIds are used to
handle J2SE-specific functionality that is not supported using
existing standard XACML DataTypes and functions.
The XACML syntax is designed to be extensible via the
definition of new DataTypes and
FunctionIds. Such extensions require extending the
implementation of any XACML Policy Decision Point (PDP) to
implement the new DataTypes and
FunctionIds. Sun's XACML Implementation [1] has been designed for easy extensibility in
this way. XACML PDPs that have not been extended, however, will
not be able to support policies that use the new
DataTypes and FunctionIds. This is not
viewed as an issue, since policies using these extensions would
only be used for Java applications, and Java applications can be
configured to use a PDP that has been appropriately extended.
http://sunlabs.east.sun.com/projects/isrg/xacml/names#class:
Defines a namespace for XACML DataTypes where the string
following
j2se#class:
is interpreted as a fully-qualified J2SE Class
name.
An <AttributeValue> having this
DataType contains a sequence of arguments to be
supplied to a Constructor for the J2SE Class.
Each of these arguments is an
<xacml:AttributeValue> itself and must
have an appropriate DataType. The
implementation recognizes the DataType
http://www.w3.org/2001/XMLSchema#string as
equivalent to j2se#class:java.lang.String. If
an <AttributeValue> having this
DataType does not contain a sequence of
arguments compatible with any Constructor for the J2SE
Class, then the evaluation of the
<AttributeValue> results in an error.
An <AttributeDesignator> having this
DataType must have an AttributeId
that refers to an instance of the designated Java Class.
These AttributeIds are described in the AttributeIds section below. If an
<AttributeDesignator> having a
DataType in this namespace does not have an
AttributeId that refers to an instance of the
designated Java Class, then the evaluation of the
<AttributeDesignator> results in a
processing-error.
Example: an <AttributeValue> that corresponds to
the Permission Class instance in the following
PolicyFile "permission" statement.
permission java.io.FilePermission "/home/alice/*", "read, write"
is specified in XACML as follows:
<AttributeValue
DataType="j2se#class:java.io.FilePermission>
<AttributeValue
DataType="string">/home/alice/*</AttributeValue>
<AttributeValue
DataType="string">read, write</AttributeValue>
</AttributeValue>
http://sunlabs.east.sun.com/projects/isrg/xacml/names#method:
Defines a namespace for XACML Functions where the string
following j2se#method: is interpreted as the
name of a J2SE Class method.
Each such function expects its first argument to have a
DataType in the j2se#class:
namespace. The function is interpreted as a method of this
first argument's Class. The function is implemented by
invoking the named method in the Class instance represented
by the first argument. The remaining arguments and their
DataTypes must correspond to arguments expected
by the named Class method and are passed as arguments to the
method invocation. If the remaining arguments and their
DataTypes do not correspond to arguments
expected by the named Class method, the evaluation of the
function results in a processing-error.
Example: the following PolicyFile "permission"
permission java.net.SocketPermission "129.255.255.255"
"listen, connect"
is specified in XACML as follows:
<ResourceMatch MatchId="j2se#method:implies">
<AttributeValue
DataType="j2se#class:java.net.SocketPermission">
<AttributeValue
DataType="string">129.255.255.255</AttributeValue>
<AttributeValue
DataType="string">listen, connect<AttributeValue>
</AttributeValue>
<ResourceAttributeDesignator
AttributeId="resource:resource-id"
DataType="j2se#class:java.net.SocketPermission"/>
</ResourceMatch>
An important use of this namespace is for referencing the
implies method of a Permission
subclass, as in the example just provided. Note that use of the
implies method in this way allows use of multiple
actions in a single XACML Request without requiring any special
handling by the XACML PDP.
http://sunlabs.east.sun.com/projects/isrg/xacml/names#function:getCertificateFromKeyStore
This function is used to retrieve an instance of a
java.security.Certificate from a J2SE keystore.
This function expects three arguments.
The
"alias" for the desired certificate within the keystore. The
DataType of this argument must be
http://www.w3.org/2001/XMLSchema#string. The URL at which the keystore
containing the certificate is to be found. The
DataType of this argument must be
http://www.w3.org/2001/XMLSchema#anyURI. The type of the keystore file (such as "JKS". The
DataType of this argument must be
http://www.w3.org/2001/XMLSchema#string.
If the arguments to this function are not of the correct type,
the result is a syntax-error.
If the specified alias can be found in a keystore of the
specified type at the specified URL, the result of this function
is an instance of a java.security.Certificate.
Otherwise, the result is "Indeterminate".
Example: an example of use of this function follows.
<Apply FunctionId="j2se#function:getCertificateFromKeyStore">
<AttributeValue DataType="string">FooSoft</AttributeValue>
<!-- keystore "file:/opt/keystores/.keystore" "JKS"; -->
<AttributeValue
DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
<AttributeValue
DataType="string">JKS</AttributeValue>
</Apply>
http://sunlabs.east.sun.com/projects/isrg/xacml/names#function:certificate-is-in
This function is an extension to the group of type-is-in
functions defined in the XACML specification, and conforms to the
semantics of such functions: "This function SHALL take an argument of
data-type
j2se#class:java.security.Certificate
as the first argument and a bag of
j2se#class:java.security.Certificate
as the second argument. The expression SHALL evaluate to
"True" if the first argument matches by the
j2se#method:equals
function to any value in the bag."
This function is used in J2SE XACML policies to match an
instance of the j2se#attribute:signerCertificate
AttributeId against a particular certificate. This AttributeId
can be used to specify a certificate associated with the
signature on the invoking Class in the requesting
ProtectionDomain or a certificate associated with a
signature on the requested Permission. When used
with the signature on the invoking Class, the
j2se#attribute:signerCertificate AttributeId occurs
in a <SubjectAttributeDesignator>. When used
with the signature on the requested Permission, the
j2se#attribute:signerCertificate AttributeId occurs
in a <ResourceAttributeDesignator>.
In J2SE XACML policies, the
j2se#function:certificate-is-in function is used as
follows. The first argument to this function is an
<Apply> element invoking the
j2se#function:getCertificateFromKeyStore function. The
second argument to this function is a
<SubjectAttributeDesignator> or
<ResourceAttributeDesignator> as described
above with an AttributeId of
j2se#attribute:signerCertificate
and a DataType that is a subclass of
j2se#class:java.security.Certificate.
The function returns "True" if the certificate specified by the
keystore alias in the keystore file in getCertificateFromKeyStore is
among the certificates used to sign either the requested
Permission class (when used with a
<ResourceAttributeDesignator>) or the CodeBase of the
requesting ProtectionDomain (when used with a
<SubjectAttributeDesignator>). Otherwise, the function returns
"False".
Example: an example of use of this function follows.
<Apply FunctionId="j2se#function:certificate-is-in">
<Apply FunctionId="j2se#function:getCertificateFromKeyStore">
<AttributeValue DataType="string">FooSoft</AttributeValue>
<!-- keystore "file:/opt/keystores/.keystore" "JKS"; -->
<AttributeValue
DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
<AttributeValue
DataType="string">JKS</AttributeValue>
</Apply>
<ResourceAttributeDescriptor
AttributeId="j2se#attribute:signerCertificate"
DataType="j2se#class:java.security.Certificate"/>
</Apply>
http://sunlabs.east.sun.com/projects/isrg/xacml/names#function:file-path-match
This function provides the ability to match file paths in
order to determine if one file or subdirectory matches or is in a
sub-directory of another. It emulates the
java.io.Permission implies
functionality, but may be used with arguments that are not
specific to the J2SE platform. Note that the matching is strictly by name
syntax: there is no lookup to see if a given file or subdirectory
is actually in another directory on the platform itself.
The function takes two arguments of DataType
http://www.w3.org/2001/XMLSchema#string and returns
a result of type
http://www.w3.org/2001/XMLSchema#boolean. The
result of the function is "True" if the file or path specified in
the first argument matches the second argument; otherwise, the
result is "False". The first argument is the "template" for the
match: the desired path or directory name, which may use wildcard
characters. The second argument is the literal file or path to
be compared to the template. If the first argument is a pathname
that ends in "<file-separator>*", it indicates all file and
directory names syntactically contained in that directory,
including the directory itself. If the first argument is a
pathname that ends with "<file-separator>-", it indicates
(recursively) all file and subdirectory names syntactically
contained in that directory. If the first argument is a pathname
consisting of the special token "[[ALL FILES]]", it matches any
file. If the characters "*" or "-" are to be treated as
filenames rather than as wildcard characters, the characters must
be escaped using "\*" or "\-".
This function recognizes and expands the ${some.property}
syntax in its literal string arguments.
http://sunlabs.east.sun.com/projects/isrg/xacml/names#function:permission-one-and-only
This function is an extension to the group of
type-one-and-only functions defined in the XACML
specification, and conforms to the semantics of such functions:
"This function SHALL take an argument of a bag of data-type
j2se#class:java.security.Permission
(or a subclass thereof) and SHALL return a value of DataType
j2se#class:java.security.Permission
(or a subclass thereof). It SHALL return the only value in
the bag. If the bag does not have one and only one value, then
the expression SHALL evaluate to "indeterminate"."
In J2SE XACML policies, this function is used to convert the bag
of Permissionobjects returned by a
<ResourceAttributeDesignator> with an
AttributeId of
urn:oasis:names:tc:xacml:1.0:resource:resource-id
into a single Permission object. This function
never fails, since the "resource-id" AttributeId is
mapped to the requested Permission in the Policy
API, and the Policy API has exactly one such
Permission.
Example: an example of the use of this function
follows.
<Apply FunctionId="j2se#function:permission-one-and-only">
<ResourceAttributeDesignator
AttributeId="resource:resource-id"
DataType="j2se#class:java.security.Permission"
</Apply>
This proposal recommends mapping some J2SE objects to existing
XACML AttributeIds, and defining some new
AttributeIds that are J2SE-specific. These are
described as follows.
This proposal recommends mapping the following existing XACML
standard AttributeIds to objects in the Policy API.
The mappings are consistent with the semantics of these
AttributeIds as defined by XACML.
urn:oasis:names:tc:xacml:1.0:subject:subject-id
XACML specifies that this AttributeId is to be
used for the identity of a subject involved in making the access
request. J2SE Policy supports two such types of subjects, one of
which corresponds to the standard XACML SubjectCategory
"access-subject" and the other of which corresponds to the
standard XACML SubjectCategory "codebase".
In the J2SE XACML Policy Provider, this AttributeId
is supported only in a <SubjectAttributeDesignator> and only for
the following SubjectCategory values.
SubjectCategory
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject
When this AttributeId is used with a SubjectCategory value of
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject,
it is mapped to the array of Principal in the
ProtectionDomain of the Policy API. The value of
the attribute is a bag containing one member for each
Principal returned from invoking
domain.getPrincipals() that is compatible with the
DataType specified for the AttributeId.
If the DataType of the attribute is
urn:oasis:names:tc:xacml:1.0:data-type:x500Name,
then the bag contains, for each Principal of
type javax.security.auth.x500.X500Principal, the
value returned from invoking Principal.getName().
If the DataType of the attribute is
j2se#class:java.security.Principal
or a subclass thereof, then the bag contains one Java object
for each Principal corresponding to the named
class.
If the DataType is
http://www.w3.org/2001/XMLSchema#string or
j2se#class:java.lang.String,
then the
bag contains, for each Principal in the array,
the value returned from invoking
Principal.getName().
Other DataTypes will be supported only if custom code is added to
the J2SE-extended XACML PDP implementation. SubjectCategory
urn:oasis:names:tc:xacml:1.0:subject-category:codebase
When this AttributeId is used with a SubjectCategory value of
urn:oasis:names:tc:xacml:1.0:subject-category:codebase
then it is mapped to the URL of the CodeSource in
the ProtectionDomain in the Policy API. The value
of the attribute is a bag consisting of one member. The value of
the bag member depends on the DataType.
If the DataType is
http://www.w3.org/2001/XMLSchema#anyURI or
http://www.w3.org/2001/XMLSchema#string, then the
bag member is the value returned by invoking
URL.toString().
If the DataType is
j2se#class:java.net.URL
or a subclass thereof, then the bag member is the Java
object that is the URL.
Other DataTypes will be supported only if custom code is added to
the J2SE-extended XACML PDP implementation. urn:oasis:names:tc:xacml:1.0:resource:resource-id
XACML specifies that this AttributeId is to be used
for the identity of the resource being accessed.
In the J2SE XACML Policy Provider, this AttributeId
is mapped to the requested Permission object in
the Policy API. This AttributeId is supported only
in a <ResourceAttributeDesignator>.
The value of the attribute is a bag containing one member. The
value of the member depends on the DataType
specified for the attribute.
If the DataType is
j2se#class:java.security.Permission
or a subclass thereof, then the value of the member is the
requested Permission object passed in the Policy
API.
If the DataType of this attribute is
http://www.w3.org/2001/XMLSchema#string or
j2se#class:java.lang.String,
then the value of the member is as follows.
If the value of Permission.getActions() is the
empty string or null, then the value of the bag member is
the fully qualified name of the Permission
subclass. For example, if the requested
Permission subclass is
javax.sound.sampled.AudioPermission, the value
of the bag member is javax.sound.sampled.AudioPermission. Otherwise, the value of the bag member is the value of
Permission.getName().
Other DataTypes will be supported only if custom code is added to
the J2SE-extended XACML PDP implementation. urn:oasis:names:tc:xacml:1.0:action:action-id
This AttributeId is mapped to the requested
Permission object in the Policy API. The
AttributeId is supported only in an
<ActionAttributeDesignator>.
This AttributeId is handled in a special way for
certain standard J2SE Permission classes that
support multiple actions in a single Permission. If
such a Permission instance is passed as the
requested permission via the Policy API, then the PDP Interface
Module parses the value returned from
Permission.getActions(). If the value contains more
than one action, then the PDP Interface Module does the
following. For each action value, the PDP Interface Module makes
one call to the PDP.evaluate() API. For each such
call, the PDP Interface Module supplies only the one action value
to the J2SE-Specific Attribute Finder Module in response to a
request for the
urn:oasis:names:tc:xacml:1.0:action:action-id
AttributeId. If any such call fails to evaluate to "Permit",
then the PDP Interface Module returns "False" as the Policy API
return value. If all such calls evaluate to "Permit", then the
PDP Interface Module returns "True" as the Policy API return
value. The Appendix
Mappings for Standard J2SE Permission Subclasses identifies
the standard J2SE Permission subclasses for which this special
handling is performed.
The value of the attribute is a bag containing one member.
The value of the member depends on the DataType
specified for the attribute.
If the DataType of this attribute is
http://www.w3.org/2001/XMLSchema#string or
j2se#class:java.lang.String, then the
value of the member is as follows.
If the value of Permission.getActions() is the
empty string or null, then the value of the bag member is
the value of Permission.getName(). Otherwise, the value of the bag member is the value of
Permission.getActions().
Other DataTypes will be supported only if custom code is added to
the J2SE-extended XACML PDP implementation.
This proposal recommends defining the following new XACML AttributeIds.
This proposal suggests using Sun's XACML Implementation [1] as the basis for the XACML Policy Provider.
This is an Open Source implementation with a non-viral BSD
license. It was written by Seth Proctor and other members of the
Internet Security Research Group (ISRG) in Sun Labs. The
following description of the XACML Policy Provider is couched in
terms of the structure and APIs in this implementation, but
should be adaptable to other implementations.
The J2SE Policy Provider that supports XACML in this recommended
approach can be implemented as follows, using Sun's XACML
Implementation [1]:
| ^
| |
J2SE Policy API
| |
____V___|_______
| PDP Interface |
| Module |<---------------
|________________| |
| ^ |
| | |
PDP.evaluate() API |
| | |
________________ ____V___|_______ _____|____________
| J2SE-specific | Sun's XACML |-------->| J2SE-Specific |
| DataTypes and | Implementation | | Attribute Finder |
| Functions | | | Module |
|________________|________________| |__________________|
|
______V_________
| Other Finder |_
| Modules | |_
|________________| | |
|________________| |
|________________|
This proposal makes use of Sun's XACML Implementation support for
pluggable "Attribute Finder Modules" that know how to retrieve
specific attributes from various repositories. It also makes use
of the ability to add support for new DataTypes
and FunctionIds easily.
The components of this structure are explained in the subsequent
sections.
The PDP Interface Module acts as an intermediary between the J2SE
Policy API and its information model and Sun's XACML
Implementation [1] PDP APIs. It translates an
invocation of the J2SE Policy.implies() method into
an XACML PDP.evaluate() invocation. Likewise, the
PDP maps the ResponseCtx output from the XACML PDP
to a return value of "True" if the Response.Decision
is Permit, and to a return value of "False"
otherwise.
The PDP Interface Module also allows the
J2SE-Specific Attribute Finder
Module access to objects passed via the Policy API.
This module performs the mapping between objects passed via the
J2SE Policy API and various XACML Attributes. Rather than trying
to construct an instance of the XACML Request schema, it supplies
appropriate values dynamically. When an XACML Attribute is
requested via the PDP's
AttributeFinder.findAttribute() method, this Finder
Module invokes the corresponding Policy API objects via the PDP
Interface Module. It then modifies the resulting values as
appropriate, and returns the corresponding results, caching
results as appropriate. The
AttributeIds supported by this module are described
in the AttributeIds section of this
proposal.
Additional AttributeIds can be supported by other Attribute
Finder Modules. For example, support for several Environment
Attributes such as the current date and time are built into
Sun's XACML Implementation, allowing J2SE Applications to make
use of policies that allow different permissions based on the
time of day. Other attributes of the environment, such as the
day of the week, can be provided by new modules. Other
attributes of a subject, such as various roles, can be
retrieved from an external repository indexed by the subject
identity. Resource labels on the resource being accessed can
be accessed from an external repository indexed by the resource
identity. This extensibility is part of the design of the XACML
policy language.
This section describes how the J2SE XACML Policy Provider
supports the specific methods in the J2SE Policy API.
The java.security.Policy Class is the abstract base class that
exports the Policy API.
It supports the following methods:
boolean implies(ProtectionDomain domain, Permission
permission) abstract PermissionCollection
getPermissions(CodeSource codesource)PermissionCollection
getPermissions(ProtectionDomain domain)static Policy getPolicy() static void setPolicy(Policy policy) abstract void refresh()
The getPolicy and setPolicy methods are
handled by the abstract class. This section recommends ways to
support the remaining methods in the J2SE XACML Policy
Provider.
In the recommended internal structure described above, the PDP
Interface Module of the XACML Policy Provider implements the
Policy.implies() method. It does this by invoking
the PDP.evaluate() method exported by Sun's XACML
Implementation. When the PDP, in evaluating an XACML Policy,
encounters an XACML AttributeDesignator with an
AttributeId that has been mapped to information
provided in the Policy API, this AttributeId is
handled by the
J2SE-Specific Attribute Finder Module (provided via a
pluggable interface exported from Sun's XACML Implementation).
This Attribute Finder Module in turn invokes the PDP Interface
Module, which make the appropriate method calls on the Policy API
objects, and returns the requested information. The
J2SE-Specific Attribute Finder Module modifies this information
as needed, and then returns the appropriate information to the
PDP.
The preceding sections of this Proposal describe the specific
mappings that are performed.
The PDP Interface Module could try to maintain a cache of
PermissionCollections indexed by
ProtectionDomain and representing previously
requested Permissions that have evaluated to
"Permit" for the indexed ProtectionDomain. The
Interface Module would need to screen out Permissions that were
obtained based on time of day or other dynamic attributes, and
this may be difficult to implement. If a safe cache can be
created, then before invoking the PDP.evaluate()
API, the PDP Interface Module can test a requested
Permission against any
PermissionCollection located in this cache for the
input ProtectionDomain.
This proposal recommends that the XACML Policy Provider return
an empty PermissionCollection as the result of
the two Policy.getPermissions methods. For
more information on this recommendation, see the
getPermissions discussion in the Issues and Rationale
Section.
The XACML Policy Provider can implement the
Policy.refresh method by clearing its cache of
retrieved Policy and PolicySet
instances, and by retrieving a fresh copy of its base policy, if
appropriate. Any cache of previously evaluated
Permissions should also be cleared.
In order to protect customer investment in existing PolicyFile
policies, this proposal includes a tool that translates
PolicyFile policies into equivalent XACML policies. This
tool can be completely automatic [with exception of property
expansion?], since PolicyFile semantics can be captured
precisely in XACML.
This translator makes the following translations.
A PolicyFile grant statement has the following general syntax:
grant [signedBy signer_name, ...] [, codebase URL],
[principal principal_class_name principal_name]...
{
permission permission_class_name target_name,
[action] [, signedBy signer_name...]
...
}
Each grant statement is translated into one XACML Rule.
Each type of phrase in the grant statement generates one
<Apply> element in the Rule's
<Condition> as follows.
<Rule RuleId="[UNIQUE-ID]" Effect="Permit">
<Condition FunctionId="and">
<!-- each grant ... signedBy [ALIAS] generates -->
<Apply FunctionId="j2se#function:certificate-is-in">
<Apply FunctionId="j2se#function:getCertificateFromKeyStore">
<AttributeValue DataType="string">[ALIAS]</AttributeValue>
<!-- from required 'keystore "[URL]" "[TYPE]"' -->
<AttributeValue
DataType="anyURI">[URL]</AttributeValue>
<AttributeValue
DataType="string">[TYPE]</AttributeValue>
</Apply>
<SubjectAttributeDescriptor
AttributeId="j2se#attribute:signerCertificate"
SubjectCategory="codebase"
DataType="j2se#class:java.security.Certificate"/>
</SubjectAttributeDescriptor>
</Apply>
<!-- each grant ... codeBase "[URL]" generates -->
<Apply FunctionId="anyURI-is-in">
<AttributeValue DataType="anyURI">[URL]>
<SubjectAttributeDescriptor
AttributeId="subject:subject-id"
SubjectCategory="codebase"
DataType="anyURI"/>
</Apply>
<!-- each grant ... principal "[ALIAS]" generates -->
<Apply FunctionId="x500Name-is-in">
<Apply FunctionId="j2se#method:getSubjectDN">
<Apply FunctionId="j2se#function:getCertificateFromKeyStore">
<AttributeValue DataType="string">[ALIAS]</AttributeValue>
<!-- from required 'keystore "[URL]" "[TYPE]"' -->
<AttributeValue
DataType="anyURI">[URL]</AttributeValue>
<AttributeValue
DataType="string">[TYPE]</AttributeValue>
</Apply>
<SubjectAttributeDescriptor
AttributeId="subject:subject-id"
SubjectCategory="access-subject"
DataType="x500Name"/>
</Apply>
<!-- each grant ... principal [CLASS] "[NAME]" generates -->
<Apply FunctionId="string-is-in">
<AttributeValue
DataType="string">[NAME]</AttributeValue>
<Apply FunctionId="map">
<Apply FunctionId="j2se#method:getName">
<SubjectAttributeDesignator
AttributeId="subject:subject-id"
DataType="j2se#class:[CLASS]"
</Apply>
</Apply>
</Apply>
<Apply FunctionId="or">
<!-- each
permission [CLASS] "[TARGET]", "[ACTIONS] signedBy "[ALIAS]"
generates -->
<Apply FunctionId="and">
<Apply
FunctionId="j2se#method:implies">
<AttributeValue
DataType="j2se#class:[CLASS]">
<AttributeValue
DataType="string">[TARGET]</AttributeValue>
<!-- following AttributeValue omitted if no
[ACTIONS] -->
<AttributeValue
DataType="string">[ACTIONS]</AttributeValue>
</AttributeValue>
<Apply FunctionId="j2se#function:permission-one-and-only">
<ResourceAttributeDesignator
AttributeId="resource:resource-id"
DataType="j2se#class:java.security.Permission"
</Apply>
</Apply>
<!-- following Apply omitted if no signedBy "[ALIAS]" -->
<Apply FunctionId="j2se#function:certificate-is-in">
<Apply FunctionId="j2se#function:getCertificateFromKeyStore">
<AttributeValue DataType="string">[ALIAS]</AttributeValue>
<!-- from required 'keystore "[URL]" "[TYPE]"' -->
<AttributeValue
DataType="anyURI">[URL]</AttributeValue>
<AttributeValue
DataType="string">[TYPE]</AttributeValue>
</Apply>
<ResourceAttributeDescriptor
AttributeId="j2se#attribute:signerCertificate"
DataType="j2se#class:java.security.Certificate"/>
</Apply>
</Apply>
</Apply>
</Condition>
</Rule>
See
Appendix 1: Example of a Translated Simple PolicyFile and
Example of a Translated Full PolicyFile for examples.
This section describes some areas of particular difficulty
encountered when trying to map the semantics of the J2SE Policy
API or PolicyFile into XACML.
The XACML PDP defined in the XACML 1.0 standard does not have
any interface that returns the equivalent of a set of
permissions. For this reason, it is not possible to implement
the two Policy.getPermissions() methods directly
using XACML.
In XACML, a Policy is evaluated on the basis of attributes of
the subjects, resources, and actions, returning a result of
"Permit" or "Deny", "Indeterminate", or "NotApplicable". XACML
policies are not designed to allow easy extraction of a static
collection of resources and associated actions "permitted" for a
given set of subject attributes. In fact, many XACML policies
would not be able to return a set of permitted resources and
actions, since the set would only be permitted at certain times
of day or under combinations of conditions that can not be
captured in a simple set of attributes.
Work is now in progress within the XACML TC to define a way of
evaluating an XACML policy in order to return a set of Attribute
values. Since this work is very preliminary, and will probably
use a very constrained form of the XACML syntax, it should not be
considered a solution to the problem of supporting a
PermissionCollection as returned from
getPermissions.
Some existing custom Policy Providers return a live
PermissionCollection that does not encapsulate a
specific collection of individual permissions. The
implies method of such a
PermissionCollection is used to test specific
Permission requests dynamically. In such cases, the
PermissionCollection that is returned may not be an
instance of the Permissions class. Such live
PermissionCollection objects typically do not
support the elements method.
The XACML Policy Provider could support the
getPermissions() methods using such a custom
PermissionCollection. For example, it could return
an XACMLPermissionCollection subclass that
encapsulates the ProtectionDomain or
CodeSourcefor which the request was made. This
subclass would implement its implies(Permission)
method by invoking the Policy.implies() method,
causing a full XACML policy evaluation to occur. If new
Permission instances are added to the
XACMLPermissionCollection, they could be saved in an
internal PermissionCollection that would be tested
before invoking Policy.implies(). (Note that this
technique would not support the overlapping
Permissions semantics of a
PermissionCollection).
In order to support the return of individual
Permissions from
XACMLPermissionCollection.elements() API, the
XACMLPermissionCollection could return a single
element consisting of a custom Permission subclass
instance. This XACMLPermission subclass would store
its associated ProtectionDomain or
CodeSource as a class variable.
When its implies(Permission) method was invoked,
XACMLPermission would use its cached
ProtectionDomain or CodeSource, along with the
Permission passed as the argument to the
implies method, to invoke
Policy.implies. XACMLPermission would
have to be compatible with all other Permission and
PermissionCollection subclasses in order to allow an
XACMLPermission to be included inside any
homogeneous or heterogeneous
PermissionCollection.
While it would be possible to support the
getPermissions methods using such a technique, this
proposal recommends that we not try to do so. This
recommendation is made in light of the ways in which the
PermissionCollection returned from
getPermissions is used.
The PermissionCollection returned by the
getPermissions(ProtectionDomain) method is used by
the standard ClassLoader to obtain
Permission objects that have been granted to a
particular ProtectionDomain, independent of any
Principal objects that may later be combined with
the ProtectionDomain. These Permission
objects are stored in the ProtectionDomain. At
runtime, this cache of pre-evaluated, static
Permissions is used as an optimization. If a
requested Permission is implied by the
PermissionCollection stored in the
ProtectionDomain, then the Permission
is granted. Otherwise, the Policy.implies() method
is invoked to make use of any Permissions that
depend on Principal associations or on
Permissions that may have been added to the policy
since the ClassLoader obtained the static set.
The result of evaluating an
XACMLPermissionCollection would be exactly equivalent
to the result of evaluating Policy.implies. A
cached PermissionCollection in the
ProtectionDomain implies that these are
pre-evaluated, or optimized Permissions, but, in the
case of XACML, this is not the case. Thus it seems more direct
to return an empty PermissionCollection from
Policy.getPermissionCollection, forcing all run-time
evaluations to use the Policy.implies API.
One more difficulty with trying to support
Policy.getPermissions as described above is that the
combine method of the JAAS
SubjectDomainCombiner does not preserve custom
PermissionCollections. This means the late binding
effects would be extinguished by this combiner. Solving this
problem would require creating and using a custom
DomainCombiner that would preserve the custom
XACMLPermissionCollection. Again, it just seems
more straightforward to force use of
Policy.implies() at runtime.
An issue closely related to that of implementing the
Policy.getPermissions methods is the issue of
supporting overlapping Permissions in a
PermissionCollection with XACML.
The J2SE Policy model is somewhat different from the XACML
Policy model. In the J2SE platform, a Policy is evaluated on the basis of the
attributes of the subjects (ProtectionDomain) making
the request to return a collection of the resources and
associated actions (PermissionCollection) to which
the subjects have access. Each requested Permission
is then evaluated against this PermissionCollection
to return a result of "True" (grant access) or "False" (deny
access).
A requested Permission may be granted by a
PermissionCollection even if it is not implied by
any single Permission in the collection. One simple
example of this behavior is a J2SE policy that grants a
particular subject access to two different
FilePermissions for a given file: one with action
"read, delete", and the other with action "write". If the
subject requests permission to "read, write" this file, this
request is granted because the aggregate
PermissionCollection recognizes that the two
individual Permission actions can be merged into a
set of actions, of which the requested action is a subset.
This aggregate behavior of Permissions in a
PermissionCollection is referred to as
overlapping Permissions.
There are few constraints on how Permission
subclasses implement this aggregate behavior. There can be
complex interactions not only between different
Permissions of the same subclass, but even
interactions between Permissions of different
subclasses.
The following preliminary proposal describes
one potential way of supporting overlapping
Permissions in an XACML J2SE Policy
Provider. Comments are invited.
This approach to handling overlapping Permissions
is based on the observation that, when an XACML Rule
is in Disjunction Normal Form (an OR of
AND predicates), then all the
Permission objects used in a single AND
predicate can be collected into a single
PermissionCollection. This
PermissionCollection captures any overlapping
Permission semantics that should be allowed to
affect the evaluation of the Rule. The procedure is
as follows.
Put the XACML Rule into Disjunctive Normal Form.
See [9] for a nice description of the standard
algorithm. Start evaluation of the Rule.
When evaluating each AND predicate, first
create a new Permissions object. Whenever an
expression of the form
<Apply FunctionId="j2se#method:implies">
<AttributeValue DataType="j2se#class:X">
[constructor arguments]
</AttributeValue>
<ResourceAttributeDesignator AttributeId="resource-id"
DataType="j2se#class:Y"/>
</Apply>
is encountered in the AND predicate, where
X and Y are subclasses of
java.security.Permission, construct a new
Permission object from the
AttributeValue. Pass this new
Permission object to the add method of
the Permissions object. Now treat the original
Apply expression as if it had evaluated to
"true".
At the end of evaluation of the AND predicate, if
the result is "true" so far, then invoke the implies
method of the Permissions object, passing it the
requested Permission object. If this method returns
"true", then the AND predicate evaluates to "true"
and the Rule evaluation can terminate by returning
the specified Effect. Otherwise, the
AND predicate evaluates to "false", and evaluation
of the next AND predicate begins with creation of a
new, empty Permissions object.
This proposal recommends that overlapping
Permissions not be supported for the first release
of the XACML Policy Provider due to the difficulty of
implementing support for these complex semantics.
In PolicyFile, a keystore entry is a way to reference a
cache of certificates. A keystore entry may occur
anywhere outside the PolicyFile's grant entries. There
can be only one keystore entry per policy file. This entry
specifies the J2SE keystore location and type to be used in
resolving keystore aliases encountered in the PolicyFile's
grant entries.
Keystore aliases may be used in PolicyFile to specify the
following.
signedBy fields
The public key certificate associated with the alias is
retrieved and matched against the "signer" certificates
associated with a ProtectionDomain, either that
of the requested Permission class or the
ProtectionDomain of the application
Class object that made the access
request. principal entries
The subject distinguished name is retrieved from the public
key certificate associated with the alias; the certificate is
assumed to be of type
java.security.cert.X509Certificate
A new J2SE-specific AttributeId has been proposed above to
reference either the signer certificates for the codebase class
or the signer certificates for the requested
Permission class.
The problem is in how, in XACML, to specify certificates
located in a keystore for use in comparing with the certificates
referenced by this AttributeId.
This proposal recommends specifying the location and type of the
keystore file as an argument to each invocation of a new
getCertificateFromKeyStore function.
An alternative solution would be some sort of
setKeyStore function taking as arguments the
location and type of the keystore. Such a function would return
true if a keystore of the specified type could be accessed at the
specified location. As a side-effect, the function would
establish the keystore to be used by invocations of the
getCertificateFromKeyStore function within some
specified scope.
While it is inconvenient to have to specify the keystore
location and type each time a certificate is retrieved, the use
of side effects to establish state is not good language design and violates the
stateless nature of other XACML constructs.
The use of a keystore alias to express a "principal" name is
just a convenience, saving the user from typing out the entire
name. If this functionality is important, it can be
accomplished by using the new
j2se#function:getCertificateFromKeyStore
function, and using the result as the argument to an invocation
of the
j2se#method:getSubjectDN
function. It does not seem worth the clutter to define a new
j2se#function:getPrincipalFromKeyStoreAlias function,
although this is certainly possible to do.
In the J2SE platform, a requested Permission may contain more
than one "action" to be performed. For example, a
FilePermission may contain an action of "read,
write". XACML, however, does not support multiple actions in a
single policy evaluation request.
This proposal recommends that instances of certain standard
Permission subclasses, such as
java.io.FilePermission and
java.net.SocketPermission, be recognized by the PDP
Interface Module and tested for multiple actions. When multiple
actions are being requested, the PDP Interface Module submits a
separate Request to the PDP.evaluate() API for each
action in the list. The PDP Interface Module returns "True" as
the Policy API response only if ALL such evaluations result in
"Permit".
Policies that compare a Permission using the j2ee#method:implies
function handle multiple actions correctly.
Multiple actions per Permission will be supported
otherwise only if custom code is added to the J2SE-extended
XACML PDP implementation for each such
Permission subclass.
PolicyFile supports a syntax within literal value strings that
allows the value of a J2SE Property to be inserted
at that point in the value. For example,
permission java.io.FilePermission "${user.home}", "read";
becomes
permission java.io.FilePermission "/home/cathy", "read";
if the current value of the user.home system property is
"/home/cathy".
This could be handled directly in several ways.
Extend the XACML PDP to support a syntax for embedding the
value retrieved by one AttributeDescriptor inside a literal
AttributeValue. For example, ${Subject,
j2se#attribute:user.home,
string, access-subject} could be expanded to insert the value
of the <SubjectAttributeDesignator> with
AttributeId="j2se#attribute:user.home",
DataType="http://www.w3.org/2001/XMLSchema#string",
and SubjectCategory="access-subject" into the
literal value where this expression occurred (assuming there is
only one Attribute that matches this Designator). Extend the XACML PDP to support J2SE ${some.property}
syntax inside literal values. Define J2SE-specific functions for comparing values in which
such expressions might occur such that they recognize and expand
these expressions.
This proposal recommends the last method - providing
J2SE-specific functions - and specifically proposes implementing
such expansion capability in the
j2se#function:file-path-match
function. Extending the XACML PDP to recognize any sort of
AttributeId insertion should be done in a
standardized way for XACML as a whole. Confining the use of an
expansion syntax to J2SE-specific functions avoids having
policies use a syntax for general attributes that is not
supported on all platforms.
PolicyFile supports another expansion syntax called "General
Expansion". It is presented as a general expansion syntax, but
actually only two types of substitution are allowed: a way of
referring to the X.500 Distinguished Name of a Principal
in the ProtectionDomain involved in making the
access request, and a way of substituting an X.500 Distinguished
Name taken from a certificate in a keystore.
This proposal recommends that this functionality not be
implemented in the first release of the J2SE XACML Policy
Provider. Based on actual customer requirements, this
functionality could be supported within literal values used with
J2SE-specific functions in a later release. As with the Property
Expansion syntax described above, this functionality is too
specific to the J2SE platform for the XACML PDP itself to be expanded to
recognize this syntax in general.
[1]
Sun's XACML Implementation , an Open Source BSD License
implementation of XACML.
[2]
OASIS XACML Version 1.0 Standard Specification , 18 February
2003.
[3]
OASIS XACML Version 1.0 Policy
Schema, 18 February 2003.
[4]
OASIS XACML Version 1.0 Request
and Response Context Schema , 18 February 2003.
[5]
Default Policy Implementation and Policy File Syntax, 20 April
2002.
[6]
Permissions in the Java[TM] 2 SDK.
[7]
Java[TM] Access Control Mechanisms, by Anne Anderson, Sun
Microsystems Laboratories Technical Report #2002-0134, Mar 15,
2002.
[8]
XACML RBAC Profile, profile for use of XACML with role based access
control policies, Working Draft 01, 5 June 2003.
[9]
KeyNote Policy Files and Conversion to Disjunctive Normal Form
for Use in IPsec , by E. Spyropoulou, et al.,
Center for
Information Systems Security Studies and Research, Computer
Science Department, Naval Postgraduate School, Monterey, CA,
January 2002.
[10]
A Brief Introduction to XACML , 14 March 2003.
The following individuals contributed valuable suggestions to
this proposal. Any errors in the proposal, however, are solely
the responsibility of the author.
- Gary Ellison
- Steve Hanna
- Charlie Lai
- Ron Monzillo
- Seth Proctor
This appendix contains a PolicyFile and its expression as an
equivalent XACML Policy. The PolicyFile is very simple, and
uses only the basic syntax.
For a more elaborate
example, see
Example of a Translated Full PolicyFile.
The translation was done manually, and so may contain errors.
Standard XACML URNs and "wordy" syntax have been shortened
slightly to make this example more readable, but anyone familiar
with XACML should be able to convert this to a schema-compliant
form easily.
PolicyFile
The simple example PolicyFile follows.
grant codeBase "http://my/classes"
{
permission java.io.FilePermission "/tmp/games",
"read, write"
};
XACML Policy
The same policy expressed using the XACML syntax, and making use
of the extensions in this proposal, follows.
<Policy PolicyId="a1bc2f890" RuleCombiningAlgId="permit-overrides">
<Target>
<Subjects><AnySubject/></Subjects>
<Resources><AnyResource/></Resources>
<Actions><AnyAction/></Actions>
</Target>
<Rule RuleId="a1bc2f890.1" Effect="Permit">
<Condition FunctionId="and">
<!-- grant codeBase "http://my/classes" -->
<Apply FunctionId="anyURI-is-in">
<AttributeValue
DataType="anyURI">http://my/classes</AttributeValue>
<SubjectAttributeDescriptor
AttributeId="subject:subject-id"
SubjectCategory="codebase"
DataType="anyURI"/>
</Apply>
<Apply FunctionId="or">
<!-- "and" in case "permission ... signedBy" -->
<Apply FunctionId="and">
<!-- permission java.io.FilePermission
"/tmp/games", "read, write", -->
<Apply
FunctionId="j2se#method:implies">
<AttributeValue
DataType="j2se#class:java.io.FilePermission">
<AttributeValue
DataType="string">/tmp/games</AttributeValue>
<AttributeValue
DataType="string">read, write</AttributeValue>
</AttributeValue>
<Apply FunctionId="j2se#function:permission-one-and-only">
<ResourceAttributeDesignator
AttributeId="resource:resource-id"
DataType="j2se#class:java.security.Permission"
</Apply>
</Apply>
</Apply>
</Apply>
</Condition>
</Rule>
</Policy>
This appendix contains a PolicyFile and its expression as an
equivalent XACML Policy. The PolicyFile uses every type of
PolicyFile syntax possible, so is rather complex. For a simpler
example, see
Example of a Translated Simple PolicyFile.
The translation was done manually, and so may contain errors.
Standard XACML URNs and "wordy" syntax have been shortened
slightly to make this example more readable, but anyone familiar
with XACML should be able to convert this to a schema-compliant
form easily.
PolicyFile
The example PolicyFile follows.
keystore "file:/opt/keystores/.keystore" "JKS";
grant codeBase "http://my/classes"
{
permission java.io.FilePermission "/tmp/games",
"read, write"
};
grant signedBy "duke,sysadmin",
codeBase "http://my/classes",
principal "bob",
principal javax.security.auth.x500.X500Principal "cn=Alice"
{
permission java.io.FilePermission "/tmp/games",
"read, write",
signedBy "FooSoft";
permission java.security.SecurityPermission "Security.insertProvider.*";
};
XACML Policy
The same policy expressed using the XACML syntax, and making use
of the extensions in this proposal, follows.
<Policy PolicyId="f234ab56c" RuleCombiningAlgId="permit-overrides">
<Target>
<Subjects><AnySubject/></Subjects>
<Resources><AnyResource/></Resources>
<Actions><AnyAction/></Actions>
</Target>
<Rule RuleId="f234ab56c.1" Effect="Permit">
<Condition FunctionId="and">
<!-- grant codeBase "http://my/classes" -->
<Apply FunctionId="anyURI-is-in">
<AttributeValue
DataType="anyURI">http://my/classes</AttributeValue>
<SubjectAttributeDescriptor
AttributeId="subject:subject-id"
SubjectCategory="codebase"
DataType="anyURI"/>
</Apply>
<Apply FunctionId="or">
<!-- "and" in case "permission ... signedBy" -->
<Apply FunctionId="and">
<!-- permission java.io.FilePermission
"/tmp/games", "read, write", -->
<Apply
FunctionId="j2se#method:implies">
<AttributeValue
DataType="j2se#class:java.io.FilePermission">
<AttributeValue
DataType="string">/tmp/games</AttributeValue>
<AttributeValue
DataType="string">read, write</AttributeValue>
</AttributeValue>
<Apply FunctionId="j2se#function:permission-one-and-only">
<ResourceAttributeDesignator
AttributeId="resource:resource-id"
DataType="j2se#class:java.security.Permission"
</Apply>
</Apply>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule RuleId="f234ab56c.2" Effect="Permit">
<Condition FunctionId="and">
<!-- grant signedBy "duke" -->
<Apply FunctionId="j2se#function:certificate-is-in">
<Apply FunctionId="j2se#function:getCertificateFromKeyStore">
<AttributeValue DataType="string">duke</AttributeValue>
<AttributeValue
DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
<AttributeValue
DataType="string">JKS</AttributeValue>
</Apply>
<SubjectAttributeDescriptor
AttributeId="j2se#attribute:signerCertificate"
SubjectCategory="codebase"
DataType="j2se#class:java.security.Certificate"/>
</SubjectAttributeDescriptor>
</Apply>
<!-- grant signedBy "sysadmin" -->
<Apply FunctionId="j2se#function:certificate-is-in">
<Apply FunctionId="j2se#function:getCertificateFromKeyStore">
<AttributeValue DataType="string">sysadmin</AttributeValue>
<AttributeValue
DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
<AttributeValue
DataType="string">JKS</AttributeValue>
</Apply>
<SubjectAttributeDescriptor
AttributeId="j2se#attribute:signerCertificate"
SubjectCategory="codebase"
DataType="j2se#class:java.security.Certificate"/>
</Apply>
<!-- grant codeBase "http://my/classes" -->
<Apply FunctionId="anyURI-is-in">
<AttributeValue DataType="anyURI">http://my/classes</AttributeValue>
<SubjectAttributeDescriptor
AttributeId="subject:subject-id"
SubjectCategory="codebase"
DataType="anyURI"/>
</Apply>
<!-- grant principal "bob" -->
<Apply FunctionId="x500Name-is-in">
<Apply FunctionId="j2se#method:getSubjectDN">
<Apply FunctionId="j2se#function:getCertificateFromKeyStore">
<AttributeValue DataType="string">bob</AttributeValue>
<AttributeValue
DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
<AttributeValue
DataType="string">JKS</AttributeValue>
</Apply>
<SubjectAttributeDescriptor
AttributeId="subject:subject-id"
SubjectCategory="access-subject"
DataType="x500Name"/>
</Apply>
<!-- grant principal javax.security.auth.x500.X500Principal "cn=Alice" -->
<Apply FunctionId="string-is-in">
<AttributeValue
DataType="string">cn=Alice</AttributeValue>
<Apply FunctionId="map">
<Apply FunctionId="j2se#method:getName">
<SubjectAttributeDesignator
AttributeId="subject:subject-id"
DataType="j2se#class:javax.security.auth.x500.X500Principal"
</Apply>
</Apply>
</Apply>
<Apply FunctionId="or">
<!-- "and" in case "permission ... signedBy" -->
<Apply FunctionId="and">
<!-- permission java.io.FilePermission
"/tmp/games", "read, write", -->
<Apply
FunctionId="j2se#method:implies">
<AttributeValue
DataType="j2se#class:java.io.FilePermission">
<AttributeValue
DataType="string">/tmp/games</AttributeValue>
<AttributeValue
DataType="string">read, write</AttributeValue>
</AttributeValue>
<Apply FunctionId="j2se#function:permission-one-and-only">
<ResourceAttributeDesignator
AttributeId="resource:resource-id"
DataType="j2se#class:java.security.Permission"
</Apply>
</Apply>
<!-- signedBy "FooSoft"; -->
<Apply FunctionId="j2se#function:certificate-is-in">
<Apply FunctionId="j2se#function:getCertificateFromKeyStore">
<AttributeValue DataType="string">FooSoft</AttributeValue>
<AttributeValue
DataType="anyURI">file:/opt/keystores/.keystore</AttributeValue>
<AttributeValue
DataType="string">JKS</AttributeValue>
</Apply>
<ResourceAttributeDescriptor
AttributeId="j2se#attribute:signerCertificate"
DataType="j2se#class:java.security.Certificate"/>
</Apply>
</Apply>
<!-- "and" in case "permission ... signedBy" -->
<Apply FunctionId="and">
<!-- permission java.security.SecurityPermission "Security.insertProvider.*" -->
<Apply
FunctionId="j2se#method:implies">
<AttributeValue
DataType="j2se#class:java.security.SecurityPermission">
<AttributeValue
DataType="string">Security.insertProvider.*</AttributeValue>
<AttributeValue
DataType="string"></AttributeValue>
</AttributeValue>
<Apply FunctionId="j2se#function:permission-one-and-only">
<ResourceAttributeDesignator
AttributeId="resource:resource-id"
DataType="j2se#class:java.security.Permission"
</Apply>
</Apply>
</Apply>
</Apply>
</Condition>
</Rule>
</Policy>
Certain Permission subclasses are provided in the
standard J2SE platform distribution. For each of these, this appendix
shows the semantics of the name and actions
parameters, and what mappings, if any, should be performed for
XACML. The word "ignored" below means that argument is supposed
to be null or the empty string, or is ignored by the
Permission subclass implementation.
java.security.AllPermission
Semantics:
- name: ignored
- actions: ignored
Mapped: no
javax.sound.sampled.AudioPermission
Semantics:
- name: a permitted action, such as "play" or "record"
- actions: ignored
Mapped: maybe
- resource:resource-id: "audio"
- action:action-id: value of "name"
javax.security.auth.AuthPermission
Semantics:
- name: name of a security config parameter (doAsPrivileged, etc.)
- actions: ignored
Mapped: no
java.awt.AWTPermission
Semantics:
- name: symbolic action (accessClipboard, accessEventQueue, etc.)
- actions: ignored
Mapped: no
ava.security.BasicPermission
Semantics:
- name: name of permission
- actions: ignored
Mapped: no
javax.security.auth.kerberos.DelegationPermission
Semantics:
- name:
specifies a pair of Kerberos service principals. The first is
the subordinate service principal being entrusted to use the
TGT. The second service principal designates the target
service the subordinate service principal is to interact with
on behalf of the initiating KerberosPrincipal. This latter
service principal is specified to restrict the use of a
proxiable ticket. the name of the subordinate and target
principals
- actions: ignored
Mapped: maybe
java.io.FilePermission
Semantics:
- name: path
(ends in "/*" (where "/" is the file separator character,
File.separatorChar) indicates a directory and all the files
contained in that directory. A pathname that ends with "/-"
indicates a directory and (recursively) all files and
subdirectories contained in that directory. The special
pathname "<<ALL FILES>>" matches all files.
A pathname consisting of a single "*" indicates all the files
in the current directory, while a pathname consisting of a
single "-" indicates all the files in the current directory
and (recursively) all files and subdirectories contained in
the current directory.
- actions: comma separated list of actions ("read", "write",
"execute", and "delete").
Mapped: yes
- resource:resource-id = value of "name"
- action:action-id = value of "actions". The PDP Interface Module
parses the action list into individual actions, and submits one
Request to the
PDP.evaluate() API for each action. A
value of "True" is returned as the return value of the
Policy.implies API only if ALL such Requests
evaluate to "Permit". Otherwise, a value of "False" is
returned.
java.util.logging.LoggingPermission
Semantics:
- name: must be "control"
- actions: ignored
Mapped: no
java.net.NetPermission
Semantics:
- name: permission name (setDefaultAuthenticator,
requestPasswordAuthentication, specify StreamHandler)
- actions: ignored
Mapped: maybe
java.security.Permission
Semantics: (abstract)
Mapped: no
javax.security.auth.PrivateCredentialPermission
Semantics:
- name: the name specifying the Credential class and Principal
Set.
- actions: the actions specifying that the Credential can be
read.
Mapped: maybe
java.util.PropertyPermission
Semantics:
- name: the name of the system property (user.home, etc.)
- actions: comma-separated list of the desired actions granted on
the property. Possible actions are "read" and "write".
Mapped: no
java.lang.reflect.ReflectPermission
Semantics:
- name: suppressAccessChecks
- actions: ignored
Mapped: no
java.lang.RuntimePermission
Semantics:
- name: createClassLoader, setSecurityManager, etc.
- actions: ignored
Mapped: no
java.security.SecurityPermission
Semantics:
- name: createAccessControlContext, setPolicy, setProperty.{key},
etc.
- actions: ignored
Mapped: no
java.io.SerializablePermission
Semantics:
- name: enableSubclassImplementation, enableSubstitution
- actions: ignored
Mapped: no
javax.security.auth.kerberos.ServicePermission
Semantics:
- name: Kerberos service principal name
- actions: initiate, accept
Mapped: maybe
- resource:resource-id = value of "name"
- action:action-id = value of "actions". The PDP Interface Module
parses the action list into individual actions, and submits one
Request to the
PDP.evaluate() API for each action. A
value of "True" is returned as the return value of the
Policy.implies API only if ALL such Requests
evaluate to "Permit". Otherwise, a value of "False" is
returned.
java.net.SocketPermission
Semantics:
- name: host DNS name or IP address, with optional port range
- actions: comma separated list "connect", "listen", "accept",
"resolve", or any combination of those. "resolve" is
automatically added when any of the other three are
specified.
Mapped: yes
- resource:resource-id = value of "name"
- action:action-id = value of "actions". The PDP Interface Module
parses the action list into individual actions, and submits one
Request to the
PDP.evaluate() API for each action. A
value of "True" is returned as the return value of the
Policy.implies API only if ALL such Requests
evaluate to "Permit". Otherwise, a value of "False" is
returned.
java.sql.SQLPermission
Semantics:
- name: setLog
- actions: ignored
Mapped: maybe
javax.net.ssl.SSLPermission
Semantics:
- name: setHostnameVerifier, getSSLSessionContext
- actions: ignored
Mapped: maybe
java.security.UnresolvedPermission
Semantics: Used by Policy implementation to hold Permissions for which
class does not yet exist when Policy is instantiated.
- name: <String>
- actions: <String>
Mapped: no
Sun, Sun Microsystems, Java[TM] 2 Platform, Standard Edition,
J2SE[TM], Java Community Process(SM), and JCP(SM) are trademarks
or registered trademarks of Sun Microsystems, Inc. in the
United States and other countries.
Copyright 2003 Sun Microsystems, Inc. All rights
reserved.
Anne Anderson
Last modified: Mon Jul 21 11:51:11 EDT 2003
| 