Obtaining Secure Code in SQL Server Analysis Services

by using MDA and QVT

Carlos Blanco

, Ignacio Garc

ıa-Rodr

ıguez de Guzm

, Eduardo Fern

andez-Medina

Juan Trujillo

and Mario Piattini

Dep. of Information Technologies and Systems. Escuela Superior de Inform

atica

Alarcos Research Group – Institute of Information Technologies and Systems

University of Castilla-La Mancha, Paseo de la Universidad, 4. 13071. Ciudad Real, Spain

Department of Information Languages and Systems. Facultad de Inform

atica

University of Alicante. San Vicente s/n. 03690. Alicante, Spain

Abstract. Data Warehouses manage historical information for the decision mak-

ing process that could be found out by unauthorized users when security con-

straints are not established. Therefore, it is very important for OLAP tools to

consider the security rules deﬁned at early stages of the development lifecycle.

Following the MDA approach we have created an architecture for developing se-

cure Data Warehouses and in this paper we complete this architecture obtaining

secure multidimensional code in SQL Server Analysis Services from our secure

multidimensional conceptual model (SECDW) by using QVT transformations.

We focus on automatically obtain code for the security constraints deﬁned at up-

per abstraction levels.

1 Introduction

Multidimensional modeling is the foundation of Data Warehouses (DWs), multidimen-

sional (MD) Databases and On-Line Analytical Processing Applications (OLAP). Data

Warehouses systems are used by decision makers to analyze the status and the develop-

ment of an organization [1], based on large amounts of data integrated from heteroge-

neous sources into a multidimensional (MD) model.

On the other hand, information security is a serious requirement that must be care-

fully taken into account, not as an isolated aspect, but as an element present in all stages

of the development lifecycle: from requirement analysis to implementation and main-

tenance [2, 3]. In this way, information assurance, security and privacy have moved

from being considered by information systems designers as narrow topics of interest

to become critical issues of fundamental importance in our society [4]. Some authors

indicate that the survival of organizations depends on the correct management of in-

formation security and conﬁdentiality [5]. Data Warehouses use enterprise information

for the decision making process and a user can ﬁnd out very important information by

using queries in OLAP tools. In this way, it is necessary that security measures deﬁned

in all early stages of the development process are applied in OLAP.

Blanco C., García-Rodríguez de Guzmán I., Fernández-Medina E., Trujillo J. and Piattini M. (2008).

Obtaining Secure Code in SQL Server Analysis Services by using MDA and QVT.

In Proceedings of the 6th International Workshop on Security in Information Systems, pages 38-48

DOI: 10.5220/0001745200380048

 SciTePress

In addition, OMG Model Driven Architecture (MDA) [6] is an standard for model-

driven approaches for software development that is based on the separation between

the speciﬁcation of the system functionality and its implementation using speciﬁc plat-

forms. MDA deﬁnes a Platform-Independent Model (PIM) that does not include infor-

mation about speciﬁc platforms and technologies. This model (PIM) can be translated

into: (1)one or more platform-speciﬁc models (PSM) with information about the used

speciﬁc technology; or (2) other PIMs with a different level of abstraction. Then, each

PSM can be translated into a code that can be executed in the speciﬁc platform. There

are several proposals for deﬁning these translations between models [7], and OMG

proposes to use Query/Views/Transformations (QVT) [8] for deﬁning transformations

between models created by using Meta-Object Facility (MOF).

In [9] a proposal for modeling secure Data Warehouses using a MDA approach,

that will be described in the following section, is presented. This proposal does not deal

with the ﬁnal implementation into OLAP tools. [10] discuss how security measures

deﬁned by using this approach could be ﬁnally implemented into OLAP tools. In this

paper, authors focus on obtain secure multidimensional code for SQL Server Analysis

Services in an automatic way following the MDA approach. Due to the lack of space

(and the extent of the presented MDA transformation), the QVT rules dealing with

the generation of the structural aspects are not presented, but those implementing the

security issues.

The rest of the paper is organized as follows: Section 2 we will describe our MDA

