A Framework for Role-Based Access Control in Group Communica(4)

In this paper we analyze the requirements access control mechanisms must fulfill in the context of group communication and define a framework for supporting fine-grained access control in client-server group communication systems. Our framework combines ro

arenotsubjectedtoagrouppolicyoratemplatepol-icy:1)createagrouptemplatepolicyand2)modifyagrouptemplatepolicy.

Acomprehensivelistofbasicoperationthatapplytoagroupandaretheobjectofaccesscontrolispre-sentedbelow:1.createagroup.

2.modifyagrouppolicy.3.joinagroup.

4.sendamessageofagiventype.5.receiveamessageofagiventype.6.ejectauserfromagroup.7.

destroyagroup.

Theabovelistdoesnotincludetheoperationofleavingagroupbecausethisisanoperationthatcannotbecontrolled.Itisimpossibletopreventaclientfromleavingagroup1.

Weallowseparatecontrolforjoiningagroup,send-ingamessage,andreceivingamessagetoprovidesupportforawiderangeofapplications.Forsomeapplicationsseveralgroupmembersmaybeallowedtosend,butnottoreceivemessages.Anexampleofsuchanapplicationisainformationreportingmilitaryapplicationwhereclientsusewirelesscommunication;itisdesirabletolimittheinformationclientsreceiveandstoretominimizethedamagecausedincaseofcompromise.Forotherapplications,somegroupmem-bersmaybeallowedtoreceivebutnottosendmes-sages.Forexample,inaconferencewithalargenum-berofparticipantsonlyrepresentativesmayanswerquestions,whiletherestoftheparticipantsarejustlistening.

3.3RolesinGroups

OneapproachtospecifyandenforceaccesscontrolistouseAccessControlLists(ACL’s).Underthisap-proach,agrouphasanACL,whichincludesasetofusersandtheoperationstheyareallowedtocarryout.Suchanapproachisappropriatewhenthenumberofprincipalsandoperationsissmallandstatic.Ingen-eral,ACL’shavethefollowingdisadvantages.First,ACL’scangetverylarge.Forexample,ifeveryregis-teredstudentinauniversityisallowedtojoinaclass-room,thentheACLwouldbesimplytoolong.Sec-ond,theACLoftenduplicatesinformationmaintainedinotherplacesanditsuseinadynamicdistributedsystemwillrequiremaintainingitsconsistencyacross

1Any

clientcane ectivelyleaveagroupbyclosingthecon-nectionwiththeserver.

severalsiteswhichcanbeverydi cultandpronetointroduceinconsistencyinthesystem.

FromthescenariodescribedinSection3.1,itisclearthatthesetofoperationsauserisallowedtocarryoutdependsupontherolethattheuserisplay-inginagroup.Forexample,althoughausermaybetheinstructorofacourse,inaguestlecturesessionshemaybeplayingaTAorastudentrole.

Wedistinguishbetweentwokindsofroles:systemrolesandapplicationroles.Systemrolesareprede- nedbytheGCS;theyexistineverygroupandhaveprede nedmeaningsintermsofoperationstheyareallowedtocarryout.Thefollowingaresystemrolesourframeworksupports:

(group)creator:thisrolehasatmostonemem-ber,identifyingtheuserthatistheoriginalcre-atorofthegroup,i.e.,the rstmemberofthegroup.Becauseoffailures,agroup’screatorrolemaybeempty. (group)controller:thisrolehasexactlyonemem-ber,whohasfullcontroloveragroup,includingchangingthepolicyforthegroupanddestroy-ingagroup.Whenausercreatesagroup,itisautomaticallymadethecreatorandthecon-trollerofthegroup.Wedi erentiatethegroupcreatorfromthegroupcontrollerforseveralrea-sons.First,thecreatorofagroupmaywanttotransferthecontrollerresponsibilitiestoanothermemberofthegroup;forexample,aTAmaycre-ateaclassroombeforetheinstructorcomesandthen,aftertheinstructorjoins,transfertheroletotheinstructor.Second,evenwhenthegroupcreatoristheoriginalcontroller,itmaycrashorleavethegroup,inwhichcaseanothermemberneedstoassumethegroupcontrollerrole. (group)member:anyuserwhojoinsagroupisautomaticallyamemberofthisrole.Eachsystemrolecomeswithasetofallowedoper-ationsandhasasetofoperationsthatcanbemore negrainedde ned.Forexample,foraclientwiththerolegroupmemberrestrictionsonsendandreceivecanbede nedbasedonthemessagetype.

Eachgroupmayalsohaveasetofapplication-speci croles,forexample,inthevirtualclassroomsce-nario,thefollowingapplicationrolesmaybeneeded:instructor,TA,student,auditor.

Onceauserjoinsagroup,theusermayalsoperformthefollowingoperationsrelatedtoroles:1.assumearole.2.droparole.