1

Licit: Administering Usage Licenses in FederatedEnvironments

Prashant C. Kediyal and Munindar P. Singh, Fellow, IEEE

Abstract—We address the problem of usage license administration in federated settings. This problem arises whenever organizations, such aseducational or research groups or institutions, share resources for business and scientific reasons. In such settings, each user’s usage of a licensedresource is typically supported by the user’s organization. License administration involves satisfying legal requirements while applying organizationalstrategies for effective resource usage, and carrying out suitable accounting and audit controls.We propose an approach, Licit, wherein an agent represents each resource sharing site and administers licenses in collaboration with other agents.We show how to represent a variety of usage licenses formally as executable policies and provide a simple information model using which each partycan specify both the attributes involved in its licenses and how to resolve them. Our architecture naturally accommodates a variety of site-specific(i.e., custom) strategies for license administration. Licit has been implemented in a popular open source framework for virtual computing, and yieldsperformance results indicating its practical feasibility.

Index Terms—IT administration, grid computing, cloud computing, usage licenses, XACML

✦

1 INTRODUCTION

Computing infrastructure is expensive to acquire, main-tain, support, and administer. For this reason, recentadvances in distributed computing under the rubricsof grid computing and cloud computing [1] promisesignificant gains in resource usage efficiency and staffproductivity. Scientific and educational computing aretwo important settings where the above-mentioned ad-vances can apply [2]. For example, research groupsin different institutions can contribute their otherwiseunused resources to a common pool with the under-standing that they would benefit from the commonpool when they need additional resources. In higher-education settings, university departments and labs areable similarly to share their resources. In K-12 education,school districts are finding that maintaining separatecomputing infrastructures individually for each schoolis prohibitively expensive. In all these cases, the goal isto improve resource usage through federation.

Our motivation becomes more apparent in connec-tion with emerging kinds of scientific workflows. Tra-ditionally, workflows have been thought of as limitedto individual organizations. However, recent researchhas begun to show a shift toward federated settings.For example, Blake and Huhns [3] motivate web-scaleworkflows built on top of distributed services. Likewise,Lu and Zhang [4] and Zhang et al. [5] motivate scientificworkflows that not only involve multiple collaboratorsbut also cut across organizational boundaries.

To realize such cross-organizational workflows pre-sumes that resources can be shared effectively. However,existing techniques have no support for ensuring that

• The authors are with the Department of Computer Science, NC StateUniversity, Raleigh, NC 27695. E-mail: {pckediya,singh}@ncsu.edu

permissions, especially, resource usage licenses, prop-agate correctly. Armbrust et al. [6] identify softwarelicenses as a key challenge of realizing cloud comput-ing. We are pursuing a research program of develop-ing approaches for the policy-based administration ofresources in federated environments. Specifically, we ad-dress the challenge of accounting for and administeringsoftware usage (and not consider software developmentor digital media sharing) licenses in federated environ-ments.

To develop the above ideas further, consider a simple,but real, example of a federated computing environ-ment. Some North Carolina institutions—including NCState University (NCSU: our institution) and NC CentralUniversity (NCCU)—federate some of their computingresources through the Virtual Computing Lab (VCL),an open source cloud infrastructure [7], [2], [8]. Theirmotivation is that they need to provide their respectiveusers (students and faculty) virtual access to hostedapplications such as Matlab, and federating resourcesenables handling peak loads better. The challenge hereis that each institution’s site license covers usage by onlyits own faculty and students. Yet the applicable licensemust be accounted for correctly even when requests fromone institution users are instantiated at VCL installationsacross the federation. One might imagine that scenariossuch as the above could be avoided if each institutionsimply obtained computing hardware from the other andhandled its licenses independently of the other. How-ever, to accomplish this, the site that is currently hostinga user from another site must be able to (1) confirm thatsuch a (suitably authenticated) guest user is legitimateand that any requirements on the usage session are met,and (2) be able to preempt the guest when necessary.That is, we need a way by which federated parties maycollaborate effectively while preserving their autonomy.

2

A variation of the above scenario arises where auniversity or a company obtains a site license but de-partments within the university or company share thecost and benefits of the license, and administer their owncomputing resources. Such cases are routine practicetoday. However, statically allocating licenses among thedepartments would clearly not be effective, and wouldobviate most benefits of obtaining a site license.

The common problem is that wherever parties feder-ate, we need a way to account for usage licenses appro-priately. Doing so is nontrivial because of the followingchallenges. First, in practice, usage licenses might in-volve considerations such as the number of concurrentusers allowed. Thus the parties must communicate therelevant information or convey appropriate decisions toone another. Second, each site may apply potentiallysubtle strategies to administering its licenses, even whenits users are engaging through one of its collaborators.For example, a concurrent users license merely statesthe upper bound on the number of concurrent userseats; how to prioritize requests or allocate such seats isentirely up to the licensee. A practically viable approachshould support such flexibility. Third, each host must beable to retain control over its resources and consequentlybe able to express site policies regarding how it collab-orates with others. For example, NCSU may decide toshare resources with NCCU all day but only after-hourswith another institution in the federation.

1.1 Approach in Brief

We propose Licit , an approach that addresses the forego-ing challenges via license, scheduling, and site policies,respectively. A license policy states the terms between thelicenser and licensee, for example, a license to use 100concurrent instances of Matlab. A scheduling policy stateshow the licensee chooses to opportunistically exploit thelicense, for example, by preempting members of one rolein favor of another. Specifically, the licensee might preferteachers over students so that the oldest (or newest)instance in use by a student is terminated if necessary tofulfill a request made by a teacher. A site policy protectsthe interest of a particular provider by capturing itspreferences when it makes its resources available in afederation. For example, NCSU may share its resourceswith NCCU but limit access by NCCU students duringthe NCSU exam week—so as to give a higher priority toNCSU students during that time.

Licit applies policy-based agents—computationallyrepresenting each site—to collaboratively administer us-age licenses. Licit involves agents who play two im-portant roles in an ongoing engagement: licensee, whocurrently owns the license on the desired resource andwith whom the current user is affiliated, and host, whoprovides the computational infrastructure over whichthe user (as a guest) would interact with the resource.

Agents implemented over services are a natural match[9] for the present problem for the following reasons.

Each site in a federation is (at least notionally) au-tonomous and heterogeneous in that it may administerits licenses according to its local strategies and basedon its local information model. Potentially, the sitesmay adopt distinct strategies and informations model.Further, to enforce certain usage constraints based onhistory and state [10] or potentially in anticipation ofdemand, each party would need to monitor events andbehave proactively—and thus each of the parties mustbe able to entertain interrupts from others.

We adopt a policy-based approach as the underlyingframework for the specification of agents and their inter-actions. Policies yield greater perspicuity and modularitythan procedural representations and have been used ina variety of settings, most commonly access control [11].We do not propose a new policy language or engine. TheLicit approach is implemented over existing technolo-gies. We show how to represent licenses, license adminis-tration strategies, and resource allocation considerationsas policies. Licit agents can exchange policies with eachother. For each agent, we organize the various policies(local as well as those received from peers and expresstheir constraints) in a simple hierarchical structure thatyields the desired computations in a natural manner.

1.2 Contributions

We develop a policy-based approach for administer-ing federated computing environments, such as thoseenabled through the expansion of cloud computingtechnologies. The novelty of the Licit approach lies inits treatment of policies in a federated setting. Licit isframed in the context of usage licenses for softwareapplications, and can be seen as demonstrating ser-vice computing techniques to support further services.However, the basic ideas of both licensing and of Licitapply to resources in general—including databases, datastreams, sensors, and so on—that could potentially besubject to a usage license.

1.3 Organization

The rest of this paper is organized as follows. Sec-tion 2 formalizes the problem domain by laying outvarious license types, scheduling strategies, the infor-mation model, and the states in the life cycles of alicense and of a usage session. Section 3 provides atechnical view of the system in detail, including itsarchitecture, the representation of a license as a policy,concepts of a scheduling policy, and the organizationof policies at a site. Section 4 presents an evaluationof our implementation’s performance demonstrating itsfeasibility in practical settings. Section 5 discusses therelevant literature and some future directions.

