WO2010060466A1

WO2010060466A1 - Method and device for the processing of policy rule data

Info

Publication number: WO2010060466A1
Application number: PCT/EP2008/066199
Authority: WO
Inventors: Jörg Bartholdt; Evelyn Pfeuffer
Original assignee: Nokia Siemens Networks Oy
Priority date: 2008-11-26
Filing date: 2008-11-26
Publication date: 2010-06-03

Abstract

Described is a method for the processing of policy data (L1 to L 3), comprising: - providing policy rule data (L1 to L3), wherein the policy rule data (L1 to L3) comprises the binding of at least one action to at least one condition, and wherein the condition is evaluated to determine whether the action has to be per formed, - automatically using the policy rule data (L1 to L 3) to create a first control code (C1, C2) which can be automatically processed, and - automatically using the policy rule data (L1 to L3) to create a second control code (C3, C4, C5) which can also be automatically processed and which is different from the first control code (C1, C2).

Description

Method and device for the processing of policy rule data

The invention relates to a method for the processing of policy data, comprising:

- providing policy rule data, wherein the policy rule data comprises the binding of at least one action to at least one condition and wherein the condition is evaluated to determine whether the action has to be performed,

- and automatically using the policy rule data to create a first control code which can be automatically processed.

Policy data is mentioned for instance in IETF (Internet Engineering Task Force), RFC (Request for Comment) 3198, "Termi^¬ nology for Policy-Based Management" .

It may be possible to enter data in a specific form that can be understood by the device which has to enforce the policy implemented in the policy data. If the policy relates to different devices it may be necessary to provide first policy data for a first device and second policy data for a second device. The second policy data may also automatically be used to create a second code which can also be automatically processed.

Nevertheless, there is still a need to improve the methods for processing policy data. This need is accomplished by the method according to claim 1. Further technical measures are given in the subclaims.

The method may comprise: - providing policy rule data, wherein the policy rule data comprises the binding of at least one action to at least one condition and wherein the condition is evaluated to determine whether the action has to be performed, - automatically using the policy rule data to create a first control code which can be automatically processed, and

- automatically using the policy rule data to create a second control code which can also be automatically processed and which is different from the first control code.

Thus, there is only a single point of input. The single point of input enforces a consistent policy in the first control code and in the second control code. A contradiction between both codes cannot arise as in the case with more than one point of input. Furthermore, the policy rule data is for different control codes. This means that the policy rule data has to be entered in a more general way and this results in a simplification of the policy rule data compared with policy data that is entered with regard to a specific control code, i.e. for a specific device.

The policy rule data may control a network resource or the access to a network resource. Controlling a network resource comprises managing of network resources. Management comprises :

- the operation of the network or network resource, i.e. keeping it smoothly running including monitoring,

- the administration, i.e. keeping track of the resources, - the maintenance, for example repairs and upgrades,

- the provisioning is concerned with configuring resources.

The first control code may be written according to a first language. The second control code may be written according to a second language that is different from the first language. The first language and the second language are readable by a computer .

The first control code may be compiled and the compiled first control code is then stored into a memory of a first device. The second control code may be stored into a memory of a second device. The first device may be an embedded device, i.e. a device that has lesser facilities than other devices, for instance less than 20 percent of the memory capacity of the second device and/or less than 20 percent of the computation power of the second device. The usage of two devices with different capabilities may be one reason for using two dif- ferent control codes.

The second device may be used to configure the first device and the compiled first control code and/or the second control code may be used to determine whether a configuration of the first device is allowed or denied. This means that both devices form a pair of devices that may be influenced by the same policy rule.

The compiled first control code may be a machine code for a processor and the second control code may be a code according to a markup language. The processor is for instance a microprocessor. The compiled first control code may include operations according to the set of operations of the processor, i.e. AND-operation, jump, compare etc.

A markup language is processed by a so called engine, i.e. a computer program that understands a hardware independent language and creates code that depends on a specific hardware or on a specific processor. Examples for mark up languages are XML (extensible Markup Language) and XACML (extensible Access Control Markup Language) the later by OASIS (Organization for the Advancement of Structured Information Standards) .

Alternatively, the compiled first control code as well as the second control code may be stored in the first device. This means that one policy is implemented in the same device in a different manner.

The compiled first control code may be processed when there is an access to the first device from a second device. And the second control code may be processed when there is an access to the first device from a third device. The second de^¬ vice may be used by a first service provider that is respon- sible for instance for installation and maintenance of a network. The third device may be used by a second service provider that is different from the first service provider. The service of the second service provider comprises for instance monitoring of the operation of the first device. Furthermore, there may be different communication protocols between the first device and the second device on one side and between the first device and the third device on the other side.

The compiled first control code may be a machine code for a processor and the second control code may implement a directory access protocol, for instance LDAP (Light Weight Directory Access Protocol) or a future version of BACnet (Building Automation and Control networks) .

The compiled first control code may be stored in a device that is part of a fire detection network that comprises a plurality of fire detectors connected to the device storing the first control code.

Providing the policy rule data may comprise the use of a graphical editor. A graphical editor enables the movement of symbols on a screen and to draw lines between these symbols. The drawing that is drawn with the graphical editor repre- sents a data structure and may be used to create data, i.e. policy data in the context of this invention. It is of course possible to use a textual language to enter the policy data. However, to prevent the creation of a more abstract language that is hard to learn it is preferred that the textual lan- guage also relates to symbols and to lines between these symbols. The textual language may be used if there is no screen available or only a display that can display only a few characters, for instance less than hundred letters and/or digits at once.

The invention relates also to a device for the processing of memory data, comprising: - an input unit, wherein the input unit enables entering of policy rule data,

