ETSI GS INS 008-2012 Identity and access management for Networks and Services (INS) Distributed access control enforcement framework Architecture (V1 1 1)《网络与业务的身份与访问管理(INS) 分布式访问控_1.pdf

《ETSI GS INS 008-2012 Identity and access management for Networks and Services (INS) Distributed access control enforcement framework Architecture (V1 1 1)《网络与业务的身份与访问管理(INS) 分布式访问控_1.pdf》由会员分享，可在线阅读，更多相关《ETSI GS INS 008-2012 Identity and access management for Networks and Services (INS) Distributed access control enforcement framework Architecture (V1 1 1)《网络与业务的身份与访问管理(INS) 分布式访问控_1.pdf（23页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI GS INS 008 V1.1.1 (2012-05) Identity and access management for Networks and Services (INS); Distributed access control enforcement framework; Architecture Disclaimer This document has been produced and approved by the Identity and access management for Networks and Services ETSI Industry Speci

2、fication Group (ISG) and represents the views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. Group Specification ETSI ETSI GS INS 008 V1.1.1 (2012-05) 2Reference DGS/INS-008 Keywords access, control, ID, privacy, security ETS

3、I 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be d

4、ownloaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the refer

5、ence shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents

6、is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permissio

7、n. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2012. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Mark

8、s of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI GS INS 008 V1.1.1 (2012-05) 3Contents Intellectual Property Rights 5g3Foreword . 5g3Introduction 5g31 Scope 6g32 Re

9、ferences 6g32.1 Normative references . 6g32.2 Informative references 6g33 Definitions and abbreviations . 7g33.1 Definitions 7g33.2 Abbreviations . 7g34 Current Architectures . 7g35 Requirements Overview . 8g35.1 Distributed Access Control Requirements . 8g35.2 Requirements of an Enforcement Framewo

10、rk in a Distributed Environment 10g36 Impact of requirements on current Architecture 11g37 General Functional Architecture Definition . 11g37.1 PEP . 12g37.2 CH 12g37.3 PDP 12g37.4 PAP 13g37.5 PIP 13g37.6 Authentication Verifier . 13g37.7 Trust Management 13g37.8 DPIP . 13g37.9 DPDP 13g37.10 Obligat

11、ion Handler . 13g37.11 Logging 13g38 Interface Definition 14g38.1 Access Request/Response 14g38.1.1 Operation: Authorize 14g38.2 Obligation Support . 14g38.2.1 Datatype: Obligation Definition . 14g38.2.2 Operation: SupportedObligations . 14g38.2.3 Operation: UsedObligations 15g38.2.4 Operation: Requ

12、estSupportedObligations . 15g38.2.5 Operation: RequestUsedObligations . 15g38.3 Referred Attribute. 16g38.3.1 Datatype: Referred Attribute Query 16g38.3.2 Operation: Referred Attribute Query 16g38.4 Referred Decision Request/Response . 17g38.4.1 Datatype: Referred Request and Referred Response 17g38

13、.4.2 Operation: Referred Authorize . 17g38.5 Trust Management 17g38.5.1 Datatype: Reputation bundle. 18g38.5.2 Datatype: Reputation 18g38.5.3 Datatype: Context . 18g38.5.4 Datatype: Subject 18g38.5.5 Datatype: Score . 19g38.5.6 Datatype: Date 19g38.5.7 Operation: Request Reputation Information . 19g

14、38.5.8 Operation: Provide Reputation Information . 19g3ETSI ETSI GS INS 008 V1.1.1 (2012-05) 49 Protocol Definition . 20g39.1 Referred Attribute Requests . 20g39.2 Referred Access Decisions . 20g39.3 Obligation Exchange 20g39.4 Authentication Verifier . 21g310 Conclusion 21g3Annex A (informative): A

15、uthors Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/ipr.etsi.org). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been

16、 carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Group Specification (GS) has been produced by ETSI Industr

17、y Specification (ISG) Identity and access management for Networks and Services (INS). Introduction Identity and access management is an important issue for network providers and likewise for service providers. Based on the new concepts being introduced in recent years, the architecture for providing

18、 the related functionalities in a distributed environment has to be reconsidered. While users are utilizing various services over all kind of networks, they still need to stay in control of their private data. Especially the distributed aspects and the enforcement of the decisions in the given envir

19、onment have to be considered. In previous work items, the ISG on Identity and access management for Networks and Services (INS) has specified requirements for, distributed access control especially for telecommunication use cases (WI 2) and an access control policy enforcement framework (WI 5). Base

20、d on these two documents i.1 and i.2 an architecture of a distributed access control and enforcement framework will be presented. The identified requirements will be revisited and their impact will be categorised according to their impact on the overall architecture, functionality aspects, the acces

21、s control policy language etc. The impact on current architectures is analysed and a general functional architecture is presented. After that the details on the interfaces and the relevant protocols are specified. ETSI ETSI GS INS 008 V1.1.1 (2012-05) 61 Scope The present document categorizes the re

22、quirements of a distributed policy management for telecommunication and services as well as a distributed enforcement environment that have been indentified in GS INS 002 i.1 and GS INS 005 i.2 based on several use cases. These requirements are categorized in the present document to identify their i

23、mpact on the architecture, general or specific functionality, interfaces, or protocols. These requirements are categorized in the present document to identify their impact on the architecture, general or specific functionality, interfaces, or protocols. Based on this categorization, new functional e

24、ntities are identified and an overall architecture defined. The interfaces of the new functional entities are specified. For exchange protocols between the entities, we rely on existing protocols, if possible, keeping the definition of new protocols minimal. 2 References References are either specif