2 FORMALIZING USAGE LICENSES

We describe the structure and elements of a usage li-cense that formalizes a license that a licensee site would

3

have obtained for the benefit of its user community. Wepropose a simple information model using which a sitecan specify a vocabulary needed for evaluating its usagelicenses, i.e., determining whether a particular user re-quest is valid according to a specific license. We beginwith a classification of the license types gathered frominterviews with academic IT experts and which arisecommonly in modern practice. From this classification,we determine a base vocabulary that can be used tostate licenses. Table 1 captures the commonly occurringusage license types. These examples illustrate a nearlycomprehensive list of licenses encountered in practice,and hint at the type of licenses supported by Licit.

TABLE 1Examples of commonly occurring usage licenses.

This license covers usage . . .

⊙ by faculty⊙ by anyone from Engineering⊙ by a person physically present within a certain geographic area

defined by zip code or by distance from the offices of thelicensing institution

⊙ for research; or for a noncommercial purpose; or in an ed-ucational activity (thus excluding business purposes of theuniversity)

⊙ if permitted by a specified licensing server⊙ for one year⊙ of Matlab⊙ for a maximum of 100 hours⊙ by up to 100 students or faculty at any time⊙ for a maximum of 100 times⊙ on a specific machine⊙ on a machine located within a certain geographic area⊙ on a Linux platform⊙ on a machine owned by a specific owner⊙ on a machine with a maximum of four processors

2.1 An Information Model for License Attributes

Figure 1 presents an information model for the attributesthat may feature in licenses. The policy representationof a license specifies the predicates that operate onthese attributes. Each site would use this informationmodel to specify its custom vocabulary of attributes. Themain benefit of developing an information model is toovercome the challenge of heterogeneity, specifically, toenable a site in a federation to interpret the terms in avocabulary that has been specified by another site.

A license vocabulary comprises attributes, each of ex-actly one data type. The attributes involved in a licensedescribe the subject (prospective user), resource, action,environment, and sometimes the license identifier. Anexample of an attribute that describes the constraints ona license—identified by a license identifier—is cumulativeusage. The environment attribute may indicate one ormore of the following: start or end time, and the iden-tifier for the node on which resource is to be deployed.An example of an environment type attribute, i.e., anattribute that describes the node, is number of processors.We introduce another entity type, context, to includeattributes that characterize an association of more than

Fig. 1. An information model for license attributes.

one of the subject, resource, action, or environment. Anexample is the attribute permitted usage, which describespermission of a subject to perform an action on a re-source in an environment.

In a significant break from current approaches tolicense administration [12], [13], [14], in our model, anattribute is resolved by an agent (i.e., host, user, orlicensee) instead of a service location. This is unavoid-able in a federated setting, since the location at whichto resolve any attribute associated with the host, suchas the number of processors, is known only at runtime.This is because the host and thereby the node at whichthe requested resource is deployed is also known onlyat runtime. The agent-based solution enables such late-binding of attributes to values because the licensee cansimply ask the appropriate agent, in this case the host,to resolve attributes such as number of processors. Tothis end, the licensee would provide values of someattributes to determine the value of a requested attribute.For example, to determine the number of processors ofa node, the licensee must provide the value for theidentifier attribute of the node.

We can now express a base vocabulary that includesthe attributes that feature in the license types of Table 1.Table 2 classifies these attributes based on the entityto which each applies. Read the first row of Table 2as follows: The attribute role describes the subject andis resolved by the licensee; example values for roleare “faculty” and “student.” Read the subsequent rowsfollowing the same pattern.

Some attributes may be particular to the licensee andmust be resolved by it. Some licenses may be based oninformation that can only be provided by the user, e.g.,a user’s acceptance of the terms regarding the purpose ofuse. We include these with the licensee.

Licit is not limited to the above attributes, and a sitemay introduce additional attributes as needed. Whethera site uses the above or its site-specific attributes, it needsto specify the agent each attribute is resolved by so thata licensee would contact that agent to request values forthose attributes.

Let us consider how an attribute vocabulary maybe used. Suppose Alice, a computer science student at

4

TABLE 2Classification of attributes that feature in common licenses.

Attribute Describes Possible values Resolved by

Role Subject faculty; student LicenseeDepartment Subject computer science LicenseeUser’s IP address Subject’s context 192.168.2.1 LicenseeUser location Subject’s context on campus; zip code Licensee or UserPurpose Subject’s intention research; educational Licensee or UserPermitted usage Request’s context true or false LicenseePeriod License’s context for one year LicenseeConcurrent usage License’s context by up to 100 users LicenseeCumulative usage License’s context up to 100 hours by a group LicenseeCounted usage License’s context five times LicenseeNode name Compute resource on a specific machine HostNode location Compute resource zip code HostNode operating system Compute resource on Linux platforms HostNode ownership Compute resource on a departmental machine HostNode type Compute resource with no more than four processors Host

NCCU (licensee), requests a usage session with Matlabat NCSU (host). The host finds that a node is available soit forwards the request to the licensee. The licensee findsthat its license for Matlab involves checking the subject’sattribute department and the number of processors of thenode on which Matlab will be deployed. Therefore, thelicensee requests the value of this attribute for Alicefrom its own (NCCU’s) attribute service, which returns“computer science.” Next, because the vocabulary statesthat this attribute is resolved by the host, the licenseerequests the value of number of processors from the host(NCSU) instead of its own attribute service. Based on theabove information, the licensee finds that it can provideaccess to Alice.

It is to be noted that the challenge of determining avalue for an attribute rests with the attribute service.A site may introduce any apparently idiosyncratic at-tributes that make sense for its local needs. All it needsto do is ensure that the attribute service can resolve suchattributes for the entity (e.g., licensee or host) involved.For example, a site may introduce an ad hoc attribute“social-influence” with values “high” and “low” anduse this attribute within a policy to decide which usersare to be accorded special treatment in accessing certainresources. The attribute service on its part may calculatea value for social influence by querying a social networkwebsite. This ad hoc example is meant to illustrate thatLicit can work in a wide range of settings.

2.2 License and Usage Session Life Cycles

We model each license as an object with a life cycle. Notsurprisingly, different types of licenses exhibit differentlife cycles and constrain possible enactments in differentways. Additionally, we model a usage session as anobject with a life cycle of its own.

In Figure 2, the usage session’s life cycle starts when aguest user’s request is accepted so that the provisioningof resources may begin. The usage session at this pointbecomes Active. A usage session may be suspended,thereby making it Dormant, and a suspended session

Fig. 2. A usage session involving a licensed resource.

Fig. 3. Life cycles of a concurrent-usage (left) and a single-usage license (right).

resumed, thereby making it Active once again. The usercan end the session from either Dormant or Active state.Note that in Figures 2 and 3 the license life cycle isinterlinked with the usage session so that it is affectedby all events that affect the usage session.

Let us now consider a concurrent users license. InFigure 3, Null means the license does not exist at thehost. Once a license is provided to the host it becomesAvailable. Once a guest user’s request is accepted so that

5

the provisioning of resources may begin the license isIn Use. When the user suspends a usage session, thecorresponding license becomes Available (for use). Whenthe suspended session is resumed, the license is In Use.Finally, the license may be withdrawn.

The above life cycles are described in terms of statediagrams. In general, different license types supportdifferent state diagrams. For example, as Figure 3 shows,a Single Usage license remains In Use when the session issuspended and becomes Null when the associated usagesession ends. A suspended session may be resumed,making the session Active

In Licit, the state of a license is maintained by thelicensee even as the usage-sessions are instantiated ina distributed manner at the various hosts. Doing soenables us to support the use case where a host deniesaccess to a user because of the host’s local policies. Inthis case, the user can try elsewhere.