- a first transformation unit, wherein the first transformation unit is able to automatically transform the policy rule data to a first control code,

- a second transformation unit, wherein the second transformation unit is able to automatically transform the policy rule data to a second control code which is different from the first control code.

This device may be used to perform one of the methods mentioned above. Therefore, the same technical effects apply.

For a more complete understanding of the present invention and the advantages thereof reference is now made to the following descriptions taken in conjunction with the accompanying drawings in which:

Figure 1 illustrates parts of a fire detection network, Figure 2 illustrates a graphical editor and a computer that processes policy rule data, and

Figure 3 illustrates parts of a distributed software/hardware system.

The making and using of the presently preferred embodiments are discussed in detail below. It should be appreciated, however, that the present invention provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific ways to make and use the in- vention and do not limit the scope of the invention. Moreover, the same reference signs refer to the same technical features if not stated otherwise. As far as "may" is used in this application it means the possibility of doing so as well as the actual technical implementation.

The present invention will be described with regard to preferred embodiments in a specific context, namely with regard to a fire detection network. The invention may also be ap- plied to other networks, for instance to a telecommunication network or to a computer network.

Figure 1 illustrates parts of a fire detection network 96 comprising:

- a panel device 100, and

- other parts 98 that are not shown in detail but may comprise a plurality of fire detectors.

Figure 1 shows also a computer 102, for instance a laptop, and a management station 104. Computer 102 is used by a first service provider that installed network 96 and that is responsible for the maintenance of network 96. Other service providers should not be able to maintain network 96. There- fore there is a policy rule to enforce this principle as described below with regard to Figure 2, line Ll. However there may be another service provider that operates or monitors network 96 and calls the fire department if a fire is detected. The service provider for monitoring network 96 uses management station 104 that may be connected via the internet to panel device 100.

Panel device 100 is an embedded device that has for cost reasons a comparable small memory and comparable low computation power, for instance with regard to computer 102 or management station 104. Panel device 100 comprises:

- a memory 132,

- configuration data 110, stored for instance in memory 132,

- BDV (Basis Data Variant) data 112, stored for instance in memory 132, BDV data may comprise country specific values and ranges for configuration data.

- compiled code CIa corresponding to a policy rule that is represented by line Ll in Figure 2,

- compiled code C2a corresponding to policy rules that are represented by lines L2, L3 in Figure 2,

- LDAP code C3 corresponding also to the policy rules that are represented by lines L2, L3 in Figure 2, - a processor 130 for processing of code CIa, C2a and C3 and code for other functions of panel device 100,

- engines 134, 136 that are realized in software to process code C2a and code C3 respectively.

The following connections are possible between computer 102 and panel device 100:

- a connection 118 via the internet 116 to access configuration data 110 by a service technician ST, see connec- tion/policy rule Ll in Figure 2,

- a connection 120 via a cable or a short range radio connection to access configuration data 110 by a service technician ST, see connection/policy rule Ll in Figure 2, and

- a connection 122 via a cable or a short range radio connec- tion to access BDV data 112 by a service technician or a manager RCLM (Regional Company Localization Manager) , see connection/policy rule L2 and L3 in Figure 2.

Connection 122 may alternatively be a connection via internet 116.

Computer device 102 comprises:

- XACML code C4 to implement connection/policy rule Ll of Figure 2 on the side of computer 102, - XACML code C5 to implement connection/policy rules L2 and L3 of Figure 2 on the side of computer 102,

- an engine 144 for the processing of XACML code C4 and C5

- a processor 140 for processing the software of engine 144,

- a memory 142, for instance for storing code C4 and C5 as well as the software of engine 144.

Management station 104 comprises:

- a processor 146 for processing software of management station 104, and - a memory 148 for storing the software of management station 104. Panel device 100, computer 102 and management station 104 are realized without software and processors, i.e. only by electronic circuits, in another embodiment.

Figure 2 illustrates a screenshot of a drawing that was drawn using a graphical editor and a computer 180 that processes policy rule data and that comprises the software of the graphical editor.

A screen 150 displays symbols 151 on a left hand part thereof, for instance symbols for technician ST, for manager RCML (Regional Country Localization Manager) or for data as well as for connection lines . The user of the graphical editor may drag and drop these symbols to the right hand side to define policy rules. Figure 2 shows an example for three policy rules. In praxis there may be more than hundred policy rules or more than thousand policy rules involved for one system.

A symbol 152 represents the service technician ST. A symbol 154 represents the RCLM. A symbol 160 represents configuration data 110 and a symbol 162 represents BDV data 112.

In the example, there is a line Ll between symbol 152 and symbol 160. Therefore, line Ll represents a policy rule for the access of the service technician ST to configuration data 110. A line L2 is between symbol 152 and symbol 162. Line L2 represents a rule for the access of the service technician ST to BDV data 112. A line L3 is between symbol 154 and symbol 162. Line L3 represents a rule for the access of the manager RCLM to BDV data 112.

Line Ll has an associated text "Action: *" that represents an unrestricted access. Furthermore, line Ll has an associated constraints box 170 that contains the text "Constraint: $sub- ject.getBC == $target . getBC" to define the policy rule further, namely to define that only service technicians ST of that service provider have access (to configuration data 110) that installed the network 98. The enforcement of this policy rule is described below in more detail.

Line L2 has an associated text "Action: read" that defines a restricted access for read only for service technician ST to BDV data 112. Line L3 has also an associated text "Action: *" that represents an unrestricted access for manager RCLM to BDV data 112.

Computer 180 comprises:

- a processor 186 for processing program code, and

- a memory 188, for storing the software of the editor and of transformation units to create codes Cl to C5 from the general policy rules that were entered using the graphical edi- tor.

