Page Comparison

Today, enterprise applications seek ways of enforcing security that allows the right people to access the right resources with restrictions enforced by enterprise policies. Identity and entitlement management systems, as a whole, attempt to address these security considerations. These systems help enterprise architects and developers in their application requirement implementations and try to significantly ease the burden of security-related implementations. These identity and entitlement management systems are governed by industry standard specifications, hence supporting security requirements for heterogeneous applications becomes easy.

Info
Click here for more information on Access control.

This topic consists of the following sections:

...

Table of Contents

maxLevel	3
minLevel	3
type	flat
separator	pipe

Types of access control

The following table describes the various types of access control.

Access Control Type	Description
Access Control Lists	Access control lists are the oldest and most basic form of access control. This type was primarily adopted for use in operating systems. This maintains a set of users and operations that can be performed on a resource as a mapping. This is easy to implement due to the use of maps. However, this is not scalable for larger user bases and can become difficult to manage.
Role-based Access Control	Role-based Access Control (RBAC) is an approach used to restrict access to authorized users based on their role. This is a static permission model which provides access control. It is used by the majority of enterprises with more than 500 users. This access control type is used when all users are categorized into different roles. The roles define the resources that can be accessed by users assigned to that role. This type of access control reduces management overhead. These users and roles can also be externalized using user stores. These roles need to be managed carefully. There can be instances where a user is assigned to multiple roles. This is a subset of ABAC. Static permissions for roles can be given by updating permission tree in WSO2 Identity Server. Click here for information on Configuring roles and permissions.
Attribute-based Access Control	Attribute-based access control (ABAC) defines a new access control paradigm whereby access rights are granted to users through the use of policies that combine attributes together. Here, authorization happens based on attributes. This access control type addresses the limitations of role-based access control to provide a more fine-grained approach. This can be based on the attributes of the user, the environment, or even the resource itself. This is more flexible when compared with the role-based approach. There is no need to know the user prior to granting access.
Policy-based Access Control	This type of access control addresses the requirement to have a more uniform access control mechanism. This helps larger enterprises to have uniform access control for the large amount of organizational units. This is helpful when carrying out security audits. This is the most complex form of access control. This involves specifying policies unambiguously using XACML and using authorized attribute sources in the enterprise. Here Policy Based Access Control(PBAC) (also called Rule-based access control) is an extension of ABAC where attributes are used in writing policies.

...

Introducing XACML

XACML (eXtensible Access Control Markup Language) is an XML-based language for access control that has been standardized by the Technical Committee of the OASIS consortium. XACML is popular as a fine grain authorization method among the community. However, there are aspects of XACML that surpasses other policy standards by being a fine-grained authorization mechanism.

Although XACML was introduced as a standard by OASIS in 2003, not many organizations that have been adapted adopted it yet. This is because of most organization's lack of interest in moving towards a XACML based solution for authorization. The following may can be some of the reasons for this:

Many software designer and developers lack a clear understanding of features, importance, and advantages of XACML.
It is comparatively difficult to implement a XACML solution when compared with a typical JDBC or hard-coded authorization system.
Performance of XACML-based authorization system may be less than adequate.
The complexity of defining and managing XACML policies.

...

is a standard which is ratified by OASIS standards organization.
is a policy language implemented using XML which is an industry standard.
supports Attribute-based Access Control (ABAC) and evaluation can be done with the additional data retrieved from Policy Information Point (PIP) which is defined by the XACML reference architecture.

Note

title	Note

Attribute-based Access Control(ABAC)

ABAC is an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc.). This model supports boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource, and the action. For example: IF the requestor is a manager, THEN allow read/write access to sensitive data.

...

Request attributes that are defined in the XACML response.
Applicable policy ids for a given XACML request are defined in the XACML response.

XACML 3.0 Multiple Decision Profile

This is new profile that comes with XACML 3.0 and is not included in the XACML3 core specification. However, this is very useful for performance improvement between PEP and PDP. This is especially the case since PEP can a useful profile that allows you to request more than one access control decision in a single XACML request context, and also allows you to request a single combined decision based on multiple individual decisions.

The XACML 3.0 Multiple Decision Profile (MDP) is particularly useful in scenarios where the PEP needs to request decisions for multiple requests in one XACML request.

