MIERA: A Method for Inter-Enterprise Role-Based Authorization

Heiko Ludwig and Luke OConnor IBM Research Division Zurich Research Laboratory, Switzerland
Abstract Large scale deployment of ecommerce solutions between various enterprises over public networks requires careful consideration of security issues. In this paper we will address the particular problem of inter-enterprise authorization, as would be required if for example a business process spans several organisations and data is passed between enterprises during the execution of the process. In this paper we propose the MIERA scheme for authorization, which can be used for both intraor inter-enterprise authorization. MIERA makes authorization decisions based on roles, represented by anonymous role certicates. We also dene an authorization tree 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, we can use a hashed version of A(T ) to reduce space requirements and also to obscure the decision procedure information in A(T ), but which still permits transactions of type T to be authorised.

Introduction

Authorization is a basic security service which provides control on who may access resources and in what manner. Traditionally authorization in single systems was implemented via an access control matrix [10] or a related concept such as access control lists [5] or capabilities [6]. These mechanisms typically assume that ne grained control over resources is required, such as explicitly specifying which users can read a given le F , which group can write to F and so on. This approach is referred to as the subject-object paradigm [8, 10], which species access control in terms of (s, o, a) triples (subject, object, access rights) and is commonly integrated quite closely with the underlying operating system. While this model is appropriate for single or closed systems, the subject-object paradigm is less suited to distributed and general ecommerce applications for which authorization decisions are required to be based on non-local information and credentials [19, 15]. Considering an inter-enterprise workow application, authorization is more likely to be based on a combination of general policies, company aliation, roles, group privileges, delegated rights, location information and possibly third party credentials rather than on read/write le permissions for example [15, 16]. A major issue is to determine how credentials (or authorization attributes) issued in one security domain (say from company A) are to be interpreted in another distinct securty domain (say company B ). One solution is to use a common credential framework as provided by Kerberos [14, 17], OSF DCE and Sesame [9, 11] for example, which permit trust relationships to be specied 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 business relationship, the Internet and WWW are promoting ecommerce and access to services where no standard authorization attributes exist. For these environments the focus is towards service requestors providing their credentials to service providers who decide if the 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 of public key cryptography [12] which permits authorities to issue statements that can be digitally signed and veried at the time of presentation. Attribute certicates [7] are a means of collecting authorization attributes into a format similar to the standard X.509 certicate for representing public keys [1]. The approach to distributed authorization that we take in this paper is to consider the middle ground between all service requestors and providers agreeing on common authorization attributes on the one hand, and service requestors processing arbitrary requestor credentials and on the other. Also we are motivated by the authorization problem for 2

inter-enterprise transantions, say between two universities or a manufacturer and a supplier, 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 scenario where two companies, s ay company A and company B , have a formal agreement for making business transactions. In the context of this paper we use the term transaction for any legally binding action between organisations, such as an oer, an order or a cancelation. We may denote the possible set of transaction types between A and B by T (A, B ) = {T1 , T2 , . . . , Tn } 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 the actual 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 situation would 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 is presented with a request from company B for company A to make X = 1000 units of product Y = widget at price P = 1 ecu per unit. Since the request originates from a public network, there are several security issues that UA may consider: Should the details (X, Y, P, UA , UB ) of the transactions be condential and encoded for 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 from company B , how can it be veried that UB is in fact authorised to request such a transaction for the given values of X, Y and P ? The rst two points can be addressed using standard security protocols and cryptographic algorithms [12]. In particular, with public key cryptography each user U can be issued with one or several certicates [1] that can be used to demonstrate their identity (and employer) through the use of digital signatures [12]. In this paper we wish to address the last point, that of authorization for the transaction. It may be costly for
In 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 extended to machine-to-machine interactions.
1