Alternatively, a device 180 may be used instead of computer 180 that does not comprise software but comprises only electronic circuits.

There is a connection 182 between computer 180 and screen 150. Computer 180 creates the following output data 184:

- source code Cl for line Ll,

- source code C2 for lines L2 and L3, - XACML code C4 for line Ll,

- XACML code C5 for lines L2, L3, and

- LDAP code C3 for lines L2, L3.

Source code Cl and source code C2 are compiled to machine code CIa and C2a respectively, for instance using computer

180 or another computer. The machine code CIa and the machine code C2a are stored in memory 132 of panel device 100.

XACML codes C4 and C5 are transferred to computer 102. LDAP code C3 is transferred to panel device 100 and stored in memory 132 too. In the following, an example of code C4 is given for the implementation of the general rule that is represented by line Ll, i.e. with regard to the access to configuration data 110 that is different from BDV (Basis Data Variant) data 112. The implementation is in XACML, i.e. a known markup language:

01) <Rule .Ru2eID="ServiceTechnician_OwnConfig"

Effect=" Permit ">

02) <Description>Service Technician may access only his BCs configurations</Description>

03) <Target>

04) <Subjects>

05) <Subject>

06) <SubjectMatch MatchID="urn : oasis : names : tc :xacml : 1.0 : function : string-equal">

07) <AttributeValue DataType="http: //www.w3.org/2001/

XMLScheme#string">ST</AttributeValue>

08) <SubjectAttributeDesignator Attributeld=" Subject

Roles" DataType="http:/ /www. w3.org/2001/ XMLScheme#string"/>

09) </SubjectMatch>

10) </Subject>

11) </Subjects>

12) <Resources> 13) <Resource>

14) <ResourceMatch MatchID="urn : oasis : names : tc :xacml : 1.0 : function : string-equal">

15) <AttributeValue DataType="http : //www. w3.org/2001/

XMLScheme#string">sbt . fs20. Configuration </AttributeValue>

16) <RecourceAttributeDesignator Attributeld=" urn: oasis : names : tc :xacml : 1.0 : resource : resource-id" DataType="http: //www.w3. org/2001/XMLScheme# string"/> 17) </ResourceMatch>

18) </Resource>

19) </Resources>

20) <Actions> 21) <anyAction/>

22) </Actions>

23) </Target>

24) <Condition FunctionID="urn : oasis : names : tc :xacml : 1.0 : function : string-equal">

25) <Apply FunctionID="urn : oasis : names : tc : xacml : 1.0 : function : string-one-and-only">

26) <SubjectAttributeDesignator DataType="http :

//www.w3.org/2001/XMLScheme#string" Attributeld=" getBC" />

27) </Apply>

28) <Apply FunctionID="urn : oasis : names : tc : xacml : 1.0 : function : string-one-and-only">

29) <ResourceAttributeDesignator DataType="http : / /www . w3 . org/2001 /XMLScheme# string"

At

getBC " />

30) </Apply>

31) </Condition>

32)

33) </Rule>

In the following the lines of the XACML text for code C4 are described with regard to the embodiment shown in Figure 1 and in Figure 2. The syntax of XACML is known from other sources but XACML and XML are explained here in an extent that is relevant to understand the embodiment.

Environment parameters are set before the XACML lines are evaluated by an engine that understands XACML, for instance:

- "SubjectRoles" contains a value that is "ST" if a service technician is logged on to computer 102 and "RCLM" if a localization manager is logged on to computer 102,

- "urn : oasis : names : tc : xacml : 1.0 : resource : resource-id" con- tains a value that indicates the resource, for instance configuration data 110,

- subject "getBC" indicates the business channel (BC) or service provider of the person who operates computer 102, and - target "getBC" indicates the business channel (BC) or service provider that installed the panel, for instance based on a previous request to the panel device 100.

01) <Rule .Ru2eID="ServiceTechnician_OwnConfig"

Effect=" Permit ">

Line 01 relates to the beginning of a rule that is valid for the service technician and configuration data, see "RuIeID". The effect or action of the rule is access permission if all conditions are fulfilled. In general, it can be said that a rule comprises three parts, namely: - the subject, i.e. who is involved,

- a resource, i.e. the target unit (software, hardware) of an action, and

- the action, for instance read access and/or write access.

Line 02 is a general description of the XACML lines 01 to 33 for maintenance purposes and has no influence to policy checks .

03) <Target> 04) <Subjects>

05) <Subject>

07) <AttributeValue DataType="http : //www.w3.org/2001/ XMLScheme# string" >ST</AttributeValue>

08) <SubjectAttributeDesignator Attributeld=" Subject

Roles" OataType="http: //www. w3.org/2001/ XMLScheme#string"/>

09) </SubjectMatch> 10) </Subject>

11) </Subjects> Line 03 relates to the target unit. However, a description of the subject comes first. Line 04 to line 11 relate to the subjects. It is possible to address more than one subject. In the example, only one subject is used in line 05 to line 10. "MatchID" in line 06 indicates the kind of match that should be performed, i.e. here the match of two strings that should be equal. Line 07 indicates the first string as "ST" which stands for service technician. Line 08 indicates the second string as the value of parameter "Subject roles" mentioned above. The data type of both strings is "string" as defined in the XML scheme of W3.org (World Wide Web Consortium) .

12) <Resources>

13) <Resource> 14) <ResourceMatch MatchID="urn : oasis : names : tc :xacml : 1.0 : function : string-equal">

15) <AttributeValue DataType="http : //www.w3.org/2001/

XMLScheme#string">sbt . fs20. Configuration

