A Scalable Modeling Language for Specifying

Access Control in Tree Based StructuresAme Osleb0UNINETT

Arne.Oslebo@uninett.no

Abstract- Configuring and managing access control in today'sheterogeneous systems is a big challenge. While there exist manystandards for authentication, different types of systems often havedifferent methods for configuring the access control.

In this paper we propose a new policy based graphical modelinglanguage that can be used for modeling and configuring accesscontrol in a wide range of different systems. The only requirementis that the information which is being controlled by the accesscontrol system is stored in a tree-based structure.

I. INTRODUCTION

In computer science and telecommunication there are manyexamples of highly successful graphical notations. Graphicalnotations are ideal for dealing with complex systems since theyact as an abstraction so that people do not have to worry aboutall the small details.

In this paper we present a new modeling language formodeling access control in systems that store information intree-based structures. With this language, Policy Tree-basedAccess Control Modeling Language (PTACOMA), it is possibleto use one single modeling language to specify and configureaccess control in a large number of different systems.

Storing information in a tree based structure is a verycommon method. Some examples are SNMP, XML, LDAP andeven a file system. With PTACOMA it is possible to specify theaccess control in all these systems using the same notation.Thismeans that administrators only have to learn one method forspecifying and configuring access control.

II. POLICY TREE-BASED ACCESS CONTROL MODELINGLANGUAGE

PTACOMA is a graphical modeling language for specifyingaccess control in systems that store information in tree-basedstructures. It is highly scalable both when it comes to numberof users, entities and the size of the three-based data structurefor which access control is being configured.

Fig. 1 shows the PTACOMA framework and the variouscomponents that are needed for using PTACOMA to configurethe access control in a system. Two goals when designingPTACOMA were to make it simple to use and easy to imple-ment support for new systems. So in this figure only the fourboxes with grey background have to be specifically designedfor different types of systems.The various components are:

UMLeditor

PTACOMA PTOTM ApX editor l XSLT ll

XMLAS OMA > p COA < AMc~~~~~~~~~~~~01 SmahOce;

Fig. 1. TACOMA framework

1) Editor. used for drawing PTACOMA diagrams and storethe diagram in a PTACOMA XML file. It is also possible touse a standard UML editor, in which case XSLT is used fortransforming the UMIL XMI based file to PTACOMA XML.

2) PTACOMA parser. takes a PTACOMA XML file asinput, verifies it against the PTACOMA XML Schema as wellas an optional application specific XML Schema and generatesa list of access rules for each user and entity in the diagram.

3) EOID parser. EOID or extended object identifier, is aterm used in PTACOMA for specifying an exact node in a treestructure. The exact syntax of an EOID will vary depending onthe system being configured. For example if SNMP is beingconfigured, then an EOID will be similar to an OID as definedin RFC2252, while for XML based systems an EOID could bean XPATH expression. An EOID can also contain wildcardsand functions that are evaluated to real values at the time ofconfiguration.

4) ACL optimizer. optimizes the number of access controlrules that has to be configured in a system.

5) Tree generator. for the ACL optimizer to be fully ef-fective, it is often necessary to have a full view of the treestructure in the system being configured. The Tree generatorprovides this service. In an SNMP scenario, the Tree generator

1-4244-0799-0/07/$25.00 t2007 IEEE 809

A\O EIDZSKiChildren Domain Entity Group Node Policy Constraint

<' AIIyS.b> ..l.' U.Policy vievv Role Subtree Table row l-ype User

Ul

Rl

<>P1

Rl

subject logical

Fig. 2. PTACOMA symbols

would be able to read and parse SMI MIB files and generatea tree structure based on this.

6) ACL configurator. receives a list of access control rulesand uses them to do the appropriate configuration needed toimplement the access control according to the PTACOMAdiagrams. It can either configure entities directly, or it canoutput ACL rules in formats like XACML.

A. SymbolsThe PTACOMA language consists of 13 different symbols

and various relations as shown in Fig. 2. The policy symbolspecifies a policy and is the main symbol used in PTACOMAto specify access rights. All policy symbols will have othersymbols related to them to specify subjects, targets and con-straints.PTACOMA has full support for core Role-Based Access

