Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/70—Admission control; Resource allocation
  • H04L47/78—Architectures of resource allocation
  • H04L47/782—Hierarchical allocation of resources, e.g. involving a hierarchy of local and centralised entities

Definitions

• the present invention relates to a method for access control within a network, especially for control of access of a subject to a resource of the network, wherein a PEP (Policy Enforcement Point) sends an access request for evaluation to a PDP (Policy Decision Point) and wherein the PDP may send a reply which may contain at least one obligation to the PEP. Further, the present invention relates to a network, wherein access control is provided, especially control of access of a subject to a resource of the network, wherein a PEP (Policy Enforcement Point) sends an access request for evaluation to a PDP (Policy Decision Point) and wherein the PDP may send a reply which may contain at least one obligation to the PEP.
• a PEP Policy Enforcement Point
• OASIS Organization for the Advancement of Structured Information Standards
• XACML OASIS extensible Access Control Markup Language
• XACML OASIS extensible Access Control Markup Language
• the policy language is flexible enough to cover approaches like Core and Hierarchical Role Based Access Control, the handling of obligation is quit neglected. Although this is quite an important issue especially to support privacy and advanced tracing of data flow. As an example the obligation could enforce the accessing unit to use a certain encryption for data persistency issues, or ensure that a specific action is performed within a given time frame. This is obtainable from Q.
• the aforementioned object is accomplished by a method comprising the features of claim 1 and a network comprising the features of claim 27.
• the method is characterized in that for specifying obligations a meta-language is used.
• the network is characterized in that for specifying obligations a meta-language is defined.
• the meta-language could be a generic language.
• a generic language could allow for a generic description of obligations even in a distributed environment.
• a detection and/or specification of possible conflicts between the obligations could be provided on the basis of the specification of the obligations and/or of definitions based on the meta-language.
• Such a detection and/or specification of possible conflicts between the obligations could be provided in a general way or depending on the assignment of at least one matching value to at least one parameter of each obligation or for two obligations. In other words, such a detection and/or specification could be provided depending on the matching assignment of at least one parameter for two obligations.
• a negotiation with regard to a respective support of the obligations by PEP and PDP could be provided on the basis of the specification and/or of definitions based on the meta-language.
• the present invention can specify a meta-language to specify obligations and potential conflicts between them as well as a method to exchange this specification between the PDP and PEP and negotiate the support of the obligations specified.
• the description of the supported obligation or obligations and their potential conflicts in a meta-language will be one major aspect of preferred embodiments of this invention.
• the present invention describes a method using the specifications based on this language to specify the capabilities of PDP and PEP.
• incompatibility between the PEP and PDP could be detected beforehand.
• the negotiation phase allows the PDP and PEP to request the compatibility of their required and supported obligations, respectively. In case of some mismatches resolution methods could be applied.
• this negotiation process could be repeated at run-time to change the set of obligations used between PDP and PEP.
• the negotiation process could be skipped and a direct/manual exchange of the obligation specification could be done.
• this specification is not fully supported by the PEP the deployment has failed. Otherwise, both PDP and PEP could refer to supported obligation specification.
• the specification or specifications of the obligations are negotiated during the deployment of the PEP and PDP.
• the negotiation could be repeated at run-time. During run-time the detection of conflicts between the specifications is also possible.
• the negotiation between the PDP and PEP could comprise three types of messages, termed request message, reply message and resolve message. Based on said three types of messages an effective negotiation is possible.
• the negotiation could be initiated by the PDP or the PEP. Both cases are possible and could be implemented by an operator.
• meta-language or specification of obligations could be realized as an extension of or an integration in the XACML standard.
• minor amendments and/or additions to an existing standard are necessary for realizing the present invention.
• an obligation could contain a unique identifier.
• the unique identifier is an URI and a set of parameters whose data types can be specified through URIs.
• URIs a very simple handling of obligations
• a policy schema could be independent from already existing or previous definitions or schemata, if a dependency from such already existing or previous definitions or schemata is not requested.
• Such a common obligation specification could be independent from the policy schema, for providing a well-defined and clear structure of components.
• the PEP and/or the PDP could check that a response from the PDP contains only an obligation or obligations used in the common obligation specification. Thus, only negotiated obligations could be used.
• a relationship model of the specified obligations could be generated preferably by the PEP and/or the PDP. If a relationship between obligations exists, the possible conflict could be either resolved or escalated for further handling.
• the PEP and the PDP could be independent from each other.
• the PEP and the PDP could be provided in a distributed environment.
• the present invention is particularly effective with regard to handling of obligations.
• the obligation specification and/or definition and/or negotiation could be dynamic.
• the present invention is providing a method for specifying arbitrary obligations including their parameters, and potential conflicts between them, either in a general way or depending on the dynamic values assigned, usable to detect incompatibilities during deployment as well as at run-time with additional conflict detection at run-time. Further, conflict detection and resolution based on obligation relations as well as negotiation of supported obligations of the PEP and required obligation of the PDP before regular operation are possible.
• the present invention is providing a distributed and independent PEP and PDP implementation with support of arbitrary obligations. Further, detection of obligation incompatibilities between PEP and PDP during deployment and detection of conflicts between combined obligations at run-time are possible.
• Fig. 1 is illustrating a structure of an extension of an existing standard according to the invention.
• Fig. 2 is illustrating an overview of the usage of the inventive method.
• Fig. 1 is obtainable the structure of an extension of the existing XACML standard.
• a generic meta-language is presented according to the invention.
• the policy schema is shown as an extension of a current policy schema within Fig. 1.
• the policy specification is based on the policy schema and is defining the identifier of the respective obligation or obligations which can be processed.
• the obligation schema is comprising the structure of defining an obligation.
• the obligation specification is comprising the type of obligation, e.g. obligation of sending a notification to a given address.
• the policy specification is based on the policy schema and refers to the obligation specification.
• the obligation specification is based on the obligation schema, see Fig. 1.
• Fig. 2 is illustrating an overview of an example of usage of the specification of obligations.
• the negotiation process could be initiated by the PDP or the PEP.
• the initiator first sends a list with the request obligations.
• the receiver analyses this list and indicates whether it either supports this obligation or does not support this obligation. For the later case it could indicate a potential solution, either by indicating that the parameter list of an obligation does not match, or the types of a parameter are different on a first glance. If no solutions are available the negotiation could be terminated with a failure.
• the initiator could react on proposed solution by either accepting fixed values - including empty ones - for the parameters, or accept a casting of the values to a different type. Additionally, it could withdraw an obligation or ask the other side to ignore it, in case it shows up. Finally, the negotiation process could be terminated with a failure at this point as well.
• This negotiation process could be repeated at run-time to change the set of obligations used between PDP and PEP. In special cases the negotiation process could be skipped and direct/manual exchange of the obligation specification could be done. In case this specification is not fully supported by the PEP the deployment has failed. Otherwise both PDP and PEP could refer to supported obligation specification.
• the PDP ensures during the loading of policy specification(s) that it only contains those defined in the obligation specification. Independently the PEP could check each access reply whether it contains only those obligation specified. The usage of incompatible obligation specification could be checked based on the supported obligation specification. Independently PEP and PDP could generate a relationship model of all obligation contained in the obligation specification. Various techniques could be used for efficient implementation of this relationship model including but not limited to graphs, linked lists, or hash maps. Based on a conflict a unidirectional relationship - e.g. inclusion - is created and the relevant parameters and the resulting conflicts are given. For a given reply the contained obligation could be checked for a relationship either in the general case or based on the concrete parameter values. If a relationship exists the resulting conflict could be either resolved or escalated for further handling.
• the invention is providing a generic description of obligation, especially within a distributed environment.
• Required and supported obligations can be exchanged between PDP and PEP to avoid unknown obligations at run-time. It is possible to identify different categories of relations between obligations. Conflicting obligations can be detected in ongoing access requests.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Theoretical Computer Science (AREA)
• General Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Health & Medical Sciences (AREA)
• Databases & Information Systems (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Computing Systems (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Computer And Data Communications (AREA)

Priority Applications (1)

Applications Claiming Priority (3)

Publications (1)

Family

ID=42316899

Family Applications (1)

Country Status (5)

Families Citing this family (5)

Family Cites Families (12)

• 2010
  • 2010-01-11 US US13/142,085 patent/US20110264816A1/en not_active Abandoned
  • 2010-01-11 CN CN2010800041321A patent/CN102273173A/zh active Pending
  • 2010-01-11 JP JP2011528372A patent/JP2012503455A/ja active Pending
  • 2010-01-11 WO PCT/EP2010/000086 patent/WO2010079144A2/en active Application Filing
  • 2010-01-11 EP EP10700699A patent/EP2311235A2/en not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events