Administrative Delegation Profile

This is also a new profile that comes with XACML 3.0. This allows you to define policies about who can write policies about what. For example, “Bob may issue a policy but only about resources in department X”.

XACML 2.0 and XACML 3.0 samples

The biggest difference between XACML 2.0 and XACML 3.0 for your client app is that the structure of the attributes in the authentication request has changed significantly in XACML 3.0.

In XACML 2.0, attributes were organized into subject, resource, environment, or action categories using XML element tags:

...

language	xml

...

, and provides a considerable improvement in performance between the PEP and the PDP in such scenarios.

For a set of tutorials that demonstrate how to work with XACML MDP requests in WSO2 Identity Server, see Working with XACML Multiple Decision Profile Requests.

XACML 3.0 JSON Profile

This is a new profile that provides a standardized interface between the PEP and the PDP using JSON. The decision request and response structure is specified in the core XACML specification.

With the introduction of the XACML 3.0 JSON profile, WSO2 Identity Server supports the JSON format in addition to the default XML format with regard to XACML 3.0 requests and responses.

Tip
WSO2 Identity Server also supports working with XACML MDP requests and responses in JSON format.

Anchor

	JSON
	JSON

Following are some of the key points to keep in mind when you work with XACML 3.0 JSON requests and responses via WSO2 Identity Server:

Certain parts of JSON requests and responses have default values to avoid bloating. For example, the default value of the data-type of an attribute should be string.
The name of the XACML XML attribute element has changed to the category object in JSON so that it is possible to call the parent element.
The <AttributeValue> element in the XML representation no longer exists. Instead a value property is introduced to the attribute object.
The AdviceId and the ObligationId attributes of <Advice/> and <Obligation/> XML elements are renamed to Id in JSON.
The order of objects and values in the serialized form (JSON) does not matter in XACML.
Anchor
shortName
shortName
You can use the short name of identifiers instead of the URI. Following are the supported identifier URIs and the short name for each:

Identifier URI Short name
urn:oasis:names:tc:xacml:

...

3.0

...

:attribute-category:resource	Resource
urn:oasis:names:tc:xacml:3.0:attribute-category:action	Action
urn:oasis:names:tc:xacml:3.0:attribute-category:environment	Environment
urn:oasis:names:tc:xacml:3.0:attribute-category:access-subject	AccessSubject
urn:oasis:names:tc:xacml:

...

3.0:

...

attribute-category:

...

recipient-subject	RecipientSubject
urn:oasis:names:tc:xacml:3.0:attribute-category:intermediary-subject	IntermediarySubject
urn:oasis:names:tc:xacml:3.0:attribute-category:codebase	Codebase
urn:oasis:names:tc:xacml:

...

3.0:

...

attribute-category:

...

requesting-machine RequestingMachine
The JSON format supports the fully qualified XACML data-type URI, and also supports the short name of the data-type.

XACML data type identifier JSON shorthand type code Mapping/inference rule
http://www.w3.org/2001/XMLSchema#string

...

In XACML 3.0, these categories are indicated using XML attributes instead of XML element tags:

...

language	xml

...

	string	JSON "String"
`http://www.w3.org/2001/XMLSchema#boolean`	boolean	JSON "Boolean"
`http://www.w3.org/2001/XMLSchema#integer`	integer	JSON "Number" without a fractional portion, and within the integer range defined by the XML schema in [XMLDatatypes]
`http://www.w3.org/2001/`

...

`XMLSchema#double`	double	JSON "Number" with a fractional portion, or out of the integer range defined by the XML schema in [XMLDatatypes]
`http://www.w3.org/2001/XMLSchema#time`	time	None. Inference must fail.
`http://www.w3.org/2001/`

...

XMLSchema#date date None. Inference must fail.
http://www.w3.org/2001/

...

XMLSchema#dateTime dateTime None. Inference must fail.
http://www.w3.org/2001/

...

