IP-based AuthN/AuthZ: modeling vs. application engineering concern, and use cases

[anarchivist]

See comments on #70. In work on the Hydra in a Box models we've recognized the need for providing IP-based auth for objects managed by a Hyku application, Throughout some of this deliberation (see, for example hybox/models#16 and hybox/models#52) we have not been able to determine whether this should be a modeling concern or an application engineering concern.

Some of the discussion on #70, e.g. raised by @diegopino notes that "[this] could be more an application or implementation concern/or even AuthZ via WebAC than something you would like to keep with your RDF properties [...]." Some of the ambiguities for me are the question about where in the stack these IP-based restrictions are implemented, and in that case, there probably need some demonstrated use cases to support those implementation decisions.

Caveat: I realize may not necessarily be a PCDM concern, nor specifically even a Fedora/LDP concern. It does seem to touch on our models and implementation around LDP and WebAccessControl. In any case some assistance in how to sharing/framing a set of questions with the W3C's ReadWriteWeb CG would be useful, because I'm still struggling with the uncertain status of WebAccessControl and the supporting BasicAccessControl Ontology as a "standard" given the existence of widely differing implementations and extensions. If it makes sense to have a broader conversation within "our" communities beyond PCDM (e.g. roping in more FCREPO, Hydra, or Islandora folks otherwise not represented directly), I would welcome that.

[DiegoPino]

The "do you want to change millions of resources to allow new network client to access them" use case was one of my concerns when thinking about going on a per-resource restriction semantic based modelling approach, as also the semantic itself of the restriction since it could add a different knowledge layer to a probably and well defined concrete RDF type for the resource itself, which could better belong to a different, more appropriate RDF resource type, like an Agent or group. A restriction model that works on the AuthZ layer plus some application layer to enforce that, which could be simple if the properties and ontologies used are clear, and tied to agents and groups sounds a natural choice to me. Also since Authz is being modelled in Fedora preferentially via webAC, so the also natural choice would be to have predicates that define the restriction on similar, linked or same resources as webAC does, even when enforcing should be dealt by Hydra or Islandora to avoid that burden for F4.

[anarchivist]

From comments on #70:

@jcoyne 💬 :

Please consider the case where you switch IPs. Do you really want to update all your objects? I think you should make this an AuthZ concern. Being in a specific IP address range makes you a specific class (group) of user. The use case is members of a certain group (e.g. The people located at Brown University) may view this object.

@tdonohue 💬 :

FWIW, DSpace implements IP authorization exactly how @jcoyne describes. In DSpace, one or more IP addresses (or ranges) can be "mapped" to a Group (e.g. "On Campus Users"). The Group is then given AuthZ rights. DSpace uses these same Groups to define embargo rights (e.g. an object is limited to view by "On Campus Users" until a specific date). So, I agree with @jcoyne here.

[awoods]

I agree that mapping IP addresses to groups is the generally recommended/practiced approach... which likely takes this conversation out of the PCDM domain.

Is there an additional outcome we would like to get from this issue, such as your mentioned use cases... or since this practice is commonly in place, maybe some links to documentation for how folks in the community implement this pattern?

[DiegoPino]

@awoods true, it's out of the PCDM domain. Where do you think this would fit better? Still an semantic issue and maybe there is space here to contribute with use cases that involve other ontologies and modelling that still include and affect PCDM. Like an integration guide/examples. Not sure

[awoods]

It strikes me as an implementation pattern for setting up your webserver to map I.P. addresses to groups. It is less clear to me where, if anywhere, that intersects with ontologies. This seems like it would be appropriate application documentation... but I may be taking a narrow view of this topic.

[anarchivist]

I'm in agreement about it being outside of the PCDM domain and ontologies after the discussion. I do think there's probably value about there being an implementation pattern guide somewhere (perhaps for Fedora?) as @DiegoPino suggests. I'm going to close this issue but happy to discuss this further.

[awoods]

JIRA ticket created: https://jira.duraspace.org/browse/FCREPO-2381