both companies A and B to have UA initiate the processes to fulll the request from UB only 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 made until next month for accounting reasons (company B has insucient funds to pay for the transaction this month, and no space to store the widgets). If UA and UB are acquainted personally then that existing trust relationship may be sucient for UA to accept the request from UB as authorised. However general ecommerce will bring together people (users) who will have no prior business or trust relationships, and the transaction then must somehow be self-authorizing. We abstract our problem to the following: how can a transaction requester (UB ) convince a transaction verier (UA ) that the requester is authorized to request a specic transaction T ? We call this the transaction authorization problem (TAP). Let us assume that UA is actually Alice and UB is actually Bob. We expect that the authorization information obtained by Bob to request T is specic to his company, and more than likely not meaningful to Alice. For example, Bob may have discussed the transaction details with his manager and department head, and lastly someone from the purchasing department, who all agreed that he could request the transaction from company A. Later Alice will then receive the transaction details from Bob along with some indication that the transaction was approved by people in company B assuming the roles of manager, department head and representative of purchasing department. The transaction is then self-authorizing to the extent that Alice is prepared to believe that the consent of these three people in the stated roles constitutes authorization for the transaction. We then see that the TAP consists of two distinct but related problems. The rst problem is that before Bob can send the transaction to company A, he must follow local procedures in his company to obtain authorization for making the transaction, and probably company B would like to automate this process as much as possible. The second problem is that once Bob has obtained the required authorization from his company, he must then convey this approval to Alice in some meaningful way given that Alice is not aware of how transactions are authorized internally in company B . In fact, company B will probably be interested in concealing its internal authorization process from other companies. While it is dicult to imagine how authorization information from company B can be exported discreetly and meaningfully to company A, it is likely that (users from) company A can verify digital signatures produced by (users from) company B . The supporting data structure for signing operations is a certicate, which binds a name (key owner) to a signing verication key. Authorization attributes for the key owner could be included 4

in a certicate, but this appears to overload the notion of a certicate beyond its original intention, and dedicated attribute certicates [7] have been introduced as a companion authorization data structure. Nonetheless, while certicates provide a convenient solution to the authentication problem, the problem of interpreting of authorization attributes remains even if the attributes are signed - we are simply more certain as to who created the attributes, not what they mean. In the example above the form of the approval given to the Bobs transaction by manager, department head and representative of purchasing department could be digital signatures veried by certicates containing these roles as names. However, the problem of Alice interpreting these signatures as constituting authorization remains. In this paper we address the TAP for transactions of type T by introducing the concept 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 with the transaction details to the verier such that in the act of verifying the signature on A(T ), the verier also determines that the requester is authorized to make the request for the transaction. Thus the only authorization semantics that the verier need consider is that the requester is authorized to make the request if and only if the signature on A(T ) can be veried. This verication is performed without regard for the identity of the requester, the position of the requester in their company, and the details of the transaction itself. While this information is important, particularly to the company of the requester, it is implicitly encoded into the signature verication process performed by the verier. Thus the transaction authorization problem is addressed not by exporting authorization attributes from one domain (company) to another, but by encoding the attributes into a signature verication process that produces a universally recognizable authorization decision: the request is authorized if and only if the signature on A(T ) veries. Returning to our example, Bob will send the transaction details to Alice along with A(T ). The A(T ) will encode the information that people of company B acting in the roles manager, department head and representative of purchasing department can jointly authorize transactions of this type. The A(T ) may also encode that the CEO alone or two vice presidents can also authorize the transaction, but this additional authorization information need not be apparent to Alice. The scheme described in this paper for addressing the TAP based on authentication trees is called MIERA (pronounced meer-rah), which is an abbreviation of Method for Inter-Enterprise Role-based Authorization. In MIERA users authorize transactions by signing some representation of the transaction, and conversely, veriers determine that a transaction is authorized by verifying signatures. Central to MIERA is the notion that users can assume roles and sign transactions to confer the authority of these roles (such as 5

department head and CEO). Which collection of roles and in what combinations can authorize a given transaction T will be specied by the structure of A(T ). The verier determines that a transaction of type T is authorized by checking role signatures against the information specied in A(T ), and this checking operation is essentially checking a signature on A(T ) produced by the requesters company. An outline of this paper is as follows. In 2 we dene anonymous role certicates which permit users to sign in the capacity of a role without revealing their name, which in most cases is incidental to the authorization process. The structure of the authorization tree A(T ) is described in 3, along with a method to hash and sign A(T ). As explained later, a signed hashed version of A(T ) must be made available to the verier. In 4, the operation of the MIERA scheme is described in detail using anonymous role certicates and 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 presented in 6.

