XACML 2.0核心规范与Sun公司解析器：访问控制语言详解

需积分: 31 185 浏览量更新于2024-07-25 收藏 603KB PDF 举报

XACML (eXtensible Access Control Markup Language) 是一种用于实现访问控制的标准化语言，版本2.0在本文件中得到了详尽定义。这份文档，access_control-xacml-2.0-core-spec-os，发布于2005年2月，由OASIS (Organization for the Advancement of Structured Information Standards) 开发并维护，版权归OASIS所有。该规范的主要目标是提供一个可扩展的框架，以便在不同系统和应用环境中统一管理和控制访问权限。 XACML 2.0标准的核心部分涵盖了访问控制的各个方面，包括授权策略的表述、规则集的设计以及如何通过XML格式进行通信。它定义了请求和响应的结构，以及如何评估这些请求以确定是否授予访问权限。核心规范文档详细描述了以下内容： 1. **定义与架构** - 规定了XACML的基本概念，如主体（Subject）、行动（Action）、资源（Resource）和环境（Environment），这四个元素共同决定了访问决策。 2. **政策模型** - 提供了如何组合和应用访问控制规则的模型，允许灵活地根据用户、操作和上下文动态调整授权策略。 3. **表达式语言** - 通过使用XPath或函数，XACML允许创建复杂的条件判断，以更精确地控制对资源的访问。 4. **请求和响应流程** - 描述了请求者如何发起访问请求，以及授权服务如何接收、解析、评估请求并返回决定的过程。 5. **标准元素和数据类型** - 规范了XACML中使用的各类数据类型和元素，如Boolean、日期、时间等，以及它们在访问控制决策中的作用。 6. **合规性与标准化** - 表明此版本的XACML已成为OASIS Access Control Technical Committee（AC-TC）批准的标准，鼓励成员对其进行评论和反馈，同时提供了专利披露和许可条款的信息。 7. **作者与联系信息** - 作者Tim Moses来自Entrust Inc., 负责文档编辑工作，有兴趣的人可以通过指定邮件列表xacml@lists.oasis-open.org提交意见，或者访问OASIS官网获取更多信息。对于那些希望在IT领域中实施XACML 2.0核心功能的开发者来说，这份文档是不可或缺的基础参考资料。理解并遵循XACML规范，能够帮助构建安全、灵活的访问控制机制，确保数据和系统的访问符合组织策略和法规要求。在实际应用中，开发者可能还需要结合实际系统的需求，阅读Sun公司的XACML解析器源码，以将其功能整合到自己的项目中。

access_control-xacml-2.0-core-spec-os 1 February 2005

The use of constraints limiting the applicability of a policy were described by Sloman [Sloman94]. 533

2.11. Abstraction layer 534

PEPs come in many forms. For instance, a PEP may be part of a remote-access gateway, part of 535

a Web server or part of an email user-agent, etc.. It is unrealistic to expect that all PEPs in an 536

enterprise do currently, or will in the future, issue decision requests to a PDP in a common format. 537

Nevertheless, a particular policy may have to be enforced by multiple PEPs. It would be inefficient 538

to force a policy writer to write the same policy several different ways in order to accommodate the 539

format requirements of each PEP. Similarly attributes may be contained in various envelope types 540

(e.g. X.509 attribute certificates, SAML attribute assertions, etc.). Therefore, there is a need for a 541

canonical form of the request and response handled by an XACML PDP. This canonical form is 542

called the XACML context. Its syntax is defined in XML schema. 543

Naturally, XACML-conformant PEPs may issue requests and receive responses in the form of an 544

XACML context. But, where this situation does not exist, an intermediate step is required to 545

convert between the request/response format understood by the PEP and the XACML context 546

format understood by the PDP. 547

The benefit of this approach is that policies may be written and analyzed independent of the 548

specific environment in which they are to be enforced. 549

In the case where the native request/response format is specified in XML Schema (e.g. a SAML-550

conformant PEP), the transformation between the native format and the XACML context may be 551

specified in the form of an Extensible Stylesheet Language Transformation [XSLT]. 552

Similarly, in the case where the resource to which access is requested is an XML document, the 553

resource itself may be included in, or referenced by, the request context. Then, through the use 554

of XPath expressions [XPath] in the policy, values in the resource may be included in the

policy 555

evaluation. 556

2.12. Actions performed in conjunction with enforcement 557

In many applications, policies specify actions that MUST be performed, either instead of, or in 558

addition to, actions that MAY be performed. This idea was described by Sloman [Sloman94]. 559

XACML provides facilities to specify actions that MUST be performed in conjunction with policy 560

evaluation in the <Obligations> element. This idea was described as a provisional action by 561

Kudo [Kudo00]. There are no standard definitions for these actions in version 2.0 of XACML. 562

Therefore, bilateral agreement between a PAP and the PEP that will enforce its policies is required 563

for correct interpretation. PEPs that conform with v2.0 of XACML are required to deny access 564

unless they understand and can discharge all of the <Obligations> elements associated with the 565

applicable policy. <Obligations> elements are returned to the PEP for enforcement. 566