Control (RBAC)[3], [5], [6], [7], [8]. This means that access

rights are always assigned to roles and then users are assignedone or more roles. PTACOMA also has full support for Hier-archical RBAC as well good support for static separation ofduty and limited support for dynamic separation of duty. Withseparation of duty policies it is for example possible to specifythat a user who has been assigned role ro can not also beassigned role r1.

Fig. 3 shows an example of a simple PTACOMA diagram.In this figure there is one single policy, P1, that grants accessto the children of node 1.2 and node 1.4 in entity El for userswith the role RI. We can also see that one single user, U1,is assigned this role. The entity symbol specifies the entitythat should be configured and the children and node symbolsspecifies the targets in the entity.An attribute of the policy symbol P1 specifies what type of

access that should be allowed, for example if it is read only,read-write etc.PTACOMA has several mechanisms for improving the scal-

ability of the language. The group symbol can be used forgrouping together other PTACOMA symbols so that they can bereused between different policies. Instead of explicitly specifyentities in a policy it is also possible to specify an entity typeand then assign an entity one or more types.

In heterogeneous systems there are often entities of differenttypes that needs to be configured differently to provide accessto the same type of information. On solution could be to createa new policy for each type of entity. As this will not scale well

Fig. 3. PTACOMA diagram

for large heterogeneous systems, PTACOMA has somethingcalled a Policy View symbol. With this symbol it is possible tocreate generic policies that grants access to information withoutknowing the exact implementation of the entities.

Say that you want to give user A access to all entities ina specific domains so that he can look at all users that arelogged on to those entities. The entities are of different typesand the needed access control varies between them. Using thePolicy View symbol it is possible to create one single policythat specifies this. Then for each type of entity all that is neededis to define how this Policy View needs to be implemented forthis specific entity. This separates the specification of the accesscontrol policy from the detailed knowledge of how entities arebuilt.

III. FORMAL SPECIFICATION

The formal specification of PTACOMA is provided by acombination of a set of metamodels and an XML Schema. Thefull specification consists of 13 metamodel diagrams and theXML Schema is capable of formally specify some issues notcaptured by the meta models.

The metamodel for a policy is shown in Fig. 4. As we cansee from this metamodel, a policy consists of the policy symbolwith one or more subject relations to a set of subject symbolsand one or more include or exclude relations to symbols thatdefines constraints and targets.

The exact syntax for specifying subjects, targets and con-straints are further detailed in other metamodel diagrams.

IV. DOMAIN HIERARCHY

In PTACOMA there are two possible hierarchies of policies,those that are formed by using group symbols and those formedby domains. To resolve possible conflicts, the access rules arecalculated using a top-down approach based on the hierarchyformed by domains. For each domain the hierarchy formed bygroups are then calculated. Policies on a higher level has higherpriority than the ones on lower levels.

Conflicts between different levels of domains can often beresolved automatically. For example if a policy on a lower levelgives full access to an entity for a user and a policy on a higherlevel restricts users of this domain to only a small subset, then

810

11 -4

/N1.2 1.4

Exclude Include

from

1.

Subjecti

-to771

Polic from Rlto

-to

Sm1

S= _I vmbo

Fig. 4. Policy metamodel

users should only be granted access as specified by the higherlevel policy.

Every domain in PTACOMA can also be defined as strictor open. A strict domain can only specify policies for usersand entities that belong to this domain or children domains.An open domain can specify policies that includes users andentities from all domains. The only requirement is that eitherthe subjects or the targets of a policy must belong to thedomain.A policy can specify the maximum, minimum or exact access

rights. When a policy specifies the maximum access allowedfor a role, then policies in lower level domains are allowedto remove some of the access rights. With a minimum policy,other policies at lower levels can add to the access rights andwith an exact policy other policies can not make any changes.

A. Distributed management

One other advantage with having multiple domains is thatit is possible to distribute the task of specifying policies.Administrators on higher levels can make broad policies whileadministrators on lower levels can do detailed configurationor further delegate authorization to other sub-domains. PTA-COMA supports this by using an editor that supports distributedediting of the same PTACOMA diagram. Administrators ofdomains should only have permission to change diagrams fortheir own domain.Many commercial UML editors already supports this today