Anonymous Role Certicates

We assume that company B has dened a set of roles R = {R1 , R2 , . . . , Rm }, such as user, manager and department head, and that each user U in company B is assigned one or several roles UR RB . The tasks or activities that a user U can perform will be directly related to the authority of the roles that U can assume. For our purposes we assume that each user U has a X.509 public key certicate CertCA (U ), that contains their name, public key and other elds, signed by some local certicate authority CA. There are several possible formats for CertCA (U ), and we assume the X.509 (version 3) certicates [1]. As X.509v3 certicates contain extension elds for general information such as an e-mail address, alternatives to X.500 names, and policy information for example, a role could be included as an extension eld. Let CertCA (U, R) be a certicate for U containing an extension for role R. User U is then able to authorize a request or action T based on the authority of role R by signing some representation T of the activity with the private key associated with CertCA (U, R). A verier can determine the correctness of the signature using CertCA (U, R) and further, an authorization decision can be based on the role extracted from CertCA (U, R). With certicates of the form CertCA (U, R) it is clear that the verier can link the signers name and role since this information is unambiguously bound to the same certicate. If the verier belongs to company A (dierent to company B ), we expect that any authorization decision will be based on R 6

rather than on the name of U . Further, company B may consider the fact that U can authorize 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 notion of an anonymous role certicate CertCA (RU ) for user U , which is an X.509v3 certicate with the following changes: the name eld represents a ctitious user ; there is an extension eld containing the role RU of U ; there is an extension eld that contains a forward reference from CertCA (U ) to Cert(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 B public key or the local CAs public key. The forward reference is a mechanism for company B to be able to identify the owner of a role certicate when the need arises. If U has several roles then there will be a role certicate for each role. It is important to note that each role certicate has a public and corresponding private key so that users may authorize activities in the capacity of role R without revealing their identity (name). Thus each user will have at least two certicates, a standard X.509v3 certicate CertCA (U ) that binds their name to a public key, and then an anonymous role certicate CertCA (RU ) that binds their role to a public key. The link between CertCA (U ) and CertCA (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 certicate CertCA (RU ) is a role signature. For a user U to obtain authorization to request particular transaction T , let company B have authorization policy which states that U must obtain approval from their manager and their department head. In practice the policy can be implemented as U creating an digital representation D(T ) of T and then obtaining signatures on D(T ) from their manager and then their department head. Using anonymous role certicates it is clear that certicates denoting manager and department head could be created, and role signatures on D(T ) for manager and department head could be created. However when U presents a verier V with D(T ) and role signatures on D(T ) for the roles manager and department head, V has insucient information to determine if the transaction is authorized since the anonymous role certicates do not indicate that the manager signature is from U s manager or that the department heads signature from U s department 7

head. The potential drawback of anonymous role certicates as dened is that they do not 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 manager of user U , or department head of user U will be called relative roles. As dened above anonymous role certicates only implement absolute roles, and additional mechanisms are required to implement relative roles, which seem to provide a more natural interpretation of authorization policy. However we do not consider absolute roles to be a severe restriction on the MIERA method of authorization, which should become apparent as the details of MIERA are explained below. Recall that the approach of MIERA is to avoid having the verier deal with any semantics associated with the authorization information presented by the requester: the only required semantics is that if a given signature on the transaction veries, then the requester is dened as being authorized to make the transaction. In following this approach the verier need not be concerned with the nature of the roles used in the requesters company, and whether the presented authorization information reects absolute or relative roles. The potential problem is that requester may circumvent their companys authorization policy by exploiting semantic dierences between absolute and relative roles which the verier cannot detect. So the requester may have obtain to signatures on D(T ) from people who are not the requesters manager or department head, but nonetheless have anonymous role certicates that allow then to sign in these roles. There are technical solutions to this problem but it should be clear that additional elds similar to the forward reference could be embedded in anonymous role certicates to reect the relativeness of roles. We note that an obvious deterrent to this type of cheating by the requester is to note that the forward reference can always be used to resolve which user made a particular role signature, so that colluders can always be identied.

Authorization Trees

Using the anonymous role certicates dened in 2, we now proceed to dene a rolebased structure A(T ) that denes which role signatures are required to deem a request for transaction of type T to be authorized. Further, a modied version of A(T ) will be made available to the verier for the purpose of deciding if a requested transaction of type T is authorized. Thus A(T ) will be used by the requester for preparing a transaction and by the verier for authorizing a transaction. Recall that for each transaction T we assume that there is some (electronic) document 8

Transaction Type

PT,1

PT,2

PT,3

Permission Sets

R1

R2

R3

R4

R5

R6

Roles

Figure 1: An authorization tree for Example 3.2. D(T ) representation of T , which will basically be some template specifying the (mandatory 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 elds of the form). We assume for any transaction type T that it is possible to distinguish between the details of transaction into D(T, U ) and the authorization information for T , which will 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 that indicates 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 travel requests require signatures on D(T, U ) from the user U , a manager (M ) and a department head (DH ), then A(T ) will encode information about the roles user, manager and department head. 2 9

In Example 3.1, we will call the set PT,1 = {U, M, DH } a permission set for transaction 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 as PT,1 , PT,2 , . . . , PT,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 transaction of type T represented by D(T, U ), if for some permission set PT,i = {R1 , R2 , . . . , Rm } of T , m users sign D(T, U ) where the union of the roles in the corresponding anonymous role certicates for these signatures are exactly the set PT,i . The purpose of A(T ) is to encode the permission sets PT,i of T . Permission sets PT,i then represent sets of roles whose joint authority is deemed sucient to authorize transactions of type T . We will represent the permission sets PT = {PT,1 , PT,2 , . . . , PT,k } with a 2-level tree as follows. For each transaction type T , an authorization tree A(T ) is created such that there are k nodes at level 1 from the root, corresponding to the k permission sets PT = {PT,1 , PT,2 , . . . , PT,k } for transaction type T . 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 with 3 nodes and each PT,i has the same number of leaves as there are roles in its permission set. So for example then PT,1 would have two children (both leaves) representing R1 and R2 , 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 AND nodes and the root of A(T ) as an OR node. By an AND node we mean that all children of the node must agree to the request D(T, U ) (all roles of a permission set must sign) while an OR node means at least one child must agree to the request D(T, U ) (at least one permission set must jointly sign). Alternatively, we may interpret A(T ) as a disjunctive representation of the roles that can authorize task T , such that A(T ) of Example 3.2 could be written as A(T ) = R1 R2 + R3 R4 R5 + R6 . The authorization tree A(T ) can be thought of as being an example of a Merkle hashtree [13]. We can then dene a hashing process H (T ) which produces a hash value for A(T ), and we can dene a signature on A(T ) as being the signature on the hash value produced 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 label the leaf as h(Ri ), and repeat this for all leaves. Then at level 1, label each node with the hash of the concatenation of the labels for its children; lastly, label the root of the tree 10

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

Transaction Type

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

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

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

Permission Sets

h(R1)

h(R2)

h(R3)

h(R4) h(R5)

h(R6)

Roles

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.

The MIERA Scheme

As in the introduction, we assume that there are two companies A and B who have agreed upon 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 type T , assume that UB from B will request UA from A to perform T , and that UA should be assured that UB is authorised to make such a request. In fact we will denote UA as V to emphasize that UB is the verier, and simply denote UB by U .

11

RA: CA: T A:

for each user U , assign U role RU R ; for each user U , create and store CertCA (RU ) ; for each transaction type T do create the transaction template D(T ); sign D(T ) to yield SignT A (D(T )) PT,i R, 1 i tk ;

hash the authorization tree to yield H (T ) ; sign H (T ) to yield SignT A (A(T )) ; store SignT A (A(T )) in a public company database P D; store D(T ), SignT A (D(T )), A(T ) in a private company database CD; od Figure 3: MIERA role assignment and creation of permission sets for transactions. Here RA denotes the role administrator, CA denotes the certicate authority, and T A the transaction administrator.

4.1

MIERA setup at the Requester Company

The required initialisation at the company B is shown in Figure 3. Users are assigned roles R = {R1 , R2 , . . . , Rm } by the (user user with the role) Role Administrator (RA), and corresponding anonymous role certicates are created by the local Certicate Authority (CA). The transaction administrator (T A) is responsible for creating transactions and assigning the correct (authorizing) permission sets to each transaction. For each transaction T , the transaction authority T A of company A denes permission sets PT = {PT,1 , PT,2 , . . . , PT,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 permission set is a multi-set since it may require signatures from two dierent users assuming the same role). By creating a transaction we actually mean the creation of D(T ) The format of

12

D(T ) should of been previously agreed on by companies A and B . of the electronic form/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 SignT A (D(T )) and SignT A (A(T )), where SignT A (A(T )) is simply the T As signature on H (T ) as dened in 3. Then the T A stores D(T ),SignT A (D(T )) and A(T ) in the private compnay database CD, while SignT A (A(T )) is stored in a public database P D accessible by all potential veriers. We also assume that the CA and T A have well-known certicates so that signatures they produce can be easily veried. In summary then, at the requesting company B users are assigned roles with corresponding certicates for signing in these roles, and the transaction authority creates and signs transactions with corresponding authorization trees. The anonymous role certicate of each user CertCA (RU ) is made available by the certicate authority CA, and the signed authorization tree SignT A (A(T )) is also made available for each transaction T .

4.2

Preparing a Transaction at the Requester Company

Imagine now that a requester (user U ) of company B wishes to prepare an authorized transaction for processing by some verier V at company A The steps followed by U are shown in Figure 4. First U retrieves the template D(T ) of T from the (companys) private database CD, and veries 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 ) to obtain D(T, U ), and then signs D(T, U ) with its role UR to give SignUR (D(T, U )). Here we assume that any transaction request by U initially requires the role signature of U , which should be reected in the permission sets for T . U then retrieves the authorization tree A(T ) for T from the private database, and again checks the signature produced by the 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 used one of their role certicates to sign D(T, U ). U needs to request further signatures until P S is equal to one of the permission sets for transactions of type T . We also note that when U attempts to acquire an additional signature from user U , user U may require to see the roles and signatures of the users who have previously signed D(T, U ). This reects the requirement that U may not only be signing the contents of D(T, U ) but also the existing role signatures denoted by the set P S . In gure 4 we have chosen to use a repeat loop to represent the problem of collecting role signatures This is a simplication of the process in practice, as for example, several users may be contacted in parallel. We defer the problem of nding the best strategy for contacting users and soliciting their signature to a special process for this task, such as a workow system. Once the role 13

U:

requires authorization for transaction T ; retrieve D(T ), SignT A (D(T )) from CD; check signature SignT A (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 ), SignT A (A(T )) from CB ; check signature SignT A (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 role signatures P S . At this point the user has provided the transaction details in D(T, U ) and has collected signatures constituting a permission set in P S . It now remains to store some additional information which can be used to convince the verier that P S is indeed a permission set for transactions of type T . The hashed tree H (T ) will be used for this purpose. As dened, A(T ) has three levels: leaves representing roles, internal nodes representing 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 , . . . , PT,k } let PT,i be the permission set for which user U has obtained the role signatures with which D(T, U ) 14

is to be authorised (that is, PT,i is represented in P S ). Then H (T ) can reconstructed from 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 produce H (T ). U then also stores path(i, H (T )) for later use by the verier, as shown in the last step 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 have signed D(T, U ) at the request of user U . H (T ) can be reconstructed from the roles certicates of R1 and R2 (which contains the roles as elds) and path(1, H (T )) = {h(PT,2 ), h(PT,3 )}. 2

4.3

Transaction Authorization at the Verier

When the requestor U is ready to initiate the processing of the transaction, U sends D(T, U ), P S and path(i, H (T )) to the verier V . The process of the verier checking the authorization of the transaction request is shown in Figure 5. Since the companies of the requestor and verier have agreed on transactions of type T , and in particular on D(T ), the verier rst obtains a signed local copy of D(T ) to determine that D(T, U ) is formatted correctly. Next the verier 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 ). We assume that the signatures in P S are appropriately formatted so that for each signature SignRj (D(T, U )), the certicate CertCA (U, Rj ) holding the corresponding verication key can be retrieved (from the certicate authority CA). If each such certicate CertCA (U, Rj ) is valid (not expired or revoked for example), and each signature of P S of D(T, U ) veries, then V proceeds to authorization step. Based on checking the signatures from P S on D(T, U ), the verier can extract a list of the roles R1 , R2 , . . . , Rt from which users acting in these roles approved the transaction. The verier can then hash these roles to form PT,i = h(R1 , R2 , . . . , Rt ), and then using path(i, H (T )) concatenate the hashes to form H (T ), the hash of some tree. The verier fetches SignT A (A(T )) from the public database of the requestor company, along with the T As certicate. Assuming that roles R1 , R2 , . . . , Rt actually constituted the permission set PT,i , and path(i, H (T )) were the hashes of the other k 1 permission sets of T , then 15

