[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on BSR INCITS 359 - Role Based Access Control - DRAFT 4/4/2003
I applaud NIST and ANSI efforts to promote Role Based Access Control. I agree that specifying Access Control rules in terms of attributes that aggregate individual users is essential to building effective security solutions for large-scale environments. However, I have some concerns with the specification as it exists today. Two of them concern technical aspects of the specification and one applies more generally. 1. The RBAC model presented in this specification is a limited one that does not meet all the requirements of modern Access Control Policies. For example, it is necessary to be able to specify access control policies based on environmental conditions, such as the date, time or day of the week or the network location from which the access request is being made. Further, while this RBAC model considers the Roles of the entity making the access request, it is frequently necessary to consider the attributes of other participants in the interaction. For example, in a healthcare environment, a patient may request that his or her medical records be transmitted to a specialist physician. The decision to grant the request in this case may depend on both the attributes of the requester (patient) and the recipient (specialist) of the data. Another example is controlled delegation, where both the attributes of the original requester and the attributes of the delegated intermediary must be considered in making an access control decision. 2. This specification seems to be envisioned for small scale, homogenous environments. It seems to ignore many of the requirements of large-scale environments, however it is exactly these environments in which an RBAC model is most useful. For example, the administrative APIs specify creating roles and users, but large-scale environments typically contain a federation of repositories based on different technologies, vendor products and administrative interfaces. It seems unrealistic to believe that all roles and users can be created by the same simple interface. Similarly, the environment will contain a variety of operating environments. It seems unrealistic that a single simple interface can be used to enable session roles across many different environments. A second example is the use of nested roles. In large-scale, federated environments, information about role membership is likely to be widely distributed and managed by autonomous organizations. The performance implications of multiple distributed accesses in order to resolve nested role membership, not to mention the issues of detecting cycles in the definitions would seem to make this kind of functionality impractical, unless some arbitrary restrictions are imposed on the generality of nested roles. A third example is the user permissions and role permissions APIs. In a large scale environment an individual or role might have millions of permissions that could only be determined by polling thousands of servers. While determining whether a particular access should be allowed could be done efficiently, determining all the permissions available to a given user or role would take an impractical amount of time, typically so long that some of the permissions would most likely have changed before the information could be compiled. Here again it would seem necessary to impose arbitrary constraints on the request to make it practical. 3. My most important concern is about the plan for standardization. It is my understanding that the intention is to make the current specification an ANSI standard, but not to further develop the specification. But information technology standards today are generally understood to enable either interoperability or portability or both. A standard should allow testing which makes it possible to unambiguously determine if an implementation conforms to the specification or not. However, this specification does not provide for interoperability or portability. The specification talks about conformance, but I do not see any objective way of determining whether a piece of software complies with the specification or not. My concern is that if this specification becomes an ANSI standard, compliance to it will be designated as a mandatory criterion for procurement both by federal agencies and private corporations. In this event, vendors will be forced to develop their own proprietary implementations, which perforce will not interoperate. Once these implementations have been developed, vendors will be reluctant to abandon them, particularly since their proprietary nature will act as a barrier to entry to competitors. If this occurs it will be against the interests of the government and the industry in general. In my opinion, it would be far preferable to choose one of two alternative approaches. Either change the term describing this specification from Standard, to some more neutral term, such as Recommendation or Model and remove the misleading references to conformance. Or alternatively, submit the specification to some standards organization, which is open to participation by the IT industry and press forward to define interoperability standards, so that products can be developed which can work together in large-scale environments, rather than encouraging the development of proprietary solutions which conform to the abstract model. Harold W. Lockhart Principal Engineering Technologist Architecture & Standards Group BEA Systems, Inc.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]