3. Models (non-normative) 567

The data-flow model and language model of XACML are described in the following sub-sections. 568

3.1. Data-flow model 569

The major actors in the XACML domain are shown in the data-flow diagram of

Figure 1. 570

access_control-xacml-2.0-core-spec-os 1 February 2005

6. The context handler requests the attributes from a PIP. 587

7. The PIP obtains the requested attributes. 588

8. The PIP returns the requested attributes to the context handler. 589

9. Optionally, the context handler includes the resource in the context. 590

10. The context handler sends the requested attributes and (optionally) the resource to the PDP. 591

The PDP evaluates the policy. 592

11. The PDP returns the response context (including the authorization decision) to the context 593

handler. 594

12. The context handler translates the response context to the native response format of the 595

PEP. The context handler returns the response to the PEP. 596

13. The PEP fulfills the obligations. 597

14. (Not shown) If access is permitted, then the PEP permits access to the resource; otherwise, it 598

denies access. 599

3.2. XACML context 600

XACML is intended to be suitable for a variety of application environments. The core language is 601

insulated from the application environment by the XACML context, as shown in Figure 2, in which 602

the scope of the XACML specification is indicated by the shaded area. The XACML context is 603

defined in XML schema, describing a canonical representation for the inputs and outputs of the 604

PDP. Attributes referenced by an instance of XACML policy may be in the form of XPath 605

expressions over the context, or attribute designators that identify the attribute by subject, 606

resource, action or environment and its identifier, data-type and (optionally) its issuer. 607

Implementations must convert between the attribute representations in the application environment 608

(e.g., SAML, J2SE, CORBA, and so on) and the attribute representations in the XACML context. 609

How this is achieved is outside the scope of the XACML specification. In some cases, such as 610

SAML, this conversion may be accomplished in an automated way through the use of an XSLT 611

transformation. 612

domain-specific

inputs

domain-specific

outputs

xacml Context/

Request.xml

xacml Context/

Response.xml

PDP

xacml

Policy.xml

613

Figure 2 - XACML context 614

Note: The PDP is not required to operate directly on the XACML representation of a policy. It may 615

operate directly on an alternative representation. 616

See Section 7.2.5 for a more detailed discussion of the request context. 617

access_control-xacml-2.0-core-spec-os 1 February 2005

encapsulated in a policy. A rule can be evaluated on the basis of its contents. The main 629

components of a rule are: 630

• a target; 631

• an effect and 632

• a condition. 633

These are discussed in the following sub-sections. 634

3.3.1.1. Rule target 635

The target defines the set of: 636

• resources; 637

• subjects; 638

• actions and 639

• environment 640

to which the rule is intended to apply. The <Condition> element may further refine the 641

applicability established by the target. If the rule is intended to apply to all entities of a particular 642

data-type, then the corresponding entity is omitted from the target. An XACML PDP verifies that 643

the matches defined by the target are satisfied by the subjects, resource, action and 644

environment attributes in the request context. Target definitions are discrete, in order that 645

applicable rules may be efficiently identified by the PDP. 646

The <Target> element may be absent from a <Rule>. In this case, the target of the <Rule> is 647

the same as that of the parent <Policy> element. 648

Certain subject name-forms, resource name-forms and certain types of resource are internally 649

structured. For instance, the X.500 directory name-form and RFC 822 name-form are structured 650

subject name-forms, whereas an account number commonly has no discernible structure. UNIX 651

file-system path-names and URIs are examples of structured resource name-forms. And an XML 652

document is an example of a structured resource. 653

Generally, the name of a node (other than a leaf node) in a structured name-form is also a legal 654

instance of the name-form. So, for instance, the RFC822 name "med.example.com" is a legal 655

RFC822 name identifying the set of mail addresses hosted by the med.example.com mail server. 656

And the XPath/XPointer value //xacml-context:Request/xacml-context:Resource/xacml-657

context:ResourceContent/md:record/md:patient/ is a legal XPath/XPointer value identifying a 658

node-set in an XML document. 659

The question arises: how should a name that identifies a set of subjects or resources be 660

interpreted by the PDP, whether it appears in a policy or a request context? Are they intended to 661

represent just the node explicitly identified by the name, or are they intended to represent the entire 662

sub-tree subordinate to that node? 663

In the case of subjects, there is no real entity that corresponds to such a node. So, names of this 664

type always refer to the set of subjects subordinate in the name structure to the identified node. 665

Consequently, non-leaf subject names should not be used in equality functions, only in match 666

functions, such as “urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match” not 667

“urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal” (see Appendix A). 668

剩余140页未读，继续阅读

xiaoshaoye1130

粉丝: 0
资源: 1

XACML 2.0核心规范与Sun公司解析器：访问控制语言详解

XACML Profile for Role Based Access

XACML Learning Tool-开源

XACML实例和中文说明文档

解析SAMLresponse详细的工具类和依赖

XACML java

XACML-<Target> 元素的结构与相关的评估

策略描述语言，XACML是什么，使用实例

策略描述语言，XACML

abac权限 开源有哪些

最新资源

abac权限开源有哪些