U: V:

send V the message D(T, U ), P S, path(i, H (T )) ; verify format of D(T, U ) with local copy of D(T ) and exit if fails; fetch and verify certicates CertCA (URj ) for signatures in P S exit if any certicate fails; verify each signature on D(T, U ) and exit if any signature fails ; extract roles Rj from certicates CertCA (URj ) ; hash the roles with path(i, H (T )) to form H (T ) ; fetch SignT A (A(T )) from requestor companys public database ; fetch and verify CertCA (T A) and exit if fails ; verify the signature SignT A (A(T )) using CertCA (T A) to yield H (T ) ;

V:

sends to U message that authorization is veried if H (T ) = H (T ); Figure 5: Transaction verication with MIERA.

H (T ) = H (T ). Then the verication of the signature SignT A (A(T )) will produce H (T ), and the verier determines the transaction to be authorised if and only if H (T ) = H (T ). Thus we see that verication 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 for authorization against the signed copy of A(T ). The explict link between the two steps is that the roles specied in the certicates used to sign D(T, U ) are the same roles that will be used to form a candidate hash tree corresponding to H (T ), and hence the signature on A(T ). Checking the signatures on D(T, U ) demonstrates the approval of a permission set P S on the transaction, while checking H (T ) against A(T ) demonstrates the approval the T A on the given permission set.

