RBAC and principle of least privilege

Hi,

I would like to add a few reflections to the access control discussion that
we had in the f2f meeting last week, where I presented a proposal on a
combi-role RBAC solution.

In the discussion an example with an insurance company app was mentioned,
and in that discussion it was claimed that this did not follow the
principle of least privilege.

I objected to that, but I did not manage to argue convincingly against it.
However, after thinking more on it, I would like to add this.

For a client to get access to restricted data, it must first interact with
the Access Grant server, and then the Access Token server before it has
obtained the necessary credentials to eventually pass the access evaluation
of the Gen2 server. To approach the Gen2 server with the credentials it
received from the AG server will never lead to a positive evaluation.

One outcome of the interaction with the AG server is that the client is
assigned a combi-role. A role is associated with a certain scope of
signals. In following interactions with the AT server, the client can only
request access to signals that are within the set of signals associated
with its role, but that does not mean that it (typically) will request
access to them all in its request to the AT server. Such a request should
most likely be denied, unless it is accompanied by a Purpose that warrants
it.

An example involving a client requesting, and receiving credentials for an
OEM role, might better describe the proposed RBAC model. After being
granted this role, which would involve strict authentication procedures to
ensure that the client request should be granted, the client basically has
potential access to the complete VSS tree. However, to access any
signal(s), it must make a request to the AT server for a specific set of
signals, and include a Purpose in this request. It is then up to the AT
server to assess whether this request meets the principle of least
privilege. The client is likely to use its OEM role credentials for
different requests to the AT server, asking for access to different sets of
signals, and with different Purposes. For each of these separately, the AT
server must  assess whether it meets the principle of least privilege.

The example with the insurance company app might be seen as a “corner case”
in that it is likely to do only one request to the AT server (or possibly
multiple identical requests over time), a case where the value of a role
based model is not so strong.
BR
Ulf
-- 
Ulf Bjorkengren
*Geotab*
Senior Connectivity Strategist | Ph. D.
Mobile +45 53562142
Visit www.geotab.com