Access-control use-cases

This is part of the list of OntologyUseCases.

Cases driving the access-control work. NormanGray described a first draft of this at the DS5PlanningStage03 meeting.

Several of the cases below describe quite complicated scenarios. However, in some cases, the complication is in what happens to the decision, rather than the complication of the decision itself (in X.812 terms, in the AEF rather than the ADF). For example the [quota on run-time] case involves a rather simple decision (possibly just `what group is this user in?'), though it might be quite complicated for the job scheduler, which is playing the role of the AEF in this case, to enforce or implement this decision. Similarly, the [database restricted results] case might require a front-end to do quite a lot of work, even though the decision might be rather simple.

Some of the cases have been gathered from useful threads on the grid@ivoa list. See in particular the threads which include messages from Ray Plante including a requirements white paper, and Guy Rixon describing essentially the delegation issue (as I read it). Ray's valuable requirements paper is most directly focused on authentication requirements, concerning the ease with which credentials might be created and used, as a usability issue, but in its discussion of groups implies some of the authorisation cases below.

Some of the cases ([Virtual-file permissions], [Shared, writeable (virtual) file)] and [Quota on VOSpace storage]) have been flagged as particularly relevant to data providers (thanks to Markus Dolensky for this point).

Binary cases

These are cases which require a simple allow/disallow decision. They are roughly grouped.

[database restricted queries]: different users can make different queries of a database: some users can make no query, others are unrestricted, and others can make restricted queries, such as querying all rows containing a specific flag. For example, a database might make its full contents available to members of a specific collaboration plus researchers based in the UK, and make available a flagged subset of the table rows to researchers based in African countries. When a user requests access to the resource, the resource owner needs to work out which category the user falls into.

[database restricted results]: a user makes a query of a database, but is only allowed to see certain results, either a restricted set of columns, or mangled or anonymised columns (eg, researcher A, doing a clinical trial, can see patient names, but researcher B, doing statistics, can see only anonymised patient data; one can imagine a similar scenario involving members and non-members of a collaboration). The difference from the previous case, is that two users can make the same query, but the results that come back depend on the user.

The following three cases are examples of the very general problem of delegating some parts of the decision-making when making authorisation decisions. There are issues here to do with the inheritance of authority to sub-authorities, and making sure that delegated roles have lower privilege than non-delegated ones: is this an implementation detail, or part of a use-case? To ask this question (talking of `sub-authorities') to some extent presumes that authority is delegated in a hierarchical fashion; if one instead thinks of simply distributing the access logic, or allowing some parts of the logic to be evaluated remotely, then questions of `privilege inheritance' become much less pressing.

[chain of groups]: person A belongs to group J; group J belongs to group K; group K belongs to group L; owner of resource X allows group L to read info and group K to read and write. Person A and all groups are registered in different communities. Must ensure that person A can write to resource X. As a concrete example, a resource might be available to members of collaboration A; the collaboration could decide that its members include all members of institution B; if an individual is in B's staff directory, then they're in collaboration A, so they have access.

[delegate locally]: a resource owner delegates some access-control authority to a local user (local, here, is in the sense that the local user is to some extent under the authority of the resource owner, who can go and LART them if they misbehave). For example, a group's sysadmin might want to give a specific researcher the power to grant DB access to someone who is visiting the group temporarily.

[delegate remotely]: a resource owner delegates some access-control power to a remote entity. For example, Institution A's library might give user X access to their e-journals, as a result of a warrant from Institution B concerning that user. This covers both

• active authorisation, where Institution B can somehow directly affect A's authorisation logic, perhaps by allowing B to assert A's PERMIS-type roles; and
• passive authorisation, where Institution B just warrants securely that X would be allowed in to their library, and lets A do with that information what they like.

Users, or their agents, won't necessarily always have the same privileges

[agent access]: a user creates a job which is to be run unattended, for example as a cron job, as part of a local batch system, or as part of a full-blown software agent. The agent-job should be given access to resources which is the same as, or derived from, the access which the user themself would have. A user might have agent-jobs running at the same time as `interactive' jobs. This is probably more an authentication issue than an authorisation one, but it might be that the best way of satisfying this case is to support a user having sub-identities which inherit access rights from the user, such as an identity which has the user's read-rights, but which is unable to delete resources, or an identity which has a lower quota.

[variable privilege]: a user might have different privileges at different times, because of actions taken by the user, or actions taken by the resource owner (this is distinct from simple time-based access control, where a user is permitted access only at certain times of day). That is, authorisation is not a simple function of identity, but might depend on other features of a certificate. For example, the NESSSI system allows `graduated security', where a user will present distinguishable certificates based on a (weakly verified) email address, on group membership, or on (strongly verified) individual identity, and be granted appropriately varying access in terms of CPU limits or interface restrictions. NESSSI also talks of `visas', which are modifications to the certificate made by the resource owner (I think -- check this).

[expiring access]: a group expires or otherwises loses privilege, with the result that users in that group no longer have access as a result of that group membership; or a certificate might expire or be revoked. This is a rather trivial case, but notes for completeness that access will typically have a lifetime, ranging from years to days, that deleted groups and certificates should not somehow accumulate and clog the system, and in consequence that there are limits on how long access decisions should be cached for. The NESSSI HotGrid certificates are expected to have validity periods of a few days.

The VO and Grid are concerned with controlling access to virtual files, distinct from the physical files they map to.

[virtual-file permissions]: Owner of a file in VOSpace can vary the CRUD permissions on a node in VOSpace, assigning different permissions to particular users and groups. This is like standard practice in local file systems, but see following cases for subtleties.

[shared, writeable (virtual) file)]: A data node in VOSpace is owned by one party and shared for writing with another party. Party of the second part can overwrite the file but:

