miera: a method for inter-enterpriserole-based authorization

7/29/2019 MIERA: A Method for Inter-EnterpriseRole-Based Authorization

1/22

MIERA: A Method for Inter-Enterprise

Role-Based Authorization

Heiko Ludwig and Luke OConnorIBM Research Division

Zurich Research Laboratory, Switzerland

Abstract

Large scale deployment of ecommerce solutions between various enterprises overpublic networks requires careful consideration of security issues. In this paper wewill address the particular problem of inter-enterprise authorization, as would berequired if for example a business process spans several organisations and data ispassed between enterprises during the execution of the process. In this paper wepropose the MIERA scheme for authorization, which can be used for both intra-or inter-enterprise authorization. MIERA makes authorization decisions based onroles, represented by anonymous role certificates. We also define an authorizationtree A(T) for a transaction of type T that determines what combination of roles can

authorize transactions of type T. In the case of inter-enterprise authorization, wecan use a hashed version ofA(T) to reduce space requirements and also to obscurethe decision procedure information in A(T), but which still permits transactions oftype T to be authorised.

1


2/22

1 Introduction

Authorization is a basic security service which provides control on who may access re-sources and in what manner. Traditionally authorization in single systems was imple-mented via an access control matrix [10] or a related concept such as access controllists [5] or capabilities [6]. These mechanisms typically assume that fine grained con-trol over resources is required, such as explicitly specifying which users can read a givenfile F, which group can write to F and so on. This approach is referred to as thesubject-object paradigm [8, 10], which specifies access control in terms of (s,o,a) triples(subject, object, access rights) and is commonly integrated quite closely with the un-derlying operating system. While this model is appropriate for single or closed systems,the subject-object paradigm is less suited to distributed and general ecommerce applica-tions for which authorization decisions are required to be based on non-local informationand credentials [19, 15]. Considering an inter-enterprise workflow application, authoriza-tion is more likely to be based on a combination of general policies, company affiliation,roles, group privileges, delegated rights, location information and possibly third partycredentials rather than on read/write file permissions for example [15, 16].

A major issue is to determine how credentials (or authorization attributes) issuedin one security domain (say from company A) are to be interpreted in another distinctsecurty domain (say company B). One solution is to use a common credential frameworkas provided by Kerberos [14, 17], OSF DCE and Sesame [9, 11] for example, whichpermit trust relationships to be specified between domains (or realms in Kerberos jargon).While such a solution is potentially feasible in controlled environments such as between

departments of the one company, or between two companies that have a close businessrelationship, the Internet and WWW are promoting ecommerce and access to serviceswhere no standard authorization attributes exist. For these environments the focus istowards service requestors providing their credentials to service providers who decide ifthe request is authorized based on the supplied credentials and a given access policy[3, 4, 2, 18]. Much of the emphasis on credentials coincides with the introduction ofpublic key cryptography [12] which permits authorities to issue statements that can bedigitally signed and verified at the time of presentation. Attribute certificates [7] are ameans of collecting authorization attributes into a format similar to the standard X.509certificate for representing public keys [1].

The approach to distributed authorization that we take in this paper is to consider themiddle ground between all service requestors and providers agreeing on common autho-rization attributes on the one hand, and service requestors processing arbitrary requestorcredentials and on the other. Also we are motivated by the authorization problem for

2


3/22

inter-enterprise transantions, say between two universities or a manufacturer and a sup-plier, where a general commerce agreement may exist between the two enterprises but

the details of each transaction must be authorised. For example consider the the sce-nario where two companies, s ay company A and company B, have a formal agreementfor making business transactions. In the context of this paper we use the term transac-tion for any legally binding action between organisations, such as an offer, an order or acancelation. We may denote the possible set of transaction types between A and B byT(A, B) = {T1, T2, . . . , T n} where for example T T(A, B) may denote

T purchase X units of product Y at price P per unit. (1)

We assume that the transaction types denoted by the set T(A, B) are general, and at theactual time when the particular transaction takes places, additional details beyond those

given in the transaction descriptions of T(A, B) must be provided. A typical situationwould be for a person UA from company A to receive a transaction of type T T(A, B)from a person UB, who purports to be from company B.

1 Let use assume that UA ispresented with a request from company B for company A to make X = 1000 units ofproduct Y = widget at price P = 1 ecu per unit. Since the request originates from apublic network, there are several security issues that UA may consider:

Should the details (X , Y , P , U A, UB) of the transactions be confidential and encodedfor integrity?

How to verify that the person UB requesting the transaction is in fact an employee

of company B?

Even if even if it is known that the person requesting the transaction is UB fromcompany B, how can it be verified that UB is in fact authorised to request such atransaction for the given values of X, Y and P?

The first two points can be addressed using standard security protocols and crypto-graphic algorithms [12]. In particular, with public key cryptography each user U canbe issued with one or several certificates [1] that can be used to demonstrate their iden-tity (and employer) through the use of digital signatures [12]. In this paper we wish toaddress the last point, that of authorization for the transaction. It may be costly for

