search

nodeSolidServer / node-solid-server

Solid server on top of the file-system in NodeJS
https://solidproject.org/for-developers/pod-server
Other
1.78k stars 297 forks source link

Add a no account option #1148

Closed jason076 closed 5 years ago

jason076 commented 5 years ago

I am currently evaluating if the node-solid-server is usable as a web access control capable ldp back-end, because I have not found any libraries for that purpose on npm. I have reviewed the whole node-solid-server code, and it seems that the access control check is coupled with the webid feature. If the "webId" parameter is set to false, everyone is allowed to read and write on the ldp-endpoints. If webId is enabled then the user is enforced to have an account on the solid-server, because the account-manager-middleware does check for it. This behavior is useful, if the user should have to accept terms and conditions before accessing the data. But isn't this behavior in conflict with the idea of oidc? Shouldn't a client who is in charge of a webId be able to read and write data without to sign up an additional account? Im am thinking about the following workflow:

  1. The Client is sending a request with a bearer token in its header which contains a valid webId.
  2. The server decodes the token
  3. The server strips of the issuer claim and the webid
  4. The server verifies the key against the public keys of the issuer
  5. The server performs the acl check as it would if webId is enabled
  6. The server performs the requested operation and sends a response

I think there are three possibilities to do that:

  1. Implement this behavior directly into the node-solid-server with an option to disabled the account checking
  2. Do a fork from the node-solid-server project strip off unnecessary code and publish an ldp server middleware capable of verifying webIds and do access control.
  3. Revise the project structure and publish the ldp and access control middleware as standalone npm packages, thus it can be used to build a back-end server.

Personally I would favor the third option, because that would increase the re usability of the code. I would be glad, if your write your opinions about that idea and starting a discussion.

michielbdejong commented 5 years ago

Yes! What you're describing sounds like the webid option has two effects: switch identity provider role on and off, and switch access control on and off. There should be a way to configure NSS to have access control but not the identity provider role. If not, then that's a bug!

jason076 commented 5 years ago

Yes! What you're describing sounds like the webid option has two effects: switch identity provider role on and off, and switch access control on and off. There should be a way to configure NSS to have access control but not the identity provider role. If not, then that's a bug!

Maybe I missed something. It could turn out that the multiuser-option turn the account check off. I will do some test now to verify it.

jason076 commented 5 years ago

Ok, I have just read the route handlers wrong. I have read router.get('/', checkAccountExists(accountManager)) as router.get(checkAccountExists(accountManager)) and that would have blocked any user who has no account on the server. Just to be certain about the correct behavior, I have run a short test. I have set up two solid server and created an account on each server, lets call them alice and bob. After that I gave bob read and write access to alice profile and logged bob into a sample angular application. I was able to read and write to alice profile by sending bobs bearer token. Both servers were running in multiuser-mode with oidc-authentification. Thus everything is working as intended.

Regarding the usage of the nss as a ldp backend server with webacl, the server could be started with multiuser=false and webid=true. I think using a nss like that is not the purpose the server was built for, but I don't know any npm packages which are capable of handling webACL in that manner the nss does. But if the nss is used as a backend-server, there is lot of unnecessary code like the whole account management. Because of that it would be great to publish a ldp and a webACL middleware seperate from the nss package and when reuse it in the project.

Maybe I will do that in a fork of this project and publish it, when you can decide if you want to use it or not.