and can be used for drawing PTACOMA diagrams.

V. USING PTACOMA TO MODEL ACCESS CONTROL IN ALARGE SCALE DEPLOYMENT OF PASSIVE MONITORING

PROBES

UNINETT, the Norwegian NREN, is currently in the processof deploying a large number of passive monitoring probesas part of the GigaCampus project[1 1]. These probes will bedeployed both in the backbone network as well as access linksto customers and will be based on technology from the ISTproject LOBSTER[10]. The deployment on access links ofcustomers will be based on a cooperation between the customerand UNINETT and both parties will be able to use the passive

monitoring probe for security, QoS monitoring, general networkusage statistics and research.One challenge in deploying passive monitoring probes in a

multi-domain environment is privacy and confidentiality issues.With the probes it is possible to look deep into the payload ofpackets which makes it important to have full control over whouses the probes and what they are used for. It must be possibleto monitor active users of the probes to see what they are doing.Customers should be allowed to see some of this managementinformation, but not necessarily all the information. This iswhere PTACOMA comes in as a good method for configuringthe access control of the management system on the monitoringprobes.

A. Monitoring APIThe Monitoring API(MAPI)[14] is the key technology used

in the passive monitoring probes. M\API was originally imple-mented as part of the IST project SCAMPI[9] and is now beingimproved in LOBSTER.MAPI was designed for making the development of mon-

itoring applications quicker and easier. Applications that usesM\API can run on top of various types of hardware without anychanges and advanced on-board processing capabilities on thenetwork adapter is automatically utilized whenever possible.

M\API is centered on the notion of a network flow. A networkflow will initially represent all the packets seen on the networkby the network adapter, but functions can then be applied to theflow to limit the number of packets. These functions can forexample be BPF filter, sampling, string search, packet counteretc. When all functions have been applied, the application canconnect to the flow and start reading the results.M\API also supports distributed monitoring where an appli-

cation can connect to multiple remote monitoring probes.

B. Monitoring probes managementTo be able to track who is using MAPI and what they are

doing, it is necessary to instrument \API so that the necessaryinformation can be retrieved. For each flow it should be possibleto see who created the flow and which functions were appliedand what arguments were passed to the functions. This way itis possible to keep a detailed log of what each user is doing.M\API already has an SNMP MIB[12] that provides some of

this information, and this can easily be extended to provide allthe necessary information. This new MAPI SNMP MIB wouldbe divided into into five different groups which in SNMP areall organized into tables:

1) Interfaces. detailed information about available interfacesthat can be used by MAPI.

2) Users. information about all uses allowed to connect toMAPI.

3) Flows. list of active flows with information about whichuser who owns the flow, which interface the flow runs on andthe number of captured packets, dropped packets etc.

4) Functions. list of functions applied to active flows.5) Arguments. list of arguments that were passed to each

function.

811

OwnflowsI I

<<S>/ 'I

0 0Customers Customers

e.User MAPI

A z,"IzI iz' zizizmapiMIB.interfaces mapiMIB.flows.ORG(.UID( mapiMIB.args.ORG(.UID(