</AttributeValue> 16) <RecourceAttributeDesignator Attributeld="urn: oasis : names : tc :xacml : 1.0 : resource : resource-id" OataType="http: //www.w3. org/2001/XMLScheme# string"/>

17) </ResourceMatch> 18) </Resource> 19) </Resources>

Line 12 to line 19 relate to that part of the policy that defines the resource or the target, i.e. configuration data 110. It is possible to address more than one resource. However only one resource is used in the example. Line 14 defines that a string comparison for equality is necessary. Line 15 defines the desired value as "sbt . fs20.Configuration", i.e. configuration data 110. Line 16 relates to the actual value that has to be compared with the desired value. The resource-id mentioned in line 16 is one of the input parameters mentioned above, i.e. a reference to the data which should be modified using computer 102. 20) <Actions>

21) <anyAction/>

22) </Actions>

23) </Target>

Line 20 to line 23 relate to the action that has to be specified with regard to the access. The action tag in line 21 is set to "any action" because no restriction to a special ac- tion is necessary, i.e. unrestricted access will be possible.

26) <SubjectAttributeDesignator DataType="http :

//www.w3.org/2001/XMLScheme#string" Attributeld="getBC" />

27) </Apply> 28) <Apply FunctionID="urn : oasis : names : tc : xacml : 1.0 : function : string-one-and-only"> 29) <ResourceAttributeDesignator DataType="http :

//www.w3.org/2001/XMLScheme#string" AttributeId=" getBC" /> 30) </Apply>

31) </Condition>

Lines 24 to 31 relate to the constraint that was entered for connection line Ll, i.e. a service technician ST is allowed only to maintain panel devices 100 of that service provider that he works for. Line 24 relates again to a string comparison for equality. Line 25 states that only one string comparison is necessary. Line 25 defines the first string, i.e. the value that indicates the service provider that installed panel device 100. Line 29 specifies the second string for comparison, i.e. the string that indicates the actual service provider the technician works for. Access is permitted only if both strings are the identically. 32) <! --Action only allowed on own recources, e.g. subject- id == owner-id-->

33) </Rule>

Line 32 is a comment for maintenance purposes. Line 33 indicates the end of the rule.

Computer 180 may generate the following "pseudo" source code Cl for panel device 100 based on line Ll:

- IF Subject not equal to "ST" RETURN false,

- IF Resource not equal to "sbt . fs20. Configuration" RETURN false .

There may be a template for code Cl and only the names of the symbols, for instance "ST", are inserted by computer 180 to create source code Cl. Source code Cl is compiled to machine code CIa, for instance in computer 180 or in another computer .

In an example service technician ST accesses configuration data 110 via connection 120. In this case, the policy check for policy rule Ll is performed in computer 100. Access is performed using for instance a proprietary communication pro- tocol. Change of parameters are possible that do not belong to BDV data 112 but to configuration data 110. Contrary to the service technician ST The Regional Country Localization Manager RCML cannot access configuration data 110.

In a next example service technician ST accesses stored configuration data 110 via connection 118. In this case the policy check for policy rule Ll is performed by panel device 100 according to its program code CIa. Again a proprietary protocol may be used for online access.

In the following an example of code C5 is given for the implementation of the general rules or policies that are represented by line L2 and line L3, i.e. with regard to the access to BDV (Basis Data Variant) data 112. The implementation is in XACML, i.e. a known markup language:

01) <Rule .Ru2eID="RCML_BDV" £ffect="Permit"> 02) <Description>Regional Company Localization Manager has unrestricted access to BDVs </Description>

03) <Target>

04) <Subjects>

05) <Subject> 06) <SubjectMatch MatchID="urn : oasis : names : tc :xacml : 1.0 : function : string-equal">

07) <AttributeValue DataType="http : //www.w3.org/2001/

XMLScheme#string">RCML</AttributeValue>

08) <SubjectAttributeDesignator

Roles" Datalype="http://www. w3.org/2001/

XMLScheme#string"/>

09) </SubjectMatch>

10) </Subject>

11) </Subjects> 12) <Resources>

13) <Resource>

15) <AttributeValue Datalype="http : //www. w3.org/2001/ XMLScheme#string">sbt.fs20.BDV

</AttributeValue>

16) <RecourceAttributeDesignator Attributeld=" urn: oasis : names : tc :xacml : 1.0 : resource : resource-id" Datalype="http: //www.w3. org/2001/XMLScheme# string"/>

17) </ResourceMatch>

18) </Resource>

19) </Resources>

20) <Actions> 21) <anyAction/>

22) </Actions>

23) </Target>

24) </Rule> 25) <Rule .Ru2eID="ServiceTechnician_OwnConfig"

Effect=" Permit">

26) <Description>Service Technician may access only his BCs configurations</Description> 27) <Target>

28) <Subjects>

29) <AnySubject/>

30) </Subjects>

31) <Resources> 32) <Resource>

33) <ResourceMatch MatchID="urn :oasis :names : tc :xacml : 1.0 : function : string-equal">

34) <AttributeValue DataType="http : //www.w3.org/2001/

XMLScheme#string">sbt.fs20.BDV </AttributeValue>

35) <RecourceAttributeDesignator Attributeld=" urn: oasis : names : tc :xacml : 1.0 : resource : resource-id" OataType="http: //www.w3. org/2001/XMLScheme# string"/> 36) </ResourceMatch>

37) </Resource>

38) </Resources>

39) <Actions>

40) <Action> 41) <ActionMatch MatchID="urn : oasis : names : tc : xacml : 1.0 : function : string-equal">

42) <AttributeValue DataType="http : //www. w3.org/2001/

XMLScheme#string">read