XMLSchema#dayTimeDuration	dayTimeDuration	None. Inference must fail.
http://www.w3.org/2001/XMLSchema#yearMonthDuration	yearMonthDuration	None. Inference must fail.
http://www.w3.org/2001/XMLSchema#anyURI	anyURI	None. Inference must fail.
http://www.w3.org/2001/XMLSchema#hexBinary	hexBinary	None. Inference must fail.
http://www.w3.org/2001/XMLSchema#base64Binary	base64Binary	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:

...

data-

...

JSON Support with XACML 3.0

JSON (JavaScript Object Notation) is a lightweight, easy-to-work with format that is typically used in data exchange. WSO2 Identity Server supports sending XACML requests in JSON format via REST calls, and also supports recieving responses in the JSON format in an authorization flow.

Following are some of the key points you need to keep in mind when you work with XACML 3.0 JSON requests and responses:

Certain parts of JSON requests and responses have default values to avoid bloating. For example, the default value of the data-type of an attribute should be string.
The name of the XACML XML attributes element has changed to the category object in JSON so that it is possible to call the parent element.
The <AttributeValue> element in the XML representation no longer exists. Instead a value property is introduced to the attribute object.
The AdviceId and the ObligationId attributes of <Advice/> and <Obligation/> XML elements are renamed to Id in JSON.
The order of objects and values in the serialized form (JSON) does not matter in XACML.

AnchorshortNameshortNameYou can use the short name of identifiers instaed of the URI. Following are the Identifier URIs and the short name for each:

Identifier	Short name
type:rfc822Name	rfc822Name	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:x500Name	x500Name	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:ipAddress	ipAddress	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:dnsName	dnsName	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:xpathExpression	xpathExpression	None. Inference must fail.

xpathExpression data-type values are represented as JSON objects, and each object contains the following properties:

Attribute Type Required Default value
XPathCategory URI Yes. You can use the short names defined for identifier URIs as values here. None
Namespaces Array of namespace declarations No None
XPath String Yes None

The namespaces property should contain the following properties:

Attribute	Type	Required	Default value
Prefix	String	No	None
Namespace	URI	Yes	None

Following is a sample JSON attribute format that contains the fully qualified XACML data-type URI:

Code Block
{ "Attribute": { "AttributeId": "urn:oasis:names:tc:xacml:3.0:

attribute-category:resourceResourceurn:oasis:names:tc:xacml:3.0:attribute-category:actionAction

content-selector",
       "DataType": "xpathExpression",
       "Value": {
               "XPathCategory": "urn:oasis:names:tc:xacml:3.0:attribute-category:

environmentEnvironmenturn:oasis:names:tc:xacml:3.0:attribute-category:access-subjectAccessSubject

resource",
               "Namespaces": [{
                       "Namespace":   "urn:oasis:names:tc:xacml:3.0:

attribute-category:recipient-subjectRecipientSubjecturn:oasis:names:tc:xacml:3.0:attribute-category:intermediary-subjectIntermediarySubjecturn:oasis:names:tc:xacml:3.0:attribute-category:codebaseCodebaseurn:oasis:names:tc:xacml:3.0:attribute-category:requesting-machineRequestingMachine

JSON format supports the fully qualified XACML data-type URI, and also supports the short name of the data-type.

XACML data type identifierJSON shorthand type codeMapping/inference rulehttp://www.w3.org/2001/XMLSchema#stringstringJSON "String"http://www.w3.org/2001/XMLSchema#booleanbooleanJSON "Boolean"http://www.w3.org/2001/XMLSchema#integerintegerJSON "Number" without a fractional portion, and within the integer range defined by the XML schema in [XMLDatatypes]http://www.w3.org/2001/XMLSchema#doubledoubleJSON "Number" with a fractional portion, or out of the integer range defined by the XML schema in [XMLDatatypes]http://www.w3.org/2001/XMLSchema#timetimeNone. Inference must fail.http://www.w3.org/2001/XMLSchema#datedateNone. Inference must fail.http://www.w3.org/2001/XMLSchema#dateTimedateTimeNone. Inference must fail.

core:schema:wd-17"
                       }, {
                       "Prefix": "md",
                       "Namespace":   "urn:example:med:schemas:record"
                           }],
               "XPath":"md:record/md:patient/md:patientDoB"
        }
   }
}

The MultiRequests object is optional in the JSON representation of XACML. The purpose of the MultiRequests object is to support the XACML multiple decision profile.

