Repository navigation
Rethink authentication configuration #672
Description
Right now, the server supports two different auth modes, confusingly named auth: "tls" and auth: "oidc", even though that doesn't cover exactly what they do. The main problem is that this one setting gives the impression that both methods are mutually exclusive, whereas they are not.
Discussions such as #667, #671, nodeSolidServer/solid-auth-client#44, solid/solid#138, nodeSolidServer/oidc-auth-manager#20 show that there is a need for more clarity, and a better configuration option.
This issue tracks general progress and will act as a tracker for multiple sub-issues.
Here are the steps we need to take in my opinion:
- Have one single contract for the entire node-solid-server to track a) the WebID of the logged-in agent b) the method through which that agents has logged in
- Document the above contract
- Ensure that “ask for a client certificate on every resource (WebID-TLS)” can be enabled and disabled independently of other features
- Ensure that “act as an OIDC identity provider” can be enabled and disabled independently of other features
- Ensure that “log in with OIDC through username/password” can be enabled and disabled independently of other features
- Ensure that “log in with OIDC through client certificates (WebID-TLS)” can be enabled and disabled independently of other features
- Ensure that “accept bearer tokens” can be enabled and disabled independently of other features
- Examine whether we want to always translate successful logins into an Express cookie-based session
- Examine whether we want to allow turning on or off cookie-based sessions
- Create a configuration section that allows to enable and disable all of the above options independently
- Update the
initgenerator to create the right config - Remove the old
authconfig section
Feedback welcome.
Activity
elf-pavlik commentedon May 13, 2018
I see that currently those 3 mechanisms allow authenticated requests:
Few questions come to my mind:
RubenVerborgh commentedon May 13, 2018
Remark by @timbl that we should differentiate between AJAX requests and regular browser requests. For the latter, cookie-based sessions are very useful.
elf-pavlik commentedon May 13, 2018
I understand that we can rely on bearer token only when we make requests with Fetch API in javascript. Regular browser requests only support client certificates and cookies.
I think in most scenarios RDF Sources would get requested with Fetch API, but Non-RDF Sources which IRIs get used directly as values of
srcattribute in HTML elements would end up as regular requests.In that case, WebID-TLS could trigger cert selection popup if media resource embedded in the page requires it. How WebID-OICD supposed to handle those cases if browser doesn't have active cookie session with the origin of that embedded media resource?
I'd also like to check if Service Worker can intercept regular browser requests for media resources and give control back to developer over how requests are performed, possibly also to include bearer token or request Federated Credential solid/solid#142 if needed for WebID-OICD flow.
RubenVerborgh commentedon May 13, 2018
We'd need some scripting to detect this and help us with that.
That might be possible to a certain extent! I am interested in porting solid-auth-client to a worker, so I can run it in the background (as we currently do for our query client, for instance).
elf-pavlik commentedon May 13, 2018
I started separated issue to discuss Service Workers including possibility of using them in such scenarios. solid/solid#143
elf-pavlik commentedon May 14, 2018
solid/solid#142 (comment)
Based on above, server not acting as IdP (OICD Issuer) would never use cookies. Given that, I think for general role of Resource Server (dataset origin) we should never rely on cookie based sessions and for authenticated request only use:
This way it would not matter if client interacts with datasets on same origin as user's IdP or datasets on all other origins.
melvincarvalho commentedon May 15, 2018
Thanks for putting this together!
Will there also be a sub issue related to the initialization of a server for the first time. ie running
Possibly some of this will change too. Is it covered in an existing sub issue?
RubenVerborgh commentedon May 15, 2018
@melvincarvalho Added to the list above
kjetilk commentedon Aug 6, 2018
The proposed changes sound quite large and intrusive, are they? Is this something we should aim for 5.0.0, or is it rather something that should be addressed in a later release where they can be first addressed at an architectural level?
RubenVerborgh commentedon Aug 7, 2018
Let's aim for 6.0.0 (it's not assigned to 5.0.0).
mhamann commentedon May 10, 2019
Reading through the initial summary, is part of the thinking to make the configuration extensible so that an admin could pass their own OIDC provider into the
ResourceAuthenticatorinitialization such that tokens from 3rd parties could be accepted as valid?