</AttributeValue> 43) <ActionAttributeDesignator AttributeId=" urn: oasis : names : tc :xacml : 1.0 : action : action- id" Datarype="http://www.w3.org/2001/XMLScheme# string"/>

44) </ActionMatch> 45) </Action>

46) </Actions>

47) </Target>

48) </Rule> In the following the lines of the XACML text are described with regard to the embodiment shown in Figure 1 and in Figure 2. The syntax of XACML is known from other sources but is ex- plained here in an extent that is relevant to understand the embodiment .

Environment parameters are set before the XACML lines are evaluated by an engine that understands XACML, for instance: - "SubjectRoles" contains a value that is "ST" if a service technician is logged on to computer 102 and "RCLM" if a localization manager is logged on to computer 102,

- "urn -.oasis : names :tc :xacml : 1.0 : resource : resource-id" contains a value that indicates the resource, for instance BDV data 112,

- "urn : oasis : names :tc :xacml : 1.0 : action : action-id" contains a value that indicates an action which should be performed with an access, for instance read.

01) <Rule RuIeID="RCML_BDV" EffeCt=" Permit">

02) <Description>Regional Company Localization Manager has unrestricted access to BDVs </Description>

Lines 01 to 24 relate to line L3 of Figure 2, i.e. to the RLMC and to BDV data 112. Line 01 describes this. Line 01 describes further that a permission for access is granted if the rule is fulfilled.

03) <Target> 04) <Subjects>

05) <Subject>

07) <AttributeValue DataType="http : //www. w3. org/2001/ XMLScheme#string">RCML</AttributeValue>

08) <SubjectAttributeDesignator Attributeld=" Subject

Roles" DataType="http: //www. w3.org/2001/ XMLScheme#string"/> 09) </SubjectMatch>

10) </Subject>

11) </Subjects>

Lines 03 to 11 relate to the subject, i.e. to the person who wants to access. If the subject role of the person that is logged on to computer 102 is the RCML a match is given and the other lines are evaluated. If no match is given access is denied.

12) <Resources>

13) <Resource>

14) <ResourceMatch MatchID="urn : oasis : names :tc :xacml : 1.0 : function : string-equal"> 15) <AttributeValue DataType="http : //www.w3.org/2001/

XMLScheme#string">sbt.fs20.BDV

</AttributeValue>

16) <RecourceAttributeDesignator Attributeld=" urn: oasis : names : tc :xacml : 1.0 : resource : resource-id" DataType="http: //www.w3. org/2001/XMLScheme# string"/>

17) </ResourceMatch>

18) </Resource>

19) </Resources>

Lines 12 to 19 relate to the resource, i.e. the unit to which an access is desired. If the unit is indicated by "sbt .fs20.BDV", i.e. the unit corresponds to BDV data 112, a match is given and the other lines are evaluated. However, if there is no match access is denied. Evaluation of further lines is not necessary if there is no match.

20) <Actions>

21) <anyAction/>

22) </Actions>

23) </Target>

24) </Rule> Lines 20 to 24 relate to the allowed actions. According to Figure 2, connection line L3, "Action: *", unlimited access should be possible for the RCML. Therefore, "anyAction" is specified in line 21.

25) <Rule .Ru2eID="ServiceTechnician_OwnConfig"

Effect=" Permit ">

26) <Description>Service Technichian may access only his BCs configurations</Description> 27) <Target>

Lines 25 to 48 relate to the policy that is modeled by connection line L2. The editor and the corresponding program for generating the XACML code C5 broadens the access rights be- cause it only knows two subjects, namely the service technician ST and the manager RCLM. The manager RCML has unrestricted access to BDV. The service technician has read access to BDV. Therefore the program acts according to an implementation rule that allows read access to everyone. The XACML code fragment is simplified by using this implementation rule as described in more detail with regard to the following lines. Furthermore, the evaluation of the XACML lines becomes faster.

28) <Subjects>

29) <AnySubject/>

30) </Subjects>

Read access is allowed for everybody according to the imple- mentation rule. Therefore "AnySubject" is specified in line 29.

31) <Resources>

32) <Resource> 33) <ResourceMatch MatchID="urn : oasis : names : tc :xacml : 1.0 : function : string-equal">

34) <AttributeValue DataType="http : //www. w3. org/2001/

XMLScheme#string">sbt.fs20.BDV </AttributeValue>

35) <RecourceAttributeDesignator Attributeld=" urn: oasis : names : tc :xacml : 1.0 : resource : resource-id" OataType="http: //www.w3. org/2001/XMLScheme# string"/>

36) </ResourceMatch>

37) </Resource>

38) </Resources>

Lines 31 to 38 relate to the resource. If there is a match between the current resource and the resource specified in line 24, i.e. "sbt . fs20.BDV" , further evaluation is necessary. If there is no match evaluation may be ended and access is denied.

39) <Actions>

40) <Action>

41) <ActionMatch MatchID="urn : oasis : names : tc : xacml : 1.0 : function : string-equal"> 42) <AttributeValue DataType="http : //www.w3. org/2001/

XMLScheme#string">read

</AttributeValue>

43) <ActionAttributeDesignator Attributeld=" urn: oasis : names : tc : xacml : 1.0 : action : action- id" DataType="http://www.w3.org/2001/XMLScheme# string"/>

44) </ActionMatch>

45) </Action>

46) </Actions> 47) </Target>

48) </Rule>

Lines 39 to 48 relate to the action that is specified for the access. If it is a read action as also specified in line 42, access is permitted if all other evaluation are valid. If a different access than read is planned, i.e. for instance "write", then access is denied. Furthermore, policy rules L2, L3 result in the creation of pseudo code C2 that will be compiled to code C2a. The pseudo code C2 is created in a similar manner as pseudo code Cl that was described above in more detail.