approach for developing secure DWs; Section 3 we will present our QVT transforma-

tions; and ﬁnally, Section 4 we will present our conclusions and future work. Code for

the proposed rules will be presented in greater detail in Appendix.

2 Model Driven Architecture For Developing Secure DWS

In this section our Model Driven Architecture for developing secure Data Warehouses

is presented. We focus on the description of the source (Secure Multidimensional PIM)

and target (SSAS Metamodel) models used by the QVT transformations proposed in

this work. Figure 1 illustrates our MDA architecture for developing secure Data Ware-

houses [9]. In this architecture security constraints speciﬁed at upper abstraction levels

are translated into conceptual, logical and code levels.

Fig. 1. MDA approach for developing secure DWs.

At business level we deﬁne both functional and non functional requirements for DWs

by using an UML proﬁle for i* called Secure Multidimensional CIM (SMD CIM) [11].

Using a QVT transformation it is possible to obtain a Secure Multidimensional PIM

(SMD PIM) at conceptual level represented with our Secure Data Warehouse (SECDW)

metamodel [12] that is an UML proﬁle for DWs enriched with an Access Control and

Audit model [13]. This conceptual model will be the source model for the proposed

QVT transformations and will be explained in more detail.

The speciﬁcation of a platform-speciﬁc model (PSM) is designed according to the

speciﬁc properties of the Database Management Systems (DBMS) such as Relational

Online Analytical Processing (ROLAP), Multidimensional Online Analytical Process-

ing (MOLAP) or Hybrid Online Analytical Processing (HOLAP). We have deﬁned

a Secure Multidimensional PSM (SMD PSM) at logical level, that is a ROLAP ap-

proach called Secure Relational Data Warehouse (SECRDW) [14]. This metamodel

extends the Relational Warehouse Metamodel (CWM) with security and audit capa-

bilities and allows us to model STables, SColumn, PrimaryKey, ForeingKey, etc. The

SecurityProperty and SecurityConstraint metaclasses are associated with the Table and

Column metaclasses to allow us deﬁning security at table and attribute levels. Besides,

SecurityConstraints let us express the constraints (SecurityRule, AuthorizationRule and

AuditRule) that are deﬁned in the SECDW metamodel with UML notes.

At code level we obtain metamodels with secure multidimensional code in the tar-

get platform that can be easily translated into ﬁnal code. In this work we deﬁne several

metamodels to represent constraints over a multidimensional approach (MOLAP) in

SQL Server Analysis Services. These metamodels will be the target models for the pro-

posed QVT transformation and will be presented in more detail in following sections.

In order to complete the MDA architecture, it is necessary to deﬁne the transforma-

tion between models. The transformation between conceptual and logical levels using

SMD PIM (SECDW) and SMD PSM (SECRDW) has already been deﬁned [15]. Fur-

thermore, the transformation from our relational metamodel at logical level (SECRDW)

to secure code in a DBMS using Oracle Label Security has been deﬁned too.

Due to the fact that in Data Warehouses OLAP tools are more used than DBMS, our

research effort is focused on developing multidimensional secure code into OLAP tools

according to the above-deﬁned security requirements at conceptual and logical levels.

In this paper, we follow the methodology deﬁned in [10] to translate security constraints

deﬁned at conceptual level (SECDW) into secure multidimensional code in SQL Server

Analysis Services, that can be automatically translated into ﬁnal code.

2.1 Secure Multidimensional Pim (SECDW)

Our Secure Multidimensional PIM, called Secure Data Warehouse (SECDW) [12], al-

lows us to represent the main security requirements for DW at conceptual level and it is

composed of an UML proﬁle for DWs [16] enriched with an Access Control and Audit

(ACA) model [13].

Traditional access control models are based on relational concepts (tables, columns,

rows, etc) and they are not appropriate for the multidimensional modeling used in Data

Warehouses. The ACA model [13] is an access control and audit model deﬁned for

DWs that allows us to specify security constraints in DW’s multidimensional models.

This model considers a combination of mandatory and role based access control which