1In the general case the interaction between companies may be between people or simply machines.For sake of clarity we will assume that the transaction is actually taking place between users UA and UB,rather than the computers of their respective companies, but the system described here can be extendedto machine-to-machine interactions.

3


4/22

both companies A and B to have UA initiate the processes to fulfill the request from UBonly later to learn that UB either made the request maliciously, made an error in the

request (only 10 rather than 1000 units are wanted), or the request should not be madeuntil next month for accounting reasons (company B has insufficient funds to pay for thetransaction this month, and no space to store the widgets). If UA and UB are acquaintedpersonally then that existing trust relationship may be sufficient for UA to accept therequest from UB as authorised. However general ecommerce will bring together people(users) who will have no prior business or trust relationships, and the transaction thenmust somehow be self-authorizing. We abstract our problem to the following: how cana transaction requester (UB) convince a transaction verifier (UA) that the requester isauthorized to request a specific transaction T? We call this the transaction authorizationproblem (TAP).

Let us assume thatUA is actually Alice and

UB is actually Bob. We expect thatthe authorization information obtained by Bob to request T is specific to his company,

and more than likely not meaningful to Alice. For example, Bob may have discussedthe transaction details with his manager and department head, and lastly someone fromthe purchasing department, who all agreed that he could request the transaction fromcompany A. Later Alice will then receive the transaction details from Bob along withsome indication that the transaction was approved by people in company B assuming theroles of manager, department head and representative of purchasing department.The transaction is then self-authorizing to the extent that Alice is prepared to believethat the consent of these three people in the stated roles constitutes authorization forthe transaction.

We then see that the TAP consists of two distinct but related problems. The firstproblem is that before Bob can send the transaction to company A, he must followlocal procedures in his company to obtain authorization for making the transaction, andprobably company B would like to automate this process as much as possible. The secondproblem is that once Bob has obtained the required authorization from his company, hemust then convey this approval to Alice in some meaningful way given that Alice is notaware of how transactions are authorized internally in company B. In fact, company Bwill probably be interested in concealing its internal authorization process from othercompanies.

While it is difficult to imagine how authorization information from company B can be

exported discreetly and meaningfully to company A, it is likely that (users from) companyA can verify digital signatures produced by (users from) company B. The supportingdata structure for signing operations is a certificate, which binds a name (key owner) toa signing verification key. Authorization attributes for the key owner could be included

4


5/22

in a certificate, but this appears to overload the notion of a certificate beyond its originalintention, and dedicated attribute certificates [7] have been introduced as a companion

authorization data structure. Nonetheless, while certificates provide a convenient solutionto the authentication problem, the problem of interpreting of authorization attributesremains even if the attributes are signed - we are simply more certain as to who createdthe attributes, not what they mean. In the example above the form of the approvalgiven to the Bobs transaction by manager, department head and representativeof purchasing department could be digital signatures verified by certificates containingthese roles as names. However, the problem of Alice interpreting these signatures asconstituting authorization remains.

In this paper we address the TAP for transactions of type T by introducing theconcept of an authorization tree A(T), which is a signed data structure produced by

the requesters company. The authorization tree is sent by the requester along withthe transaction details to the verifier such that in the act of verifying the signature onA(T), the verifier also determines that the requester is authorized to make the requestfor the transaction. Thus the only authorization semantics that the verifier need consideris that the requester is authorized to make the request if and only if the signature onA(T) can be verified. This verification is performed without regard for the identity ofthe requester, the position of the requester in their company, and the details of thetransaction itself. While this information is important, particularly to the company ofthe requester, it is implicitly encoded into the signature verification process performed bythe verifier. Thus the transaction authorization problem is addressed not by exportingauthorization attributes from one domain (company) to another, but by encoding the

attributes into a signature verification process that produces a universally recognizableauthorization decision: the request is authorized if and only if the signature on A(T)verifies. Returning to our example, Bob will send the transaction details to Alice alongwith A(T). The A(T) will encode the information that people of company B acting in theroles manager, department head and representative of purchasing department canjointly authorize transactions of this type. The A(T) may also encode that the CEOalone or two vice presidents can also authorize the transaction, but this additionalauthorization information need not be apparent to Alice.

The scheme described in this paper for addressing the TAP based on authenticationtrees is called MIERA (pronounced meer-rah), which is an abbreviation of Method for

Inter-Enterprise Role-based Authorization. In MIERA users authorize transactions bysigning some representation of the transaction, and conversely, verifiers determine that atransaction is authorized by verifying signatures. Central to MIERA is the notion thatusers can assume roles and sign transactions to confer the authority of these roles (such as

5


6/22

department head and CEO). Which collection of roles and in what combinations canauthorize a given transaction T will be specified by the structure of A(T). The verifier

determines that a transaction of type T is authorized by checking role signatures againstthe information specified in A(T), and this checking operation is essentially checking asignature on A(T) produced by the requesters company.

