Architecture: XACML
XACML
XACML stands for eXtensible Access Control Markup Language and it is both an
XML schema for access control policies and the processing model to process them. Xacml
has been ratified by the OASIS standards
organization and the actual version is
version 2.0.
OpenPermis XACML Support
The OpenPermis Framework implements the request and the response schema of the XACML 2.0
specification. See:
Request: Spezification Restrictions
XML Element |
Restrictions |
Request Element |
Must contain exactly one Subject, one Resource, and one Action element.
Environment element is ignored.
|
Subject Element |
- Must contain exactly one Attribute of type
"urn:oasis:names:tc:xacml:1.0:subject:subject-id". The value of this
Attribute must be either of type "http://www.w3.org/2001/XMLSchema#anyURI"
or "http://www.w3.org/2001/XMLSchema#string".
- All other subject attributes are ignored.
- Optional attribute SubjectCategory is ignored.
|
Resource Element |
- The optional element ResourceType is ignored.
- Must contain exactly one Attribute of type
"urn:oasis:names:tc:xacml:1.0:subject:resource-id". The value of this
Attribute must be either of type "http://www.w3.org/2001/XMLSchema#anyURI"
or "http://www.w3.org/2001/XMLSchema#string".
- Attribute of type"urn:oasis:names:tc:xacml:2.0:resource:target-namespace"
is ignored.
|
Action Element |
- Must contain exactly one Attribute of type
"urn:oasis:names:tc:xacml:1.0:subject:resource-id". The value of this
Attribute must be of type "http://www.w3.org/2001/XMLSchema#string".
- Attribute of type"urn:oasis:names:tc:xacml:1.0:action:implied-action"
is ignored.
- Attribute of type"urn:oasis:names:tc:xacml:1.0:action:action-namespace"
is ignored.
|
Attribute Element |
- Attribute Issuer is ignored.
|
Response: Spezification Restrictions
XML Element |
Restrictions |
Response Element |
Contains exactly one Result element (Optional feature of multiple results is
not supported).
|
Obligations Element |
OpenPermis evaluates target access rules to decide if an authorization request
should be permitted or not. This means that more than one target access rules
may grant access for a request. This is fine as long as we don't have to deal
with obligations, since "Permit" and "Permit" still grant access. But if two
target access rule matches and both of them specified obligations, which
obligations should be returned?
In this case a list of all obligations of the matching target access rules are
returned. But the receiver of the XACML response has no possibility to
distinguish the different obligation sets anymore.
|
Conformance Tests