is based on the classiﬁcation of subjects and objects in the system. ACA deﬁnes three

ways of classiﬁcation: security levels that indicate the clearance level of the user; secu-

rity roles that are used by a company to organize users in a hierarchical role structure

according to the responsibilities of each type of work (each user can play more than one

role); and security compartments that are used by an organization to classify users into

a set of horizontal compartments or groups. In the ACA model an authorization subject

is an identity composed of: userID (to identify the user), roleId (one or more user roles),

compartmentID (one or more user compartments), securityLevel (a security level or a

levels interval) and subjectExpression (OCL expression about the user proﬁles).

Fig. 2. Secure Multidimensional PIM (SECDW).

According to MD models, we can identify the main authorization objects as follows:

facts, dimension, classiﬁcation, hierarchy levels, measures, dimension attributes and

instances. The authorization object component is composed of two parts: an identity

(that can be one of the following subattributes: class name or attribute name) and an

objectExpression in OCL.

Our ACA model also allows us to deﬁne several kinds of security rules: Sensitive infor-

mation assignment rules (SIAR) that specify multilevel security policies and allow us

to deﬁne sensitivity information for each element in the MD model; Authorization rules

(AUR) that specify the subject which the rule applies to, the object which the authoriza-

tion refers to, the action which the rule refers to and the sign describing whether the rule

permits or denies access; and Auditing rules (AR) that help us ensure that authorized

users do not misuse their privileges.

SMD PIM metamodel (SECDW) is shown in Figure 2 and includes the main char-

acteristics of Data Warehouses as many-to-many relations, degenerated dimensions,

multiple classiﬁcations and the alternative path of hierarchies. We have improved this

metamodel with several classes that allow us to represent our security classiﬁcation in

roles, levels and compartments in order to use them to carry out our transformations

(i.e. for each security level we need to know what are the upper and inferior levels).

Security aspects can be deﬁned according to our Access Control and Audit model.

We can deﬁne security levels (SecurityLevels), user categories (SecurityCompartment),

user roles (SecurityRoles) and security constraints (SConstraints) for each element of

the metamodel: SecureFact, SecureDegenerateFact, SecureDimension, SecureBase, Se-

cureDegenerateDimension, SecureFactAttribute, SecureDescriptor, SecureOID and Se-

cureDimensionAttribute. Moreover, there is a UserProﬁle metaclass containing infor-

mation about each users right of access to the multidimensional model.

According to our ACA model we can deﬁne security rules (SIAR), authorization

rules (AUR) and audit rules (AU) by using OCL expressions and UML notes associated

with the corresponding class.

2.2 Secure Multidimensional Code (SSAS Metamodel)

To implement security measures into OLAP tools we have selected SQL Server Anal-

ysis Services (SSAS) because it works with multidimensional models and allows us

to deﬁne security measures over multidimensional elements (cube, dimension, cell).

However, SSAS uses a role-based access control policy (RBAC) that is supposed to

translate our measures deﬁned according to our ACA model (with security roles, levels

and compartments) into role approach.

Firstly, we have analyse source code in SSAS and we have deﬁned the needed meta-

models which represent multidimensional secure code with DW’s structure and security

measures in a previous step before ﬁnal code that can be automatically obtained from

these metamodels. SSAS deﬁnes a DW by using several XML source ﬁles. To obtain

our SSAS metamodels we focus on roles conﬁguration, DW’s structure deﬁnition and

how security constraints are speciﬁed.

In Figure 3 (a) is shown the role metamodel used to deﬁne roles in SSAS. We will

use this metamodel to deﬁne roles in SSAS for each security role, level and compart-

ment deﬁned at conceptual level. Figure 3 (b) shows the cube metamodel to represent

a cube in SSAS. We can deﬁne structural aspects for a cube as dimensions, attributes,

hierarchies or measures, and security constraints by using permissions over cubes, di-

mensions or cells. Finally, in Figure 3 (c) we can see the dimension metamodel for

deﬁning dimensions and bases in SSAS by using Attributes and Hierarchies. Security