The JSON attribute object contains an array of attribute objects. The attribute object contains the following properties:

Property name	Type	Required	Default value
AttributeId	URI	Yes	None. The identifier used in the XML representation of a XACML attribute will be used in its JSON representation
Value	Either string, boolean, number (this maps to either a XACML integer or double as defined in supported data types), object, array of strings, array of boolean, Array of number, array of object, or a mixed array of string and number where the string values represents a numerical value.	Yes	None.
Issuer	String	No	Null
Data Type	URI	No	The data type value can be omitted in the JSON representation. The default value is `http://www.w3.org/2001/`XMLSchema#dayTimeDuration	dayTimeDuration	None. Inference must fail.
http://www.w3.org/2001/XMLSchema#yearMonthDuration	yearMonthDuration	None. Inference must fail.
http://www.w3.org/2001/XMLSchema#anyURI	anyURI	None. Inference must fail.
http://www.w3.org/2001/XMLSchema#hexBinary	hexBinary	None. Inference must fail.
http://www.w3.org/2001/XMLSchema#base64Binary	base64Binary	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name	rfc822Name	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:x500Name	x500Name	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:ipAddress	ipAddress	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:dnsName	dnsName	None. Inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:xpathExpression	xpathExpression	None. Inference must fail.

Values of the xpathExpression data-type are represented as JSON objects, and each object contains the following properties:

AttributeTypeRequiredDefault valueXPathCategoryURIYes. You can use the short names defined for identifier URIs as values here.NoneNamespacesArray of namespace declarationsNoNoneXPathStringYesNone

The namespaces property should contain the following properties:

