The WebComDACarchitecture is shown in Figure 8.23. It is broken down into a number of compo-
nents. The middleware systems, such as COM or EJB, provide the components that can be used by WebCom applications. Both the components and the security policy are discovered by interroga-
tors. These interrogators determine the services that are available on a middleware server and input
this information into a database. This database is used by the WebCom integrated development en- vironment (IDE) to allow developers to create applications using these services. During component interrogation, the interrogators also extract the security policy for these middleware components and also store this information in a database. This information is represented in a palette in the WebCom IDE. Middleware System Middleware System Middleware System RBAC to Trust Management Transation KeyStar Client KeyStar Client KeyStar Client Select M/W Services Generate T.M. Credentials Server KeyStar Update Security Interrogates Services
Use Middleware Services
Interrogator Database
Policy on Clients
Update Server Policies
Sec Policy
Sec Policy
Sec Policy
WebCom IDE
Figure 8.23: The WebComDAC Architecture.
Once an application has been created, an access control policy must also be created for this application. Typically, this takes the form of a trust management policy. This may require changes to the authorisation policies of the middleware systems. In this case, the KeyStar subsystem is used to make these updates.
Middleware systems typically use a type of role based access control (RBAC) for authorisa- tion. RBAC-like policies can be encoded in terms of equivalent cryptographic certificates/policies [109, 152]. In addition to supporting ad hoc KeyNote policies, WebComDAC supports middle-
ware RBAC-like security policies within KeyNote authorisation credentials. This is unlike [109], where authorisation certificates are only integrated as part of the lower-level middleware system. WebComDAC uses KeyNote to determine whether it is safe to execute a middleware component.
A WebComDAC environment can automatically convert middleware RBAC policies to their
8.4 WebComDAC 169
interoperability, both between the middleware and trust management layers, and within different Middlewares. In addition to providing a uniform way of specifying RBAC policies for different middleware systems, it also becomes possible to enforce standardised RBAC middleware policies across middleware systems that do not have a configured RBAC policy.
Role-based access control (RBAC) [158] is widely used to provide access control in Database management systems, operating systems and Middleware architectures. In RBAC, access rights (permissions) are associated with roles, and users are members of these roles. When a user is as- signed to a role, they gain all the permissions of that role in the system. This allows an organisation to model its security infrastructure along the lines of its business. For the purposes of this disserta- tion we extend the conventional RBAC model of Users, Roles and Permissions, to include Domain.
• Permission: represent actions, capabilities, applications or any other active behaviour that can be “performed” and, to which, we intend to control authorisation.
• Domains: administrative boundaries that group permissions and manage their underlying resources. In general, domains do not intersect in their underlying permissions.
• Roles: roles are logical groupings of permissions that reflect a particular task that can be assigned to some user. We assume that roles do intersect in their underlying permissions.
• Users: include humans or any other entity that can be assigned a role.
An RBAC policy is defined in terms of the following relations.
RoleP erm : (Domain × Role) ↔ P ermission
RoleU ser : (Domain × Role) ↔ U ser
where RoleP erm((d, r), p) means that the role r (in domain d) holds permission p (on some ob-
ject), and RoleU ser(d, r, u) means that user u is assigned to domain-role pair (d, r). Table 8.1
uses this model to provide a uniform interpretation of basic COM+, EJB and CORBA middleware RBAC policies.
There are a variety of approaches to supporting roles in KeyNote. Encoding the fixed relation- ships from the Domain-Role-Permission table as a single KeyNote credential provides a simplistic representation of the RBAC policy. Individual credentials are then issued, associating users to roles.
Example 8.10 The ShareTrader Domain-Role-Permission table can be encoded as the following
Type Domain Role User Permission
EJB Combination of
Host, EJB Server, relevant bean container.
Application Spe- cific for each server.
Exist globally on each server, can be members of differ- ent roles.
Method calls (of an object type) that roles are permitted to make.
COM Windows NT Do-
mains. Unique to Do- mains. Windows Users. Unique to each Domain. Considering only Launch,Access andRunAs. CORBA Machine name and
ORB server name.
Unique to Do- mains. Can be members of different roles, unique to each server. Relate to method calls on objects of the given object type.
Table 8.1: Interpretation of Middleware RBAC Models
Authorizer: POLICY Licencees: "Kwebcom"
Conditions: app_domain="ShareTrader" && (Domain=="mgmt"&&(role=="TraderMgr") ->
(perm=="setlimit"||perm=="analyzerisk"||...); ....
(Domain=="staff"&&(role=="sales") ->
(perm=="pricedeal"||perm=="capturedeal");
This specifies that the WebCom administration keyKwebcomis authorised to administer rights in connection with this policy.
Authorizer: "Kwebcom" Licencee: "Kjoe"
Condition: app_domain=="ShareTrader" && role=="Trader";
This credential authorises Joe as a Trader. △
The above approach promotes a more centralised policy administration, with the WebCom envi- ronment (administrator) managing delegation and is comparable to the conventional middleware approach.
Alternatively, the Domain-Role-Permission table can be decentralised and spread across a num- ber of credentials and additional authorisations and role memberships delegated to other keys. A common strategy is to represent roles (from domains) in terms of public keys; delegation is used to create the role-permission and role-user relationships. In practice, roles are best supported using SDSI-like local names [152], however, we can approximate the role membership effect in KeyNote as follows.
Example 8.11 Public keysKRtraderandKRsales, etc., are used to represent roles. Credentials associate authorisations to the roles. For example,
8.4 WebComDAC 171
Authorizer: KRtrader Licencee: KRsales
Condition: app_domain=="ShareTrader" && perm=="pricedeal"||perm=="capturedeal";
Sally is assigned this role using a credential, signed byKRtrader, authorisingKsally. In prac- tice, if Joe is a member of theKRtraderand is permitted to further delegate the associated per- missions, then Joe could authorise Sally to be in theKRsalesrole. △
A disadvantage of this more flexible and decentralised approach is that, in giving administration authority to individual users, it provides only limited control of how these users subsequently del- egate their authority; trading manager, Mandy, can decide to directly authorise salesperson, Sally, tosetlimit, regardless of the intended role hierarchy. In [63], we describe how distributed workflow rules supported by WebCom are used to place constraints on the delegation actions of such users.