16

The MEIRA Demonstrator

The MIERA schema has been implemented as a Java package that can be used by developers to apply the schema to an e-business system. The implementation uses Java 1.2 and is based on the security mechanisms of Suns Java Cryptography Extension (JCE). Reecting the underlying model, the implementation provides two main structures for provider and requester applications, the transaction package and the authorisation tree package. A Demonstrator has been built that illustrates to a user how MIERA works and also provides a reference implementation that shows how to use the MIERA package in an application.

5.1

Authorisation Tree Package

This package contains a number of dierent classes related to editing, transmitting and verifying authorisation trees according to the MIERA schema. The GeneralAuthorizationTree class implements an authorisation tree as described in this 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 provides the authorisation structure for. This class provides methods for editing and viewing the tree. It is intended to be used by the transaction authority and users that create a transaction to be sent to a provider. Also, the GeneralAuthorizationTree class provides a method to create an instance of PublisizableAuthorizationTree. This is the equivalent of 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 is sent to the provider, i.e. path(i, H (T )), i being the chosen permission set. A TransmissableAuthorizationTree instance is an authorisation tree that only contains the hashes of the permission that were not used and the role hashes of the used permission set. In addition, it provides a method for creating an ASCII representation that can be stored and transmitted to a provider. The VericationTree class provides methods that are used in a provider application. An ASCII representation of the tree - as transmitted by a requester - can be passed to a constructor that then creates the tree structure. This class also provides a method to compute 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 algorithm as provided by JCE.