2.3 Scheduling Strategies

Often an organization must optimize its license usageaccording to its local needs. Usage licenses often pro-vide a lot of flexibility in this regard. For example, atypical license would specify the maximum number ofconcurrent users. It would not specify which users, ifany, are to be accorded priority over others. SupposeNCSU has obtained a license for 100 concurrent users.NCSU could arbitrarily reserve 10 of the licensed seatsfor faculty and only allow up to 90 student users. (Such astatic allocation is not necessarily optimal but may wellbe sufficiently effective for the needs of a licensee: Inany case, it is the licensee’s prerogative to allocate licenseseats according to its local strategies.) Alternatively, sup-pose all 100 seats are taken. Now, if a request arrivesfrom another prospective user, NCSU has many choices,including these:

• Deny the request.• Preempt one of the current users to free up a license

seat, using a variety of strategies to choose which ofthe current users would be preempted: For example,

– The one who has used the resources the most.– The one who has the longest running session

(for fairness).– The one who has the shortest running session

(to waste the least amount of work).– The one with the lowest organizational rank.

• Suspend one of the current users to temporarily freeup a license seat using a variety of strategies suchas the above; when a license seat becomes available,resume one of the (potentially multiple) suspendedusers according to a suitable strategy.

• Delay the request, holding it in a queue, and servethe request when a seat frees up; apply any of nu-merous possible disciplines to maintain the queue.

The above examples seek to illustrate the rich varietyof strategies that an organization may apply while it

respects a usage license. In current practice, these strate-gies are hardwired or handled in an ad hoc manualmanner, which is expensive and would not scale tolarge federations. In this context, Li et al. [15] pointout the need for a scheduling mechanism that accountsfor requests distributed beyond the local domain. Weaddress the above need by formalizing a schedulingstrategy for a license as a policy, thereby abstracting itout of the code and making it reusable. The licenseechecks the applicable scheduling strategy in decidingupon a request.

When a new request arrives that results in a need forscheduling, we need to carry out a comparison of therequest with all the other requests authorized by thesame license. In a federated setting, however, sessionsassociated with various requests may be distributedover various hosts. In such a scenario, performing afederation-wide comparison or prioritization to deter-mine the session associated with the lowest priorityrequest (according to whatever is the stated schedulingstrategy) requires the agents to cooperatively maintainan annotated index of distributed instances. Section 3.3describes a simple scheme to address this challenge.

3 TECHNICAL APPROACH: AGENTS AND POLICIES

The demands of the autonomy and heterogeneity of thesites involved in federated license administration driveus toward an architecture based on agents and policies.Each site is represented computationally by an agentwho stores and applies the policies of the site. The agentof each site deals with local users as well as with alocal runtime environment. The runtime environment ateach site manages the resources in consideration underthe control of the site’s agent. Additionally, the agent ateach site also plays the role of a licensee that provideslicense and scheduling decisions. The agents have nodirect control over other agents, because each agent isautonomous, reflecting the real-world autonomy of theparticipants in a federation. However, the agents cancommunicate requests and decisions to each other.

Based on the foregoing, the following scenario de-scribes how a typical episode of license administrationmight proceed.

• The licensee creates policies pertaining to the spe-cific license of interest along with a vocabulary thatdescribes the attributes referenced in the policies.The description includes the agent who would re-solve each attribute along with other supportinginformation.

• Using hierarchical site policies, a licensee and hostcreate a service agreement wherein the host wouldsupport the licensee’s users for a particular resource(i.e., executable image). They also configure them-selves with information on how to contact eachother.

• A user requests permission to use a resource at thehost site that the runtime environment forwards tothe Licit agent.

6

• The host’s agent applies its site policies to determinehow to proceed. In particular, the host’s agent mayuse a policy decision point (PDP), realized overa policy engine, to make the decision regardingwhether to permit the initiation of the usage session.The PDP obtains the requisite information from anattribute service. If the host grants the request, itforwards the request to the user’s licensee for alicense check.

• The licensee, in a manner similar to that of the host,uses a PDP to perform a license check. Here thelicensee may request its own attribute service or (in-directly) that of the host to resolve some attributesso as to reach a decision.

• If a conflicting demand exists and a scheduling pol-icy applies, the licensee uses the scheduler that—asdescribed in Section 2.3 and Section 3.3—determineshow to prioritize between the current request andother running instances. If, according to the schedul-ing policy, some instance needs to be terminatedthen the licensee notifies the appropriate host’sagent. The host’s agent in turn notifies the runtimeenvironment.

• If the decision to the current request is favorable anda scheduling policy exists that applies to it now, ormay apply to it in the future, then, before replying,the licensee records information such as (1) the re-quest identifier, (2) the host at which the request willbe instantiated, and (3) the normalized value of theattribute specified in the ranking criteria—describedin detail in Section 3.3. Thus, the licensee builds anactive-requests log that serves as an annotated indexto the distributed instances.

• If the host receives a favorable decision, it asksthe runtime environment to make the requestedresource available to the user.

• The runtime environment produces a cryptographictoken, which the agent conveys to the user.

• The user interacts with the runtime environmentdirectly using the above cryptographic token.

Figure 4 depicts the main elements of our proposedarchitecture. These modules are installed at each siteto enable it to participate in federated license admin-istration. The user (or, rather, the user’s agent) requestsinitiating, terminating, and suspending usage sessions.The user agent may also decide to request another hostif its preferred host fails. Additionally, the user mayprovide values for specific attributes if requested.

The attribute service abstracts over a variety of mech-anisms for obtaining values for any attributes of interestneeded to evaluate the request with respect to the li-cense. Such attributes pertain to the user, to the user’scontext, to the host, to ongoing interactions relevant tousage licenses, to the states of relevant licenses, and evento legacy license managers such as FlexNet, which werevisit in Section 5.1.

The Licit agent is the cornerstone of our approach asit acts as the host or the licensee, depending on the con-

Fig. 4. An illustration of our architecture. Here the PDP refers toa policy decision point, which is the standard policy architecturecomponent that applies policies to determine a decision as toallow or deny the given action.

text. The Licit agent comprises the attribute finder thatuses the vocabulary to direct queries to the appropriateattribute service, the PDP that interprets licenses andsite policies stated in XACML, and the scheduler thatevaluates the scheduling policy.

3.1 Background on XACML and Scheduling Policies

Each XACML policy primarily considers four entities ofinterest: (1) subject (the entity that initiates the request);(2) resource (the entity to be used, such as instantiablesoftware, as in our setting); (3) action (which the subjectwould perform on the resource); and (4) environment(which gathers other relevant information about thecomputational or user context, such as time and date).We adopt the eXtended Access Control Markup Lan-guage (XACML) [16], which has emerged as the leadingstandard for stating policies. XACML 2.0 (XACML) sup-ports defining attributes and matching predicates and issufficient for the scope of Licit. We did not find anynew feature available in XACML 3.0 [17] necessary forour purposes. Therefore, to increase the generality ofour approach, we assume only the weaker XACML 2.0language.

3.2 Capturing Licenses as Policies

XACML provides the following elements: policy sets,policies, rules, and conditions. A policy set comprises otherpolicy sets or policies; a policy comprises rules; and, arule comprises conditions. In Licit, we use the XACMLelements as follows. We group all the usage licenses foran organization in a single all-enclosing policy set. Apolicy set or policy elements in the enclosing set express

7

a license for a single resource. Although Licit does notlimit the type of action, in our setting, the only relevantaction that can be performed on the resource is “execute”because the resources here are installed software images.Constraints on the action are specified by rules thatinclude the specific conditions under which the actionis licensed.

The following snippets illustrate our XACML repre-sentation for licenses. The snippets when put togetherspecify NCCU’s license that states that any user fromNCCU is permitted to execute MATLAB, but only on anode running “Windows 7” that has no more than twoprocessors.

• As mentioned above, policy sets group all licensesfor an organization. Hence, in the example be-low, the match criterion in the policy set elementspecifies that subject:org-id, a standard XACML at-tribute meaning the subject’s organization, mustequal “NCCU.” Thus policies in this policy set applyto a request from anyone from NCCU.<P o l i c y S e t P o l i c y S e t I d =”NCCU:LICENSES”><SubjectMatch

MatchId=” f u n c t i o n : s t r i n g −equal ”><Attr ibuteValue> NCCU </Attr ibuteValue><S u b j e c t A t t r i b u t e D e s i g n a t o r

A t t r i b u t e I d =” s u b j e c t : o r g−id ”/></SubjectMatch>

</ P o l i c y S e t>

• Enclosed in the policy set above, another policy setelement specifies a license for a single resource. Inthe example for a MATLAB license listed below,the policy set specifies that resource:prettyname, anattribute declared in the licensee’s vocabulary, mustbe tested for string equality with the name (here,“MATLAB”) of the resource to which this licenseapplies.<P o l i c y S e t

P o l i c y S e t I d =”NCCU:MATLAB:LICENSE”<ResourceMatch

MatchId=” f u n c t i o n : s t r i n g −equal ”><Attr ibuteValue>MATLAB</Attr ibuteValue><ResourceAttr ibuteDesignator

A t t r i b u t e I d = ” resource :pret tyname ”/></ResourceMatch>

</ P o l i c y S e t>

• Enclosed in the policy set element from the pre-vious listing, the policy element here correspondsto the license for a group of users to carry out anaction. The group of users may be defined using theSubjectMatch element as shown in the first listing.However, since the example license is for all usersfrom NCCU, we only need specify that the attributeaction-id, a standard XACML attribute, must have thevalue “execute.”<Pol i cy

Pol i cy Id=”MATLAB:LICENSE:TO:EXECUTE”><ActionMatch

MatchId=” f u n c t i o n : s t r i n g −equal ”><Attr ibuteValue>execute</Attr ibuteValue>

<Act ionAttr ibuteDes ignatorA t t r i b u t e I d =” a c t i o n : a c t i o n −id ”/>

</ActionMatch></Pol i cy>

• Finally, the rule element specifies the Condition andEffect that determines whether to permit or deny arequest if the stated conditions are met. In the Licitapproach, the effect is always to permit because itis only when an action is permitted under somecondition that it is included in the license. Thecondition element specifies a conjunction or disjunc-tion of nestable Boolean functions that operates onattributes and values. The example below specifies acondition to check that the operating system (givenby the attribute node:OS) equals “Windows 7” andthe number of processors (given by the attributenode:processors) does not exceed two.

<Rule E f f e c t =” Permit ” RuleId=”CommitRule”><Condition FunctionId=” funct ion :and ”><Apply

FunctionId=” integer−l e s s−than−or−equal ”><S u b j e c t A t t r i b u t e D e s i g n a t o r

A t t r i b u t e I d =” node:processors ”/><Attr ibuteValue>2</Attr ibuteValue>

</Apply><Apply

FunctionId=” f u n c t i o n : s t r i n g −equal ”><S u b j e c t A t t r i b u t e D e s i g n a t o r

A t t r i b u t e I d =”node:OS”/><Attr ibuteValue>Windows 7

</Attr ibuteValue></Apply>

</Condition></Rule>

• In special cases, for example, of licenses based onconcurrent users that require accounting, the policyelement above includes an obligation element. Theobligation requires the licensee to count the license’susage when the license evaluation results in grant-ing the permission.

<Obl igat ions><Obl igat ion

Obl igat ionId=” c o u n t l i c e n s e ”F u l f i l l O n =” Permit ”>

<AttributeAssignmentA t t r i b u t e I d =” l i c e n s e i d ”DataType=”XMLSchema# s t r i n g ”>TC−010

</AttributeAssignment></Obl igat ion>

</Obl igat ions>

• A request is processed as follows. The subject’sorganization determines which top-level policy setto use. The request is evaluated against the nextlevel policy set that specifies the resource requested.Finally, the action requested and possibly otherattributes of the subject determines the applicablepolicy where relevant conditions in the rule deter-mine the effect. If the license contains an obligation,the licensee creates a checked-out record that corre-sponds with the in-use state in a license’s life-cycle.

8

• Since XACML combines the outcomes of all thepolicies that apply, we need to consider the case thatAlice may be able to use MATLAB either becauseshe is enrolled as a student in Engineering or isemployed as a staff member in Science. Thus, wedisjoin multiple licenses by setting PolicyCombiningAl-gId to “permit overrides,” because Alice must not bedenied access to MATLAB just because she does nothave access to some other resource. Similarly, at therule level, we always set RuleCombiningAlgId to “permitoverrides,” because we want a usage request to begranted if it is permitted under any rule.

<P o l i c y S e t P o l i c y S e t I d =”NCCU:MATLAB:LICENSE”PolicyCombiningAlgId=” pol icy−combining−algo:permit−overr ides ”>

<Pol i cy Pol i cy Id=”MATLAB:LICENSE:TO:EXECUTE”RuleCombiningAlgId=” rule−combining−algo:permit−overr ides ”>

3.3 Expressing Strategies as Policies

A scheduling strategy identifies the license to which itapplies. Given the currently active sessions, the strategydetermines whether the incoming request should berejected or a response to it delayed. Or, whether one ofthe active sessions should be preemptively suspendedor ended after some time to free the license needed toaccept the incoming request.

Since a XACML response can only be permit or deny,we need to go beyond XACML to treat strategies prop-erly. All scheduling policies can be grouped together foran organization, as we showed above for the licenses.Further, each scheduling policy must include—what isknown in XACML terms as—the target that includesexactly one LicenseID element that identifies the license towhich the policy applies. However, beyond this, licensesand scheduling policies differ. As seen in the listingbelow, scheduling policies hold additional information.In particular, a scheduling policy contains informationregarding the ranking criteria and the preemptive actionto take after some time on the lowest priority requestdetermined by the policy.

We capture priorities among requests through a sim-plified representation of the ranking criteria based on thevalues of a specified attribute, for which we provide alist of values, sorted from least to highest priority. Forexample, we may assert that priority is determined bythe attribute Role using a list �student, faculty�, whichindicates that a request from a student is ranked lowerthan that from a faculty member.

<S c h e d u l i n g P o l i c i e s><OrganizationName>NCCU</OrganizationName><Pol i cy><LicenseID>TC−010</LicenseID><PreemptiveAction><Action>End</Action><Time>0</Time>

</PreemptiveAction>

<RankingCri ter ia><C r i t e r i o n><A t t r i b u t e I d>r o l e</ A t t r i b u t e I d><ListOfValues><Value>student</Value><Value>p r o f e ss o r</Value>

</ListOfValues><SortOrder>Ascending</SortOrder>

</ C r i t e r i o n></RankingCri ter ia>

</Pol i cy><S c h e d u l i n g P o l i c i e s>

Notice that Licit separates licenses from strategies,although both licenses and strategies are representedcomputationally as policies. This separation facilitatesauthoring and reuse of licenses and strategies.

Scheduling proceeds as follows. Upon receiving arequest, the licensee first checks the license to determinewhether the request is legal with respect to any ofthe stated licenses. If so, the licensee checks whether ascheduling policy applies to the request. A reschedulingpolicy (specified using XACML and different from ascheduling policy) for a license is identical to the licensein all respects except that the action is reschedule insteadof execute and there is no check for constraints relatedto the attribute concurrent users. Thus, a reschedulingpolicy presupposes that the request was denied only dueto constraints on concurrent users and that reschedulingcould help. The licensee then looks at the schedulingpolicy and it determines whether and, if so, which ofthe current users to preempt.

As Sections 2.3 and 3 describe, requests may be dis-tributed at hosts anywhere in the federation. Due to com-munication overhead and reliability concerns, it wouldgenerally be inadvisable for the licensee to attempt toprioritize among requests by coordinating with severalhosts at the time when a decision on a new request is tobe made. To avoid having to communicate with multipleparties, we provide an index sorting mechanism. Theindex is sorted using a normalized value calculated asfollows: Before granting any request, the licensee alwayslocally stores a normalized value of the ranking criterionfor the request. For example, if the criterion is based onattribute Role and is specified by �student, faculty� andthe request is from a student, the normalized value isone. It is simply the ordinal position of the value of theattribute in the list. Similarly, if the value is a date, thenormalized value is the time in milliseconds from theUnix epoch (00:00:00 UTC on 1 January 1970). This listof normalized values then becomes a locally availableindex that a comparator can easily sort, ensuring bothspeed and reliability.

3.4 Structuring Policies for Enactment

As explained above, we capture the local preferences of asite, the various licenses, and the strategies to be appliedduring license administration as policies. Further, soas to uniformly accommodate the above policies, weorganize them hierarchically using XACML’s Reference

9

element. As seen in Figure 5, at the root level are thelocal policies of a site viewed as a host. These apply toevery request and are stored in the same policy set. Anexample local host policy might be “Take no requestsbetween 10:00 AM and 12:00 PM.” Policies at the nextlevel down capture the host’s business relationships withvarious licensees. An example host policy pertaining toa licensee might be “Take no requests from NCCU onweekends.” These policies are stored in separate policysets, one for each licensee. Once the host has enforcedits policies, it forwards the user request to the licensee,which then performs a license check and applies anyscheduling policies. All licenses from a licensee are heldin the same policy set, as explained earlier.

Fig. 5. Representation of hierarchical policies.

4 IMPLEMENTATION AND EVALUATION

We have applied our approach in formalizing the entireset of licenses illustrated in Table 1. Each license type iscaptured via a templatic policy that can be instantiatedfor an instance of that license type that yield an exe-cutable policy. We have also formalized as policies somesample scheduling strategies based on time informationabout sessions, such as their duration.

4.1 Policy Engine

Our policy engine is adapted from an open-sourceXACML implementation provided by Oracle (previouslySun) [18]. Specifically, we implement the following ab-stract classes. One, the Policy Finder loads policies from adata store. Currently, the data store is a directory in thefile system. This class enables enforcing a hierarchicalapplication of policies that protects the host’s interest, asSection 3.4 describes. Two, the Attribute Finder resolvesthe attributes that occur in a XACML policy. Three, theScheduler maintains the index to the distributed instancesand loads, interprets, and enforces scheduling policies.However, neither the scheduling policies are expressedin XACML nor the Scheduler is part of the XACMLspecifications, it is mentioned here only to list the threeimportant modules that enable policies in our approach.Our implementation enables each agent to interpret theattributes occurring in policies based on the informationmodel described in Section 2.1 above.

Upon receiving a request, the policy engine deter-mines the applicable license. For each attribute that thelicense references (here, the subject’s department), thepolicy engine indirectly contacts the attribute service viathe agent who is supposed to resolve the attribute. Thepolicy engine then computes a decision based on theattribute values it obtains.

4.2 Realizing Licenses on Apache VCL

Apache VCL, an Apache top level project [8], is an open-source toolkit for managing a cloud environment forsharing computational resources among collaboratingorganizations [7]. VCL is widely deployed in academicsettings wherein users (mostly students or researchers)can execute software images for preallocated amounts oftime.

When a user signs in, the VCL portal offers a listof resources that the user may request. The user mayrequest the next available time slot or specify an ac-ceptable interval. Taking into consideration ownershipand licensing, the VCL portal determines the machine onwhich to provision the request. VCL currently performsonly a rudimentary usage license check. We enhance itby replacing its license checking module with a requestto our agent, that in turn treats the VCL Daemon (VCLD)as the resource framework that would provision thenecessary resources to instantiate the request.

4.3 Performance Evaluation

Licit is a distributed approach wherein each license eval-uation and associated scheduling decision is based ondata aggregated by from one or more agents distributedacross the federation. In such a setting, simply estab-lishing correctness is insufficient because the system isunusable if it does not scale to handle thousands of users.Below we describe pertinent performance tests centeredon the load understood as the number of concurrent re-quests made for resources. Note that concurrent requestsis a significantly clearer requirement than concurrentusers in the system since users may request resourcesat different times.

To evaluate the performance of our functional proto-type, we set up the host and licensee on different ma-chines with simulated users and an attribute authorityrunning on the same machine as the licensee. Thus,this setup models a scenario where a user from oneorganization requests compute resources from a hostelsewhere such that the host has to go back to thelicensee to check on licenses before making a resourceinstance available. For each machine we used the defaultconfiguration of the JBoss Application ServerTM v4.2.3with Java Runtime EnvironmentTM 5.0.22. The machineswe used had 3.37 GB RAM with two Intel XeonTM 1.66GHz dual core processors and ran the Windows XPProfessional (version 2002) operating system.

10

To cover functional tests, we consider licenses basedon conditions and attributes from Table 2 that fall underone or more of the following classes:

• Host-resolved (e.g., Node OS).• Licensee-resolved (e.g., Department).• State-based (e.g., Counted).• Rescheduled (e.g., Concurrent users).• Combining host- and licensee-resolved attributes.• Attributes aggregated from multiple sources.Next, for each license, we designed two requests such

that one would result in a permit and one in a denydecision. Thus, we had 20 test cases in all from tenlicenses that cover the criteria stated above. Beyondestablishing correctness, the functional test cases help usevaluate the performance of our implementation.

Using the TestNG framework [19], we created a testsuite that simulates a user by sequentially submitting thetest cases in a single invocation of a thread. We simulatedconcurrent requests by increasing the number of threads.In TestNG terms, a test group is an abstraction that callsa test method. Among other parameters, this test groupcan be configured with invocation count that determineshow many times the test method will be invoked and thenumber of threads that will complete the invocation. Wecreated ten groups with the number of threads set to one,two, four, and so on up to 512, and the invocation countset to 256. Thus each group simulated a different numberof concurrent requests. All the groups called the sametest method 256 (invocation number) times, irrespectiveof the number of threads. Since the test method itselfmade 20 requests corresponding to the 20 test cases, eachrun of a group made 5,120 (256 times 20) requests fordecisions. One cycle of testing ran the ten groups.

For each request, we logged its start and end times,test case name, decision, and the number of activethreads. Since the positive and negative test cases werenamed appropriately, a simple visual inspection of theoutput, sorted on the test case name, was sufficient toverify the correctness of our implementation in permit-ting and denying requests.

The evaluations of the requests do not all requirethe same amount of computations. For example, a li-cense based on the role of the user alone requires noaccounting. By contrast, a license based on the numberof concurrent users may require accounting and possiblyrescheduling. We created ten additional licenses basedon the concurrent users attribute. From these licenses, wefashioned two additional cycles of tests: one where thelicenses only had to be accounted for and another thatrequired rescheduling as well. In each of the three cycles,we initialized the licensee’s PDP with 4,000 licenses inall, including the licenses related to the test cases.

For the data in Figure 6, we calculated the reciprocalthroughput for n concurrent requests as the ratio of theelapsed time to the number of requests in that run. We de-fine the elapsed time as the time taken between the firstsubmission among the n requests and the response re-ceived on the completion of the nth request. We observe

Fig. 6. Relationship between reciprocal throughput and numberof concurrent requests (shown in a log scale).

that, as the concurrent load on the system increases, thethroughput improves and then levels off. We observethat throughput improves significantly for up to fourconcurrent requests and then levels off, possibly becausethe machines used had four cores in total.

Fig. 7. Relationship between average response time and thenumber of concurrent requests. Both axes are in the log scale.

For Figure 7, the average response time was calculatedover the entire population of samples collected from eachrun of a test group. In the graph, error bars for ±1standard deviation—calculated using the STDEV functionin Microsoft Office Excel—from the average responsetime are shown: The standard deviation in these runsis on the order of 35% of the mean value. We see thatthe response time increases linearly with the number ofconcurrent requests.

It is worth considering the practical impact of theseresults. It is clear that increasing the number of concur-rent requests increases the response time. However, ourexperiments consider a particularly demanding setting

11

wherein multiple users make quasi-simultaneous requests.Specifically, we generated peak request rates of greaterthan 60 per millisecond. A bursty load from a laboratorysession for a university course would generally not havethat many user requests hit the servers within the samemillisecond. To validate the above intuition, we analyzedusage data obtained from NCSU’s VCL installation overthe entire semester of Spring 2012. We found that therewere only six cases of two requests placed within thesame second and there were zero cases of three or morerequests placed within the second. Thus our tests exceedthe needs of current usage patterns by a wide margin.

The longer response time seen in Figure 7 occursbecause our test suite creates a sustained load of simul-taneous requests that leads to a request queue buildingup. Thus, each decision request is simply spending timewaiting to be processed. In any case, in cases whereour system failed, it simply discarded the decisionsand resumed normal operation when the bursty loadsubsided and more manageable loads resumed.

It is to be noted that some implementations ofXACML, including the one in Python that one of theauthors occasionally contributes to [20] and the one inJava that we used for our evaluation [18], process thepolicies such that the performance suffers linearly withthe number of policies in the system. Perhaps in antici-pation, XACML specifications [16] suggest an approachfor policy indexing wherein the policies are stored ina database and the PDP queries only the applicablepolicies before evaluating them. In Licit’s case this isthe approach we took so that we cached the policiesand indexed them by organization name, resource name,and action. Since all requests carry this information, theapplicable policies can be easily retrieved.

Recently, Liu et al. [21] and others [22] have also triedto address the problem of linear performance. Our ap-proach could be ported to any XACML implementationin principle. However, the above two implementationsare still quite weak and lack sufficiently strong supportin terms of bug fixes and continuing enhancements.Further, the lack of a standard API for XACML addi-tionally complicates the porting task. Note that ourimplementation is open source and interested parties arewelcome to port it to the XACML implementation oftheir choice.

4.4 Reproducibility of Results

Our entire code base is available as an open sourceproject at http://www.opensource.ncsu.edu/LICIT.

In addition, the experimental setup described abovefor performance evaluation is available as an instantiableimage. Readers are welcome to contact the authors toobtain access to that image.

5 DISCUSSION

We find that a policy-based approach to federated us-age license administration works naturally. It helps us

capture the local concerns of each site while supportingcollaborations between them. Whereas existing compu-tational approaches for policies concentrate on low-levelmatters such as access control, we need policies dealingwith the construction of cross-organizational partner-ships. Thus Licit, by handling usage licenses well, canprovide a well-grounded entry point into the study ofpolicies in cross-organizations broadly.

Our approach makes licensing-relevant interactionsexplicit within a federation. Thus it can naturally supportricher forms of accounting of licenses, such as wherethe licenses are being used and by users with whatattributes. Such accounting can provide valuable insightneeded for system administration, especially, in fine-tuning the strategies through which resources are allo-cated by an organization.

We are in discussions regarding moving our imple-mentation of Licit into production.

5.1 Relevant Literature

FlexNet Manager [12] is the industry leader in softwareusage license administration. It enables a software ven-dor to specify licenses in terms of the features of itsproduct and helps a user organization monitor its licenseusage for various software products. Licit is more flexiblethan FlexNet and supports specifying licenses based onselected attributes of the subject, resource, action, andenvironment. Licit not only supports a customizablevocabulary, if necessary, it can also work on top of anexisting FlexNet installation. Additionally, we supportspecifying attributes, such as number of processors, whichare resolved by an host agent known only at run time(see Section 2.1). FlexNet does not support schedulingof licenses, which is supported in Licit. Further, Licitdoes not require software vendors to embed a licenseagent into their software. Instead, Licit handles licenseadministration modularly through an external agent,which moreover can comply with the local needs of eachsite. The terms of each usage license can be negotiatedbetween the software vendor who provides the resourceand the licensee. A policy can be authored for eachlicense, although most practical licenses would followthe templates illustrated by the examples of Table 1.

Competing research approaches for license adminis-tration are centralized. For example, in connection withTeraGrid, Ogawa et al. [23] propose an architecture andapproach for licenses that hands over the tasks of licenseadministration totally to the service provider. In otherwords, the service provider obtains the licenses andmerely bills the user. Although the licenses and thecomputational resources may be obtained from differentvendors, the two are conflated by the service provider.The user organization is thus unable to communicateor employ its existing licenses. Further, the user orga-nization is unable to apply its strategies for reallocatingresources among its various users.

Perry and colleagues [24], [25], [26] also proposepolicy-based licenses. However, these works do not sup-

12

port federated settings and do not provide a systematicvocabulary with which to specify licenses. Further, un-like Zhao and Perry [24], we do not require an ontologyfor licenses. We apply the XACML standard to statelicenses as policies. Importantly, Noorian and Perry [27]describe patterns of licenses that corroborate the licensetypes we presented in Section 2.

The European Union’s SmartLM project [28], [14] rec-ognizes the same situation as Licit, namely, that thechallenge of licensing is the main obstacle to the ex-pansion of cyberinfrastructure technologies. However,SmartLM’s technical approach is different from Licit’sin some key respects. SmartLM emphasizes service levelagreements between a user organization and a provider.In this respect, SmartLM is similar to Ogawa et al.’sapproach, as described above, and different from Licit.Licit supports cases where the licenses belong to theuser organization—that is, they are prepaid. The Licitapproach, although not the current implementation, canalso accommodate cases that require incremental pay-ment for licenses. Further, Licit includes support forlicenses for being transmitted under the control of thelicensee (user) organization, whereas SmartLM appearsto treat licensing in a manner that hides considerationsof licensing from the user organization. In SmartLM, theorchestration service coordinates between licensee andhost but only for the coordinated allocation of licensesand resources.

More generally, however, SmartLM does not supportfederation in that it provides neither an interactionmodel using which heterogeneous sites can communi-cate nor an information model for the bases underlyinglicense application. As we showed above, there are nat-ural situations in current practice where the licensee andhost must cooperate to resolve the value of a particularattribute. A telling example is the attribute number ofprocessors. Thus SmartLM does not handle some impor-tant types of licenses that Licit accommodates. Also,a scheduling mechanism that compares distributed re-quests is missing.

GenLM [29] deals with the broad problem of licensingin grid and cloud environments. However, GenLM takesa quite different stance from that taken in Licit. InGenLM, a user sends a request (including a claimedlicense) to a provider (host in our terminology) andthe host contacts the licensor to determine if the userhas claimed a valid license. GenLM’s technical contri-butions are in how it handles the messaging protocols,especially with regard to encryption and digital sig-natures. In contrast, we treat the above as establishedinfrastructure. Our contribution is in how licenses areadministered in terms of each host’s policies and eachlicensee’s strategies, which could depend on attributesnot included in the license itself. Hence, we include aflexible information model using which a licensee couldspecify its own vocabulary.

GenLM addresses the challenge of lost messages byforcing a handshake in the spirit of the two-phase com-

mit protocol for distributed transactions. We take anoptimistic approach. Specifically, in Licit, if a messagethat checks in a license is lost, the state of the licenseat the licensee may spuriously get stuck in in use. Weaddress this problem through a simple mechanism ofleases wherein a license expires by default after a timeperiod (specified by the user) for which the session isexpected to last, unless it is renewed in the meantime.Our agent-based architecture supports another solution,namely, one in which the licensee conducts periodicchecks with hosts: this is not yet implemented in Licit.

Kung et al. [30] posit four desirable features of in-frastructure that supports authentication, authorization,and accounting. First, the infrastructure must allow sub-jects from one organization to use resources in another.Second, the infrastructure must be resilient to securityattacks. Third, the infrastructure must facilitate usage viasingle-sign-on technologies. Fourth, the infrastructuremust support heterogeneity. In our setting, resilience isachieved through the lower-level virtualization technolo-gies and single-sign-on is provided by the federationthrough existing methods. We can safely assume that wewould entertain only requests that originate from withinthe federation. The Licit approach clearly supports Kunget al.’s first and fourth requirements, especially due toour use of the XACML standard.

The Rights Expression Language [31] (REL) includeselements—agents, resources, rights, constraints, andrequirements—that correspond to subject, resource, ac-tion, rules and conditions, and obligation in XACML.Thus XACML and thereby Licit are equivalent in expres-siveness to REL. However, Licit provides scheduling,ad hoc specification of vocabularies, and late bindingof values to attributes like number of processors that areresolved by the host. These features are essential in theself-service federated environment that is the setting forLicit.

A reduced profile of REL, such as Open Data RightsLanguage (ODRL) [13], can also be used to expressthe licenses described in the earlier sections. However,agents do not figure in the ODRL model. At best,ODRL provides the context element, Service, to identify alocation—not an agent—that would resolve an attribute.And, as we showed in Section 2.1, doing so is notsufficient in federated settings. Although the URI meantto define a Service in ODRL can also be used to namean agent, ODRL did not intend for the semantics to besuch. In any case, to accommodate our scenario, ODRLwould need to be extended to support important licensesavailable in Licit, such as the concurrent use license.Dahlem et al. [32] agree on the need to extend ODRLto express software usage licenses.

The body of work by Gangadharan and colleagues onextending ODRL and presenting a sophisticated analysisof service licenses [33] and license composition [34] isvaluable. If necessary, their insights can be incorporatedinto Licit due to XACML’s equivalence in expressivenesswith REL. Interestingly, Gangadharan et al. [35] affirm

13

the need for consumer-specified licenses in federationsbut address it at the level of subsumption betweenprovider and consumer specifications. More recently,Truong et al. [36] call for a participatory effort towardstandardization of terms for modeling data contracts.We conjecture that our vocabulary-based declarative ap-proach could play well as a low-level mechanism thatenables consumers to address challenges in realizingconsumer-specified licenses. Related to the above is Con-way et al.’s [37] approach for data governance using theiRODS system. Our approach could facilitate expandingsuch work to federated environments, where there areof necessity multiple loci of policy application.

5.2 Directions

Each organization may potentially use its own strategiesfor dealing with different license types. However, inpractice each organization would converge to a few“best practice” strategies that its administrators findacceptable and which interact well with the strategiesadopted by the organizations with which it interacts.An important future direction is to enhance Licit intwo respects. First, for most system administrators, Licitshould come ready with a small number of strategies,judged to be sound by us and validated with our targetuser community. Licit will include a simple dashboardby which a system administrator may specify (i) whichexisting strategy to use for which specific license (de-pending on its license type); and (ii) any parameters tobe specified for that strategy. For example, a possiblestrategy may be to limit the amount of time each useris alloted on an application when its usage load goesabove a specified threshold—the parameters would bethe usage load threshold and the time alloted to eachuser. Second, Licit should provide a simple enactmenttool that supports simulating the usage of differentresources as well as the messages sent and receivedbased on specified strategies. In this manner, systemadministrators could determine if the strategies theychoose are unstable or imperfect in other ways.

The development of policy-based approaches for var-ious system administration tasks is a major trend in in-dustry and academia. Over the last few years, a numberof policy approaches have been proposed for resourcemanagement in the Grid, for example, by Dumitrescuet al. [38] and Wasson and Humphreys [39]. Such ap-proaches are valuable but they largely disregard cross-organizational aspects. Udupi and Singh [40], [41] usethe term governance for a way to administer resources in across-organizational setting, and develop a policy-basedapproach for governance. Udupi and Singh propose amore expansive architecture than we use in Licit, thoughlicense administration is a particularly important varietyof governance. Udupi and Singh’s architecture includesa Policy Organization Point (POP), which supports themodification of organizational relationships. Althoughwe follow Udupi and Singh’s approach in conceptual

terms, in the interest of developing a robust, ready-to-deploy system, in Licit, we have omitted the machinerepresentation of extensive organizational relationshipsand reasoning and modifications about such representa-tions.

Indeed, Licit demonstrates a particularly importantand immediate example of the problem of governance offederated systems, which is drawing the attention of sev-eral researchers [9]. Specifically, Singh [42] has recentlydeveloped a representation for cross-organizational “so-ciotechnical” systems based on normative relationshipssuch as commitments, authorizations, prohibitions, pow-ers, and sanctions. These normative relationships helpcharacterize a federated system declaratively in concep-tual terms by providing a basis for capturing the interac-tions of autonomous parties. Each relationship providesa basis for the policies of the interacting parties. We hopeto investigate the enhancement of Licit to accommodatesuch broader, normative, forms of governance in cross-organizational settings.

ACKNOWLEDGMENTS

This work was supported partially by the NCSU ITnginitiative. We benefited from discussions with MatthewArrott, Wayne Clark, Aaron Peeler, Josh Thompson,David Thuente, and Mladen Vouk. In particular, AaronPeeler provided us statistics regarding VCL usage. Weare also indebted to the anonymous reviewers for helpfulcomments.

REFERENCES

[1] I. T. Foster, Y. Zhao, I. Raicu, and S. Lu, “Cloud computing andgrid computing 360-degree compared,” CoRR, vol. abs/0901.0131,2009, http://arxiv.org/abs/0901.0131.

[2] H. E. Schaffer, S. F. Averitt, M. I. Hoit, A. Peeler, E. D. Sills, andM. A. Vouk, “NCSU’s virtual computing lab: A cloud computingsolution,” IEEE Computer, vol. 42, no. 7, pp. 94–97, Jul. 2009.

[3] M. B. Blake and M. N. Huhns, “Web-scale workflow: Integratingdistributed services,” IEEE Internet Computing, vol. 12, no. 1, pp.55–59, Jan. 2008.

[4] S. Lu and J. Zhang, “Collaborative scientific workflows,” inProceedings of the 7th IEEE International Conference on Web Services(ICWS). Los Angeles: IEEE Computer Society, 2009, pp. 527–534.

[5] J. Zhang, D. Kuc, and S. Lu, “Confucius: A scientific collaborationsystem using collaborative scientific workflows,” in Proceedingsof the 8th IEEE International Conference on Web Services (ICWS).Miami: IEEE Computer Society, 2010, pp. 575–583.

[6] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz,A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, andM. Zaharia, “A view of cloud computing,” Communications of theACM, vol. 53, no. 4, pp. 50–58, Apr 2010.

[7] M. Vouk, S. Averitt, M. Bugaev, A. Kurth, A. Peeler, H. Shaffer,E. Sills, S. Stein, and J. Thompson, “Powered by VCL-usingvirtual computing laboratory (VCL) technology to power cloudcomputing,” in Proceedings of the 2nd International Conference onVirtual Computing Initiative, Research Triangle Park, NC, May2008, pp. 1–10.

[8] Apache, “Virtual Computing Laboratory (VCL),” 2012, an ApacheSoftware Foundation top level project: http://vcl.apache.org/.

[9] F. Brazier, F. Dignum, V. Dignum, M. N. Huhns, T. Lessner,J. Padget, T. Quillinan, and M. P. Singh, “Governance of services:A natural function for agents,” in Proceedings of the 8th AAMASWorkshop on Service-Oriented Computing: Agents, Semantics, andEngineering (SOCASE), 2010, pp. 8–22.

14

[10] J. Park and R. Sandhu, “The UCONABC usage control model,”ACM Transactions on Information Systems and Security, vol. 7, no. 1,pp. 128–174, Feb 2004.

[11] M. Winslett, “Policy-driven distributed authorization: Status andprospects,” in Proceedings of the 8th IEEE International Workshopon Policies for Distributed Systems and Networks. Bologna: IEEEComputer Society, June 2007, pp. 12–18.

[12] Flexera, “License administration guide,”http://www.globes.com/support/utilities/LicenseAdministration.pdf.