An outline of this paper is as follows. In 2 we define anonymous role certificateswhich permit users to sign in the capacity of a role without revealing their name, whichin most cases is incidental to the authorization process. The structure of the authorizationtree A(T) is described in 3, along with a method to hash and sign A(T). As explainedlater, a signed hashed version of A(T) must be made available to the verifier. In 4, theoperation of the MIERA scheme is described in detail using anonymous role certificatesand authorization trees. We defer discussion of the MIERA scheme until 4 and 5 gives

details of a Java MIERA prototype. Finally conclusions and further work are presentedin 6.

2 Anonymous Role Certificates

We assume that company B has defined a set of roles R = {R1, R2, . . . , Rm}, such asuser, manager and department head, and that each user U in company B is assignedone or several roles UR RB. The tasks or activities that a user U can perform willbe directly related to the authority of the roles that U can assume. For our purposeswe assume that each user U has a X.509 public key certificate CertCA(U), that contains

their name, public key and other fields, signed by some local certificate authority CA.There are several possible formats for CertCA(U), and we assume the X.509 (version 3)certificates [1].

As X.509v3 certificates contain extension fields for general information such as ane-mail address, alternatives to X.500 names, and policy information for example, a rolecould be included as an extension field. Let CertCA(U, R) be a certificate for U containingan extension for role R. User U is then able to authorize a request or action T basedon the authority of role R by signing some representation T of the activity with theprivate key associated with CertCA(U, R). A verifier can determine the correctness ofthe signature using CertCA(U, R) and further, an authorization decision can be based

on the role extracted fromCert

CA(U, R

). With certificates of the formCert

CA(U, R

)it is clear that the verifier can link the signers name and role since this informationis unambiguously bound to the same certificate. If the verifier belongs to company A(different to company B), we expect that any authorization decision will be based on R

6


7/22

rather than on the name of U. Further, company B may consider the fact that U canauthorize activities in the capacity of role R as private information. Thus to break the

link between the name of U and the authority of U based on role R we use the notionof an anonymous role certificate CertCA(RU) for user U, which is an X.509v3 certificatewith the following changes:

the name field represents a fictitious user ;

there is an extension field containing the role RU of U ;

there is an extension field that contains a forward reference from CertCA(U) toCert(UR) ;

The forward reference for example may take the form of E(B, U, passwd) which denotes

the public key encryption of the concatenation of U and a password by companys Bpublic key or the local CAs public key. The forward reference is a mechanism forcompany B to be able to identify the owner of a role certificate when the need arises.If U has several roles then there will be a role certificate for each role. It is importantto note that each role certificate has a public and corresponding private key so thatusers may authorize activities in the capacity of role R without revealing their identity(name). Thus each user will have at least two certificates, a standard X.509v3 certificateCertCA(U) that binds their name to a public key, and then an anonymous role certificateCertCA(RU) that binds their role to a public key. The link between CertCA(U) andCertCA(RU) can be resolved by the company of U using the forward reference, but given

CertCA(U, R) there is no obvious way to determine CertCA(UR) or the identity of U.We will say that a signature produced by a private key associated with a role certificateCertCA(RU) is a role signature.

For a user U to obtain authorization to request particular transaction T, let companyB have authorization policy which states that U must obtain approval from their man-ager and their department head. In practice the policy can be implemented as U creatingan digital representation D(T) of T and then obtaining signatures on D(T) from theirmanager and then their department head. Using anonymous role certificates it is clearthat certificates denoting manager and department head could be created, and rolesignatures on D(T) for manager and department head could be created. However when

U presents a verifier V with D(T) and role signatures on D(T) for the roles managerand department head, V has insufficient information to determine if the transaction isauthorized since the anonymous role certificates do not indicate that the manager signa-ture is from Us manager or that the department heads signature from Us department

7


8/22

head. The potential drawback of anonymous role certificates as defined is that they donot give information about the relative roles between two users. We will call roles such

as user, manager and department head absolute roles, while roles such as managerof user U, or department head of user U will be called relative roles. As defined aboveanonymous role certificates only implement absolute roles, and additional mechanisms arerequired to implement relative roles, which seem to provide a more natural interpretationof authorization policy.

However we do not consider absolute roles to be a severe restriction on the MIERAmethod of authorization, which should become apparent as the details of MIERA areexplained below. Recall that the approach of MIERA is to avoid having the verifierdeal with any semantics associated with the authorization information presented by therequester: the only required semantics is that if a given signature on the transaction

verifies, then the requester is defined as being authorized to make the transaction. Infollowing this approach the verifier need not be concerned with the nature of the rolesused in the requesters company, and whether the presented authorization informationreflects absolute or relative roles.

The potential problem is that requester may circumvent their companys authorizationpolicy by exploiting semantic differences between absolute and relative roles which theverifier cannot detect. So the requester may have obtain to signatures on D(T) frompeople who are not the requesters manager or department head, but nonetheless haveanonymous role certificates that allow then to sign in these roles. There are technicalsolutions to this problem but it should be clear that additional fields similar to the forwardreference could be embedded in anonymous role certificates to reflect the relativeness of

