This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
XACML
XACML

Version management

Difference between version and

At line 1 added 49 lines
!!! Overview[1]
[{$pagename}] stands for [eXtensible Access Control Markup Language]. [{$pagename}] is a [Policy Based Management System] that defines a declarative [Access Control] [policy] language implemented in [XML] and a processing model describing how to evaluate [authorization] requests according to the rules defined in policies.
As a published standard specification, one of the goals of [{$pagename}] is to promote common terminology and interoperability between authorization implementations by multiple vendors.
[{$pagename}] is primarily an [Attribute Based Access Control] ([ABAC]) system, where [attributes] associated with an [Entity] or [Resource Action] or [resource] are inputs into the decision of whether a given [Entity] may access a given [resource] and perform a particular [Resource Action].
[Role Based Access Control] ([RBAC]) can also be implemented in [{$pagename}] as a specialization of [ABAC].
The [{$pagename}] model supports and encourages the separation of the [authorization] decision from the point of use. When [authorization] decisions are baked into client [applications] (or based on local machine users and [Access Control Lists] ([ACLs])), it is very difficult to update the decision criteria when the governing [policy] changes. When the client is decoupled from the authorization decision, authorization policies can be updated on the fly and affect all clients immediately.
!!! Core [RBAC] and [{$pagename}]
Core [RBAC], includes the following five basic data elements:
* [Users] - Users are implemented using [{$pagename}] [Subjects]. Any of the [{$pagename}] Subject Category values may be used, as appropriate.
* [Roles] - Roles are expressed using one or more [{$pagename}] Subject Attributes. The set of roles is very application and policy domain-specific, and it is very important that different uses of roles not be confused. For these reasons, [{$pagename}] is not attempting to define any standard set of roles. It is recommended that each application or policy domain agree on and publish a unique set of AttributeId values, DataType values, and <AttributeValue> values that will be used for the various roles relevant to that domain.
* Objects - Objects are expressed using [{$pagename}] [Resources].
* Operations - Operations are expressed using [{$pagename}] Actions.
* [Permissions] - Permissions are expressed using [{$pagename}] [Role] <PolicySet> (RPS) and [Permission] <PolicySet> (PPS) instances as described in previous sections.
Core [RBAC] requires support for multiple users per role, multiple roles per user, multiple permissions per role, and multiple roles per permission. Each of these requirements can be satisfied by [{$pagename}] policies based on this Profile as follows. Note, however, that the actual assignment of roles to users is outside the scope of the [{$pagename}] PDP.
!! [{$pagename}] [Versions]
* version 2.0 was ratified by OASIS standards organization on 1 February [2005|Year 2005]. As of [2007|Year 2007],
* version 3.0 adds generic [attribute] categories for the evaluation context and policy [delegation] profile (administrative policy profile) was standardized in January [2013|Year 2013]
** Contains [REST Profile of XACML]
** Multiple Decision Profile: Multiple resource request (XACML 2.0) was renamed Multiple Decision Profile (XACML 3.0) and enhanced with new variants. This profile lets a requestor –typically the Policy Enforcement Point (PEP) ask several questions in one go to which the Policy Decision Point (PDP) returns one answer with multiple decisions. This profile is particularly useful in web-portal-based scenarios where decisions have to be reached for different parts of a portal within a given page for a given user. It enhances performance as it reduces communication overhead between PEP and PDP.
** [Delegation]: the ability to delegate administrative rights in XACML is new as of XACML 3.0. Delegation enables global administrators to delegate constrained administrative rights to local administrators. For instance, a global administrator can define access control (AC) policies for an entire set of resources within an organization. The administrator can also delegate the right to Administrator A to manage a set of resources SA. Administrator A’s rights to define access control rules are constrained by the delegation policy that the global administrator has defined. Delegation is most useful in federation scenarios, cloud-based scenarios, and in environments where the domains to secure are so vast that they require local knowledge to define relevant policies.
** Obligation expressions: this new feature lets administrators define statements that are returned from the PDP to the PEP along with a PERMIT or DENY decision. The receiving PEP has to comply with that statement before it can act on the decision. An example of an obligation is as follows: \\Request: Can Doctor X access Patient Y’s data? \\Response: Permit, he can, provided you, the PEP, write in the hospital access log, the fact that Doctor X has had access to Patient Y’s data.
** Advice expressions: this new feature is similar to obligations with the exception that PEPs do not have to comply with the statement. PEPs can consider or discard the statement.
** Policy combination algorithms: in XACML, policies are combined together to produce a single decision. Each policy can reach different decisions. These decisions must be combined to return a single result. XACML 3.0 enhances XACML 2.0’s existing combination algorithms.
** New attribute functions and datatypes: XACML 3.0 brings in new datatypes and new functions that can be used for the attributes and attribute matching. In particular XACML 3.0 utilizes XPath to manipulate attributes.
** New profiles: XACML 3.0 brings additional profiles. In particular a new profile for export compliance has been produced to help author policies that can cater for export compliance scenarios. Similarly, a new profile for [Intellectual Property] Control (IPC) has been introduced.
** Enhanced profiles: the Hierarchical Resource Profile present in XACML 2.0 has been reviewed and enhanced in XACML 3.0.
For the latest information visit the [OASIS eXtensible Access Control Markup Language (XACML) TC|http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml] site and their [Wiki|http://wiki.oasis-open.org/xacml/].
!! XACML is dead [2]
Here are the reasons why we predict XACML is dead:
* Lack of broad adoption. The standard is still not widely adopted with large enterprises who have written their authorization engines.
* Inability to serve the federated, extended enterprise. XACML was designed to meet the [authorization] needs of the monolithic enterprise where all users are managed centrally in [Microsoft Active Directory]. This is clearly not the case today: companies increasingly have to deal with users whose identities they do not manage.
* [PDP] does a lot of complex things that it does not inform the [PEP] about. If you get a 'no, you can't do that' decision in the application from the [PEP], you'd want to know why. Our customers tell us that this can prove to be very difficult. The PEP may not be able to find out from the complex PDP evaluation process why an [authorization] was denied.
* Not suitable for [Cloud computing] and [Distributed system] deployment. While some [PEPs] can bundle the [PDP] for faster performance, using a [PEPs] in a cloud environment where you only have a [WAN] link between a [PDP] and a [PEP] is not an option.
* Commercial support is non-existent. There is no software library with [PEP] support. Major ISVs have not implemented externalized authorization or plugin frameworks for externalized authorization. Replacing native [SharePoint] [authorization] with an [Entitlement] Management [PEP] is a nightmare requiring a one-off, non-standard, non-repeatable development and operations process.
* Refactoring and rebuilding existing in-house applications is not an option. [Entitlement] Management deployment requires a refactoring of the application to use the [PEP] hooks for centralized, externalized authorization. This is not a reality at most companies. They cannot just refactor [applications] because of a different [authorization] model (sometimes, especially with [mainframe] [applications] the [authorization] model is not even understood well enough to do this…)
* [OAuth 2.0] supports the [Mobile Device] [application] [endpoint] in a lightweight manner. [XACML] today largely supports web based applications. While OAuth's current profiles are not a full-blown replacement for [XACML] functionality, we see that OAuth's simplicity made it the de-facto choice for mobile and also non-mobile applications. !! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [XACML|http://en.wikipedia.org/wiki/XACML|target='_blank'] - based on information retrieved 2013-09-06
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop