Enforcing Fin-graind Authorization Policis for Java Mobil Agnts Giovanni Russllo Changyu Dong Narankr Dulay Dpartmnt of Computing Imprial Collg London South Knsington London, SW7 2AZ, UK {g.russllo, changyu.dong, n.dulay}@imprial.ac.uk Abstract Th Mobil Agnt (MA) paradigm advocats th migration of agnt cod to achiv computational goals. MAs rquir an xcutabl nvironmnt on hosts whr mobil cod can b xcutd. Th xcution of forign cod on a host raiss scurity concrns for both th agnt and th host. In [1] it has bn rcognizd that most of th approachs for providing scurity in MA suffr from a limitation of xprssing complx scurity rquirmnts. Thus, approachs hav bn proposd that introduc th us of a policy languag for spcifying scurity policis to control MA s accss to host rsourcs. With this papr, w outlin a framwork whr scurity policis can b uniformly spcifid for protcting both MAs and host rsourcs. 1 Introduction Currnt distributd systms involv a larg numbr of applications which rquir a varity of scurity mchanisms to fulfill thir nds. In particular, th us of MAs introducs nw challngs and scurity thrats that nd to b carfully considrd [4]. On th on hand it is ncssary to protct th host nvironmnt whr agnts ar xcutd from malicious and buggy mobil cod. It is ncssary to protct th host information and rsourcs from illgal accsss and ovr-consumption by incoming mobil cod. On th othr hand, it is ncssary to protct th stat and bhavior of th mobil cod from tampring or misus by malicious hosts. Additionally, it would b dsirabl that hosts provid QoS-lik guarants on th rsourcs that ar mad availabl to mobil cod. For instanc, if an agnt movs to a givn host thn th host has to mak sur that nough mmory and procssor tim is givn to th agnt for a corrct xcution. Most of th rsarch in providing scurity framworks for MAs has concntratd only on th first part of th problm. Sandboxing tchniqus and typ-saf languags can b usd to rigidly control th intraction btwn th mobil cod and th host. Th rigidity of such approachs can b ovrcom if a languag-basd approach is usd for spcifying authorization policis. For instanc, in [1] an approach was adoptd whr th Java scurity architctur was intgratd with a policy languag. Howvr, all of ths approachs focus on controlling th MA accsss on th host rsourcs. In this papr, w propos a framwork whr it is possibl to spcify policis for both th MAs and th host rsourcs. Th framwork is currntly implmntd for Java basd MAs. Policis ar xprssd using an xtnsion of th Pondr languag [2] and ar nforcd using a Pondr intrprtr. In our approach, th nforcmnt of policis is don transparntly to th MA cod. Th contributions of this papr ar twofold. First of all, w provid th dscription and implmntation of a framwork whr scurity policis can b uniformly spcifid for both MAs and host rsourcs. Scondly, th framwork is indpndnt from both th actual mchanism usd for policy nforcmnt and th spcific policy languag. This papr is organizd as follows. Sction 2 rviws prvious rsarch conductd on policy spcification for MAs. In Sction 3, w dscrib our syntax for spcifying policis. W implmntd our framwork and its dtaild dscription is providd 4. W conclud in Sction 5 and provid som futur dirctions of our rsarch. 2 Background Svral policy-basd approachs hav bn proposd for th spcification of policis to control th intraction of agnts. KAoS [14] is a collction of componnt-basd policis and domain managmnt srvics which provid support for mobil agnt, grid computing and wb srvics. KAoS rlis on a DAML dscription-logic-basd ontology of th computational nvironmnt, application contxt, and th policis thmslvs. It maks it possibl to rprsnt subjcts, actions, and situation at multipl lvls of abstrac-
tion and to dynamically calculat rlations btwn policis and nvironmnt ntitis and othr policis basd on ontology rlations. Ri [8] is a policy framwork dsignd for prvasiv computing applications, rprsnts policis in a smantic languag lik RDF-S, DAML+OIL or OWL. Using a smantic languag allows diffrnt systms to shar a modl of policis, rols and othr attributs. Th languag is not tid to any spcific application and it prmits domain spcific information to b addd without modification. In LGI [10], policis spcify which actions th agnt has to nforc upon th rcipt or snding of mssags. Policis us a simpl Prolog notation. It assums that policis ar intrprtd by trustd controllrs at ach agnt s sit. Pondr [2] is a dclarativ, objct-orintd languag that supports th spcification of svral typs of managmnt policis for distributd systms. Pondr uss an objct-orintd approach which allows usrs to dfin diffrnt typs of policis to mt spcific administrativ and scurity managmnt goals. In [1] Pondr was usd for spcifying authorization policis for mobil cod. Th authors dscrib an xtnsion of th accss control mchanism providd by th Java scurity framwork [6]. Th xtnsion consists of svral moduls that hav bn introducd to map authorization policis spcifid in Pondr into Java scurity structurs. With th us of th Pondr languag, it bcoms possibl to spcify mor complx policis. Howvr, th Java scurity framwork is limitd to control rsourc accss of th host. Prvnting an agnt from prforming an opration or forcing th agnt to rjct th rsult of a rqust is out of th scop of th Java scurity framwork. PEP 1 Outbound rqust Mobil Agnt PEP 4 Inbound rply invocation rply PEP 2 Inbound rqust Host Rsourc PEP 3 Outbound rply Figur 1. Policy nforcmnt points. To fill th gap of th abov approachs, w propos a framwork whr th Policy Enforcmnt Points (PEP) can b spcifid for both th agnt and host rsourcs. As shown in Figur 1, w spcify four points of policy nforcmnt: PEP 1: at this point policis ar nforcd whn th agnt snds out a rqust to a (mor gnrally to any local or rmot host or agnt) host rsourcs. For instanc, th agnt is not authorizd to invok a rsourc of th host unlss crtain conditions ar mt. Such conditions could b contxtual, such as tim of th day or host location. Conditions can b dfind on proprtis of ithr th agnt or th targt rsourc on th host. PEP 1 policy could b usd to protct th privacy of th agnt s data. For instanc, th agnt is authorizd to invok th host rsourc but data passd as paramtrs should b filtrd to rmov privat or snsitiv information. In othr words, th nforcmnt of authorization policis at this point allows us to sparatly dfin and control th xcution of oprations by th agnt. Only whn crtain assumptions hold, can th call b mad. W namd such policis Subjct Authorization (SA) policis. PEP 2: this point is usd for activating traditional authorization policis for accss control on th rsourc. Policis ar nforcd whn th host rsourc rcivs a rqust. W namd this typ of policis Targt Authorization (TA) policis. PEP 3: this point allows th host to apply policis whn th rsourc snds back th rply. For xampl, to rmov snsitiv data from th rply that is snt back to th agnt. Just dnying th agnt th right to prform th opration is not sufficint to covr this cas. Th rsourc will provid information to th agnt. Howvr th rsourc administrator dfins th conditions undr which th information is can b givn without compromising confidntiality. W namd ths policis Targt-Rturn Authorization (TRA) policis. PEP 4: this point allows us to nforc policis whn th agnt rcivs th rply. PEP 4 policis can b usd to protct th intgrity of th agnt from malicious or buggy data snt from th rsourc. W namd such policis Subjct-Rturn Authorization (SRA) policis. Figur 1 shows an agnt that is th initiator of a rqust. Howvr, it could b th cas that th agnt provids som functionality to th host nvironmnt. If this is th cas, thn th agnt bcoms th targt of an invocation. Thrfor, PEP 2 and 3 ar also usd to nforc authorization policis on th functionalitis xposd by th agnt. If spcifid at th application lvl, th nforcmnt points may look diffrnt for ach application. Such points can b uniformly abstractd as mthod invocations whn sn at th systm lvl (.g., at th lvl of th Java virtual machin) whr w can intrcpt any mthod invocation (and also rplis), and it is transparnt to th application. An intrcptd mthod invocation or rply can provid most of th information for policy valuation. For instanc,
most accss control policis-bas thir dcisions on (subjct, targt, action) tupls. This information is includd implicitly in th mthod call or th rply. In addition, th paramtrs of th mthod call and th rturn valu of th rply can provid mor information if ndd. Our approach is indpndnt from th policy languag, as long as th languag offrs a syntax to xprss th typs of policis rquird by ach PEP. In th following sctions, w discuss in mor dtail th policy languag and intrprtr usd in our framwork. SA auth+/- subjct.action(p) targt TA auth+/- subjct targt.action(p) TRA rply+/- subjct targt.action(r) SRA rply+/- subjct.action(r) targt Figur 2. Mobil Agnt Authorization Policy Syntax. In th following, w provid svral xampls of authorization policis for both MAs and host rsourcs. 3.1 Exampls of Policy Spcifications In this sction w provid xampls of policis that it is possibl to spcify using our approach. Th policis that w considr ar for mobil agnt for halthcar applications. Policy 1 shows a rfrain policy that prvnts a mobil patint agnt rqusting tratmnt to a mdical srvic providd by th host whn th mdical srvic cannot provid a valid crtificat signd by th National Halth Srvic (NHS). Policy 1 Ngativ authorization policy for th patint agnt to issu a rqust of a tratmnt to a mdical srvic. auth- patintagnt.rqusttrat() MdSrvic whn!mdsrvic.isnhscrtifid() 3 Mobil Agnt Authorization Policis In our approach a positiv authorization policy dfins which subjcts ar grantd th prmissions to xcut actions of a givn targt. W also support ngativ authorization policis. In our xampls, subjcts typically map to mobil agnts and targts to host rsourcs. Howvr, MAs can b targts and host rsourcs can b subjcts. A ngativ authorization policy can b sn as a rfinmnt of mor gnral positiv authorization policis. Ngativ authorization policis ar also particular usful whn prmissions (in th form of a positiv authorization) nd to b rmovd to a group of subjcts. Whn daling with policy basd systms, it is unavoidabl that conflicts aris in th st of policis. This issu is mor acut in th cas of agnts migrating through diffrnt hosts. As a mattr of facts, policy administrators cannot b awar of th policis that agnts tak along during thir migrations. Conflict rsolution is fundamntal for policy basd systms, as discussd in [9]. Th study of conflict rsolution is on main ara of our futur rsarch. Th main contribution of this papr that diffrntiats our approach from prvious rsarch is that for a givn action authorization policis ar uniformly applid to subjcts as wll as to targts. Figur 2 prsnts th authorization policis that can b spcifid in our framwork. 1 Th kyword rply± spcifis that th authorization policy is to b applid on th rply of th action. In this cas, th rsult of th action is xplicitly indicatd by th paramtr r of th action. 1 Although in th syntax w xplicitly idntify ach typ of policis, th position of th action in th policy slf-xplains whthr th policy is to apply to a subjct or a targt. Policy 2 is anothr ngativ authorization policy applid on th patint agnt. Howvr, this policy dnis to th agnt accss to th tratmnt rturnd by th mdical srvic whn th rturnd tratmnt is signd by a GP that is not rcognizd by th NHS. Policy 2 Ngativ authorization policy for th patint agnt to rciv th rsult of a rqust issud to a mdical srvic. rply- patintagnt.rqusttrat(prscription) MdSrvic whn!prscription.gp().isnhscrtifid() Positiv authorization policis can b usd for applying filtrs to th data that is supplid or rturnd. Th filtr is spcifid by using th filtr kyword in th action claus. Filtring policis must b positiv authorization bcaus no transformation nds to b applid if th action is forbiddn. Policy 3 shows a filtring policy for an agnt of an mploy. Th agnt of an mploy has to provid to th GP of th company whr th mploy works hr mdical rcord. Th data is stord on th data bas of th company. For privacy rasons, th mploy psychiatric data must b rmovd from hr mdical rcord. Th policy applis a filtr that nullifis th snsitiv fild from th rcord. Th filtr is xcutd bfor th action is prformd. Policy 3 Filtring policy for an agnt whn providing snsitiv data to a databas on a host. auth+ mployagnt.ins(rcord) mploymddb filtr myrcord.psych := NULL It should b notd how th us of our framwork ralizs a complt sparation of concrns [11]. In fact, all th
dtails about chcking th crdntials of th targt, th targt s rply, and th application of filtrs on snsitiv data ar spcifid outsid th logic of th application. Ths dtails ar isolatd and capturd in th policy spcification. Policy 4 provids an authorization policy for a nurs agnt that has to prform accsss on th patints mdical rcords in a hospital. According to this policy, a nurs agnt can accss th mdical rcords of a patint whn th nurs is on duty on th ward whr th patint is assignd. Policy 4 Authorization policy for granting accss right to a nurs agnt on th mdical rcords of patints in a hospital. auth+ nursagnt mdicalrcorddb.accssfor(patint) whn (nursagnt.ward = patint.ward) Th policy intrprtr organizs th ntitis (agnts and rsourcs) that ar spcifid in a policy in hirarchical domains of objcts. Domains can b usd to spcify th subjct and targt in a policy. Whn an agnt arrivs in a host, th local policy intrprtr authnticats th agnt and adds it in a local domain. Th domain whr th agnt is addd dpnds on th agnt s crdntials. Using this approach, w can spcify th prvious authorization policy in trms of domains as shown in Policy 5. In this cas, agnts rprsnting hospital prsonnl and patints ar organizd in domains. Each domain rprsnts th diffrnt wards of th hospital. Whn th nurs starts hr shift in a ward, hr agnt is insrtd in th appropriat ward domain (ward10 in our xampl). Policy 5 Authorization policy for accss control basd on th domain location of th nurs and patint agnts. nursagnt in /hospital/prsonnl/ward10/ patintagnt in /hospital/patints/ward10/ auth+ nursagnt.gtrcord() patintagnt Mor dtails on how this policy is nforc ar providd in Sction 4.2.1. 4 Implmntation This sction discusss dtails of th implmntation of our framwork. Th actual prototyp is built mainly in Java, although our framwork is concptually indpndnt of th actual programming languag. Java was mainly chosn for a fastr intgration with our xisting policy intrprtr. 4.1 MA Migration Dtails This sction provids insights on som aspcts rlatd to th migration of a mobil agnt in our framwork. Figur 3 shows th migration of an agnt to its dstination host. In particular, th figur shows that th unit of migrating Mobil Agnt MA Policis allocation loading Mobil Agnt Policy Intrprtr MA Policis dstination host nforcmnt invocation Host Rsourc Host Policis Figur 3. Th migration of an agnt and its policis. mobility is composd by th agnt logic (that is th xcutabl part) and th agnt policis. On arrival on th host, th agnt logic is insrtd in th xcutabl nvironmnt whr it can intract with th host rsourcs. Th agnt policis ar loadd by th host s intrprtr in its local data structur. Whn th agnt intracts with th rsourcs in th host, th intrprtr nforcs th policis as rquird. Th basic assumption in our approach is that th host policy intrprtr whr an agnt movs is trustd. A host is trustd whn it can provid to th agnt crdntials to guarant that th xcution will b carrid according to th constrains spcifid by th agnt s policis. Which ar such crdntials and th spcific mthod that an agnt has to us for building nough trust on th host intgrity is th subjct of our futur rsarch. W ar also considring a mor radical approach which wraps a policy intrprtr around th mobil agnt. 4.2 Implmnting th Policy Enforcmnt Points In this sction, w dscrib th architctur of our prototyp that w built to dmonstrat th fasibility of our approach. Crucial to our approach is th ralization of a PEP mchanism such that (i) it supports a fin-graind lvl of nforcmnt point spcification and (ii) it is compltly transparnt to th application logic. Svral tchniqus could b usd for ralizing th PEP mchanism of our approach. For instanc, using th standard Wrappr Pattrn, th agnt and rsourc cod is wrappd by a pic of cod that intrcpts all th inbound and outbound calls to and from th componnt. Each tim a call is intrcptd, th wrappr passs th ncssary information to th Policy Intrprtr to activat a policy. A Java-basd solution that supports th wrappr pattrn is th Java Managmnt Extnsion (JMX) [5]. In JMX, th agnt and th rsourcs must b managd by a Man- xcution nvironmnt policy dcision making
agd Ban (MBan). A MBan is a spcial Java ban that xposs via a standardizd intrfac (dfind by th JMX spcification) attributs and mthods of th rsourc that it manags. MBans hav th capability to mit notifications upon crtain vnts. Such vnts could call th PEPs in our framwork. Anothr Java-spcific solution is basd on th us of th Java Virtual Machin Tool Intrfac (JVMTI) [7]. JVMTI provids an intrfac that can b usd by usr cod to control and monitoring Java applications. In JVMTI such usr cod is calld an agnt. To avoid confusion, w will rfr to it as ti-agnt. Ti-agnts us th functionality xposd by JVMTI to b notifid whn vnts occur in th application, and to qury and control th application during xcution. Among th vnts that a ti-agnt can intrcpt thr ar thos that captur whn th xcution ntrs and xits a mthod. JVMTI allows ti-agnts to rtriv information rgarding mthod call, such as objct typ of th callr and th call, th paramtr valus passd in th mthod invocation, and th valu that th mthod rturns. Givn th fin-graind control and monitoring capability, and th fact that it is not rquird to chang any application cod, w implmntd th PEP mchanism using JVMTI. An altrnativ approach would b to us Aspct- Orintd Programming [3]. Such an approach is usd by Vrhannman, t al. in [13]. Thy us Java Aspct Componnts [12] to implmnt a wrappr to intrcpt mthod calls from th callr to call and to nforc policis as rquird. This tchniqu rquirs that th agnt cod is modifid with th injction of aspct-spcific cod at th host sid. Crucial in AOP is th spcification of whr th aspct cod must bn injctd. In JAC, this is don transparntly to th application using dscriptor fils. Th dscriptor provids thos points to th JAC middlwar that thn wavs th aspct cod with th application cod. This is compltly transparnt to th application. W dcidd to us JVMTI mainly for two rasons. Th first rason is that JVMTI is a standard Java tool. Using an aspct orintd approach rquirs us to rly on non-standard Java compilrs and tools that ar not always so thoroughly dvlopd. Th scond rason is that th us of JVMTI dos not rquirs any changs in th application cod. It should b notd howvr, that th dsign of our framwork is indpndnt of th actual mchanism usd for implmnting a PEP. In principl, all th abov approachs could b usd to implmntd a PEP with nough capabilitis that would nabl our framwork to function as rquird. This has th main advantag of allowing our framwork to nforc policis across systms implmntd using diffrnt tchnologis. Figur 4 givs an ovrviw of our architctur. Givn that th JVMTI and policy intrprtr moduls wr alrady availabl, th only moduls that w implmntd ar th ti a.c and th TIAgnt.java. A g n t s n d nativ cod Java cod PEP 4 PEP 1 invocation vnts rply JVMTI ti_a.c JNI TIAgnt.java Policy Intrprtr PEP 2 PEP 3 r c i v R s o u r c Policy tabl Policy tabl Hirarchical Domain Rprsntation Figur 4. Th moduls implmntd in our framwork to provid a complt control ovr authorization. Th ti a.c is th ti-agnt writtn in C that is injctd in th JVM at start-up tim as a command lin option. Onc th ti a.c has bn loadd into th JVM, it rgistrs th notification callbacks for JVMTI vnts. In particular, th agnt rgistrs for JVMTI EVENT METHOD ENTRY and JVMTI EVENT METHOD EXIT to intrcpt whn th xcution flow ntrs and xits a mthod, rspctivly. For xampl, Figur 4 shows an agnt that is xcuting its own mthod snd to invok th mthod rciv of th rsourc. In this xampl, ti a.c is notifid by th JVMTI notification systm whn th following vnts occurs: ntring mthod snd (vnt 1), ntring mthod rciv (vnt 2), xiting mthod rciv (vnt 3), and finally xiting mthod snd aftr th call to rciv (vnt 4). Such vnts ar on-to-on mappd to th PEPs that our framwork rquirs. Mthod ntry and mthod xit vnts ar notifid vry tim a mthod is calld. This rquirs that ti a.c that has to filtr out all thos vnts rlativ to mthods for which a policy has not bn spcifid. This mans that th ti a.c
nds to b intrfacd with th policy intrprtr bcaus th intrprtr organizs th policis in its domain hirarchy. This task is fulfilld by th TIAgnt.java that provids to th ti a.c information on th policis loadd by th intrprtr. Th information that th TIAgnt.java xtracts from a loadd policy is concatnatd to from a so calld signatur. A signatur is th concatnation of th following lmnts: th action that is th nam of th mthod to b invokd, th targt that is th host objct s full class nam that contains th mthod, and th subjct that is th MA objct s full class nam that invoks th mthod. Th signaturs ar passd to th ti a.c that can us thm to intrcpt th appropriat vnts. Th ti a.c and TIAgnt.java maintain policy tabls whr policy signaturs ar stord. This nabls us to minimiz th dpndncis of our framwork from th policy rprsntation usd by th spcific intrprtr. vnt lt th invocation procds ti_a.c rtriv action and targt look up in th tabl rtriv th subjct from th fram invok isauthorizd rturn tru TIAgnt.java rtriv policy rfrnc from tabl authnticat subjct OID chck subjct and targt OIDS rturn tru Policy Objct Figur 7. Th mssag squnc chart of th activation of an authorization policy. ky valu act+tar tag sbj_list: sbj 1 sbj 2 Figur 5. Th policy tabl of th ti a.c. Th policy tabl maintaind by th ti a.c is a hash tabl rprsntd in Figur 5. Th ky column contains th concatnation of th action and targt. Th valu column contains structurs with th following filds: tag, that can hav thr valus: 0 for an authorization policy on ntring th mthod, and 2 for an authorization policy on xiting th mthod; subjct list, a linkd list subjcts for which an authorization policy is spcifid. ky valu signatur rfrnc to policy objct 1 rfrnc to policy objct 2 Figur 6. Th policy tabl of th TIAgnt.java. Th policy tabl of th TIAgnt.java is rprsntd in Figur 6. It is a hash tabl whr th ky column contains signaturs. Th valu column contains a linkd list of rfrncs to th actual policy objcts as rprsntd by th policy intrprtr. Th main rason of having two sparat instancs of th tabl is to lowr th ovrhad of JNI calls btwn th TIAgnt.java and ti a.c. For ach vnt, th ti a.c rtrivs th mthod nam (action) and th full class nam (targt) of th objct that contains th mthod. Using this information, th ti a.c looks up a matching ky in its tabl. If a match is found, th procss to activat th propr policy is startd. Othrwis, th ti a.c just ignors th vnt. By having its local tabl, th ti a.c can prform locally th sarch instad of having to us a costly JNI call to th TIAgnt.java. Whnvr th intrprtr updats th st of policis (i.., for loading nw policis, disabling or nabling policis), th TIAgnt.java is notifid that an updat was prformd. This triggrs th updat on its own tabl. As soon as th TIAgnt.java changs its tabl, th ti a.c intrcpts th changs and updat its local tabl, accordingly. In th following, w xplain with an xampl th dtails of th authorization of a mthod invocation. 4.2.1. An xampl of Authorization Policy Enforcmnt. Lt us considr on of th policis prsntd abov. In particular, lt us considr th authorization policy dfind in
Policy 5 Th policy spcifis that th nurs agnt is authorizd to gt th rcords of a patint agnt whn th nurs is on duty on th sam ward whr th patint is assignd. Figur 7 shows a mssag squnc chart of th policy xcution for authorizing th nurs accss. Whn th xcution flow ntrs th mthod radrcord of th patint agnt, JVMTI raiss an vnt capturd by th ti a.c. Th ti a.c rtrivs th mthod nam (action) that is bing invokd and th agnt s full class nam (targt) whr th mthod blongs to. This information is usd to look up in its policy tabl for a matching lmnt. Onc th lmnt is rtrivd, th ti a.c uss th subjctlist to idntifywhich agnt is invoking th mthod. For ach lmnt in th subjct list, th ti a.c scans th frams of th currnt xcution stack (providd by th JVMTI) for a match. If no matching subjct is found, thn th ti a.c has to notify th TIAgnt.java that an unauthorizd accss is bing attmptd and appropriat actions should b takn (for instanc, throwing an xcption). Onc th nurs agnt is found in th currnt xcution stack, to complt th authorization it is ncssary to authnticat th subjct. As for th authntication, in th currnt implmntation of our prototyp, w us th authntication mchanism providd by th policy intrprtr. As w said, th policy intrprtr maintains a domain structur populatd with managd objcts. Each managd objct rprsnts a componnt that nds to b managd. In this cas, a componnt can b ithr an agnt or a rsourc. Whn a nw componnt is discovrd, th policy intrprtr chcks th componnts s crdntials. If th componnt is authnticatd, th policy intrprtr instantiats th corrspondnt managd objct in its domain structur. Each managd objct is uniquly idntifid by an ID gnratd by th intrprtr, calld OID. Thus th subjct can b authnticatd if it provids a valid OID. This holds also for th targt. Th ti a.c rtrivs th subjct and targt OIDs. Aftrwards, th ti a.c invoks th TIAgnt.java s mthod isauthorizd (using JNI) passing th following information: th signatur, that is th concatnation of subjct and targt class nam followd by th mthod nam, th subjct OID, th targt OID, and an array containing th paramtrs valus of th mthod invocation (in this cas th array is null bcaus no condition claus is spcifid in th policy). Using th signatur, th isauthorizd mthod rtrivs from th policy tabl th linkd list of policy rfrncs. Multipl policis could b dfind for th sam combination of action, targt, and subjct. All of ths policis ar containd in th list. Th mthod gos through th list until a policy that authorizd th xcution of th opration is found. A policy authorizs an action if th subjct and th targt OIDs ar valid. This also mans that th OIDs must b containd in th spcifid domains. In this cas, th nurs agnt OID must b containd in th ward10 domain for th hospital prsonnl, and th patint agnt OID must b in ward10 domain for th patints. Whn th policy that authorizs th action is found, thn th isauthorizd mthod immdiatly rturns to th ti a.c that th invocation can procd. Othrwis th isauthorizd mthod rturns fals to th ti a.c that dos not allow th invocation. 5 Conclusions and Futur Work In this papr, w prsntd a framwork for authorization policy nforcmnt for mobil agnt applications. Th main contribution of our approach is that authorization policis can b usd to protct both th mobil agnts and h host rsourcs. This fills th gap of prvious approachs whr policis could b spcifid and nforcd on th host rsourcs. This papr also dscribd our implmntation of th framwork. As futur work, w fors working in combining a Trust Managmnt Systm (TMS) with accss control. Sinc th intrcption mchanism is indpndnt from th actual authorization modl, w can asily intgrat a TMS in our suit. Th TMS will tak dcisions on whthr a givn ntity should b grantd authorization basd on th trust lvl that th ownr of th accssd rsourc puts on th ntity. This lvl can chang ovr tim, providing a vry flxibl framwork in comparison with th ys-or-no approach of classical scurity modls. Anothr main ara of futur rsarch is th introduction in our framwork of conflict rsolution stratgis to automatically rsolv conflicts that could aris btwn policis. Acknowldgmnts This rsarch was supportd by th UK s EPSRC rsarch grant EP/C537181/1 and forms part of th CarGrid, a collaborativ projct with th Univrsity of Cambridg. Th authors would also lik to thank th mmbrs of th Policy Rsarch Group at Imprial Collg for thir support. Rfrncs [1] Corradi t al. A flxibl accss control srvic for Java mobil cod. In 16th Annual Computr Scurity Application Confrnc (ACSAC 00)s.
[2] N. Damianou, N. Dulay, E. Lupu and M. Sloman. Th Pondr Policy Spcification Languag. In Proc. 2nd IEEE Intrnational Workshop on Policis for Distributd Systms and Ntworks, pp. 18 38, 2001. [3] R.E.FilmanandD.P.Fridman. Aspct-Orintd Programming is Quantification and Obliviousnss. Workshop on Advancd Sparation of Concrns, OOPSLA, Octobr 2000. [4] W. Jansn and T. Karygiannis. Mobil Agnt Scurity. NIST Spcial Publication 800-19, National Institut of Standard and Tchnology, 2000. [5] Java Managmnt Extnsion Spcifications. http://jcp.org/aboutjava/communityprocss/final/jsr003/ indx3.html [6] Java Scurity Whit Papr. http://java.sun.com/dvlopr/ tchnicalarticls/scurity/whitpapr/js Whit Papr.pdf [7] JVM Tool Intrfac http://java.sun.com/j2s/1.5.0/docs/guid/ jvmti/indx.html [8] L. Kagal, T. Finin and A. Joshi. A policy languag for a prvasiv computing nvironmnt. In Proc. 4th IEEE Intrnational Workshop on Policis for Distributd Systms and Ntworks, pp. 63 74, 2003. [9] E. Lupu and M. Sloman. Conflicts in Policy-Basd Distributd Systms Managmnt. IEEE Transaction on Softwar Enginring, pp. 852 869, Vol. 25, No. 6, 1999. [10] N. H. Minsky and P. Pal. Law-Govrnd Rgularitis in Objct Systms - Part 2: A Concrt Implmntation. Thory and Practic of Objct Systms (TAPOS), John Wily. 2, 1997. [11] D. L. Parnas. On th critria to b usd in dcomposing systms into moduls. Communications of th ACM, 15(12):1053-1058, Dcmbr 1972. [12] R. Pawlak, L. Sinturir, L. Duchin, and G. Florin. JAC: A Flxibl Framwork for AOP in Java. In Rflction 01, volum 2192 of Lctur Nots in Computr Scinc, pags 1 24. Springr-Vrlag, Sptmbr 2001. [13] T. Vrhannman, F. Pissns, B. D. Win and Woutr Joosn Uniform Application-lvl Accss Control Enforcmnt of Organizationwid Policis. In Proc. 21st Annual Computr Scurity Applications Confrnc, pp. 431 440, 2005. [14] A. Uszok, J. Bradshaw, R. Jffrs, N. Suri, P. Hays, M. Brdy, L. Bunch, M. Johnson, S. Kulkarni and J. Lott. KAoS policy and domain srvics: toward a dscriptionlogic approach to policy rprsntation, dconfliction, and nforcmnt. In Proc. 4th IEEE Intrnational Workshop on Policis for Distributd Systms and Ntworks, pp. 93 96, 2003.