roles. We note that an obvious deterrent to this type of cheating by the requester isto note that the forward reference can always be used to resolve which user made aparticular role signature, so that colluders can always be identified.

3 Authorization Trees

Using the anonymous role certificates defined in 2, we now proceed to define a role-based structure A(T) that defines which role signatures are required to deem a requestfor transaction of type T to be authorized. Further, a modified version of A(T) will be

made available to the verifier for the purpose of deciding if a requested transaction oftype T is authorized. Thus A(T) will be used by the requester for preparing a transactionand by the verifier for authorizing a transaction.

Recall that for each transaction T we assume that there is some (electronic) document

8


9/22

T

PT,1

R3 R4 R5

Transaction Type

Permission Sets

RolesR1 R2

PT,2

R6

PT,3

Figure 1: An authorization tree for Example 3.2.

D(T) representation of T, which will basically be some template specifying the (manda-

tory and optional) information to be provided by the requester. Also we let D(T, U)denote D(T) after the requester (some user U) has supplied the requested information(D(T) may be an HTML form, and D(T, U) after U has populated the fields of theform). We assume for any transaction type T that it is possible to distinguish betweenthe details of transaction into D(T, U) and the authorization information for T, whichwill be stored separately in another structure A(T).

Example 3.1 Consider the task T = travel request and let D(T) be a HTML form thatindicates that the user U making the travel request must provide their name, department,reason for travel, travel details, and costings. When the user U has decided on this

information, this information plus D(T) is denoted as D(T, U). Assuming that travelrequests require signatures on D(T, U) from the user U, a manager (M) and a departmenthead (DH), then A(T) will encode information about the roles user, manager anddepartment head. 2

9


10/22

In Example 3.1, we will call the set PT,1 = {U,M,DH} a permission set for transac-tion T = travel request. In this case the transaction T has only one permission set,

but in general a transaction may have several permission sets which we will denote asPT,1, PT,2, . . . , P T,k . Each permission set consists of a set of roles (that is, PT,i R,potentially a multi-set), with the meaning that any user U is authorised for a transactionof type T represented by D(T, U), if for some permission set PT,i = {R1, R2, . . . , Rm} ofT, m users sign D(T, U) where the union of the roles in the corresponding anonymousrole certificates for these signatures are exactly the set PT,i . The purpose ofA(T) is toencode the permission sets PT,i of T.

Permission sets PT,i then represent sets of roles whose joint authority is deemedsufficient to authorize transactions of type T. We will represent the permission setsPT = {PT,1, PT,2, . . . , P T,k} with a 2-level tree as follows. For each transaction type T, an

authorization treeA

(T

) is created such that there arek

nodes at level 1 from the root,corresponding to the k permission sets PT = {PT,1, PT,2, . . . , P T,k} for transaction typeT. The nodes at level two are leaves, and represent the roles of each permission set.

Example 3.2 If the permission sets PT for T are PT,1 = {R1, R2}, PT,2 = {R3, R4, R5}and PT,3 = {R6}, then A(T) has two levels where level 1 represents PT,1, PT,2 and PT,3 with3 nodes and each PT,i has the same number of leaves as there are roles in its permissionset. So for example then PT,1 would have two children (both leaves) representing R1 andR2, as shown in Figure 3. 2

Since T is considered authorized if for at least one permission set PT,i , signatures are

acquired for each role in PT,i , we may consider the nodes representing the PT,i as ANDnodes and the root ofA(T) as an OR node. By an AND node we mean that all children ofthe node must agree to the request D(T, U) (all roles of a permission set must sign) whilean OR node means at least one child must agree to the request D(T, U) (at least onepermission set must jointly sign). Alternatively, we may interpret A(T) as a disjunctiverepresentation of the roles that can authorize task T, such that A(T) of Example 3.2could be written as A(T) = R1R2 + R3R4R5 + R6.

The authorization tree A(T) can be thought of as being an example of a Merkle hash-tree [13]. We can then define a hashing process H(T) which produces a hash value forA(T), and we can define a signature on A(T) as being the signature on the hash valueproduced by H(T). The hash H(T) of A(T) is computed in the following standard way.Let h() be a hash function such as SHA-1 [12]. If a leaf represents role Ri, then labelthe leaf as h(Ri), and repeat this for all leaves. Then at level 1, label each node with thehash of the concatenation of the labels for its children; lastly, label the root of the tree

10


11/22

h(PT,1) =h(h(R1)|h(R2))

h(R3) h(R4) h(R5)

Transaction Type

Permission Sets

Rolesh(R1) h(R2) h(R6)

h(PT,2) =h(h(R3)|h(R4)|h(R5))

h(PT,3) =h(h(R6))

h(T) =h(h(PT,1)|h(PT,2)|h(PT,3))

Figure 2: The structure of a hashed authorization tree for Example 3.2.

by the hash of the concatenation of the labels for its children, and let this hash be H(T).This process is shown in Figure 2.

4 The MIERA Scheme