17

5.2

Transaction Package

The Transaction package consists of the Transaction class and its two main components, the FormContainer that contains the signed content of the transaction, and the TreeContainer that contains the information related to the authorization tree. The FormContainer and TreeContainer together contain the information that is necessary to verify the authorisation of the transaction according to the MIERA schema. This class is intended to be used by both, provider and requestor of a transaction. The Transaction class provides 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 transaction from its transmittable form, and to verify a transaction. The FormContainer consists of a reference to a Java SignedObject that contains the signed content of the transaction D(T ) and a list of anonymous role certicates CertCA (RU ) for those roles that were used to sign the form. Using the SignedObject for the content of the transaction makes the Transaction class independent of a particular kind of transaction content representation and therefore applicable for various kinds of systems. The Transaction class uses X.509v3 certicates as implemented by Javas JCE. In the current implementation the role certicates contain the role name in the name eld. The demonstrator does not provide forward references to the real user name of the role certicate. The TreeContainer encompasses a VericationTree eld, which references an authorisation tree that provides methods for verifying the transaction, a eld for an ASCII representation of the authorisation tree, from which a VericationTree can be re-constructed, and the signed reference hash that is issued by the transaction authority for the given transaction type. The transaction can be converted by the requestor into a transmittable (ASCII) form that can be sent using transport mechanisms such as e-mail The transmittable form of the transaction must contain the ASCII representation of the verication tree and the signed content of the transaction. It may contain also the signed reference hash H (T ) and the list of used role certicates. But those can also be obtained by the provider in a dierent way, such as using an X.500 directory service. Before the verify method can be used, the signed reference hash and the list of used role certicates must have been obtained. The verify method works as explained in Figure 5.

