Resource entitlement overview

[hallundbaek]

Right now it is possible to get an overview over resource entitlements through the API, and it is possible to look up the individual applications that lead to the entitlements.

Through this, it is possible to link application data to resource entitlements, through an external service querying REMS through the API. That situation is fine, but it strikes me as a common use-case, that can be solved generally.

Would such a feature be within scope of REMS? I am thinking something to the tune of :extra-pages where instead of markdown files, it would be resource urn's and application selectors, with the pages in question showing data tables of the selected values.

I've tried searching the open issues, but I haven't found anything of this sort, maybe I didn't look hard enough?

[Macroz]

Shortly, I think in most cases either the (handled) applications or the API has been enough.

For example, there can be an external job that synchronizes the entitlements to an IdP (for access to some download or system), or a CRM system for case management. Both of these likely contain further reporting features or there is no need to check up on the entitlement row itself.

I can see entitlements being a useful report for some users, but nobody has requested one yet. Originally the database table was enough with the additional manual export possibility. Seems like most projects are moving toward the acccess rights / entitlements / claims propagating automatically to another system for automatic access management. So manual work checking up on that is perhaps not required.

[hallundbaek]

I can see how it would be the case that many places have established systems for propagating this information.
The problem with that setup, in my opinion, is that unless you are very careful, you might run the risk of information diverging.

As such I am exploring options to avoid that situation. Specifically where REMS data is the authoritative truth with regard to entitlements/application information.

For that setup, I'm either looking at implementing a read-only overview that is external to REMS, or to implement it directly in REMS.

I'm leaning towards the latter, to piggyback on the auth/roles setup of REMS as well as the underlying data types. In that case its an important point whether or not this would result in having to maintain a fork of REMS, or whether it is a feature you would welcome in upstream REMS.

Of course under the assumption that an implementation of such a feature lives up to your standards.

[Macroz]

In many of these cases REMS is the authoritative source, it's just nobody needs to go there to look at the info.

Inside REMS I think the easiest idea would be to add just another page to the admin pages that just puts the API entitlements into a table. There are plenty of examples, and this is easy because it is read-only. Further features can be added for e.g. filtering or grouping later.

[hallundbaek]

In many of these cases REMS is the authoritative source, it's just nobody needs to go there to look at the info.

Makes sense. For our use-case its the same people that process applications, that need to be able to pull data from overviews, and if they're in REMS anyways, why not give them the overview there, is my reasoning.

Inside REMS I think the easiest idea would be to add just another page to the admin pages that just puts the API entitlements into a table. There are plenty of examples, and this is easy because it is read-only. Further features can be added for e.g. filtering or grouping later.

Yeah, I was thinking something of that sort. Would a general solution that enables that be welcome as a PR?

[Macroz]

Yeah, I don't see why this feature can't be added in some form. We'll discuss it tomorrow in our planning anyway.