Policy rules L2, L3 result also in the creation of an LDAP authority description that is implemented in code C3: access to dn . subtree="dc=BDV, dc=fs20" by dn="cn=RCML, ou=Groups, dc=fs20" read, write by * read, wherein :

- "dn" stands for "distinguished name",

- "en" stands for "common name",

- "ou" stands for "organizational unit", and - "dc" stands for "domain component" .

There may be for example an access via connection 122 to BDV data 112 by service technician ST for read only. If access is to stored BDV data 112, the policy check is performed by pro- gram code C5 of computer 102. The protocol that is used for the access may be a proprietary or a standardized one. If the service technician ST does not known BDV data he may use BDV data 112 stored in panel 100. Alternatively, it is possible to store BDV data also in laptop 102 and to perform the check in laptop 102.

If access is between computer 102 and panel device 100 to configuration data 110, the policy check L2 is performed by program code C2a in panel device 100.

Access to BDV data 112 is possible for RCLM for read and write, i.e. without restriction.

An example for an access with BACnet from management station 104 to BDV data 112 by monitoring staff of the second provider is: read "buildingl/fIoorl/panel5/thresholdl" . This read access would be allowed according to policy rule L2 implemented also in code C3 that is relevant here for the access. According to code C3 read access is granted to everyone, i.e. also to the second service provider that uses man- agement station 104. However write is forbidden according to code C3.

This access implies a check according to LDAP policy implemented in code C3. In other embodiments the policy may be im- plemented using the planned BACnet authorization part. In this case the check is done according to the BACnet implemented policy.

In other words, a graphical editor for multidimensional poli- cies and its transformation and mapping to different enforcement elements in a heterogenic information technology environment has been described.

"Policy" means according to IETF (Internet Engineering Task Force), RFC (Request for Comment) 3198, "Terminology for Policy-Based Management" :

- a rule or a set of rules to administer, manage and control access to network resources. In other words, a policy describes who may access which target unit in which way.

"Policy rule" means according to RFC 3198:

- A basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed (or not) .

"Heterogenic" means that different software units work together, especially units manufactured by different manufacturers .

Management tasks and administrative tasks are meanwhile performed based on rules or guidelines in many fields, for instance in technical fields that relate to the computing world, especially in the fields of telecommunication, computer networks, on workstations, computer administration and in web (www, world wide web) service management. This is named as policy based management.

Policies, i.e. rules or guidelines, are used at different levels thereby, for instance at the following levels:

- business goal,

- network specific configuration parameters, - or device specific configuration parameters.

These different levels are also named as "policy abstractions", see RFC (Request for Comment) 3198. "Multidimensional" means here that the policies have effects to differ- ent levels. The policy may influence a level in its entirety or only in parts.

It is possible to map single policy network elements and other units, i.e. so called "enforcement units", one to one in an information technology infrastructure or in a communication infrastructure. This requires that the policies are entered in a tailored fashion to the respective unit and separate for the respective unit. These units are mostly assigned to a specific policy abstraction level. However, these units overlap several levels more often nowadays. Furthermore, a policy for a unit has to be written in a policy description language that was defined for the respective unit. An XML (extensible Markup Language) based policy description language is often used for the formulation of policies due to an approach that is closely related to a specific network element. There result very specific policy implementations depending on the target unit even if XACML (speak "exsace- mel", extensible Access Control Markup Language), i.e. a standardized policy description language, is used. Addition- ally, the XML format or the XACML format can be written or understood only by XML/XACML-specialists . The reason for this is that it is necessary to know the special know how of the policy representation with regard to the language elements and its use in the specific context of the target unit although work is done on the ASCII (American Standard Code II) level. The reason for this is that the known editor programs are only syntax oriented but do not have semantic or domain specific means that help to complete inputs.

Therefore, there is the following problem: Several policies are written at separated units of different policy abstractions levels in different languages. The policies overlap functionally and are correspondingly error-prone (consistency) . An operator who has to enter these policies does often not have the special knowledge and is therefore overstrained. Policies for one target unit can not be transferred to another target unit in a simple manner even when both units cover a common functional area. A single-point of input is not given from the view of the operator.

Solutions to this problem may cover only some aspects of a simplified policy-entering. There may be simple XML editors or improved XML/XACML editors that allow to enter and to modify policies in the format XML or in the format XACML. These editors may function on the basis of XML/XACML tags or elements, i.e. they show the tags as input parameter - partially enhanced with descriptions and help texts for filling in. The XML syntax, for instance brackets, parentheses, opening element, closing element etc., may be created by the editor. The input may be oriented closely to the XML structure. Each policy processing unit may belong to a separate editor that creates a specific syntax and content for the respective unit. The editor may transform the entered policy data in a format that the respective unit understands, for instance ASCII or binary, and may transfer these data to the respective unit. These editors may not be able to process policy-data or policies for more than one unit and to associate the policy data or the policies to the respective units. Furthermore they may describe policy data only in an abstraction level that is understandable by the corresponding unit. The entering of policies may be easier thereby, for instance by using templates containing default settings for which the operator has to change the values. However, all these solutions let the responsibility to find and to enter an adequate separation and modeling at the hands of the operator. The task of the administrators is to decide which rule has to be registered at which device. This is also a decision about the device that has to enforce the rule. Furthermore, the administrators have to provide for repetition of rules or of parts of rules in one or more than one device. In the example, the service technician ST is allowed to change his own configurations in the laptop and in the panel.

