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.
...
- Can business managers (who should determine how access controls would be implemented) define and modify different authorization logic?
- Can we find new IT technicians to manage these legacy systems? Especially when those who developed the system have left the organization?
- Can different authorization logic be modified without any source code changes in a dynamic way?
- Is authorization system capable of evaluating following rule? “X resource can be accessed by the Users who are from example.com domain and whose age is greater than 21 years old”
- If we are going to implement a new information system with the organization, can we re-use the authorization logic of a legacy system?
- Can we achieve a fine-grained authorization level without defining a large number of static combinations?
- Are the authorization systems capable of answering the questions such as: “Can a user, Bob Alex, transfer transfer X amount from Y current account at 1.00pm?“
...
Advice is a newly introduced feature with XACML 3.0. Advice is similar to obligations and it shares much of its syntax. The difference is contractual: the PEP can disregard any advice it receives. PEPs do not have to comply with advice statements; PEPs can consider or discard the statement. A common scenario is to explain why something was denied: “User bob Alex is denied because he because Alex does not have a valid email”.
...
As an example, let's look at a Target element. In XACML 2.0, we have an AND relationship between foo1 and foo2 resources and an OR relationship between bar1 and bar2 actions. However, we cannot create an OR relationship between a foo1 resource and bar1 action. so we cannot define something such as “Target would be matched when Bob Alex can access the foo resource or do a bar action” by using the Target element.
...
XACML 3.0 has an AND relationship between “foo” resource and “bar1″ role and an OR relationship between “bar2″ action. So we cannot define something as “Target would be matched, when Bob Alex can access foo resource and do bar1 action or do bar2 action”.
...
| Code Block |
|---|
{
"Response": [
{
"Decision": "Deny",
"Status": {
"StatusCode": {
"Value": "urn:oasis:names:tc:xacml:1.0:status:ok"
}
},
"AccessSubject": {
"Attribute": [
{
"AttributeId": "subject-id",
"Value": "dinali",
"IncludeInResult": "true",
"DataType": "string"
}
]
},
"Resource": {
"Attribute": [
{
"AttributeId": "resource-id",
"Value": "index.jsp",
"IncludeInResult": "true",
"DataType": "string"
}
]
},
"Action": {
"Attribute": [
{
"AttributeId": "action-id",
"Value": "modify-welcome",
"IncludeInResult": "true",
"DataType": "string"
}
]
}
}
]
} |
For a tutorial that demonstrate how WSO2 IS supports fine-grained authorization using XACML requests in JSON format, see Fine-grained Authorization using XACML Requests in JSON Format.
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 “Alex may issue a policy but only about resources in department X”.
...
| Code Block | ||
|---|---|---|
| ||
<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os access_control-xacml-2.0-context-schema-os.xsd">
<Subject>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>Julius Hibbert</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI">
<AttributeValue>http://medico.com/record/patient/BartSimpson</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<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 | ||
|---|---|---|
| ||
<?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" 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">
<Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
<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">
<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" />
</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.