As in the introduction, we assume that there are two companies A and B who have agreedupon a set of transaction types T(A, B) = {T1, T2,...,Tn} that they will cooperate on,such that T T(A, B) will be represented by the template D(T). For a transaction typeT, assume that UB from B will request UA from A to perform T, and that UA should beassured that UB is authorised to make such a request. In fact we will denote UA as V to

emphasize that UB is the verifier, and simply denote UB by U.

11


12/22

RA: for each user U, assign U role RU R ;

CA: for each user U, create and store CertCA(RU) ;

T A: for each transaction type T do

create the transaction template D(T);sign D(T) to yield SignTA(D(T))

PT,i R, 1 i tk ;

hash the authorization tree to yield H(T) ;

sign H(T) to yield SignTA(A(T)) ;

store SignTA(A(T)) in a public company database P D;store D(T),SignTA(D(T)), A(T) in a private company database CD;

od

Figure 3: MIERA role assignment and creation of permission sets for transactions. HereRA denotes the role administrator, CA denotes the certificate authority, and T A thetransaction administrator.

4.1 MIERA setup at the Requester Company

The required initialisation at the company B is shown in Figure 3. Users are assignedroles R = {R1, R2, . . . , Rm} by the (user user with the role) Role Administrator (RA),and corresponding anonymous role certificates are created by the local Certificate Au-thority (CA). The transaction administrator (T A) is responsible for creating transac-tions and assigning the correct (authorizing) permission sets to each transaction. Foreach transaction T, the transaction authority T A of company A defines permission setsPT = {PT,1, PT,2, . . . , P T,k} with respect to company roles as in Figure 3. In Figure 3,PT,i R denotes the assignment of a subset of roles to the multi-set PT,i (a permis-

sion set is a multi-set since it may require signatures from two different users assumingthe same role).

By creating a transaction we actually mean the creation of D(T) The format of

12


13/22

D(T) should of been previously agreed on by companies A and B. of the electronicform/template of T which we denote as D(T), and also its authorization tree A(T).

The T A then signs D(T) and A(T) to give SignTA(D(T)) and SignTA(A(T)), whereSignTA(A(T)) is simply the T As signature on H(T) as defined in 3. Then the T A storesD(T),SignTA(D(T)) and A(T) in the private compnay database CD, while SignTA(A(T))is stored in a public database P D accessible by all potential verifiers. We also assumethat the CA and T A have well-known certificates so that signatures they produce canbe easily verified.

In summary then, at the requesting company B users are assigned roles with corre-sponding certificates for signing in these roles, and the transaction authority creates andsigns transactions with corresponding authorization trees. The anonymous role certifi-cate of each user CertCA(RU) is made available by the certificate authority CA, and the

signed authorization treeSign

TA(A

(T

)) is also made available for each transactionT

.

4.2 Preparing a Transaction at the Requester Company

Imagine now that a requester (user U) of company B wishes to prepare an authorizedtransaction for processing by some verifier V at company A The steps followed by U areshown in Figure 4. First U retrieves the template D(T) of T from the (companys) privatedatabase CD, and verifies its correctness by checking the T As signature on D(T). If the signature is correct U then supplies the required transaction information for D(T) toobtain D(T, U), and then signs D(T, U) with its role UR to give SignUR(D(T, U)). Herewe assume that any transaction request by U initially requires the role signature of U,

which should be reflected in the permission sets for T. U then retrieves the authorizationtree A(T) for T from the private database, and again checks the signature produced bythe T A. If the signature is correct U then proceeds to obtain role signatures for D(T, U).In Figure 4 the set P S, for permission set, is the set of users who have currently usedone of their role certificates to sign D(T, U). U needs to request further signatures untilP S is equal to one of the permission sets for transactions of type T. We also note thatwhen U attempts to acquire an additional signature from user U, user U may requireto see the roles and signatures of the users who have previously signed D(T, U). Thisreflects the requirement that U may not only be signing the contents of D(T, U) but alsothe existing role signatures denoted by the set P S. In figure 4 we have chosen to use a

repeat loop to represent the problem of collecting role signatures This is a simplificationof the process in practice, as for example, several users may be contacted in parallel. Wedefer the problem of finding the best strategy for contacting users and soliciting theirsignature to a special process for this task, such as a workflow system. Once the role

13


14/22

U: requires authorization for transaction T ;

retrieve D(T),SignTA(D(T)) from CD;check signature SignTA(D(T)) and exit if fails;

complete transaction details to give D(T, U) ;sign D(T, U) to give SignUR(D(T, U));

U: retrieve A(T),SignTA(A(T)) from CB;check signature SignTA(A(T)) and exit if fails;

P S = {UR} ;

U: repeat

U requests U to sign D(T, U) given current role signatures from P S;

if U signs D(T, U), P S then P S P S {UR,SignUR(D(T, U))} ;

until i, 1 i tk, PT,i P S ;

U: store D(T, U), P S and path(i, H(T));

Figure 4: User U obtaining authorization for a transaction of type T.