• may not change the file permissions; therefore, is unable to widen the sharing without the owner's cooperation;
• may not delete and recreate the node representing the file; therefore, may not trash it and create a replica under new ownership.

And finally...

[monotonic access]: if a user is a member of two groups which have different levels of access to a resource, they should receive the more permissive level of access. For example, if an individual is part of a `researcher' and a `student' group, and supposing that the former has access to resources the latter does not, they should be given access to the resource. This is probably what most users and administrators would expect, but it is also part of a more fundamental principle, that one should not lose privilege based on the disclosure of information; or, put another way, that you should not grant privilege based on the absence of information.

[telescope access]: remember that not all resources are software, and `access' might involve controlling hardware such as robotic telescopes. This maps to both binary and non-binary (quota-style) access controls. For example, a user has a "network wide" user name, this maps to having free access to some telescopes and limited access to other telescopes. May also have different kinds of access, e.g. able to queue observations, able to do TOO overrides on some (but not all) telescopes. Also maps to finite time allocation on the resources (different for different systems).

Non-binary cases

The following are cases which require more than a simple binary result. They can probably be recast as binary decisions if necessary -- for example, one could ask `this file is eight days old: do I delete it?' -- but it's an open question whether this can or should be done in general. At any rate, any authorisation system would have to be able to address decisions of the following form, one way or another.

[Quota on VOSpace storage]: A party's use of VOSpace is limited in both size and time. In the general case, these two limits may be linked, e.g. 100GB for a week, 1Tb for a day, 100MB forever.

[Quota on cached results]: A DAL service caches results on behalf of a user. The size of the cached results is limited and the limit varies from party to party. If the service uses VOSpace for access to the cache, then this is the same as quota on VOSpace storage.

[Quota on run-time]: An ADQL service gets a spectrum of queries ranging from sub-second run-times through multi-hour operations to queries that never complete. Queries are aborted after some limit in run-time. The limit varies from party to party. Note that JHU already operate a quota system like this; they found early on that they needed it.

Please add to this list, or comment on the reasonableness of the use-cases already there. One important aspect of the work on this project is to create a `wizard' which will help resource owners express their policies in a form which the reasoner can handle. The list of patterns which this `wizard' can generate will be informed by the use-cases here.

Technologies

Privilege management infrastructures (PMI)

PERMIS is an X.509 PMI. It's heavily based on LDAP servers, and turns out to be rather hard to use. The Shibboleth infrastructure involves where-are-you-from servers which exchange SAML assertions. WS-Policy, SAML, and the OASIS Extensible Access Control ML (XACML) are ways of expressing policies and assertions, as distinct from being systems which implement and reason about them. All of the systems mentioned here are, it seems, rather static, having problems with even moderately dynamic information. Related to that, though distinct, neither PERMIS nor Shibboleth does delegation very naturally (for example, `we'll let you use this resource if institution X would let you borrow from their library').

X.812 | ISO-10181-3

ITU-T Recommendation X.812 (identical to ISO/IEC-10181-3) defines a vocabulary for Access Control. This includes the usefully distinguished set of concepts below. Note that none of these are concerned directly either with authentication (the assertion that a user is who they claim to be) or with the secure transmission of assertions (such as that a given user is indeed a member of staff at a particular institution). Establishing and transmitting these assertions are problems orthogonal to authorisation, and their connection with the authorisation problem is that both are examples of ACI.

AEF

Access-control Enforcement Function. This is the software which permits or denies access to a resource [the /usr/bin/login program is (as I understand it) such a function, as you have to go through this program to get access to a Unix box; it does or does not give you a shell]. That is, the AEF enforces the decision which the ADF makes.

ADF

Access-control Decision Function. This is the function which provides the yes/no decision. The AEF consults the ADF to decide whether to grant or deny access. [In the /usr/bin/login case, this would I think be the crypt(3) function]

ACI

Access Control Information. This is information such as the identify of the individual requesting access (the initiator), their group or role memberships, or information about the properties of the target, such as its confidentiality. [in the /usr/bin/login case, this is, I think, the username/password pair]

ADI

Access-control Decision Information. This is the subset of the ACI which is actually used as input by the ADF. Thus the offered password plus salt is what is given to crypt(3) and compared with the saved password hash, so I think these are part of the ADI, but the username isn't. The time of day, or the number of previous login attempts, if they were relevant to the decision, would also be ADI, though these aren't supplied by the individual. I think that time-of-day and so on would be ACI whether or not they were used by the ADF (and thus were ADI).

The above use-cases are all concerned with different types of ACI, including the ACI which represents the access policies, therefore they are effectively constraints on the ADF which we must employ. Because the Access Control methodology must work with a variety of different technologies, such as web pages, JDBC calls, or RPC -- that is, with a variety of different AEFs -- the ADF should probably be technology neutral.

-- NormanGray - 09 Mar 2006 / 23,25 Apr 2006 / 5,7,10,12 Jul 2006

-- GuyRixon - 15 Jun 2006

-- AlasdairAllan - 07 Jul 2006