The basic idea is to make the policy description at an ab- stract level that concerns the system as a whole and not single parts of the system. As shown in Figure 3, it is for example possible to configure on the system level with the granularity "security on/off". But this means that there are different configuration formats, times and levels for the different levels, components and/or subcomponents of the system. For instance, it is not always possible to roll out a policy immediately after entering. Many devices may depend on a specific rule and therefore the roll out has to take place during the evening or during the night.

The demand "security" may imply at the level of an ERP (Enterprise Resource Planning) software program or software system that the four eyes principle has to be obeyed for critical actions. This may result in the boot up (loading a pro- gram in a volatile memory and execution of the program by a processor) of a work flow engine with interaction to user.

All critical actions in an audit trail may be stored in a database, i.e. an electronic memory, at the level of configura- tion and monitoring. An audit trail comprises data, i.e. a kind of protocol data or of log data. There are different ways to store the audit trail, for instance typical in data bases, in files but also in a central audit server, that is disposed in a security area. This means that it is not possible to change audit data later.

Furthermore, only SSL-Connections (Secure Socket Layer, now TLS - Transport Layer Security) may be accepted that are authenticated from the client side.

The artifacts, i.e. electronic data, created thereby may be of different nature, for instance: - electronic BPEL (Business Process Execution Language) description,

- with regard to an audit trail an electronic configuration file, for instance in a proprietary format, and

- an electronic certificate that may be used for SSL.

This means that a system-operator can reach a consistent state of the system via all layers of the system without having detailed or expert knowledge, for instance how to configure the use of an SSL-certificate in a device.

This idea is naturally not restricted to security policies but relates to all kind of policies, for instance to:

- transaction policy,

- redundancy policy, i.e. which units should be redundant with regard to one another and with regard to which conditions,

- reporting policies, for instance with regard to automatic alarms .

Transaction policies are used to specify the relationship among actions that either all of the actions have to be exe^¬ cuted or none of the actions are executed. If there are for instance three actions A, B and C all actions are executed or none of them is executed.

There are the following technical effects :

- systems, especially huge heterogenic systems, may be maintained more efficiently, - prevention of faults and breakdown by the prevention of inconsistent states of the system, for instance a computer system, a computer network, or a telecommunication system,

- saving of costs and time by: - shorter breakdown times of the overall system,

- lower effort for the education and training of the operator, fewer special knowledge is necessary, domain specific, tailored (eventually graphical) policy description language at a high abstraction level.

- no redundant input of policy data or information, i.e. there is a single point of input,

- simplification of integration of different units in an information technology or telecommunication infrastructure: - interchangeability of the transformation algorithm results in adaptability to new formats which are demanded for instance by newly added policy enforcement entities.

There may be a software in an embedded device and a configuration software in a distributed system. The software on the embedded device has to check messages from outside according to a policy. The configuration software may be installed on a laptop or central computer. The configuration software has to check also read operations and/or write operations to configuration data according to a policy. Both system parts enforce parts of a superordinated policy, i.e. each system part is responsible for its own part of the policy.

Examples for checks according to a policy in an embedded system or an embedded device are:

Al) read/write access for specific roles (see RFC 3198) or users, for instance administrator, service technician, to specific parameters, especially to setting parameters. Bl) acceptance of state changes from other embedded devices, for instance forwarding of alarms, or forwarding of fault state data, Cl) new/changed configuration only from the configuration software, that is also named as configuration program.

Examples for checks according to a policy in the configura- tion program (software, tool) are:

A2) Modification only to configurations of the same service provider,

B2) changes to templates for configuration. It is for instance only for the RCLM possible to change BDV data in the example described above.

The description of the policy may be necessary in different languages for both system parts, for instance for embedded device in BACnet (Building Automation and Control networks) specific format, LDAP (Light Weight Directory Access Protocol) or in a machine language (machine code) and for the configuration program in XACML or XML. There may be for instance an embedded device that receives read/write requests via BACnet and a hierarchical policy language may be used, compa- rable to LDAP, or a generated code fragment may be used that performs the actual checks. The detailed knowledge about the specific languages or protocols is not used for the definition of the superior policy and a uniform and abstract language may be used, for instance using a graphical language or a textual language.

Embodiment in the context of an SBT (Siemens Building Technology) Sintenso FS20 application with two examples for superior or general policies that have an influence to multiple devices:

1) Changes to a configuration of a panel device (fire detection terminal or fire detection central unit) must be allowed only by configuration tools of the same domain, i.e. of the same service provider that operates the panels and usually also installed the panels. A service technician may work at the configuration tool. It is also possible that an administrator uses a configuration tool. The administrator is named as Regional Company Localization Manager (RCML) in this context. The RCML uses a special password for registration with the configuration tool an has in some cases more rights than a service technician.

A configuration change may be performed with a direct connection between the configuration tool and the panel. The panel device has to enforce the policy for this configuration, see case Cl mentioned above.

A configuration change may be performed directly to saved configuration data using a connection between the configuration tool and the panel. The configuration tool has to en- force the policy for this configuration, see case A2 mentioned above.

The policies are implemented in the panel using program code, an example was described in more detail above with regard to Figures 1 and 2. This means that the policy is defined at the time of compilation.

The program of the configuration tool, i.e. the configuration program, may be performed on a laptop computer, for instance. Therefore, there are fewer constrains with regard to memory and computation power compared to the embedded device. Thus, it is possible to use for instance an XACML-engine (program) which evaluates the policy dynamically. A fragment of this XACML policy which describes the rule that only the staff of the same service provider may change the configuration was described in detail above with regard to XACML code C4.

2) Threshold values for the activation of alarms or for the calibration of specific elements have to fulfill country spe- cific rules. The set of thresholds for one country is named as basis data variant (BDV) . The changing of these values has to be performed only by authorized specialized staff. This is implemented or modeled by the role "RCML" . All other roles are only allowed to read these values because all tools and devices have to fulfill the threshold values:

