Using CORBA Security Service
Konstantin Beznosovand Yi Deng
Center for Advanced Distributed Systems Engineering
School of ComputerScience
Florida International University
Abstract
Thepapershowshowrole-basedaccess control (RBAC)
modelscouldbeimplementedusingCORBASecurity
ser-vice. A conguration of CORBA protection system is
dened. We provide denitions of RBAC
0
and RBAC
1
implementations in the framework of CORBA Security
and describe what is required from an implementation
ofCORBA Securityservicein ordertosupport RBAC
0 -RBAC 3 models. 1 Introduction
Role-based accesscontrol (RBAC)[SCFY96] is afamily
of reference models in which permissions are associated
withrolesandusersareassignedtoappropriateroles. A
role can represent competency, authority, responsibility
orspecic duty assignments. Some variationsof RBAC
includethecapabilitytoestablishrelationsbetweenroles,
between permissions and roles, and between users and
roles. There are four established RBAC reference
mod-els: unrelatedroles(RBAC
0
),role-hierarchies(RBAC
1 ),
userandroleassignmentconstraints(RBAC
2
),andboth
ThisworkwassupportedinpartbytheNSFunder
Coopera-tiveAgreementNo. HDR-9707076andbyBaptistHealthSystems
ofSouthFlorida.
Allcorrespondence should beaddressedto Konstantin Beznosov,
SchoolofComputerScience,FloridaInternationalUniversity,
Mia-mi,FL33199,[email protected], http://cadse.cs.fiu.edu.
0
hierarchies and constraints (RBAC
3
). RBAC
support-sthree securityprincipals: least privilege, separationof
dutiesand dataabstraction.
Amajor purpose of RBAC is to facilitate access
con-troladministrationandreview. RBACisapromising
ap-proachtoaddresstheneedsofthecommercialenterprises
better than lattice-based MAC [BL75] and owner-based
DAC [Lam71]. Recent series of papersdescribe ways to
model or implement RBAC using the technologies
em-ployedbythecommercialusers: Oracle[Not95],NetWare
[ES95], Java [Giu98], DG/UX [Mey97], object-oriented
systems[Bar95], object-oriented databases [Won97],
M-SWindowsNT [BC98], enterprise securitymanagement
systems[Awi97]. Evidence of RBAC recognition in the
USgovernmentisthefactthattheproposedruleson
secu-rityfromtheDepartmentofHealthandHumanServices
[Dep98]includeRBACasoneoftherequiredalternatives
foraccess control.
At the same time, the commercial market is
expe-riencing the spread of systems based on Common
Ob-jectRequest BrokerArchitecture (CORBA)technology.
CORBA is aversatile object-based distributed
comput-ingtechnology, which is becoming aworldwideindustry
standard for constructing distributed software systems.
CORBAstandardizationprocessisbasedonthe
consen-susofover800softwarecompanies.Thecomputing
mod-el that CORBA adheres to is outlined in Object
Man-agement Architecture (OMA) [SS95]. The CORBA
en-vironment, includingCORBA SecurityService, provides
a general-purpose infrastructure for developing and
de-ploying distributed object systems in a broad range of
specialized vertical domains. CORBA Security service
(CS)denes theinterfaces to a collection of objectsfor
couldbeindependentfromtheparticularsecurity
infras-tructure provided by a user enterprise computing
envi-ronment. Duetoitsgeneralnature,CSisnottailoredto
anyparticularaccesscontrolmodel. Instead,itdenesa
generalmechanismwhichissupposed tobeadequatefor
themajorityofcasesandcouldbeconguredtosupport
various access control models. For example,it is shown
in [Kar96] how to implement lattice-based MAC using
theCORBA authorizationmodel. Inthenextfewyears
we expect to witnesssignicantnancial investmentsin
theenterprise-widedeploymentofCSin commercialand
governmentorganizations,including thosewhowill
con-structtheirsecuritypoliciesutilizingRBACconcepts. It
is important to foresee if CS will fully support RBAC
models. However,we are notaware of anywork in the
researchcommunitythathasexploredthepotentialofCS
forsupportofRBACreferencemodels.
Inthispaperwepresentanapproachforimplementing
RBAC models using the access control mechanism
pro-vided byCS. WedeneacongurationofCSprotection
system. ThenwedeneRBAC
0
andRBAC
1
implementa-tionsintermsofCSframeworkanddescribehowRBAC
0
-RBAC
3
could be implemented in CS. We illustrate the
discussionwithseveralexamples. Ourapproachallowsan
implementation compliant with CS specication to
sup-port RBAC
0
. Additional functionality, which is beyond
CS specication scope, should be implemented in order
tosupport RBAC
1
and/orRBAC
2 .
Thepaperisorganizedasfollows: Section 2describes
the access control model of CS and denes a
congura-tionofthe CORBAprotectionsystem;Section 3denes
RBAC models using CS concepts and shows a possible
implementation of RBAC
0 -RBAC
3
using CS with
illus-trationonanexamplerolehierarchy;Section4concludes
thepaper.
2 CORBA Access Control Model
Inthis section, we rstinformallydescribetheCORBA
AccessControlmodel. Then,weformallydenea
cong-urationoftheCORBAProtectionSystemstate.
2.1 Informal Description
The CORBA environment, including CORBA Security
Service,providesageneral-purposeinfrastructurefor
de-velopingand deployingdistributed object-basedsystems
interfacesdened in the OMG Interface Denition
Lan-guage(IDL).ACORBAinterfaceisacollectionofthree
things: operations, attributes, and exceptions. An
im-plementationof aCORBA interfaceis called aCORBA
object. Hence,weuse\CORBAobject"orjust \object"
tomean\implementationofaCORBAinterface",where
it does notcause confusion. Objectfunctionality is
ex-posed toother CORBA-basedapplicationsonly through
thecorresponding interfaces. Objectshaveobject
refer-encesbywhich theycanbereferenced. An object
refer-ence is a handle through which onerequests operations
ontheobject.
TheCS model comprises the following functionalities
visibletoapplicationdevelopersandsecurity
administra-tors: identicationandauthentication,authorizationand
accesscontrol,auditing,integrityandcondentiality
pro-tection,authenticationof clients andtarget objects,
op-tionalnon-repudiation,administrationofsecuritypolicies
andrelatedinformation.
Oneof the objectives of CS is to be totally
unobtru-siveto application developers. Security-unawareobjects
shouldbeableto runsecurelyonasecureORBwithout
anyactiveinvolvementonthesiteofapplicationobjects.
Inthe meantime, it must be possible for security-aware
objectstoexercisestrictersecuritypoliciesthantheones
enforcedby CS. IntheCS model, allobjectinvocations
aremediatedbytheappropriatesecurityfunctions in
or-dertoenforcevarioussecuritypoliciessuchasaccess
con-trol. A simplied schemaof control points in CS model
is represented in Figure 1. Those functions are part of
CSand aretightly integratedwith theORB becauseall
messagesbetweenCORBAobjectsandclientsarepassed
throughtheORB.
CSusesthe notionofprincipal. \Aprincipal is a
hu-man user orsystem entity that is registeredin and
au-thentictothesystem"[Obj98]. Intranslationtothe
tra-ditionalsecurityterminology,aprincipalisasubject. CS
managesaccess controlpolicies basedonthesecurity
at-tributesofprincipals andattributesofobjectsaswellas
operations implemented by those objects. Objects that
havecommonsecurityrequirementsaregroupedin
secu-ritypolicy domains. Accesscontrolpoliciescontrolwhat
principalscaninvokewhatoperationsonwhatobjectsin
thedomain the policies are dened on. Policies can be
enforced either by the ORB or by the application. In
thelatter case, such anapplication is called a
security-aware application. Domains allow application of access
re-ORB
client application
access decision
Client
Object
Target
request
request
client-side invocation access decision
target application
access decision
target-side invocation access decision
Figure1: AccessControlPointsinCORBASecurityService(from [Obj98])
AsitcanbeseeninFigure1,theclient-sideand
target-side invocation access policy governs whether the client
can invokethe requested operationon thetarget object
onbehalfofthecurrentprincipal. Thispolicyisenforced
by the ORB in cooperation with the security service it
usesforall(security-awareandunaware)applications. A
client may invoke an operation on the target object as
speciedintherequestonlyifthisisallowedbytheobject
invocationaccesspolicy.
AuserusesaUserSponsor 1
toauthenticateto theCS
environment(Figure2). AUserSponsor authenticateson
User
Create
Principal
Authenticator
User
Sponsor
Attributes
Credentials
Authenticate
ORB
Request
Client
Figure2: UserAuthentication
behalf of auser with and obtainsauthenticated
creden-tialsfrom aPrincipalAuthenticator . Instances of
User-Sponsor implementuserinterfacespecictothe
authenti-cationmethodsupportedbytheconcreteimplementation
of CS. For example, for password-basedauthentication,
1
AUserSponsorisanimplementationartifactwhichhandlesthe
it prompts the user for user name and password. For
authenticationbased onsmart-cards, it interacts witha
smart-card reader and (probably) prompts the user to
insert the card in the reader. CS standard does not
mandateanyparticularauthenticationmethod. Whatit
doesspecify isthe interfaceof aPrincipalAuthenticator.
A PrincipalAuthenticator conducts the actual
authenti-cation and creates Credentials object for a new
princi-pal. Basedontheauthenticationdata itreceivedfroma
UserSponsor and on the underlying security technology
(Kerberos,SESAME,oranyothercapabletechnology)as
wellasonanyrulesitadheresto,PrincipalAuthenticator
instantiates Credentials with various information. The
informationin Credentials constitutethe identityof the
newprincipalwhichinitiatesrequestsonCORBA
object-sonbehalfof theuser. Principal authenticatedsecurity
attributesarepartof theinformationstoredin the
Cre-dentials object.
The concept of a user is absent from CS AC model.
Insteada principal represents the usercompletely. The
notionofasessionisindistinguishablefromthenotionof
aprincipal. Thus multiple principals can act on behalf
ofa single user. Theyall potentiallyhave dierent
set-s of credentialsand therefore exist in CS as completely
independent entities. Among other data, principal
cre-dentialscontainsecurityattributes. Hereafter,we
under-standattributeto meansecurityattribute. FromtheCS
AC model point of view, a principal is nothing but an
unorderedcollectionofauthenticatedattributes. All
at-tributesare typed. Attributetypes arepartitioned into
primary and secondary groups the principal is a
mem-berof,clearance, capabilities,etc. Identityattributes, if
present, provide additional information about the
prin-cipal: audit id, accounting id, and non-repudiation id,
reecting thefact that aprincipal might havevarious
i-dentitiesusedfordierentpurposes. Principalcredentials
maycontainzeroormoreattributesofthesamefamilyor
type. 2
Anexampleofsecurityattributesassignedto
au-thenticatedprincipals isprovided inTable1. Oneofthe
standard CORBA attribute types is the role attribute.
Due to the extensibility of the schema for dening
se-curity attributes, an implementation of CS cansupport
attribute typesthat are notdened bythe CORBA
Se-curitystandard. AlthoughthenormativepartofCSdoes
notmandatethewayattributesaremanaged,assignment
of such attributesto users is meant to beperformed by
useradministrators. Principal Attributes p 1 a 1 p 2 a 2 ,a 6 p 3 a 2 ,a 3 p 4 a 4 ,a 5
Table1: SecurityAttributesPossessedbyAuthenticated
Principals
AllaprincipaldoesintheCORBAcomputational
mod-elisinvokeoperationsoncorrespondingobjects. Inorder
to makearequestoneneedsto knowtwothings: object
reference, which uniquelyidenties anobject,and
oper-ation name. CORBA interfaces can inherit from other
CORBA interfaces via interface inheritance. An
opera-tionnameisuniqueforaninterface. 3
Thus,anyoperation
isuniquelyidentiedbyitsnameandbythenameofthe
interfaceitisdenedin.
In this paper, we usenotation i
k m n , to refer to n-th operationonk-thinterface. There isaglobal 4
set of requiredrights for each
oper-ation dened by itsinterface's required rights mapping.
This set, together with a combinator (all or any
right-s), denes what rights a principal has to have in order
2
Thisruleappliestoall attributetypesincludingaccessid,
al-thoughitishardtoforeseeausefulimplementationofCSwherea
principalwouldhavemultipleornoaccessidentities.
3
InterfaceinheritanceinCORBAdoesnotallowtoinheritfrom
interfaceswithoperationsofthesametype. Thisruleresolvesthe
problemofoperationnameoverloading.
4
I.e. notdependent onapolicydomaininwhichthe objectis
requiredrights for operations on three interfaces i
1 , i 2 , and i 3
. It is assumed that required rights are dened
and their semanticsare precisely documented by
appli-cation developers who know the best what each
opera-tiondoes. Depending onthe access policy
(DomainAc-cessPolicy) enforcedin aparticular ACpolicy domain, 5
aprincipalisgranteddierentrights(GrantedRights)
ac-cording to what SecurityAttributes it has. 6
Each
Do-mainAccessPolicydeneswhatrightsaregrantedforeach
security attribute. An example of a mapping between
principal privilege attributes and granted rights is
pro-videdinTable3. Securityadministratorsareresponsible
Attributes GrantedRights
Domain d 1 d 2 a 1 r 1 r 2 a 2 - r 1 a 3 r 2; r 3 -a 4 r 3 r 1; r 4 a 5 r 1 ;r 2 ;r 3 r 2 ;r 3 ;r 4 a 6 r 6 r 1
Table3: GrantedRightsperAttribute
fordeningwhat rightsare grantedto what security
at-tributesin whatdelegationstateon domainperdomain
basis. Wheneveraprincipalattemptsanoperation
invo-cation,principal'seectiverightsarecomputedvia
oper-ationAccessPolicy::geteective rights. 7
CSspecication
purposefullydoesnotdenehowtheoperationcombines
rightsgrantedthroughdierentprivilegeattributeentries
inTable3. ThespeciersletCSimplementorsdenethe
operation's internal behavior([Obj98, p. 122]). A
sim-plestimplementationofgeteective rightscouldbewhen
thesetofrightsgrantedtoaprincipalisaunionofrights
grantedtoeverysecurityattributetheprincipalhas. For
our examples, we will assume exactly this
implementa-tionof theoperation. If weuse ourexampleof security
attributesassignedtoprincipalsp
1 ,p 2 ,p 3 ,andp 4 (Table
1), and the examples of required (Table 2) and
grant-ed(Table3) rights,then Table4showswhat rightsthe
principalsaregrantedineachdomain.
5
IntheCORBAsecuritymodel,asecuritypolicydomainisjust
acollectionofobjects.
6
Forthe sakeofbrevity,weomitdelegation statequalierfor
grantedrights. Thisdoesnotchangethecorrectnessofthe
discus-sion,asweshowbelow.
7
i 1 m 1 r 1
all Only a principal who is granted right r
1
can invoke the
operation. i 1 m 2 r 1 ,r 2
any Anyprincipal whois grantedeither r
1 orr
2
rightcan
in-voketheoperation.
i 2 m 1 r 2 ,r 3
all Only aprincipal whois grantedbothr
2 andr
3
rightscan
invoketheoperation.
i 2 m 2 r 2 ,r 3 , r 4
all Only a principal who is granted all r
2 ;r 3 ;r 4 rights can
invoketheoperation.
i 3 m 1 r 1 ,r 2 ,r 3 ,r 4
any Any principal who is grantedeither ofr
1 ;r 2 ;r 3 ;r 4 rights
caninvoketheoperation.
Table2: RequiredRightsMatrix
Principal GrantedRights
Domains d 1 d 2 p 1 r 1 r 2 p 2 r 6 r 1 p 3 r 2; r 3 r 1 p 4 r 1 ;r 2 ;r 3 r 1 ;r 2 ;r 3 ;r 4
Table4: GrantedRightsPerPrincipal
2.2 CORBAProtection State
Congura-tion
WesummarizetheabovedescriptionoftheCSAC
mod-el by dening the protection state conguration of a
CORBAsystem:
Denition2.1 A conguration of a CORBA system
protection state is the thirteen-tuple (A, IM, O, R, D,
C, RRM, DS, IDM, GRM, eectiverights, combine,
in-terface operation)interpretedasfollows:
Aisthesetofprivilegeattributes.
IM is the set of operations uniquely identied by
interfacesthat theyaredened on.
O isasetof distinguishableinterfaceinstances.
Ristheset ofrights.
D istheset ofaccesspolicy domains.
RRM is the required rightsmatrix, with arow for
everyinterfaceoperationfromIM andtwocolumns.
Fortherstcolumn(RequiredRights),wehave[IM,
Rights] R. For the second column (Combinator),
wehave[IM,Combinator]2C.
DS =fi,dgisasetofdelegationstates.
IDM is thematrixofdomain membership for
inter-face instances with arow for everydomain from D
andacolumnforeveryinterfaceinstancefromO.We
denotethecontentsof(D,O)cellofIDM by[D,O].
Wehave[D,O]fT,Fg 8
,[d;o]==T =)o2d.
GRM is the granted rights matrix, with a row for
everyattributefromAandacolumnforeveryaccess
policydomainfromD.Wedenotethecontentsofthe
(A,D)cellofGRM by[A, D].Wehave[A,D]R.
eectiverights: D2 A !2 R ,afunctionmapping aset a 1 ;a 2 ;:::a l
of privilege attributes (where81<
i<l:a i 2A) inadomaind j 2D to aset ofrights r 1 ;r 2 ;:::r p (where8i;1<i<p: r i 2R )that arein
eect forthegivenset ofattributes.
combine: 2 D 2 R !2 R
,afunctionmappingsetsof
rightsreturnedfromeective rightsforeverydomain
in D theinterfaceinstance is amember of, to aset
ofeectiverights.
interfaceoperation: MO !IM,afunction
map-pinganoperationnamem andaninterfaceinstance
o2O intoaninterfaceoperationuniquelyidentied
ontheinterface,whicho implements.
2
grantedrightsforeachattributeinalldomainstowhicho
belongs. It combinesthose rightsaccordingto its
imple-mentation and returns eective rights for each domain.
Resultsreturned from eective rights serveas input
pa-rametersfor thefunction combine. The lattercombines
them according to its implementation. Rights returned
bycombine are checkedagainstRRM. Ifthematch
suc-ceeds,thenaccessisgranted. Otherwise,accessisdenied.
Table 5showswhat operationscan beinvoked by the
principals from our example. For each domain, an
ac-Principals Operations Domains d 1 d 2 p 1 i 1 m 1 ,i 1 m 2 i 1 m 2 p 2 - i 1 m 1 ,i 1 m 2 p 3 i 1 m 2 ,i 2 m 1 i 1 m 1 ,i 1 m 2 p 4 i 1 m 1 ,i 1 m 2 ,i 2 m 1 i 1 m 1 ,i 1 m 2 ,i 2 m 1 , i 2 m 2 ,i 3 m 1
Table5: OperationsthataPrincipalCanInvoke
cess matrix from [Lam71], such asin Table 6, could be
constructed. Subjects Objects i 1 i 2 i 3 p 1 i 1 m 2 p 2 i 1 m 1 ,i 1 m 2 p 3 i 1 m 1 ,i 1 m 2 p 4 i 1 m 1 ,i 1 m 2 i 2 m 1 ,i 2 m 2 i 3 m 1
Table6: AccessMatrixforDomaind
2
Threegeneralobservationsareworthnotingforan
ac-cess matrix constructed for any CS system. First,
sub-jectscannot be objects,i.e. the CORBA access control
modeldoesnothavetheconceptofoperationson
princi-pals. Itonlyhastheconceptofoperationsoninterfaces,
whichareobjectsaccordingtotheterminologyofthe
ac-cessmatrix[Lam71]. Second,sincei
k m p i l m q , k
l^pq(i.e. just pqisnotenoughfori
k m p i l m q ),
as in Table 6, the semantics of operations in a general
casemightbedierent. Thus,foreachsubjects and
ob-jecto,thecontentofcell[s,o]isspecictotheobject,i.e.
nooperationspermittedononeobjectcould be
permit-tedonanotherobjectbecauseoperationsaresemantically
dierent for every interfaceunless interfaces are related
ed by the same object in the access matrix; therefore,
implementations ofthe sameinterfaceare
indistinguish-ablefromtheaccesscontrolpointofview. Thisisoneof
thereasonspolicydomainsareimportantintheCORBA
accesscontrolmodel.
3 Support of RBAC by the
CORBA Access Control Model
AmongthefourRBACreferencemodelsdenedby
Sand-huetal[SCFY96],RBAC
0
isthebasemodel. Itrequires
onlythatasystemhasnotionsofusers,roles,permissions
andsessions. Therearenoconstraintsontheassignment
of permissions to roles and users to roles. RBAC
1 has
hierarchiesofrolesinadditiontoeverythingRBAC
0 has.
RBAC
2
hasconstraintsontheassignmentofuserstoroles
andpermissionstorolesinadditiontoeverythingRBAC
0 has. RBAC 3 combinesRBAC 1 andRBAC 2 . Inthis
sec-tion, we dene RBAC
0
and RBAC
1
using the language
ofDenition 2.1 of the CORBAprotection state
cong-uration. This will help us show the correctness of our
approachtoconguringaCORBAsystemforsupporting
variousRBACmodels.
3.1 RBAC
0
: Base Model
ForthebasemodelRBAC
0
,thefoursetsofidentitiesare
represented in CS as follows: 9
Users in RBAC map to
usersin CS; Roles are representedby set A of privilege
attributesoftyperole;Permissionsareequivalenttothe
setofrightsRinCS;Sessionsareequivalenttoprincipals,
whicharenothingbutsetsofsecurityattributes,fromCS
ACpointofview.
RBAC
0
denition(reprintisavailableinAppendix)in
thelanguageof CSisformallydenedasfollows:
Denition3.1
U,A,R,P (users,attributesoftyperole,rights,and
principals, respectively)
PARA,amany-to-manyassignmentofgranted
rightsto securityattributesoftyperole relation.
UA UA, a many-to-many user to security
at-tributesoftyperole assignmentrelation.
9
WedonotmentionCSACdomainsbecause,asitwillbeshown
i
tothesingleuseruser(p
i
),constantfortheprincipal
lifetime,and
roles : P !2 A
,afunctionmappingeachprincipalp
i
to aset ofprivilege attributes oftyperole roles(p
i )
f a j (user(p
i
), a) 2Ag and principal p
i has the grantedrights S a2roles(pi) fr j(r,a)2PAg 2
It is easy to see that the denition describes a
sys-tem compliant with the RBAC
0
denition provided in
[SCFY96]. Given the denition, we will show how a
CORBA protection system specied by a conguration
language from Denition 2.1 could be used to
imple-ment a security system compliant to this denition of
RBAC
0
. PA relation is specied by grantedrights
ma-trix GRM. UA relation is managed by user
administra-tors in CS that dene what values of attributes of type
role are assigned to users. However such
managemen-t functionality is beyond the scope of CS specication,
which means that functionality dened by UA relation
is implementation-specic. An implementation of
Prin-cipalAuthenticator 10
initializesnew principal credentials
with security attributes according to UA. An example
is provided in Table 1, where attributes a
1
through a
6
have the type role. The value of the principal's
privi-lege attribute of the type AccessId is equivalent to the
returnvaluefromthe functionuser. An implementation
of PrincipalAuthenticator should initializeprincipal
cre-dentialsaccordingto the function roles. Sincea userin
RBAC
0
can activate any subset of roles the user is
as-signedto,implementationofUAensuresimplementation
ofRBAC
0
. Thus,wehaveshownthat allrelations,
func-tionsand sets speciedin Denition 3.1 canbedirectly
supported by CS-compliant implementations. In order
foraCSimplementationtosupport RBAC
0
itshould:
1. complywithCSstandard,and
2. provideameansto administrateuser-to-role
assign-mentrelationUA,and
3. provide a means for users to select through
User-Sponsor aset ofroleswithwhich theywouldliketo
activatethenewprincipal,and
10
AsitwasdescribedinSection2,aPrincipalAuthenticator
con-ductsthe actualauthenticationand createsCredentialsobjectfor
principal credentials containing privilege attributes
oftyperole accordingto relationUA, and
5. implement PrincipalAuthenticator which creates
principal credentials containing one and only one
privilege attributeoftypeAccessId.
AstraightforwardimplementationofRBAC
0
inCSwould
betheonethatusesprivilegeattributesofonlytyperole
forconstructinggrantedrightstables, such asTable3.
3.2 RBAC 1 : Role Hierarchies RBAC 1 isRBAC 0
withrolehierarchies. RBAC
1
(the
def-initionreprintis available in Appendix) in the language
ofCS isformallydenedasfollows:
Denition3.2
U, A,R, P,PA, UAand user are unchangedfrom
RBAC
0 .
R H AAisapartialorderonRcalledtherole
hi-erarchy,writtenas. Itisthesameasin[SCFY96].
roles : P !2 A
is modiedfrom RBAC
0 to require roles(p i ) f a j (9a 0 a) [(users(p i ), a 0 ) 2UA] g andprincipal p i
hasthegrantedrights S a2roles(pi) f rj(9a 00 a)[(r,a 00 )2PA] g 2
The function roles isto beimplementedand enforced
byaPrincipal Authenticator (Figure2onPage3). A
us-erprovides to a UserSponsor a set of roles which they
want the principal to be activated with. The
Princi-palAuthenticator, during the authentication phase with
theUserSponsor,createsnewcredentialsoftheprincipal.
Thecredentialshaverequestedbyuserrolesprovidedthat
theysatisfythedenitionoffunctionroles forRBAC
1 .
A valid implementation of RBAC
1
could be one that
allowsauserto specifyanyrolejuniorto thosetheuser
isamemberof. Inthiscase,animplementationof
Prin-cipalAuthenticator activatesall roleswhichare juniorto
thespeciedrole.
Inorder for a CS implementation to support RBAC
1
itshould:
1. implementRBAC
0 ,and
principal credentials containing privilege attributes
ofthetyperole accordingto relationsUAand RH,
aswellasthefunctionroles.
3.3 RBAC
2
: Constraints
ConstraintsinRBACarepredicatesthatapplytoUAand
PArelationsandtheuser androlesfunctions([SCFY96]).
ConstraintsonUA relationaretobeenforcedbyan
im-plementationofuseradministratortools. Constraintson
thefunctionsuser androlesaretheresponsibilityof
Prin-cipalAuthenticator implementation. Constraints on PA
relationaretobeenforcedbyanimplementationof
secu-rityadministratortools.
In order for aCS implementation to support RBAC
2
itshould:
1. implementRBAC
0 ,and
2. implementsupportofconstraintsonUArelationuser
administratortools,and
3. implement PrincipalAuthenticator with support of
constraintsonfunctionsuser androles,and
4. enableenforcementofconstraintsonPArelationby
securityadministrationtools.
3.4 RBAC 3 : RBAC 1 + RBAC 2 RBAC 3 is a combination of RBAC 1 and RBAC 2 along
withpossiblyadditionalconstrainsontherolehierarchy.
ItcanbeimplementedinCSaswell. Obviously,inorder
foraCSimplementationtosupport RBAC
3 itshould: 1. implementRBAC 1 , 2. implementRBAC 2 ,and
3. implementpossibleadditionalconstrainsontherole
hierarchy.
Requirements for support of RBAC
1
and RBAC
2 by
CORBA Security service implementation have been
al-readydiscussed. Implementationofadditionalstatic
con-strainsontheRBAC
1
rolehierarchyistobedonebyuser
administratortools. Forthesupportdynamicconstrains,
additionalfunctionalityintheimplementationof
Princi-palAuthenticator is required,in additionto the
adminis-Toillustrate thepointsmadeinthissection,wedescribe
aprotectionstateofaCORBAsystemdenedby
Deni-tion2.1that implementsanexamplerole hierarchy. We
use an example hierarchy from [SP98] shown in Figure
3. WewillshowhowaCORBA-baseddistributedsystem
couldbeconguredto supportRBAC
1
withan example
hierarchyshownonFigure3andtoprotectaccessto
im-plementations of CORBA interfacesshown in Figures 4
and5. Thefollowingaccesscontrolpoliciesdescribewhat
Figure4: ExampleCORBAInterfaces
Figure5: EmployeeInterface
actionsareallowed. Allother actionsaredenied.
1. Anyonecanlookupanemployee'snameand
experi-ence.
2. Everyone in the engineering department can get a
description of and report problems regarding any
project.
3. Engineers, assigned to projects, can make changes
andreviewchangesrelatedtotheirprojects.
Production
Engineer 1
(PE1)
Quality
(QE1)
Engineer 1
Production
Engineer 2
(PE2)
Quality
Engineer 2
(QE2)
Director (DIR)
Project Lead 2 (PL2)
Project Lead 1 (PL1)
Employee (E)
Engineering Department (ED)
Engineer 2 (E2)
Engineer 1 (E1)
Project 2
Project 1
Figure 3: AnExampleRole Hierarchy(from[SP98])
5. Productionengineerscancreatenewreleases.
6. Projectleaderscancloseproblems.
7. The director can manage employees (assign them
to projects,un-assign them from projects, add new
recordstotheirexperience,andre)andclose
engi-neeringprojects.
Wedenethateective rights returnsaunionofgranted
rightsper attribute. We dene that combine returns a
unionofrightsgrantedineachdomain.
Single AccessPolicy Domain Solution
In order to implementthe role hierarchyin CS without
using access policy domains, we introduce two new
in-terfacesEngineeringProject1 andEngineeringProject2,as
shown in Figure6. Thefollowingcongurationofa
A =fe, ed,e1, e2, pe1,pe2, qe1,qe2, pl1, pl2,dirg.
All theseattributeshavetyperole.
IM =fEmployee::getname,
Employee::assignto project,
Employee::unassignfromproject,
Employee::addexperience,
Employee::getexperience,Employee::re,
EngineeringProject1::inspectquality, EngineeringProject1::makechanges, EngineeringProject1::reportproblem, EngineeringProject1::reviewchanges, EngineeringProject1::close, EngineeringProject1::closeproblem,
EngineeringProject1::createnewrelease,
EngineeringProject1::getdescription,
EngineeringProject2::inspectquality,
Figure6: EngineeringProject InterfaceHierarchy
EngineeringProject2::reviewchanges,
EngineeringProject2::close,
EngineeringProject2::closeproblem,
EngineeringProject2::createnewrelease,
EngineeringProject2::getdescriptiong.
Wedonotuseanyimplementationsofinterface
En-gineeringProject. Onlyderivedinterfacesare used.
O=fe,ed,e1,e2,pe1,pe2,qe1,qe2,pl1,pl2,dir,
pr-j1,prj2g. prj1 isaninstanceofEngineeringProject1,
and prj2 is an instance ofEngineeringProject2. All
other elements of O are instances of interface
Em-ployee.
R =fgn,atp,ufp, ae,ge, f,mc1,rc1,iq1,rp1,cp1,
cnr1,gd1,c1,mc2,rc2,iq2,rp2,cp2,cnr2,gd2,c2g 11
D =fd1g
C =fallg{weuseonlyonecombinator.
RRM isshowninTable7. Weomittedcolumnwith
rightscombinatorsbecauserequiredrightsforall
op-erationshavethesamecombinator{\all". 12
DS =fi,dg
IntheIDM,allinterfaceinstancesareinmembersof
theonlyaccess policy domain.
Employee::getname gn
Employee::assignto project atp
Employee::unassignfrom project ufp
Employee::addexperience ae
Employee::getexperience ge
Employee::re f
EngineeringProject1::getdescription gd1
EngineeringProject1::inspectquality iq1
EngineeringProject1::makechanges mc1
EngineeringProject1::reviewchanges rc1
EngineeringProject1::reportproblem rp1
EngineeringProject1::closeproblem cp1
EngineeringProject1::createnewrelease cnr1
EngineeringProject1::close c1
EngineeringProject2::getdescription gd2
EngineeringProject2::inspectquality iq2
EngineeringProject2::makechanges mc2
EngineeringProject2::reviewchanges rc2
EngineeringProject2::reportproblem rp2
EngineeringProject2::closeproblem cp2
EngineeringProject2::createnewrelease cnr2
EngineeringProject2::close c2
Table 7: Required Rights Matrix for the Solution with
SingleDomain eectiverights( d j , a 1 ;a 2 ;:::a l ) S ai;1il f r j r2GRM[a i , d j
] g { union of granted rights per
at-tribute. combine(r 1;d1 ;r 2;d1 ;:::r l;d1 ,..., r 1;dp ;r 2;dp ;:::r m;dp ) S frjr2fr 1;d1 :::r m;dp
gg{unionof rightsgranted
in eachdomain.
TheCORBAprotectionsystemcongurationdescribed
above allows enforcement of the sample policies listed
on Page 8. For example, a lead of project 1 with role
pl1activated is ableto invoke operationsget name and
getexperience on all implementations of interface
Em-ployee as well as all but close operations on all
imple-mentationsofinterfaceEngineeringProject1.
11
Weusedrstlettersofeachoperationtocreateacorresponding
right.
12
Wecould haveused \any" aswell. When anoperation's
com-e gn,ge ed gd1,gd2,rp1,rp2 e1 mc1,rc1 pe1 cnr1 qe1 iq1 pl1 cp1 e2 mc2,rc2 pe2 cnr1 qe2 iq1 pl2 cp1
dir atp,ufp,ae, f,c1, c2
Table8: GrantedRightsMatrixforSingleDomain
Solu-tion.
From observingthe congurationof theCORBA
pro-tectionsysteminthissolution,signicantadministrative
overhead could be noticed. The overhead is due to the
gratuitous use of a separate interface
(EngineeringPro-ject(1,2)) perproject . This is becausewepurposefully
limitedoursolution toasingle accesspolicy domain. It
could beeasily shown how the unnecessaryredundancy
of protectionsystemcongurationdata iseliminated by
using access policy domains and ahierarchyofsuch
do-mains. Weomitthedescriptionofasolutionwith
multi-pledomainsdueto spacelimitation.
4 Conclusions
Inthispaper,weprovidedadenitionofprotection
sys-temcongurationforCORBASecurityservice(CS).We
dened RBAC
0
and RBAC
1
models in the language of
CS and described how RBAC
0 -RBAC
3
could be
imple-mentedin CS.Wediscussed whatfunctionalityneedsto
be implemented, besides compliance with CS standard,
inorder tosupport RBACmodelsbyCS.Weillustrated
thediscussionwithasingleaccesspolicydomainexample
ofCS protectionsystemconguration,which supportsa
samplerole-hierarchyandaccesspolicies.
Implementations compliant with the CS specication
cansupportRBAC
0
{RBAC
3
. However,additional
func-tionality non-specied by CS is required.
Implemen-tations of PrincipalAuthenticator interface and
User-Sponsor need to be aware of roles and their
hierar-chies (RBAC
1
). To support constraints (RBAC
2 ), a
PrincipalAuthenticator hastoenforcecorresponding
con-straints. Tools to administer user-to-role and
role-to-Theworkpresentedin thispapersetsupaframework
forimplementingaswellasforassessingimplementations
ofRBACmodels usingCS. Itprovidesdirections forCS
developersto realizing RBACin theirsystems. It gives
criteria to users for selecting such CS implementations
thatsupportmodelsfrom theRBAC
0 -RBAC
3 family.
Acknowledgements
We are grateful for very helpful comments from the
anonymous reviewers. We also thank the OMG
securi-ty special interestgroup (SecSIG) for feedback received
during thepresentation, in December1997, on
support-ing RBAC in CORBA Security. Special thanks to Bob
Blakleyfrom DASCOMInc. forinsightful commentson
therstdraftofSection2.
References
[ACM95] ACM. Proceedings of the First ACM
Work-shop onRole-BasedAccessControl,
Gaithers-burg,Maryland, USA,November1995.
[ACM97] ACM. Proceedings of the SecondACM
Work-shop on Role-Based Access Control, Fairfax,
Virginia,USA,November1997.
[ACM98] ACM. Proceedings of the Third ACM
Work-shop on Role-Based Access Control, Fairfax,
Virginia,USA,October1998.
[Awi97] Roland Awischus. Role based access control
withsecurityadministrationmanager(SAM).
In Proceedings of the SecondACM Workshop
onRole-BasedAccessControl [ACM97],pages
61{68.
[Bar95] JohnBarkley. Implementingrole-basedaccess
controlusingobjecttechnology.InProceedings
of the First ACM Workshop on Role-Based
AccessControl [ACM95],pages93{98.
[BC98] John Barkley and Anthony Cincotta.
Man-aging role/permission relationshipsusing
ob-jectaccess types. InProceedings of the Third
ACMWorkshoponRole-BasedAccessControl
[ACM98],pages73{80.
com-306,TheMITRE Corporation,Bedford,MA,
USA,March1975.
[Dep98] Department of Health and Human Services.
Security and Electronic Signature Standards;
ProposedRule,August1998.45CFRPart142.
[ES95] Jeremy Epstein and Ravi Sandhu. NetWare
4as an example of role-based access control.
In Proceedings of the First ACM Workshop
onRole-BasedAccessControl [ACM95],pages
71{82.
[Giu98] LuigiGiuri.Role-basedaccesscontrolinJava.
In Proceedings of the Third ACM Workshop
onRole-BasedAccessControl [ACM98],pages
91{99.
[Kar96] Gunter Karjoth. Analysisof authorization in
CORBA security. Technical report, IBM
Re-search Division, Zurich Research Laboratory,
December1996.
[Lam71] ButlerLampson.Protection.InIn5th
Prince-ton Symposium on Information Science and
Systems,pages437{443,1971.
[Mey97] WilliamJ.Meyers.RBACemulationon
trust-ed DG/UX. In Proceedings of the Second
ACMWorkshoponRole-BasedAccessControl
[ACM97],pages55{60.
[Not95] LouAnna Notargiacomo. Role-based access
controlinORACLE7andTrustedORACLE7.
In Proceedings of the First ACM Workshop
onRole-BasedAccessControl [ACM95],pages
65{69.
[Obj98] Object Managment Group. CORBAservices:
Common Object Services, July 1998. OMG
documentnumber: formal/98-07-05.
[SCFY96] Ravi Sandhu, Edward Coyne, Hal Feinstein,
andCharles Youman. Role-basedaccess
con-trol models. IEEE Computer, 29(2):38{47,
February1996.
[SP98] RaviSandhuandJoonS.Park.Decentralized
user-role assignment for web-based intranets.
In Proceedings of the Third ACM Workshop
onRole-BasedAccessControl [ACM98],pages
tone. ObjectManagementArchitectureGuide.
JohnWiley&Sons,3edition,June1995.
[Won97] RaymondK.Wong.RBACsupportin
object-orientedrole databases. InProceedings of the
SecondACMWorkshop onRole-BasedAccess
Control [ACM97],pages109{120.
Appendix
DenitionsofRBACmodelsfrom [SCFY96]:
Denition4.1 The R BAC
0
model has the following
components:
U,R,P,andS (users,roles,permissionsandsessions
respectively),
PA P R , a many-to-many permission to role
assignmentrelation,
UAUR ,amany-to-manyusertoroleassignment
relation,
user : S ! U, afunction mapping each session s
i
tothesingleuseruser(s
i
)(constantforthesession's
lifetime), and
roles : S ! 2 R
, afunction mappingeachsession s
i
to aset ofroles roles(s
i
)fr j(user(s
i
),r)2UAg
(whichcanchangewithtime)andsessions
i hasthe permissions S r2roles(si) fp j(p,r)2PAg 2
Denition4.2 The R BAC
1
model has the following
components:
U, R, P, S, PA, UA, and user are unchangedfrom
R BAC
0 ,
RHRR is apartial order onR called the role
hierarchyorroledominancerelation,alsowritten as
,and
roles : S !2 R
is modiedfrom RBAC
0 to require roles(s i ) fr j(9r 0 r)[ (users(s i ),r 0 )2UA ]g
(whichcanchangewithtime)andsessions
i hasthe permissions S r2roles(si) fp j(9r 00 r)[ (p,r 00 )2PA ]g 2