AttributeTypeRequiredDefault valuePrefixStringNoNoneNamespaceURIYesNoneFollowing is a sample JSON attribute format: Code Block{ "Attribute": {

`XMLSchema#string` .
IncludeInResult	Boolean	No	False

The results of the JSON request is represented by the decision object in the form of a JSON Object. This can have following properties:

Property name Type Required Default value
Decision String Yes. Possible values are: Permit, Deny, NotApplicable, Indeterminate None.
The results can have the status, obligations, associatedAdvice, category, and policyIdentifierList, which are optional.

Following is a sample JSON request that you can try out with WSO2 Identity Server:

Code Block

{
   "Request": {
      "AccessSubject": {
         "Attribute": [
            {
               "AttributeId": "subject-id",
               "Value": "sam",
               "DataType": "string",
               "IncludeInResult": true
            }
         ]
      },
     
      "Resource": {
         "Attribute": [
            {
               "AttributeId": "resource-id",
               "Value": "index.jsp",
               "DataType": "string",
               "IncludeInResult": true
            }
         ]
      },
      "Action": {
            "Attribute": [{
                    "AttributeId": "action-id",
                    "Value": "modify-welcome",
                    "

...

DataType": "

...

string",

...

IncludeInResult":

...

true

...

 }
            ]

...

Following is a sample XACML JSON response that you will get for the above request:

Code Block
{ "

...

Response":

...

[
        {
            "

...

Decision": "

...

Deny",

...

"Status":

...

{
                "StatusCode": {

...

The JSON attribute object contains an array of attribute objects. The attribute object contains the following properties:

...

The results of the JSON request is represented by the decision object in the form of a JSON Object. This can have following properties:

...

Following is a sample JSON request that you can try out with WSO2 Identity Server:

Code Block

{
   "Request": {  "Value": "urn:oasis:names:tc:xacml:1.0:status:ok"
                }
            },
            "AccessSubject": {
                "Attribute": [
            {        {
       "AttributeId": "subject-id",                "ValueAttributeId": "dinalisubject-id",
                        "DataTypeValue": "stringdinali",
               "IncludeInResult": true        "IncludeInResult": "true",
   }          ]       },    "DataType": "string"
       "Resource": {          "Attribute": [     }
         {       ]
        "AttributeId": "resource-id",   },
            "ValueResource": "index.jsp",{
                "DataTypeAttribute": "string",[
               "IncludeInResult": true    {
        }          ]       },"AttributeId": "resource-id",
          "Action": {             "AttributeValue": [{"index.jsp",
                        "AttributeIdIncludeInResult": "action-idtrue",
                        "ValueDataType": "modify-welcome",string"
                    }
  "DataType": "string",             ]
       "IncludeInResult": true    },
            }"Action": {
           ]     "Attribute": [
   }             } }

...

Code Block

{   {
 "Response": [         {             "DecisionAttributeId": "Denyaction-id",
            "Status": {           "Value": "modify-welcome",
    "StatusCode": {                     "ValueIncludeInResult": "urn:oasis:names:tc:xacml:1.0:status:ok"true",
                }        "DataType": "string"
    },             "AccessSubject": {  }
              "Attribute": [ ]
            }
      {  }
                      "AttributeId": "subject-id",
                        "Value": "dinali",]
}

Administrative Delegation Profile

This is also a new profile that comes with XACML 3.0. This allows you to define policies about who can write policies about what. For example, “Bob may issue a policy but only about resources in department X”.

XACML 2.0 and XACML 3.0 samples

The biggest difference between XACML 2.0 and XACML 3.0 for your client app is that the structure of the attributes in the authentication request has changed significantly in XACML 3.0.

In XACML 2.0, attributes were organized into subject, resource, environment, or action categories using XML element tags:

Code Block

language	xml

<Request  xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             "IncludeInResult": "true",xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os  access_control-xacml-2.0-context-schema-os.xsd">
        <Subject>
               "DataType": "string"<Attribute
                     }AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
                ]   DataType="http://www.w3.org/2001/XMLSchema#string">
         },       <AttributeValue>Julius Hibbert</AttributeValue>
    "Resource": {       </Attribute>
         "Attribute": [</Subject>
        <Resource>
             {
   <Attribute
                    "AttributeId=": "urn:oasis:names:tc:xacml:1.0:resource:resource-id",
                        "Value": "index.jsp",
   DataType="http://www.w3.org/2001/XMLSchema#anyURI">
                    "IncludeInResult": "true",<AttributeValue>http://medico.com/record/patient/BartSimpson</AttributeValue>
            </Attribute>
        </Resource>
   "DataType": "string"    <Action>
            <Attribute
   }               AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
 ]             },             "Action": {DataType="http://www.w3.org/2001/XMLSchema#string">
                 "Attribute": [<AttributeValue>read</AttributeValue>
            </Attribute>
        </Action>
 {       <Environment/>
</Request>

In XACML 3.0, these categories are indicated using XML attributes instead of XML element tags:

Code Block

language	xml

<?xml version="1.0" encoding="utf-8"?>
<Request xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd" ReturnPolicyIdList="false"           "AttributeId": "action-id",
             CombinedDecision="false" xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
          "Value": "modify-welcome",<Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
                        "IncludeInResult": "true",
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Julius Hibbert</AttributeValue>
    </Attribute>
  </Attributes>
  <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
           "DataType": "string"<Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://medico.com/record/patient/BartSimpson</AttributeValue>
    </Attribute>
  </Attributes>
    }
        <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
    <Attribute IncludeInResult="false"  ]AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
    </Attribute>
}  </Attributes>
  <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"   }
    ]
}

For a tutorial on how to send XACML requests in JSON format via the XACML REST profile, see Fine-grained Authorization using XACML Requests in JSON Format.

...

/>
</Request>

The <Subject> element in XACML 2.0 becomes <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"> in XACML 3.0, for example. This is the same for the resource, environment, and action categories.

Versions Compared

Old Version 5

New Version 6

Key

Types of access control

Introducing XACML

Attribute-based Access Control(ABAC)

XACML 3.0 Multiple Decision Profile

Administrative Delegation Profile

XACML 2.0 and XACML 3.0 samples

XACML 3.0 JSON Profile

JSON Support with XACML 3.0

Administrative Delegation Profile

XACML 2.0 and XACML 3.0 samples

`XMLSchema#date`	date	None. Inference must fail.
`http://www.w3.org/2001/`

`XMLSchema#dateTime`	dateTime	None. Inference must fail.
http://www.w3.org/2001/

Attribute	Type	Required	Default value
XPathCategory	URI	Yes. You can use the short names defined for identifier URIs as values here.	None
Namespaces	Array of namespace declarations	No	None
XPath	String	Yes	None