a) This is checked in the panel, for instance for input by hand at the embedded device. The check is implemented in the program code at the time of compilation. A detailed example was given above.

b) In the configuration tool the policies are modeled as XACML policies as described above with regard to XACML code C5.

c) Inputs by hand may alternatively also come from a central management station. These inputs may be transmitted using the BACnet protocol. However the standardization process of the security part of BACnet is not completed at the time of filing this application. BACnet uses hierarchical data structures of entries which can be set and read by BACnet. Therefore a policy description language may be used which can ad- dress whole data trees or sub trees of the hierarchical data structure, i.e. a third possibility in addition to XACML and program coding of policies. The BDV data may be located in a specific branch of the BACnet tree. An example for describing the authorization in LDAP (Lightweight Directory Access Pro- tocol) was also given above, see code C3.

The superordinated policy may be entered with a graphical editor, for instance as described above. There may be symbols and connections between the symbols. Alternatively, a textual description language for connections between entities or symbols may be used.

In the example, there are hexagons that represent "roles" or sources of access and octagons that represent "resources" or targets of access as well as connections lines that represent "actions" or method of access. An EMF/GMF (Eclipse Modeling Framework/Graphical Modeling Framework) based editor may be used to enter the general policy by drag and drop. The anno- tations of the connection lines, i.e. so called constraints, may be entered using a dialog box. "$subject" references the caller of the XACML engine. ".getBS" enables to get the domain name of the caller. In SBT the domain name of the ser- vice provider is also named as "Business channel" (BC) .

Analogous, this is true for "$target" with regard to the target of the access.

From this general policy it is possible to generate the code fragments for the panel device 100, XACML-policies for the configuration tool 102 and BACnet hierarchy based policies or LDAP based policies.

Although embodiments of the present invention and their ad- vantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made therein without departing from the spirit and scope of the invention as defined by the appended claims. For example, it will be readily understood by those skilled in the art that many of the features, functions, processes and methods described herein may be varied while remaining within the scope of the present invention. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the system, process, manufacture, method or steps described in the present invention. As one of ordinary skills in the art will readily appreciate from the disclosure of the invention systems, processes, manufacture, methods or steps presently existing or to be developed later that perform substantially the same function or achieve sub- stantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such systems, processes, methods or steps . List of reference signs

96 fire detection network 98 other parts of network

100 panel device

102 computer

104 management station

110 configuration data 112 BDV data

116 Internet

118 to 124 access

130 processor

132 memory 134, 136 engine

140 processor

142 memory

144 engine

146 processor 148 memory

150 screen

151 symbols

152 symbol for ST 154 symbol for RCLM 160 symbol for configuration data

162 symbol for BDV data

Ll to L3 connection line

170 constraints box

180 computer 182 connection

184 output

186 processor

188 memory

Cl to C5 code CIa, C2a compiled code

Claims

1. Method for the processing of policy data (Ll to L3) , comprising : providing policy rule data (Ll to L3), wherein the policy rule data (Ll to L3) comprises the binding of at least one action to at least one condition, and wherein the condition is evaluated to determine whether the action has to be performed, automatically using the policy rule data (LIl to L3) to create a first control code (Cl, C2) which can be automatically processed, and automatically using the policy rule data (Ll to L3) to create a second control code (C3, C4, C5) which can also be auto- matically processed and which is different from the first control code (Cl, C2) .

2. Method according to claim 1, wherein the first control code (Cl) is compiled and the compiled first control code (Cl) is stored into a memory of a first device (100), and the second control code (C4, C5) is stored into a memory of a second device (102), wherein the first device (100) is an embedded device that has less than 20 percent of the memory capacity of the second de- vice (102) and/or that has less than 20 percent of the computation power of the second device (102) .

3. Method according to claim 2, wherein the second device (102) is used to configure the first device (100) and wherein the compiled first control code (CIa) and/or the second con^¬ trol code (C4, C5) is used to determine whether a configura^¬ tion of the first device (100) is allowed or denied.

4. Method according to claim 2 or 3, wherein the compiled first control code (CIa, C2a) is a machine code for a processor, and wherein the second control code (C4, C5) is a code according to a markup language .

5. Method according to claim 1, wherein the first control code (C2) is compiled and the compiled first control code (C2a) is stored in a first device (100) and the second con- trol code (C3) is also stored in the first device (100) .

6. Method according to claim 5, wherein the compiled first control code (C2) is processed when there is an access to the first device (100) from the second device (102), and the second control code (C3) is processed when there is an access to the first device (100) from a third device (104) .

7. Method according to claim 6, wherein the compiled first control code (C2a) is a machine code for a processor and the second control code (C3) implements a directory access protocol .

8. Method according to one of the preceding claims, wherein the compiled first control code (CIa, C2a) is stored in a device that is part of a fire detection network (96) .

9. Method according to one of the preceding claims, wherein the providing of the policy rule data comprises the use of a graphical editor (150, 180) .

10. Device (180) for the processing of policy data, comprising : an input unit (150), wherein the input unit (150) enables entering of policy rule data (Ll to L3) , a first transformation unit (186, 188), wherein the first transformation unit (186, 188) is able to automatically transform the policy rule data (Ll to L3) to a first control code (Cl, CIa) , a second transformation unit (186, 188), wherein the second transformation unit (186, 188) is able to automatically transform the policy rule data (Ll to L3) to a second control code (C4, C5) which is different from the first control code (Cl, CIa) .

11. Device (180) according to claim 10, wherein the device (180) comprises units to perform a method according to one of the claims 1 to 9.