25、ic (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. Referenced documents which are not fo

26、und to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. 2.1 Normative references The following referenced documen

27、ts are necessary for the application of the present document. Not applicable. 2.2 Informative references The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 ETSI GS INS 002: “Identity

28、and Access Management for Networks and Services; Distributed Access Control for Telecommunications; Use Cases and Requirements“. i.2 ETSI GS INS 005: “Identity and access management for Networks and Services; Requirements of an Enforcement Framework in a Distributed Environment“. i.3 OASIS: “eXtensi

29、ble Access Control Markup Language (XACML) v2.0“, 1 February 2005. i.4 OASIS: “eXtensible Access Control Markup Language (XACML) v3.0“, 10 August 2010. Committee Specification 01. i.5 OASIS Standard: “Security Assertion Markup Language (SAML) v2.0, profile of XACML v2.0“, 1 February 2005. i.6 IETF R

30、FC 3986: “Uniform Resource Identifier (URI): Generic Syntax“. ETSI ETSI GS INS 008 V1.1.1 (2012-05) 73 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: associated/sticky policies: policies associated with obfuscated us

31、er data and sent around with this data, determining the relevant disclosure constraints NOTE: Sticky policies are usually specified as the results of an automated matching between users wishes and service providers promises with regard to data handling. They contain the authorization rules and oblig

32、ations that the PEP is obliged to enforce. obligation: operation specified in conjunction with a policy, either by the data owner or other relevant entities, and should be enforced as part of a policy decision NOTE: Obligations may be triggered by timing constraints, by policy violations, or by even

33、t notifications from other entities. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: CH Context Handler DPDP Distributed Policy Decision Point DPIP Distributed Policy Information Point IdM Identity Management IdP Identity ProviderIETF Internet Engineeri

34、ng Task Force ITU-T International Telecommunication Union - Telecommunication Standardization Sector OASIS Organisation for the Advancement of Structured Information Standards PAP Policy Administration Point PDP Policy Decision Point PEP Policy Enforcement Point PIP Policy Information Point RFC Requ

35、est for CommentsSAML Security Assertion Markup Language SOAP Simple Object Access Protocol SP Service Provider TISPAN ETSI Technical Committee for Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) URI Uniform Resource Identifier URL Uniform Resource Lo

36、cation UTC Universal Time Coordinated XACML eXtensible Access Control Markup Language XML eXtensible Markup Language 4 Current Architectures The different architectures specified by standard bodies such as 3GPP, TISPAN, IETF or OASIS have been discussed in the preceding work items 2 i.1 and 5 i.2. E

37、TSI ETSI GS INS 008 V1.1.1 (2012-05) 85 Requirements Overview The following two clauses provide an overview of the requirements identified in WI2 and WI5. For cross referencing, the numbering of the requirements is identical to those in WI2 and WI5, except that an A (Access Control) and E (Enforceme

38、nt) is added as a prefix. Additional requirements discovered during the work on this work item are marked as F (Framework). For each requirement we identified the potential impact on: Overall Architecture Overall Functionality (OverallFunc) Functionality of an Entity (EntityFunc) Impact on Language

39、Interfaces of Entities Impact on Protocol 5.1 Distributed Access Control Requirements Number Summary Impact on 6.1 General Access Control Framework Requirements R A1 In order to support transparency, there should be a mechanism for an entity to provide evidence that it needs certain information from

40、 the user and an interface for external auditing in terms of privacy policies and data processing. OverallFunc R A2 Authentication, Integrity and non-repudiation should be enabled for all transactions. OverallFunc R A3 Support for granular authorization. OverallFunc, Language R F1 Policies consulted

41、 for Authorization may contain conflicting policies or may result into conflicting decisions. The system should have appropriate mechanisms to deal with such conflicts. OverallFunc 6.1.1 General Access Control Framework Requirements: Policy Management R A4 Authenticity, integrity and non-repudiation

42、 should exist between the different entities. OverallFunc R A5 Users should have a simple mechanism to both set and realize the consequence of policies; even when these policies are set by an agent on behalf of the user. OverallFunc R A6 Enable authorized personnel to audit the status and usage of t

43、he security mechanisms, including access to these audit information in a timely manner. This information should be made available in a well defined format to enable an auditor to check with related guidelines. OverallFunc, Architecture R A7 Availability of Preferences. OverallFunc R A8 The framework

44、 must support dynamic management of policies at any time. OverallFunc R A9 The access control framework must support the delegation of rights. OverallFunc R A10 The possession of attributes must be unforgeable. OverallFunc 6.1.2 General Access Control Framework Requirements: Decision R A11 Authentic

45、ation assertion and authentication context should be available for the authorization. OverallFunc R A12 If an authentication assertion could not be directly understood by the original requestor, a method to transform the assertion and related data should be provided by trusted entities. Architecture

46、, OverallFunc R A13 The requestor is authenticated and is either a user, an application acting on behalf of a user, or a machine running an application and/or under the control of a particular user. Architecture, OverallFunc R A14 The authorization for a particular type of access should be based on

47、a request which includes related attribute information and the resource with related information. OverallFunc, Language R A15 Authorization requests should be responded within a well defined time frame, or a default reaction should be enforced. Architecture R A16 Authorization responses may include

48、addition obligations which have to be enforced as a reaction of the request independently whether the response was a denial or a permit. OverallFunc, Language ETSI ETSI GS INS 008 V1.1.1 (2012-05) 9Number Summary Impact on 6.1.3 General Access Control Framework Requirements: Enforcement R A17 User a

49、gent should be able to authenticate to a mutually agreed authentication server. Architecture R A18 Different types of authentication technologies or protocols can be supported. Architecture R A19 Authentication request might be forwarded to another authentication server. Architecture, OverallFunc R A20 An authentication server function should exist and should be able to create assertions about the users identity. EnitityFunc R A21 Consistent policy enforcement must be available on each layer of the architecture. Architecture R F2 The aut