[13] R. Iannella, “Open data rights language,” Sept 2002,http://www.w3.org/TR/odrl/.

[14] C. Cacciari, D. Mallmann, C. Zsigri, F. D’Andria, B. Hagemeier,A. Rumpl, W. Ziegler, and J. Martrat, “SLA-based managementof software licenses as web service resources in distributed envi-ronments,” in Proceedings of the 7th International Workshop on GridEconomics and Business Models, ser. LNCS, vol. 6296. Ischia, Italy:Springer, August 2010, pp. 78–92.

[15] J. Li, O. Waldrich, and W. Ziegler, “Towards SLA-based softwarelicenses and license management in grid computing,” in FromGrids to Service and Pervasive Computing, T. Priol and M. Vanneschi,Eds. New York: Springer, 2008, pp. 139–152.

[16] OASIS, “eXtensible Access Control Markup Language (XACML)version 2.0 specification document,” OASIS Standard, Feb. 2005,http://docs.oasis-open.org/xacml/2.0/access-control-xacml-2.0-core-spec-os.pdf.

[17] ——, “eXtensible Access Control Markup Language (XACML)version 3.0 specification document,” OASIS Standard,Aug. 2010, http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf.

[18] Oracle, “Sun’s XACML implementation,”http://sunxacml.sourceforge.net.

[19] C. Beust, “TestNG: Next generation Java testing,”http://testng.org/doc.

[20] P. Kershaw, “NDG XACML,” http://ndg-security.ceda.ac.uk/wiki/XACML.

[21] A. X. Liu, F. Chen, J. Hwang, and T. Xie, “Designing fast andscalable xacml policy evaluation engines,” IEEE Transactions onComputers, vol. 60, pp. 1802–1817, 2011.

[22] Anonymous, “Enterprise Java XACML,”http://code.google.com/p/enterprise-java-xacml/.

[23] H. Ogawa, S. Itoh, T. Sonoda, and S. Sekiguchi, “GridASP: AnASP framework for grid utility computing,” Concurrency andComputation: Practice and Experience, vol. 19, no. 6, pp. 885–891,2007.

[24] Q. Zhao and M. Perry, “An ontology for autonomic licensemanagement,” in Proceedings of the 4th International Conference onAutonomic and Autonomous Systems, March 2008, pp. 204–211.

[25] Q. Zhao, Y. Zhou, and M. Perry, “Policy-driven licensing modelfor component software,” in Proceedings of the 4th IEEE Interna-tional Workshop on Policies for Distributed Systems and Networks,Lake Como, Italy, June 2003, pp. 219–228.

[26] ——, “Agent design of SmArt license management system usingGaia methodology,” in Proceedings of the 3rd International Confer-ence on Autonomic and Autonomous Systems. Washington, DC:IEEE Computer Society, 2007, pp. 9–15.

[27] L. Noorian and M. Perry, “Autonomic software license man-agement system: An implementation of licensing patterns,” inProceedings of the 5th International Conference on Autonomic andAutonomous Systems. Los Alamitos, CA: IEEE Computer Society,2009, pp. 257–263.

[28] European-Commission, “SmartLM project web pages,” Feb 2008,http://www.smartlm.eu.

[29] M. Dalheimer and F.-J. Pfreundt, “GenLM: License managementfor grid and cloud computing environments,” in Proceedings ofthe 9th IEEE/ACM International Symposium on Cluster Computingand the Grid. Shanghai: IEEE Computer Society, May 2009, pp.132–139.

[30] H.-T. Kung, F. Zhu, and M. Iansiti, “A stateless network ar-chitecture for inter-enterprise authentication, authorization andaccounting,” in Proceedings of the 3rd International Conference onWeb Services, Las Vegas, Nevada, USA, June 2003, pp. 235–242.

[31] R. G. Gonzalez, “A semantic web approach to digital rights man-agement,” Ph.D. dissertation, Universitat Pompeu Fabra, 2005.

[32] D. Dahlem, I. Dusparic, and J. Dowling, “A pervasive applicationsrights management architecture (PARMA) based on ODRL,” inProceedings of the 1st International ODRL Workshop, April 2004, pp.45–63.

[33] G. R. Gangadharan and V. D’Andrea, “Service licensing:conceptualization, formalization, and expression,” Service OrientedComputing and Applications, vol. 5, pp. 37–59, 2011. [Online].Available: 10.1007/s11761-011-0079-6

[34] G. R. Gangadharan, M. Weiss, V. D’Andrea, and R. Iannella,“Service license composition and compatibility analysis,” in Pro-ceedings of the 5th International Conference on Service OrientedComputing, ser. LNCS, vol. 4749. Vienna: Springer Berlin /Heidelberg, 2007, pp. 257–269.

[35] G. R. Gangadharan, H.-L. Truong, M. Treiber, V. D’Andrea,S. Dustdar, R. Iannella, and M. Weiss, “Consumer-specified ser-vice license selection and composition,” in Proceedings of the7th International Conference on Composition-Based Software Systems.Madrid: IEEE Computer Society, 2008, pp. 194–203.

[36] H.-L. Truong, G. Gangadharan, M. Comerio, S. Dustdar, andF. De Paoli, “On analyzing and developing data contracts incloud-based data marketplaces,” in Proceedings of the Asia-PacificServices Computing Conference, Dec. 2011, pp. 174–181.

[37] M. Conway, R. Moore, A. Rajasekar, and J.-Y. Nief, “Demonstra-tion of policy-guided data preservation using iRODS,” in Proceed-ings of the IEEE International Symposium on Policies for DistributedSystems and Networks (POLICY). Pisa: IEEE Computer Society,Jun. 2011, pp. 173–174.

[38] C. L. Dumitrescu, M. Wilde, and I. Foster, “A model for usagepolicy-based resource allocation in grids,” in Proceedings of the 6thInternational IEEE Workshop of Policies for Distributed Systems andNetworks (POLICY), 2005, pp. 191–200.

[39] G. Wasson and M. Humphrey, “Toward explicit policy manage-ment for virtual organizations,” in Proceedings of the 4th Interna-tional IEEE Workshop of Policies for Distributed Systems and Networks(POLICY), 2003, pp. 173–182.

[40] Y. B. Udupi and M. P. Singh, “Multiagent policy architecturefor virtual business organizations,” in Proceedings of the 3rd IEEEInternational Conference on Services Computing (SCC). Chicago:IEEE Computer Society, 2006, pp. 44–51.

[41] ——, “Governance of cross-organizational service agreements: Apolicy-based approach,” in Proceedings of the 4th IEEE InternationalConference on Services Computing (SCC). Salt Lake City: IEEEComputer Society, 2007, pp. 36–43.

[42] M. P. Singh, “Norms as a basis for governing sociotechnicalsystems,” ACM Transactions on Intelligent Systems and Technology(TIST), pp. 1–21, 2013, to appear; available at http://www.csc.ncsu.edu/faculty/mpsingh/papers.

Prashant C. Kediyal has over 10 years of softwareengineering experience primarily from working in thebanking and insurance industry. He is now a Ph.D.student in the Department of Computer Science,North Carolina State University, Raleigh. His researchinterests include multiagent and policy-based sys-tems, service-oriented architecture, and governance.

Munindar P. Singh Munindar P. Singh is a Profes-sor in the Department of Computer Science, NorthCarolina State University, Raleigh. His research inter-ests include multiagent systems and service-orientedcomputing with a special interest in the challengesof trust, service selection, and business processesin large-scale open environments. His books includethe coauthored Service-Oriented Computing (Wiley,2005). Singh is the Editor-in-Chief of the ACM Trans-

actions on Internet Technology and was the Editor-in-Chief of the IEEE Internet Computing from 1999

to 2002. He is a member of the editorial boards of IEEE Internet Computing,Autonomous Agents and Multiagent Systems, Journal of Artificial Intelligence

Research, and the ACM Transactions on Intelligent Systems and Technology.