Discuss AuthZ

[dannylamb]

What can we do to ensure people don't see what they shouldn't, and can be done at a level of granularity similar (if not exactly equal to) what Drupal provides.

First guess from everyone is probably WebAC.

[DiegoPino]

We could explorer https://www.drupal.org/project/authorization and the LDAP example https://github.com/Laudanum/ldap. AuthZ and AuthN are pluggable in Drupal 8 and we can add whatever we wan't. Since Users are entities we should probably also explore how to sync fedora4 webac resources (agents, etc) to Drupal users.

[whikloj]

WebAC is a work in progress, but I think there is some movement from the W3C LDP Next Community to look at improving it.

[whikloj]

Also, we don't need to sync users/agents to Fedora. Fedora's WebAC module allows both agents and groups to be URLs, so we could actually have Fedora check Drupal for the list of agents in a group.

[ddavis]

This is a big subject. To make Drupal work well its likely that AuthZ decisions must be made inside Drupal (or with a central authority source that is very fast and very compatible with Drupal). e.g. menu items, decorators, and buttons must be responsive (much like any MVC UI). Many Authz decisions must be made a priori. Thus Fedora (and WebAC) likely should not drive Authz in Drupal. Only the simplest sites are likely to work until and if Drupal embraces WebAC as a core mechanism. Since CLAW already centers its operations around having Drupal nodes, arguably AuthZ should be no different for now. Of course, a "system-level" accommodation needs to be made with Fedora but this is no different from any potentially integrated component that has an existing AuthZ architecture.

Lots more to discuss. We are currently exploring Organic Groups and building up use cases.

[dannylamb]

I agree with @ddavis on letting Drupal be Drupal, and not letting Fedora drive our view of AuthZ.

I know Solr has plugins for rules based permissions. Just like with WebAC and Fedora, we could make Solr mimic Drupal. I'd like to look into that instead of hiding results using fq's like in the current stack. But then what about ElasticSearch? Where do we draw the line?

Triplestores have even less options, and are a mixed bag. Some just provide two endpoints, one for read only access and another for SPARQL update.

The more you look at it, it seems like a 'systems' or 'operations' issue for each organization as they choose what to take on. Especially if they want to swap out search engines or triple stores. Yet, we're still on the hook to provide a working system through a dev environment. So we gotta figure out precisely what we're willing to support, and make it work. We'll never be able to sustain integrating every random thing for people, but at least we can provide them a starting point.

[ajs6f]

So we gotta figure out precisely what we're willing to support, and make it work. We'll never be able to sustain integrating every random thing for people, but at least we can provide them a starting point.

This. Scope is everything here. The traditional Fedora program argued that access policy is an inherent component of the intellectual object and must therefore be managed in the repository. Whether or not that argument holds in the abstract, it doesn't seem to have worked out in practice. So CLAW has got to decide (at least for now) what it will do, and what it will leave to the integrator.

[DiegoPino]

@dannylamb whatever option we choose it must be consistent with our other promises. Making Drupal be aware of WebAC does not mean to make Drupal permission system depend on Fedora4 in anyway, but to be able to translate WebAC into/from Drupal. E.g, the MVP document says that you should be able to recreate an Islandora CLAW (drupal side) repository from a Fedora4 one. I just want that to be possible without demanding our users to apply permission by hand (using the Drupal UI) to 500.000 nodes.

[dannylamb]

@DiegoPino Apply permissions by hand? I'm assuming we'd use access functions like hasPermission() on the user object for most things. If you mean you want to recreate users with roles and perms intact, then yes, we'll flush users to Fedora. But that still doesn't mean I'm making Fedora the center of our authorization layer.

[dannylamb]

Or we re-word the promise to say we'll restore your content only :D

[ajs6f]

I understand the whole "grand promise" of CLAW as being that neither side (Fedora nor Drupal) is indispensable. Action and information is always available from either side. Neither is privileged.

[ddavis]

There is great wisdom in these comments. AFAIK, SI is pushing some boundaries. Drupal is primarily a Web CMS. SI needs to push it as far as possible towards a collaboration portal. We plan to stay with Islandora because, with CLAW, it is developing extensions for building a linked-data capable UI with key integrations with Fedora and a reliable execution environment (Karaf-Camel). We are at 5 million objects and expect to grow at 5 million per year. I expect this is on the large size for a typical Islandora installation. And, as I noted above, we need to push Drupal towards more complex user interaction models that are not is Drupal's traditional sweet spot.

A big outstanding wish is having a solution to "distributed policy enforcement" in a system (or a system of systems). But this is a very big, largely unsolved problem as we know. For the moment, a pragmatic detente between Islandora and Fedora keeps the lights on. If anything, for now I would run a thought exercise where I started with Islandora/Drupal (its applications and information models) and project its AuthZ requirements on to a given Fedora instance, not the other way around. My assumption is that Islandora would be the first policy enforcement point, and no operation it permits correctly would be rejected by the associated Fedora instance. That supported microservices would use the same security model and only run into AuthZ problems if they were incorrectly written. Fedora, for now, would not be visible directly to "external" systems. And external system integrations would be future issue.