signatures are collected, U then stores the request D(T, U) along with the collected rolesignatures P S.

At this point the user has provided the transaction details in D(T, U) and has col-lected signatures constituting a permission set in P S. It now remains to store someadditional information which can be used to convince the verifier that P S is indeed apermission set for transactions of type T. The hashed tree H(T) will be used for this

purpose. As defined, A(T) has three levels: leaves representing roles, internal nodesrepresenting permission sets, and the root representing the union of the permission sets.For a given transaction T with k permission sets PT = {PT,1, PT,2, . . . , P T,k} let PT,i bethe permission set for which user U has obtained the role signatures with which D(T, U)

14


15/22

is to be authorised (that is, PT,i is represented in P S). Then H(T) can reconstructedfrom the k 1 hashes

path(i, H(T)) = {H(PT,1), . . . , H (PT,i1), H(PT,i+1), . . . , H (PT,k)},

knowledge of the roles in PT,i , and knowledge of the hashing process used to produceH(T). U then also stores path(i, H(T)) for later use by the verifier, as shown in the laststep of Figure 4.

Example 4.1 If for example the permission sets for T are PT,1 = {R1, R2}, PT,2 ={R3, R4, R5} and PT,3 = {R6}, and that two users representing roles R1 and R2 havesigned D(T, U) at the request of user U. H(T) can be reconstructed from the rolescertificates of R1 and R2 (which contains the roles as fields) and path(1, H(T)) =

{h(PT,2), h(PT,3)}.2

4.3 Transaction Authorization at the Verifier

When the requestor U is ready to initiate the processing of the transaction, U sendsD(T, U), P S and path(i, H(T)) to the verifier V. The process of the verifier checkingthe authorization of the transaction request is shown in Figure 5. Since the companiesof the requestor and verifier have agreed on transactions of type T, and in particular onD(T), the verifier first obtains a signed local copy of D(T) to determine that D(T, U) isformatted correctly.

Next the verifier checks the signatures in P S on D(T, U). Let us assume that the

permission set selected by the requestor was PT,i which consisted of the m roles PT,i ={R1, R2, . . . , Rm}, which means that P S should consist of m signatures on D(T, U). Weassume that the signatures in P S are appropriately formatted so that for each signa-ture SignRj(D(T, U)), the certificate CertCA(U, Rj) holding the corresponding verifica-tion key can be retrieved (from the certificate authority CA). If each such certificateCertCA(U, Rj) is valid (not expired or revoked for example), and each signature of P Sof D(T, U) verifies, then V proceeds to authorization step.

Based on checking the signatures from P S on D(T, U), the verifier can extract a list ofthe roles R1, R

2, . . . , R

t from which users acting in these roles approved the transaction.The verifier can then hash these roles to form PT,i = h(R

1, R

2, . . . , R

t), and then using

path(i, H(T)) concatenate the hashes to form H(T

), the hash of some tree. The verifierfetches SignTA(A(T)) from the public database of the requestor company, along with theT As certificate. Assuming that roles R1, R

2, . . . , R

t actually constituted the permissionset PT,i , and path(i, H(T)) were the hashes of the other k 1 permission sets of T, then

15


16/22

U: send V the message D(T, U),PS,path(i, H(T)) ;

V: verify format of D(T, U) with local copy of D(T) and exit if fails;

fetch and verify certificates CertCA(URj) for signatures in P Sexit if any certificate fails;

verify each signature on D(T, U) and exit if any signature fails ;

extract roles Rj from certificates CertCA(URj) ;hash the roles with path(i, H(T)) to form H(T) ;

fetch SignTA(A(T)) from requestor companys public database ;fetch and verify CertCA(T A) and exit if fails ;verify the signature SignTA(A(T)) using CertCA(T A) to yield H(T) ;

V: sends to U message that authorization is verified if H(T) = H(T);

Figure 5: Transaction verification with MIERA.

H(T) = H(T). Then the verification of the signature SignTA(A(T)) will produce H(T),

and the verifier determines the transaction to be authorised if and only ifH(T

) = H(T).Thus we see that verification is a two step process: check the signatures on D(T, U)

as provided in P S, and then extract the roles from these signatures and verify them forauthorization against the signed copy of A(T). The explict link between the two steps isthat the roles specified in the certificates used to sign D(T, U) are the same roles that willbe used to form a candidate hash tree corresponding to H(T), and hence the signatureon A(T). Checking the signatures on D(T, U) demonstrates the approval of a permissionset P S on the transaction, while checking H(T) against A(T) demonstrates the approvalthe T A on the given permission set.

16


17/22

5 The MEIRA Demonstrator

The MIERA schema has been implemented as a Java package that can be used bydevelopers to apply the schema to an e-business system. The implementation uses Java1.2 and is based on the security mechanisms of Suns Java Cryptography Extension (JCE).Reflecting the underlying model, the implementation provides two main structures forprovider and requester applications, the transaction package and the authorisation treepackage. A Demonstrator has been built that illustrates to a user how MIERA worksand also provides a reference implementation that shows how to use the MIERA packagein an application.