Fig. 3. SSAS Metamodel: Role conﬁguration (a), Cube (b) and Dimension (c).

constraints can be established at dimension and cell levels and we can use complex

MDX queries as allowed or denied set to deﬁne advanced security constraints.

3 Transformations

In order to obtain secure multidimensional code we follow the methodology previously

deﬁned in [10]. According to our ACA model we threat with levels, compartments and

roles but in SSAS we use a role-based policy and in a ﬁrst step we have to translate this

security information by creating new roles for each possible classiﬁcation.

SSAS uses an open policy with speciﬁc denials and we have to deﬁne what multidimen-

sional elements are hidden for certain roles. Therefore, we have to analyse the security

rules deﬁned at conceptual level, to detect the involved roles and to hide them certain

DW elements. To hide these elements we have to consider the concepts of security role,

level and compartment. When access is denied to a certain security role this access has

to be also denied to its descendants, and when is denied to a certain security level access

has to be denied to each role that represents a lower security level.

Due to space constraints, this paper does not include the structural transformation and

is focused on obtaining the secure multidimensional code corresponding to the security

rules deﬁned in our SECDW metamodel at conceptual level (see Figure 4). The analysis

Fig. 4. General view of the proposed transformations.

and the automatic transformation of advanced security rules (SIAR and AUR) deﬁned in

UML notes with OCL expressions will be treated in future works. To deﬁne Audit rules

in SSAS, administrators can directly establish audit activity on data including informa-

tion about when data has been read and modiﬁed. These deﬁned rules are presented in

greater detail in Appendix and are composed of three main transformations (see Fig-

ure 4): SECDW2Role, SECDW2Cube and SECDW2Dimension. SECDW2Role is in

charge of generating the set of models representing the ”role ﬁles”. After executing

SECDW2Role the models produced contains enough information to easily produce the

XML Role ﬁles. SECDW2Cube obtains Cube ﬁles from the SECDW model. The Cube

ﬁles are also a very important part in the DW description. Thus, the transformation

SECDW2Cube tackles with the generation of models representing this ﬁles. This trans-

formation deals on one hand with the generation of structure of the DW and on the other

hand with the inclusion of the aforementioned security issues. Due to the lack of space,

the structural rules has been omitted. Finally, SECDW2Dimensions is in charge of pro-

ducing the set of models representing the dimensions of the DW. Due to the extent of

the transformation only the security issues has been taken into account for this paper.

4 Conclusions

We have accomplished an important step to complete our MDA architecture for de-

veloping secure Data Warehouses with the automatic generation of secure multidimen-

sional code into an speciﬁc OLAP tool, SQL Server Analysis Services, by using QVT

transformations.

In a previous work we obtained secure code for Oracle Label Security from a rela-

tional PSM metamodel, but we used a relational approach in a DBMS. In Data Ware-

houses, OLAP tools are more used than DBMS and we are focus our research effort on

OLAP tools and multidimensional approaches.

Therefore, in this work we use the multidimensional capabilities of SSAS to trans-

late the security measures deﬁned in our secure multidimensional model at conceptual

level into secure multidimensional code for SSAS. We obtain code with the role con-

ﬁguration of our system, the structural deﬁnition of the DW and the main part of the

security measures deﬁned at above levels. The ﬁnal code adds other elements that can

be easily obtained from our multidimensional secure code with an automatic transfor-

mation.

On the other hand, we realize that OLAP tools do not support the complete security

requirements deﬁnition over the multidimensional model at upper abstraction levels and

deal with partial security establishment. SSAS only uses RBAC as access control policy

and our security model is richer than the security capabilities that SSAS offers. We have

adapted our security information into a role-based approach and we have hidden mul-

tidimensional elements for certain roles to represents security rules. Furthermore, we

can not represent security constraints on OLAP operations at upper abstraction levels

allowing users to avoid the access to unauthorized information by using navigations or

inferences.

Our MDA architecture for developing secure DW allows us to deﬁne security re-

quirements but should be extended with the possibility of establishing navigations and

inferences constraints that can be translated into OLAP code. In the same way, tools