Fedora would still be an enforcement point for data center security. But applications would be required to comply with the instance's security model for some body of its content. I still consider that neither side is privileged but there is a pre-established contract for a compatible security model that each enforces independently.

[DiegoPino]

@dannylamb by hand i mean: if i have a fedora4 repo with WebACL applied on it's resources and i connect an Islandora Repo to it -> on sync from fedora to islandora -> i don't want to manually apply Drupal Permissions on each imported resource. I want Islandora to undestand/translate and enforce WebACL

[dannylamb]

@whikloj you mentioned a use case in the last CLAW call. wanna put it here?

[ajs6f]

In a sense, we have a micro- and macro- cosm here. In the small, how do we integrate Drupal and Fedora? In the large, how do we integrate CLAW and other stuff? We can't take the mirroring principle beyond CLAW itself, internally. But within CLAW, I think it's the right answer.

[ddavis]

After the D.C. Fug and a meeting I had with Luke Brainbridge of Digital Echidna I am more convinced that permissions in Islandora and in Fedora are two separate, albeit interacting, concerns. Bainbridge implemented a 2/3 of use cases solution for global permissions in Islandora 7.x with OG and XACML. SI is experimenting with light-weight Drupal wrapper nodes for Fedora objects with all enforcement in Drupal. At the FUG, there was a consensus that many Islandora implementations need to have policy features the support highly interactive rich web applications.

I would imagine Islandora and Fedora being equally privileged each providing their own policy enforcement. Then, optionally, having means to take a policy expression transferred by CLAW from Islandora to Fedora and vice-versa, potentially including a transformation in between, would be a good way to integrate the the two components.

Fedora can still keep its promise that permissions are directly related to content. Islandora may choose to make the same promise or not, but regardless permissions would be wholly managed inside Islandora too. If we have to wait until there is a distributed policy expression language that is supported by both products I suspect we could wind up getting stuck. No one I heard is prepared to make a firm statement of what the distributed policy expression language should be but there is a good place to put it when it is ready, sync'd by CLAW.

Is this a way forward for now?

[ruebot]

@midnightLuke ^^

[DiegoPino]

@ddavis. On Claw you get OG groups or any other permission module that is available for Drupal 8 or you as institution want to develop for granted: every fedora resource can be synced to a Drupal 8 entity so what works for Drupal will work for you. So there should be really no concern there.

But since CLAW also allows other repository users resources(means not islandora/ not via islandora ingested contents to fedora4, and no Drupal OG aware permissions as consecuence) to be synced, webAC to whatever we can provide on Drupal world translation is a need, or at least a good start in my opinion.

For what i remember, webAC is the current common denominator for permission handling on Fedora4 and i would like to allow that.

As you state, each system could expose it's own, dependent or independent, common or completely different way of managing permissions. More over, on the Fedora4 side, i would assume we would mostly handle permissions "on behalf of" , meaning a unique Authentication(user/pass) and passing Users and groups as headers.

The key here is what we provide out of the box, (the simplest use case) and how we do allow for standard Fedora 4 scenarios that do implement webAC to have their permissions respected and integrated back to Islandora, if the user/admin wants so.

[DiegoPino]

@ddavis forgot about this. What are those:

2/3 of use cases solution for global permissions in Islandora 7.x with OG and XACML

Would love to read about your use cases. Thanks!

[midnightLuke]

For the OG and XACML solution we ended up mapping og roles to global roles and essentially spoofing default roles for Islandora so that we didn't need to make modifications to the drupal filter. This ended up taking the form of two modules: OG Global Roles and CWRC: XACML Modifications. The first module creates and manages global roles on behalf of the OG module and tries to hide the extra roles from all the global UIs (or else these UIs would become unreasonable pretty quickly). The second module focuses on the XACML editor and makes some UI tweaks by adding a third "group" option that contains all the group roles and adds the Chosen library to the XACML editor for easier searching/filtering.

We will hopefully be open sourcing this work soon, but essentially this was the best way we could find to keep the POLICY datastream in the repository as the "single source of truth" for access decisions on objects, while also leveraging the OG module for granular permission control with Islandora.

[whikloj]

Sorry just getting around here again. My use case is around some of the current workflow and permissions available in the current Islandora stack that we would very much like to see available in CLAW. Here is the use case

[dannylamb]

I might be coming around to what @ddavis was saying.

So maybe this suggestion is a bit reckless, but since in CLAW users don't directly interact with Fedora anymore, don't we need to only worry about Drupal? All Islandora would need is a user in Fedora with sufficient (admin-esque) privileges. The rest is up to the repository administrator. And if said administrator wants to slather xacml or webac triples all over their repo, that's fine as long as it doesn't interfere with Islandora's user.

Thinking of how Drupal works, it just has a drupal user for SQL and its own db, and doesn't have access to the other databases, right? The application handles the authorization within the Drupal database. We should just do the same.