5.1 Authorisation Tree Package

This package contains a number of different classes related to editing, transmitting andverifying authorisation trees according to the MIERA schema.

The GeneralAuthorizationTreeclass implements an authorisation tree as described inthis paper. It consists of a list of permission set nodes, which in turn contain role nodes.It also contains an attribute for the name of the transaction type T that it providesthe authorisation structure for. This class provides methods for editing and viewingthe tree. It is intended to be used by the transaction authority and users that create atransaction to be sent to a provider. Also, the GeneralAuthorizationTree class providesa method to create an instance of PublisizableAuthorizationTree. This is the equivalentof the GeneralAuthorizationTree but using hashes of role names rather than the plain

role names. This class also provides a method for deriving the tree information that issent to the provider, i.e. path(i, H(T)), i being the chosen permission set.

A TransmissableAuthorizationTreeinstance is an authorisation tree that only containsthe hashes of the permission that were not used and the role hashes of the used permissionset. In addition, it provides a method for creating an ASCII representation that can bestored and transmitted to a provider.

The VerificationTree class provides methods that are used in a provider application.An ASCII representation of the tree - as transmitted by a requester - can be passed toa constructor that then creates the tree structure. This class also provides a method tocompute the root hash of the tree and to verify it against the above mentioned reference

hash. For the hashing operations the AuthorizationTree package uses the SHA algorithmas provided by JCE.

17


18/22

5.2 Transaction Package

The Transaction package consists of the Transactionclass and its two main components,the FormContainer that contains the signed content of the transaction, and the TreeCon-tainer that contains the information related to the authorization tree. The FormCon-tainer and TreeContainer together contain the information that is necessary to verify theauthorisation of the transaction according to the MIERA schema. This class is intendedto be used by both, provider and requestor of a transaction. The Transaction class pro-vides methods to edit and assemble a transaction for a requester, to retrieve its elements,to create a transmittable representation of the transaction, to re-construct a transactionfrom its transmittable form, and to verify a transaction.

The FormContainer consists of a reference to a Java SignedObject that containsthe signed content of the transaction D(T) and a list of anonymous role certificates

CertCA(RU) for those roles that were used to sign the form. Using the SignedObject forthe content of the transaction makes the Transaction class independent of a particularkind of transaction content representation and therefore applicable for various kinds ofsystems. The Transaction class uses X.509v3 certificates as implemented by Javas JCE.In the current implementation the role certificates contain the role name in the namefield. The demonstrator does not provide forward references to the real user name of therole certificate.

The TreeContainer encompasses a VerificationTree field, which references an authori-sation tree that provides methods for verifying the transaction, a field for an ASCII repre-sentation of the authorisation tree, from which a VerificationTree can be re-constructed,

and the signed reference hash that is issued by the transaction authority for the giventransaction type.

The transaction can be converted by the requestor into a transmittable (ASCII) formthat can be sent using transport mechanisms such as e-mail The transmittable form ofthe transaction must contain the ASCII representation of the verification tree and thesigned content of the transaction. It may contain also the signed reference hash H(T)and the list of used role certificates. But those can also be obtained by the provider ina different way, such as using an X.500 directory service. Before the verify method canbe used, the signed reference hash and the list of used role certificates must have beenobtained. The verify method works as explained in Figure 5.

18


19/22

5.3 Demonstrator

The MIERA Demonstrator uses the core MIERA packages to illustrate their use. Itcontains an authorisation tree editor that provides a graphical user interface to instancesof the GeneralAuthorizationTree class and writes them into file.

Moreover, the Demonstrator is a sample requester application that allows a user tochoose a transaction type, to choose a permission set according to the type, to fill in thenecessary form and then submit it for authorisation. On submission, the form data isconverted into an HTML representation and submitted to the role owners as specifiedin the chosen permission set. For purposes of simplicity (clear text) role names uniquelyidentify a user carrying this particular role. When all signatures are obtained, the ap-plication completes the transaction object fields by retrieving the role certificates froma Java KeyStore and reading the signed root hash from a file. The send transaction

button writes the transaction to a file.The authoriser client is simple. It displays the HTML form to the user and shows

the list of authorisers that have signed the document before. It also provides a signbutton, which then triggers the forwarding of the form to the remaining authorisers andthe requester.

The verifier client reads a transaction from the pre-defined file and creates a newVerificationTree object. On click it calls the verification method and displays success orfailure for each step of the verification procedure.

Although the MIERA Demonstrator is kept simple since it is a self-contained appli-cation that retrieves all input such as certificates from the file system and also simulates

transport of the transaction using a file, the Demonstrator clearly illustrates the mainconcepts of MIERA and demonstrates the usage of the core classes. However, properdeployment of the MIERA schema requires proper key management, real role resolu-tion that provides a set of suitable role owners to a transaction-requesting user, and aproper transport mechanism such as e-mail or more advanced inter-organisational processintegration tools such as VEC or CrossFlow.

6 Conclusion