should be extended to give us control over navigations and inferences that can ﬁnd out

unauthorized enterprise information.

As a future work, we will deﬁne the remainder of the QVT transformations to ob-

tain secure multidimensional code in SSAS from conceptual models. We will extend

this work presenting the structural transformations that did not include due to space

constraints. We will analyse the advanced security rules deﬁned with OCL expressions

and we will create the corresponding QVT transformations to complete our secure code.

And ﬁnally, we will also extend this complete approach to obtain secure multidimen-

sional code in other OLAP tools as Pentaho.

Acknowledgements

This research is part of the ESFINGE (TIN2006-15175-C05-05) and METASIGN

(TIN2004-00779) Projects ﬁnanced by the Spanish Ministry of Education and Science,

and of the MISTICO (PBC-06-0082) Project ﬁnanced by the FEDER and the Regional

Science and Technology Ministry of Castilla-La Mancha (Spain).

References

1. Kimball, R.: The Data Warehouse Toolkit 2 Edition. John Wiley and Sons (2002)

2. Devanbu, P., Stubblebine, S.: Software engineering for security: a roadmap. ACM Press.

Future of Software Engineering (2000) 227–239

3. Mouratidis, H., Giorgini, P.: An introduction. In: Integrating Security and Software Engi-

neering: Advances and Future Visions. Idea Group Publishing (2006)

4. Denker, G., Kagal, L., Finin, T.: Security in the semantic web using owl. Information

Security Technical Report 10 (2005) 51–58

5. Dhillon, G., Backhouse, J.: Information system security management in the new millennium.

Communications of the ACM 43 (2000) 125–128

6. MDA, O.M.G.: Model driven architecture guide. (2003)

7. Czarnecki, K., Helsen, S.: Classiﬁcation of model transformation approaches. (2003)

8. QVT, O.M.G.: (Omg mof 2.0 query, views, transformations request for proposals)

9. Fern

andez-Medina, E., Trujillo, J., Piattini, M.: Model driven multidimensional modeling of

secure data warehouses. European Journal of Information Systems 16 (2007) 374–389

10. Blanco, C., Fern

andez-Medina, E., Trujillo, J., Piattini, M.: Implementing multidimensional

security into olap tools. In: Third International Workshop ”Dependability Aspects on Data

WArehousing and Mining applications” (DAWAM 2008), Barcelona, Spain, IEEE Computer

Society (2008) 1248–1253

11. Soler, E., Stefanov, V., Maz

on, J.N., Trujillo, J., Fern

andez-Medina, E., Piattini, M.: To-

wards comprehensive requirement analysis for data warehouses: Considering security re-

quirements. In: Proccedings of The Third International Conference on Availability, Reliabil-

ity and Security (ARES), Barcelona, Spain, IEEE Computer Society (2008) 104–111

12. Fernndez-Medina, E., Trujillo, J., Villarroel, R., Piattini, M.: Developing secure data ware-

houses with a uml extension. Information Systems 32 (2007) 826–856

13. Fern

andez-Medina, E., Trujillo, J., Villarroel, R., Piattini, M.: Access control and audit

model for the multidimensional modeling of data warehouses. Decision Support Systems 42

(2006) 1270–1289

14. Soler, E., Villaroel, R., Trujillo, J., Fernndez-Medina, E., Piattini, M.: Representing security

and audit rules for data warehouses at the logical level by using the common warehouse

metamodel. In: 1st Int. Conference on Availability, Reliability and Security, Vienna, Austria

(2006) 914–921

15. Soler, E., Trujillo, J., Fernndez-Medina, E., Piattini, M.: A set of qvt relations to transform

pim to psm in the design of secure data warehouses. In: IEEE International Symposium

on Frontiers on Availability, Reliability and Security (FARES 2007), Viena, Austria (2007)

644–651

16. Lujan-Mora, S., Trujillo, J., Song, I.Y.: A uml proﬁle for multidimensional modeling in data

warehouses. Data and Knowledge Engineering 59 (2006) 725–769