mapiMIB.users.ORG(. UID( mapiMIB.functions.ORG(). UD(

Fig. 5. PTACOMA MAPI diagrams

C. Access control requirementsUNINETT administrators should have full access to all

information in the MAPI MIB. Customer administrators shouldbe able to see some information about all active users on theirown probe and detailed information about users belonging totheir domain that are running monitoring applications on bothlocal and remote monitoring probes. The information aboutguest users on their own probe should be limited to user IDand name of organization as well as information about flowsand functions. The full name of a user should not be disclosed.

Guest users should only be allowed access to their own flowsand information about available interfaces is open for everyone.

This access control requirements can easily be fulfilled inSNMP by including an organization and user ID as index tothe Users, Flows, Functions and Arguments tables in the M\APIMIB. Using these indexes it is possible to configure the View-based Access Control Model (VACM)[13] in SNMP v3 forproper access control.

The only problem with this is that as the number of usersincreases the number of configuration lines needed to configureVACM increases rapidly. Even for a moderate number of users,several hundred configuration lines are needed and it is veryeasy to loose control over who has access to what.

D. PTACOAJA diagramsSpecifying the needed access control rules in PTACOMA is

relatively simple and all that is needed is three policies, onefor each user type. One policy is shown in Fig. 5.

This policy grants guest users full access to the interfacestable and access to their own flows, functions and arguments.This is done by limiting access to the tables to include onlyrows with index ORG(.UID(. The ORG( and UID( functionsare translated into the organization and user ID at configurationso that only rows belonging to the user is accessible. This wayonly one single policy for guest users is necessary.

VI. SUMMARY AND FUTURE WORK

In this paper we have presented a new graphical modelinglanguage for specifying access control in applications and

systems that store information in tree based systems. Theadvantage of PTACOMA is that it is a policy based graphicallanguage that is highly scalable and it is possible to use thesame language to specify access control rules for a largenumber of different types of applications and systems.

The example that was provided was relatively simple andonly need a few of the features available in the PTACOMAlanguage. Even so it clearly demonstrated the ease of specifyingaccess control in an SNMP framework using PTACOMA. Handediting several hundred lines of access control configuration isnot scalable. One other alternative could have been to createa script that automatically added and deleted users from theaccess control for the M\API MIB. This however has thedisadvantage of only working for this specific application. Ifaccess to other SNMP MIBs should be configured, a new scriptwould have to be developed.

Using a script also locks you to the SNMP technology.In the future it might be more suitable to move the mon-itoring of M\API to other technologies like WSDM[16] orNETCONF[17]. Both these technologies are XML based andas long as the data model remains the same, the PTACOMAdiagrams would still be valid. All that would be needed is anew ACL configurator.A PTACOMA prototype with SNMP support has been imple-

mented, but so far only supports a small subset ofthe features oflanguage. A full featured implementation is needed to be ableto experiment with the language and gain more experience withit to see if further enhancements are needed.

REFERENCES

[1] M. Sloman, "Policy driven management for distributed systems", 1994[2] David F. Ferraiolo and Ravi S. Sandhu and Serban I. Gavrila and

D. Richard Kuhn and Ramaswamy Chandramouli, "Proposed {NIST}standard for role-based access control", 2001

[3] D. Ferraiolo and R. Kuhn, "Role-Based Access Controls",1992[4] XACML, http://xml.coverpages.org/xacml.html[5] Matunda Nyanchama and Sylvia L. Osborn, "Access Rights Administra-

tion in Role-Based Security Systems", 1994[6] John F. Barkley and Konstantin Beznosov and Jinny Uppal, "Supporting

Relationships in Access Control Using Role Based Access Control", 1999[7] David F. Ferraiolo and John F. Barkley and D. Richard Kuhn, "A

role-based access control model and reference implementation within acorporate intranet", 1999

[8] Ravi S. Sandhu and Edward J. Coyne and Hal L. Feinstein and CharlesE. Youman, "Role-Based Access Control Models", 1996

[9] SCAMPI IST project, http://www.ist-scampi.org[10] LOBSTER IST project, http://www.ist-lobster.org[11] Olaf Schjelderup, "GigaCampus - a new generation of university and

college campus networks", NORDUnet2005[12] SCAMPI Project, "D1.2 SCAMPI Architecture and Component Design",

2003[13] RFC 2275, "View-based Access Control Model (VACM) for the Simple

Network Management Protocol (SNMP)", 1998[14] M. Polychronakis, E.P. Markatos, K.G.Anagnostakis and Arne

Osleb0,"Design of an Application Programming Interface for IPNetworking Monitoring", NOMS 2004

[15] Panos Trimintzios, Michalis Polychronakis, Antonis Papadogiannakis,Michalis Foukarakis, Evangelos Markatos & Ame Osleb0, "DiMAPI: AnApplication Programming Interface for Distributed Network Monitoring",NOMS 2006

[16] OASIS, "An Introduction to WSDM", wsdm-1.0-intro-primer-cd-01, 2006[17] IETF, "Network Configuration (netconf) working group",

http://www.ietf.org/html.charters/netconf-charter.html

812