In general authorization is a more difficult problem than authentication when consid-

ered across inter-enterprise domains. The reason for this is that authentication can beconsidered as verifying a binding between a name or identity and some authenticationtoken such as a certificate, a Kerberos ticket, or a fingerprint. The binding is typically

19


20/22

demonstrated by an appropriate challenge-and-response protocol. Authorization on theother hand entails more semantics. Just as with authentication one may have an authen-

tication token whose ownership can be demonstrated, but this still leaves unanswered theproblem of interpreting which actions should be permitted based on the authorizationtoken. Authorization credentials issued to user UB of company B are expected to haveno meaning to a user UA in company A, if for no other reason than the credentials weresimply not issued by company A.

In this paper we have presented in detail the MIERA solution to inter-enterpriseauthorization which makes use of anonymous role certificates, hash trees and a new con-truct called an authorization structure. The goal is for company B to encode sufficientinformation in the authorization structure so that UA from company A has confidence inwhether UB from company B is authorized for a given transaction. The issue of interpret-

ing credentials is avoided by the encoding semantics of the authorization structure: if thesignature on the authorization structure verifies based on the signatures provided by UBand the signature on the authorization structure itself then UA assumes the transactionis authorized, irrespective of what credentials UB may have.

Further work is required to determine how to minimize the information leaked aboutthe decision procedures of a compnay through the authorization structure. The currentsolution with permission trees hides some information, but using different permissionsets to authorize multiple transactions will eventually reveal the entire structure of theauthorization tree. Even when hashed roles are used it can be deduced which user, ifany, is frequently approving transactions. More investigation is required to determine ifstronger anonymity properties can be built into an authorization structure.

References

[1] ISO/IEC 9594, Information Technology - Open Systems Interconnection The Di-rectory: Authentication Framework, 1993. Also published as ITU-T X.509 (1997 E)Recommendation, June 1997.

[2] M. Blaze, J. Feigenbaum, A. D. Keromytis, and J. Ioannidis. The KeyNote Trust-Management system. Internet draft draft-ietf-trustmgt-keynote-00.txt, Trust Man-agement Working Group, August 1998.

[3] M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized trust management. In IEEESymposium on privacy and Security, pages 164173. IEEE Computer Society Press,1996.

20


21/22

[4] N. Ching, V. Jones, and M. Winslett. Authorization in the digital library: secureaccess to services across enterprise boundaries. In ADL.

[5] D. E. Denning. Cryptography and Data Security. AddisonWesley Publishing Com-pany, 1982.

[6] J. B. Dennis and E. C. VanHorn. Programming semantics for multiprogrammedcomputations. Communications of the ACM, 9(3):143155, March 1966.

[7] S. Farrell. An Internet AttributeCertificate Profile for Authorization, August20, 1998, available at http://www.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt.

[8] G. S. Graham and P. J. Denning. Protection - Principles and Practice. In AFIPS

Spring Joint Computer Conference, volume 40, pages 417429, 1972.

[9] P. Kaiser, T. Parker, and D. Pinkas. SESAME: the solution to security for opendistributed systems. Computer Communications, 17(7):501518, 1994.

[10] B. W. Lampson. Protection. In Proceedings of 5th Princeton Symposium of Infor-mation Sciences and Systems, pages 437443, Princeton University, 1971. Reprintedin ACM Operating Systems Review 8(1), 1824, 1974.

[11] P. V. McMahon. SESAME V2 public key and authorization extensions to Ker-beros. In proceedings of the Symposium on Network and Distributed System Security

(NDSS), pages 114131. IEEE, February 1995.

[12] A. Menezes, P. van Oorschot, and S. Vanstone. Handbook of Applied Cryptography.CRC press, 1996.

[13] R. C. Merkle. A certified digital signature. Advances in Cryptology, CRYPTO89, Lecture Notes in Computer Science, vol. 218, G. Brassard ed., Springer-Verlag,pages 218238, 1989.

[14] B. C. Neuman and T. Tso. Kerberos: an authentication service for computernetworks. IEEE Communications, 32(9), 1994.

[15] R. Thomas and S. Sandhu. Task-based authorization: a paradigm for flexible andadaptable access control in distributed applications. proceedings of 16th NIST-NCSCNational Computer Security Conference, Baltimore, MD, pages 409415, 1993.

21


22/22

[16] R. K. Thomas and R. S. Sandhu. Task-based authorization controls (TBAC): afamily of mocels for active and enterprise oriented authorization management. In

proceedings of IFIP WG11.3 Workshop on Database Security, August 1997.

[17] J. T. Trostle and B. C. Neuman. A flexible distributed authorization policy. Inproceedings of the Symposium on Network and Distributed Systems Security (NDSS) ,1996.

[18] T. Y. C Woo and S. S. Lam. Designing a distributed authroization service.

[19] T. Y. C Woo and S. S. Lam. Authorization in distributed systems: a new approach.Journal of Computer Security, 2(2,3):107136, 1993.

22

miera: a method for inter-enterpriserole-based authorization

Documents