Appendix

In this Appendix the QVT transformations deﬁned to obtain secure multidimensional

code from conceptual models deﬁned according to our SECDW metamodel are pre-

sented focusing on security rules. The proposed transformations are divided into sev-

eral relations, each of them is in charge of transforming elements from the source model

into elements of the target model. It is possible to distinguish between two kinds of re-

lations: relations and top relations. Top relations are mandatory and must always be

held by both the source and target models. On the opposite, simple relations and only

executed when other relations invokes them. Thus, top relation could be considered as

a ”main” function or method.

SECDW2Role

transformation SECDW2Role(SECDW pim, Role psm){

top relation Package2RoleFiles {

checkonly domain psm p:Package{

name = n;

ownedMember = OWNMEMB:Set(PackageableElement); }

enforce domain pim rf:RoleFiles{

name = n;

ownedRoles = OWNROLES:Set(Role); }

where{

OWNMEMB->forAll(sr:SRole | OWNROLS->including

(SRole2Role(sr)));

OWNMEMB->forAll(sc:SCompartment |

OWNROLS->including(SCompartment2Role(sc)));

OWNMEMB->forAll(sl:SLevel | OWNROLS->including

(SLevel2Role(sl))); }

}

relation SCompartment2Role {

checkonly domain psm sc:SCompartment{

name = n; }

enforce domain pim r:Role{

fileName = "SC"+n+".role";

ID = "SC"+n;

roleName = "SC"+n;

ownedMembers = OWNEDMEMBS:Set(Member); }

}

relation SRole2Role {

checkonly domain psm sr:SRole{

name = n; }

enforce domain pim r:Role{

fileName = "SR"+n+".role";

ID = "SR"+n;

roleName = "SR"+n;

ownedMembers = OWNMEMBS:Set(Member); }

}

relation SLevel2Role {

checkonly domain psm sl:SRole{

name = n; }

enforce domain pim r:Role{

fileName = "SL"+n+".role";

ID = "SL"+n;

roleName = "SL"+n;

ownedMembers = OWNEDMEMBS:Set(Member); }

}

SECDW2Cube

transformation SECDW2Cube (SECDW psm, Cube pim){

top relation Package2CubeFiles{

checkonly domain psm p:Package{

name = n;

ownedMember = OWNMEMB:Set(PackageableElement); }

enforce domaim pim d:DataWareHouse{

name = n;

ownedCubes = OWNCUBS:Set(Cube); }

where{

OWNMEMB->forAll(sf:SFact |

OWNCUBS->including(SFact2Cube(sf))); }

}

relation SFact2Cube{

checkonly domain psm sf:SFact{

name = n;

securityLevels= SECLEVS:Set(Level);

securityRoles = SECROL:Set(Role);

securityCompartments = SECCOMPS:Set(Compartment);

ownedAttribute = OWNATTR:Set(Property); }

enforce domain pim c:Cube{

name = n;

ID = n;

ownedCubePermissions = OWNCUBEPERMS:Set(CubePermission); }

where{

securityCompartments->forAll(sc:SCompartment |

SCompartmentClass2CubePermission(sc,c));

securityRoles->forAll(sr:SRole |

functionGetRoleChilds(sl)->forAll(srChild:SRole|

SRoleClass2CubePermission(sr,c));

securityLevels->forAll(sl:SLevel |

functionGetUpperLevels(sl)->forAll(slUpper:SLevel|

SLevelClass2CubePermission(sl,c)); }

}

relation CreateMeasureGroups {…}

relation SProperty2Measure {…}

relation SDimension2Dimension {…}

relation ProcessSBase {…}

relation CreateOwnedHierarchies {…}

relation SProperty2Attribute {…}

relation SCompartmentClass2CubePermission{

checkonly domain psm sc:SCompartment{

name = n; }

enforce domain pim c:Cube{

name = cubeName;

ID = cubeName;

ownedCubePermissions = OWNCUBEPERMS:Set(CubePermission); }

enforce domain pim cp:CubePermission{

ID = "CubePermission"+n;

name = "CubePermission"+n;

RoleID = n;

Process = "true";

Read = "Allowed"; }

where{

OWNCUBEPERMS->including(cp); }

}

relation SRoleClass2CubePermission{

checkonly domain psm sr:SRole{

name = n; }

enforce domain pim c:Cube{

name = cubeName;

ID = cubeName;

ownedCubePermissions = OWNCUBEPERMS:Set(CubePermission); }

enforce domain pim cp:CubePermission{

ID = "CubePermission"+n;

name = "CubePermission"+n;

RoleID = n;

Process = "true";

Read = "Allowed"; }

where{

OWNCUBEPERMS->including(cp); }

}

relation SLevelClass2CubePermission{

checkonly domain psm sl:SLevel{

name = n; }

enforce domain pim c:Cube{

name = cubeName;

ID = cubeName;

ownedCubePermissions = OWNCUBEPERMS:Set(CubePermission); }

enforce domain pim cp:CubePermission{

ID = "CubePermission"+n;

name = "CubePermission"+n;

RoleID = n;

Process = "true";

Read = "Allowed"; }

where{

OWNCUBEPERMS->including(cp); }

}

relation SCompartmentAtt2CellPermission {…}

relation SRoleAtt2CellPermission {…}

relation SLevelAtt2CellPermission {…}

SECDW2Dimension

transformation SECDW2Dimensions(SECDW pim, Dimensions psm){

top relation Package2DimensionFiles{

checkonly domain pim p:Package{

name = n; ownedMembers }

enforce domain psm df:DimensionFiles{

name = n;

ownedDimensions = OWNDIMS:Set(Dimension); }

where{

OWNMEMB->forAll(sd:SDimension | SDimension2Dimension(df,sd)); }

}

relation SDimension2Dimension{

enforce domain psm df:DimensionFiles{

name = n; }

checkonly domain pim sd:SDimension{

name = sdName;

securityLevels = SECLEVS:Set(SLevel);

securityRoles = SECROLS:Set(SRole);

securityCompartments = SECCOMPS:Set(SCompartment);

ownedAttribute = OWNATTR:Set(Property); }

enforce domain psm d:Dimension{

ID = sdName; Name = sdName; }

when{ n = sd.owner.name; }

where{

SDimension.owner.owner->forAll(sc:SCompartment |

createDimensionSIARForSCompartment(sc,d));

SECCOMPS->forAll(sc:SCompartment |

authorizeSCompartment(sc,tempSCompartment));

SDimension.owner.owner->forAll(sr:SRole |

createDimensionSIARForSRole(sr,d));

SECROLS->forAll(sr:SRole |

getLeafSecurityRoles(sr)->forAll(tempSRole:SRole |

authorizeSRole(d,tempSRole));

SDimension.owner.owner->forAll(sl:SLevel |

createDimensionSIARForSLevel(sl,d));

SECLEVS->forAll(sl:SLevel |

getUpperSecurityLevels(sl)->forAll(tempSLevel:SLevel |

authorizeSLevel(d,tempSLevel));

OWNATTR->select(oclIsKindOf(SecureProperty))->

forAll(sp:SecureProperty | processSecureProperty(sd,d,sp)) }

}

relation KeyProperty2KeyAttribute {…}

relation NonKeyProperty2Attribute {…}

relation SBase2Attributes {…}

relation createDimensionSIARForSCompartment{

checkonly domain pim sc:SCompartment{ name = compartmentName; }

enforce domain pim d:Dimension{

name = dimName;

ownedDimensionPermissions = OWNDIMPERMS:Set(DimensionPermission); }

enforce domain psm ap:DimensionPermission{

ID = "DimensionPermission" + compartmentName;

Name = "DimensionPermission" + compartmentName;

RoleID = compartmentName; }

}

relation createDimensionSIARForSRole{

checkonly domain pim sr:SRole{ name = roleName; }

enforce domain pim d:Dimension{

name = dimName;

ownedDimensionPermissions = OWNDIMPERMS:Set(DimensionPermission); }

enforce domain psm ap:DimensionPermission{

ID = "DimensionPermission" + roleName;

Name = "DimensionPermission" + roleName;

RoleID = roleName; }

}

relation createDimensionSIARForSLevel{

checkonly domain pim Sl:SLevel{ name = levelName; }

enforce domain pim d:Dimension{

name = dimName;

ownedDimensionPermissions = OWNDIMPERMS:Set(DimensionPermission); }

enforce domain psm ap:DimensionPermission{

ID = "DimensionPermission" + levelName;

Name = "DimensionPermission" + levelName;

RoleID = levelName; }

}

relation authorizeSCompartment {…}

relation authorizeSRole{

enforce domain psm d:Dimension{

name = n;

ownedDimensionPermissions = OWNDIMPERMS:Set(DimensionPermission); }

checkonly domain pim sr:SRole{

name = sRolName; }

where{

let authDimPer:DimensionPermission = OWNDIMPERMS->

select(ID = ("DimensionPermission"+sRolName)) in

authDimPer.Read = "Allowed"; authDimPer.Process = "true"; }

}

relation authorizeSLevel{

enforce domain psm d:Dimension{

name = n;

ownedDimensionPermissions = OWNDIMPERMS:Set(DimensionPermission); }

checkonly domain pim sl:SLevel{ name = slevelName; }

where{

let authDimPer:DimensionPermission = OWNDIMPERMS->

select(ID = ("DimensionPermission"+slevelName)) in

authDimPer.Read = "Allowed"; authDimPer.Process = "true"; }

}

relation processSecureProperty{

checkonly domain pim sd:SDimension{

name = n; }

enforce domain psm d:Dimension{

name = n;

ownedDimensionPermissions = OWNDIMPER:Set(DimensionPermission); }

checkonly domain pim sp:SecureProperty{

name = spName;

securityLevels = SECLEVS:Set(SLevel);

securityRoles = SECROLS:Set(SRole);

securityCompartments = SECCOMPS:Set(SCompartment); }

where{

SECLEVS->forAll(sl:SLevel |

getUpperLevels(sl)->forAll(tmpSLevel:SLevel |

createPositiveAttributePermisions(d.ownedDimensionPermisions->

select(ID=("DimensionPermission"+tmpSLevel.name)),sp);

getLowerLevels(sl)-> forAll(tmpSLevel:SLevel |

createNegativeAttributePermisions(d.ownedDimensionPermisions->

select(ID=("DimensionPermission"+tmpSLevel.name)),sp);

SECROLS->forAll(sr:SRole |

getLeafSRoles(sr)->forAll(tmpSRole:SRole |

createPositiveAttributePermisions (d.ownedDimensionPermisions->

select(ID=("DimensionPermission"+tmpSRole.name)),sp);

getNonLeafRoles(sr)->forAll(tmpSRole:SRole |

createNegativeAttributePermisions(d.ownedDimensionPermisions->

select(ID=("DimensionPermission"+tmpSRole.name)),sp);

SECLEVS->forAll(sc:SCompartment |

createPositiveAttributePermisions (d.ownedDimensionPermisions->

select(ID=("DimensionPermission"+sl.name)),sp); }

}

relation createPositiveAttributePermisions{

checkonly domain pim sp:SecureProperty{

name = spName; }

enforce domain psm dp:DimensionPermission{

ID = "DimensionPermission"+ID;

Name = "DimensionPermission"+ID;

ownedAttributePermissions = OWNATTPERMS:Set(AttributePermission); }

enforce domain psm at:AttributePermission{

AttributeID = spName; }

}

relation createNegativeAttributePermissions{

checkonly domain pim sp:SecureProperty{

name = spName; }

enforce domain psm dp:DimensionPermission{

ID = "DimensionPermission"+ID;

Name = "DimensionPermission"+ID;

ownedAttributePermissions = OWNATTPERMS:Set(AttributePermission); }

enforce domain psm at:AttributePermission{

AttributeID = spName;

DeniedSet = "["+sp.class.name+"].["+sp.name+"]"; }

}