18

5.3

Demonstrator

The MIERA Demonstrator uses the core MIERA packages to illustrate their use. It contains an authorisation tree editor that provides a graphical user interface to instances of the GeneralAuthorizationTree class and writes them into le. Moreover, the Demonstrator is a sample requester application that allows a user to choose a transaction type, to choose a permission set according to the type, to ll in the necessary form and then submit it for authorisation. On submission, the form data is converted into an HTML representation and submitted to the role owners as specied in the chosen permission set. For purposes of simplicity (clear text) role names uniquely identify a user carrying this particular role. When all signatures are obtained, the application completes the transaction object elds by retrieving the role certicates from a Java KeyStore and reading the signed root hash from a le. The send transaction button writes the transaction to a le. 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 sign button, which then triggers the forwarding of the form to the remaining authorisers and the requester. The verier client reads a transaction from the pre-dened le and creates a new VericationTree object. On click it calls the verication method and displays success or failure for each step of the verication procedure. Although the MIERA Demonstrator is kept simple since it is a self-contained application that retrieves all input such as certicates from the le system and also simulates transport of the transaction using a le, the Demonstrator clearly illustrates the main concepts of MIERA and demonstrates the usage of the core classes. However, proper deployment of the MIERA schema requires proper key management, real role resolution that provides a set of suitable role owners to a transaction-requesting user, and a proper transport mechanism such as e-mail or more advanced inter-organisational process integration tools such as VEC or CrossFlow.