[ajs6f]

Just as a thought experiment, let's think about the worst possible thing that can happen in the situation @dannylamb describes. Are there security problems that could arise?

[DiegoPino]

My 25 Cents. The ability to re-create an Islandora Site (in case of the worst possible situation, like Database failure on the drupal side) starting from a Fedora4 Repo would be nice.
e.g If the original and dead islandora side had many fine grained permissions and those where not reflected someway (ideally as close to WEBAC or any other standard out there) in Fedora4 also, restoring those manually in a million resources repository would be a time consuming, if not, hate-to-islandora-devs developing, task.

[dannylamb]

@DiegoPino Is there not a way to backup/restore/migrate permissions? Not sure if Features handles that. I personally don't want to put drupal roles/perms and users, etc.... in Fedora if we don't have to.

[dannylamb]

Turns out exporting roles in configuration management actually exports the permissions attached to that role.

[DiegoPino]

@dannylamb true. I don't want to put Drupal permissions either, but i feel we will have to search for a midpoint: The Catastrophic use case i brought here (SQL dies, drupal explodes in fireworks and blue smoke) affects also permissions, handled in the same storage layer. So this would assume that if you want to restore your permissions you need to have that set of yaml config files in hand exported on a daily basis (i know i know, other topic, not really about architecture). Under those terms, then Drupal is the master in CLAW env. And i'm not completely convinced.

But there is also another concern, less theoretical than who is the master/source of our architecture: permissions, roles are tied in Drupal to Node ID, NID (or getId() response if custom entity) or UUID or both? Even when every entity has an internal UUID (and those permissions exported will have be bound to its original object) we need a way to make sure that on "re-create-from-fedora4" the IDS match so "backed up" permission get attached to what they supposed to be. How do we do that if those id's are autogenerated? Do we have the ability to guide that? And if we do have the ability to guide that -> provide those on creation, do we have those numbers, for each resources that could have a permission applied in Drupal an tripple in Fedora (again and back, Drupal data in fedora)

I feel one simpler way, at least on my humble point of view, would be to map permissions from Drupal ones to whatever WebAC is able to provide in granularity, even when that means to a better granularity than Fedora 4 is actually capable to handle (WebAC seems to be a larger semi-standard?). That would at least, live up with the expectations on being able to revive a dead Drupal site just based on fedora.

[ruebot]

The ability to re-create an Islandora Site (in case of the worst possible situation, like Database failure on the drupal side) starting from a Fedora4 Repo would be nice.

IMO, if you have Fedora 4, you should also have an export of the Drupal database. But, I do see what y'all are getting at.

don't want to put drupal roles/perms and users, etc

Hrm... does this also mean we won't be saying what Drupal user did what on each object like we do in 1.x now via the Drupal filter?

[dannylamb]

As far as Fedora is concerned, there's a single user for the entire application. I hadn't thought of the implication to auditing.

Would it be possible to add users to a group and give that group sufficient privileges? That would work with every authz method Fedora supports and keep the audit trail tied to individual users.

[ruebot]

As far as Fedora is concerned, there's a single user for the entire application. I hadn't thought of the implication to auditing.

That's not good at all from a preservation and auditing perspective, and is a step back from what we do now in 1.x. That functionality is one of the huge reasons I use Islandora over Hydra.

[dannylamb]

And how do you feel about the proposed solution to that problem?

[dannylamb]

And to that affect, what does Hydra do to ameliorate the situation?

[ajs6f]

It doesn't-- I think that's @ruebot 's point. It uses one user. But Hydra is a terrible model for how to interact with Fedora.

[ruebot]

@dannylamb sorry, what's the proposed solution?

[dannylamb]

Would it be possible to add users to a group and give that group sufficient privileges? That would work with every authz method Fedora supports and keep the audit trail tied to individual users.

For basic auth, it would be giving all users 'admin' roles. WebAC and XACML could do this and give people the ability to expand/refine permissions in their Fedora.

[ruebot]

My biggest concern is getting the Drupal user in the audit log for any CRUD actions on a given object. If we can do that, then, naively I think we don't have to worry about WebAC/XACML because it'll all be done that the Drupal level. That's if I'm understanding @dannylamb correctly 😄

[dannylamb]

Yes, we can have a functional audit 😃

If the filter's still in the picture, I'd like to dust it off and see if we can use JWT's. Should be straightforward to implement as a ServletFilter. I'd like to provide those from Drupal and use them for both Fedora and the microservicces.

[ruebot]

JWT's? What's that?

[dannylamb]

JSON Web Token

[acoburn]

https://jwt.io/ JSON Web Tokens. They're all the rage.

[whikloj]

👍 to fixing up but continuing the use of the filter.

[ddavis]

Thanks for the link to JWT, it looks very interesting.

[ruebot]

@Islandora-CLAW/committers are we ok to close this one since we've implemented JWT? #520

[dannylamb]

Close it. If we need to revisit a particular facet of the discussion we can make a new issue.