Creating an app with a Client/Admin where admin can query connected client pods

Build a Solid App Solid App Development FAQs
1

TLDR: How do I create an application in the Solid spirit where standard users can connect pods to the app, and administrators can query these pods perpetually afterward in some unified way? As the Solid-OIDC documentation stands, I’m not sure how this is possible, if I’m meant to use tokens or write to the users profile, or alter the .acl lists.
An architecture-in-progress is below, how can I make it more granular with specific technologies? Or should I re-architect this app in some way to make more sense using Solid?

Hey Solid Community,
I’m trying to make an application with Solid that allows users to connect pods hosted by specified providers to it. App administrators should then be able to query the linked data stored at these pods in some unified way. (This is a proof of concept I’m doing for a University course)

An example use case of this application is at a credit risk assessment company. They may require users to sharing read access to pods offered by their financial institutions. Administrators can then easily query data from the user’s pods to quickly perform a provider agnostic risk assessment.

Thus I want this app to have the following two characteristics:

  1. A user should be able to grant the application persistent access to pods they have access to
  2. An administrator should be able to perform queries to all pods connected by users.

Architecture.JPG

In my reading I’ve come across several parts of the ecosystem that would help me to this end, but I have been unable to bring them together into a comprehensive architecture that has really clicked in my head. In the preliminary architecture above I’ve sketched out the rough structure, but I am struggling on implementation details. How do I let admins query pods shared by users? Should I store OAuth tokens? How do I log users in differently to admins? etc. I’m basically not sure how all the jigsaw pieces fit together, or if I’m missing any pieces.

I would like any help possible on getting started creating this application as I am struggling to break ground and am getting a bit lost in design and piles of documentation. Below I’ll elaborate roughly about where my thoughts are so far, and answers to them would be dearly loved, however asking further questions that I haven’t thought of would also be appreciated. Screenshots of my application so far are using solid-ui-react to handle login/logout.

(1) User granting an application persistent access

A user should be able to login to an application as usual using their WebID. This is trivial using solid-ui-react.

Login.JPG

From here users are able to connect pods, and view those they have already connected. This information will hopefully be displayed a screen roughly similar to the one below. (Hopefully it crystallises how the app should work for you. Users can connect pods from a list of “trusted” pod providers to ensure data is up-to-date and valid)

image
image715×954 31.2 KB

I am currently trying to work out how to persist application connections to pods between WebID login sessions. I have several questions:

  1. How do I create and serve a “Client ID” on my application? Where should I store/host this? (I think this is relevant to persistent permissions granting? But I may be wrong…)
  2. How do I maintain per pod connections between sessions in a way that any administrator of the application can query user data?
    a. Learning about OAuth and Solid-OIDC recently has been interesting, but storing the OAuth token between sessions seems very much like the incorrect way to do things. Are there any suggestions as to how this could properly be done

(2) Administrator Pod Querying

  1. How would I structure the application to serve a different frontend for standard users than to administrators? This doesn’t have to be rigorous in terms of security as it is a proof of concept. Should I create a text file with administrator WebIDs in it, and serve a different frontend if the logged in WebID is equal to that?
  2. How should the app be architected such that any administrator can query the connected pods of any registered user?

Any thoughts on either of these subsections, or how I should structure this application overall would be greatly appreciated :smiley:

1 Like
2

administrators can query these pods perpetually

If I understand correctly, the goal of your “administrators” is to have them query data needed for the risk assessment reports.

In this case the easiest setup to get you started would probably be (there are more interesting things you can do with access control policies but I’ll ignore them for now):

  1. Each user is provisioned with a Pod (in particular a WebId + at least one storage Storage)
  2. Each “admin” is provisioned with their own Pod (or there is an admin Pod which all admins can log into).
  3. The “user” grants the "admin"s WebId read-only access to the resources / containers within their Pod storage needed for the risk assessment. There are docs on how to do this step using Inrupt’s client libraries here. This way the administrators can perpetually query those resources in the Pod using any application they like (at least until a user revokes access).

How do I create and serve a “Client ID” on my application? Where should I store/host this? (I think this is relevant to persistent permissions granting? But I may be wrong…)

If you want permission by application rather than just user yes you will need this (my recommendation above ignores this for ease of getting the first version of your application up and running quickly).

This website can be used to help you generate a ClientID document. It must be served as a .jsonld document under your website domain.

How do I maintain per pod connections between sessions in a way that any administrator of the application can query user data?

Pod’s aren’t “connected” per se. Rather you grant users (by WebId) and applications (by ClientId) permission to read & write resources in your Pod storage; and this is not contrainted to a particular session. Inrupts client libraries can be used to help set these permissions (c.f. Access Policies: Universal API — Inrupt JavaScript Client Libraries).

2 Likes
3

Interesting, thanks jeswr!