OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]