Conclusion

In general authorization is a more dicult problem than authentication when considered across inter-enterprise domains. The reason for this is that authentication can be considered as verifying a binding between a name or identity and some authentication token such as a certicate, a Kerberos ticket, or a ngerprint. The binding is typically

19

demonstrated by an appropriate challenge-and-response protocol. Authorization on the other hand entails more semantics. Just as with authentication one may have an authentication token whose ownership can be demonstrated, but this still leaves unanswered the problem of interpreting which actions should be permitted based on the authorization token. Authorization credentials issued to user UB of company B are expected to have no meaning to a user UA in company A, if for no other reason than the credentials were simply not issued by company A. In this paper we have presented in detail the MIERA solution to inter-enterprise authorization which makes use of anonymous role certicates, hash trees and a new contruct called an authorization structure. The goal is for company B to encode sucient information in the authorization structure so that UA from company A has condence in whether UB from company B is authorized for a given transaction. The issue of interpreting credentials is avoided by the encoding semantics of the authorization structure: if the signature on the authorization structure veries based on the signatures provided by UB and the signature on the authorization structure itself then UA assumes the transaction is authorized, irrespective of what credentials UB may have. Further work is required to determine how to minimize the information leaked about the decision procedures of a compnay through the authorization structure. The current solution with permission trees hides some information, but using dierent permission sets to authorize multiple transactions will eventually reveal the entire structure of the authorization tree. Even when hashed roles are used it can be deduced which user, if any, is frequently approving transactions. More investigation is required to determine if stronger anonymity properties can be built into an authorization structure.

References
[1] ISO/IEC 9594, Information Technology - Open Systems Interconnection The Directory: 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 TrustManagement system. Internet draft draft-ietf-trustmgt-keynote-00.txt, Trust Management Working Group, August 1998. [3] M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized trust management. In IEEE Symposium on privacy and Security, pages 164173. IEEE Computer Society Press, 1996. 20

[4] N. Ching, V. Jones, and M. Winslett. Authorization in the digital library: secure access to services across enterprise boundaries. In ADL. [5] D. E. Denning. Cryptography and Data Security. AddisonWesley Publishing Company, 1982. [6] J. B. Dennis and E. C. VanHorn. Programming semantics for multiprogrammed computations. Communications of the ACM, 9(3):143155, March 1966. [7] S. Farrell. An Internet AttributeCerticate Prole for Authorization, August 20, 1998, available at http://www.ietf.org/internet-drafts/draft-ietf-tls-ac509prof00.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 open distributed systems. Computer Communications, 17(7):501518, 1994. [10] B. W. Lampson. Protection. In Proceedings of 5th Princeton Symposium of Information Sciences and Systems, pages 437443, Princeton University, 1971. Reprinted in ACM Operating Systems Review 8(1), 1824, 1974. [11] P. V. McMahon. SESAME V2 public key and authorization extensions to Kerberos. 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 certied digital signature. Advances in Cryptology, CRYPTO 89, 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 computer networks. IEEE Communications, 32(9), 1994. [15] R. Thomas and S. Sandhu. Task-based authorization: a paradigm for exible and adaptable access control in distributed applications. proceedings of 16th NIST-NCSC National Computer Security Conference, Baltimore, MD, pages 409415, 1993. 21

[16] R. K. Thomas and R. S. Sandhu. Task-based authorization controls (TBAC): a family 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 exible distributed authorization policy. In proceedings 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