search

solid / authentication-panel

GitHub repository for the Solid Authentication Panel
MIT License
11 stars 15 forks source link

Proposed Authentication Upgrade Approach #45

Closed jaxoncreed closed 3 years ago

jaxoncreed commented 4 years ago

Proposed Authentication Upgrade Approach

Scope

At the moment, the Solid ecosystem depends on an authentication token structure that was designed before the relevant draft specification was released by the IETF. In November, work began to replace this token.

The following outlines a proposed approach to move the ecosystem towards a more secure token while easing the migration for the affected existing components.

Background

The need to change the token was originally identified by Justin Richer and the new token is a central part of the current work on the Authentication specification. Given there was no official 1.0 spec for authentication, it was decided to make one with the new token at the center.

In parallel, work was undertaken to use the new token in developer libraries.

Problems with the Current Token

  1. The token was designed before a draft recommendation was released by IETF, so the format is different.
  2. The token is not future proof for verifiable credentials (VC). VCs are useful in access control use cases that are not based on a user’s identity. For example, a resource controller might want to make a document available only to people who can prove they are citizens of a European Union (EU) member state. It would check for a VC signed by an EU government verifying that the bearer of that VC is a citizen.
  3. The current token is not future-proofed to handle client constraining access control.
  4. When both a Pod and application are served over HTTP rather than HTTPS, the current token can be stolen and replayed.

Components Affected

Upgrade Plan Success Criteria

The following are the proposed success criteria for an upgrade plan:

Approach for Each Component

Solid Authentication Spec

The process of writing a normative spec for approval by the authX panel is ongoing. While it is not explicitly required to begin implementations, it is required to confirm that implementations are conformant to the specification.

Solid-Auth-Client

Solid-Auth-Fetcher will replace Solid-Auth-Client as the primary auth client library in the solid ecosystem. While Solid-Auth-Client was designed to operate in the web browser, Solid-Auth-Fetcher is designed to operate in many environments with different interfaces. This will add some complexity to an application developer’s upgrade process.

To ease the transition, a wrapper for Solid-Auth-Fetcher with the same interface as Solid-Auth-Client will be provided. The wrapper should be made available on NPM as ‘solid-auth-client 2.0’ with a security warning to upgrade.

Solid-Auth-Client 2.0 should clear sessions that use the old token.

Solid-Auth-Fetcher

The first release of Solid-Auth-Fetcher should include server and browser compatibility. It should be compatible with the new token but should recognize when it is communicating with a server that only supports the old token and fail elegantly.

It would make sense to release Solid-Auth-Fetcher at the same time as solid-auth-client 2.0.

NSS

NSS must also be upgraded to work with the new token. The upgrade must use an identity provider that can issue both old and new tokens, and a storage server that can accept both old and new tokens. Server maintainers should be able to enable and disable support for each token type in the configuration.

Inrupt.net and solid.community deployments

inrupt.net and solid.community should be upgraded to the new version of NSS. The deployment should be configured to support both the old and new tokens for an agreed period, after which it should be changed to only work with the new token. This gives application developers time to upgrade their applications. The proposed duration for support of both tokens is 90 days.

Solid-Auth-Cli

Solid-Auth-Cli was the counterpart to Solid-Auth-Client that focused on login from the server. The interface for Solid-Auth-Cli is bad practice as it invites the developer to pass the username and password for the user. Therefore, Solid-Auth-Cli should be deprecated and replaced by Solid-Auth-Fetcher.

Libraries that depend on Solid-Auth-Client or Solid-Auth-Cli

There are multiple libraries that depend on Solid-Auth-Client or Solid-Auth-Cli. An incomplete list is as follows:

Those depending on Solid-Auth-Client should be upgraded to use Solid-Auth-Fetcher or Solid-Auth-Client 2.0. Those depending on Solid-Auth-Cli should use Solid-Auth-Fetcher.

Auth based dependencies on Solid-Auth-Client and Solid-Auth-Cli

Dependencies on Solid-Auth-Client and Solid-Auth-Cli should be deprecated. (seen below):

Communications

As this is a significant change, the approach should be approved by the auth panel initially, then a communications plan should be created and approved before communicating with the community.

Approach Summary

The diagram below reflects the current recommended approach for rolling out the auth upgrade to the Solid ecosystem:

https://www.lucidchart.com/invitations/accept/1a670674-6786-4a8d-822c-27f307633de7

zenomt commented 4 years ago

The token was designed before a draft recommendation was released by IETF

nothing has been "released by IETF". draft-fett-oauth-dpop is just an Internet-Draft, submitted by the authors to the I-D repository. it is not a work item of any IETF working group. anyone (for example, the draft's authors) can submit an Internet-Draft that says anything they want. the existence of an I-D (especially one that is not a work item of a working group) carries zero weight. it most importantly carries no implication that it represents a (possibly forthcoming) consensus of the IETF.

the implication in the quoted sentence is that now there is a "draft recommendation ... released by IETF". this is not the case. while this is a minor editorial issue in the above text, i suspect it indicates a more pervasive misunderstanding in this panel as to the vigor of draft-fett-oauth-dpop.

In November, work began to replace this token.

i have been proposing a more secure and more appropriate authentication mechanism continuously since significantly before November. #12 was opened in August 2019, and refers to my proposal which took its current form in May 2019.

dmitrizagidulin commented 4 years ago

@jaxoncreed +1, sounds good.

acoburn commented 4 years ago

@jaxoncreed +1 from me, too

elf-pavlik commented 4 years ago

We discussed during today's call and IMO we shouldn't try to upgrade until we clarify how we handle user restricting clients. In various conversations we talked in terms of capability credentials presented by the client. Even @zenomt draft has comparable notion relying on AppAuthorization document (I try to compare them in https://github.com/solid/authorization-and-access-control-panel/issues/63). In open ecosystem scenarios where each user can have control over restrictions they put on clients they choose to use, client presenting just id-credential doesn't give RS any information about what restrictions it should enforce on that specific client. In one of the calls we discussed that we may only need capability credential and user's webid would be available in there, this way we don't need distinct id-credential at all. We touched this topic during many panel meetings. I think we should not try to move forward until we finally address it. To stay precise, I think we could start moving forward with all the DPoP and general VC parts, but not assuming that client just has to present id-credential. Client could as well just present capability-credential.

jeff-zucker commented 4 years ago

I just spoke with @jaxoncreed and we agreed that solid-auth-cli's login and session management should all be done by solid-auth-fetcher as soon as it is able to handle console-based logins (a few months from now?) but that in the meantime it is the only login outside the browser and should not be deprecated until a solid-auth-fetcher login is available.

In addition to its login/session functions, solid-auth-cli hands requests for file:// URIs to solid-rest which allows rdflib, solid-file-client, the Data Kitchen, and other browser-agnostic libraries to handle the file system with the same methods they use on pods. This part of solid-auth-cli will either need to be maintained or integrated in another way so I will continue working with @jaxoncreed on how that can best be done.

jeff-zucker commented 4 years ago

I am totally on board with deprecating solid-auth-cli - I knew it would happen eventually and having a single auth package is a big win. However, I think the transition needs to be thought out more carefully with a more complete knowledge of the situation specific to solid-auth-cli.

Solid-auth-cli is used by (that I know of)

None of those apps will continue to work in a browserless context with a simple replacement of solid-auth-cli by solid-auth-fetcher. This is because solid-auth-cli, in addition to providing scanty login and session methods which should rightfully be replaced by solid-auth-fetcher, also includes a specialized fetch method which hands off file:// URIs to solid-rest. This allows rdflib and any browser-agnostic or Electron tool to use the local file system and other backends with the same methods as used on a pod but, without running a Solid server. This is useful for moving files to and from the local file system as well as for testing and supports, for example, use of the mashlib databrowser on the local file system.

In order to preserve the functionality of the current solid-auth-cli, either a) there needs to be a cutout in solid-auth-fetcher.fetch handing off file:// URIs to solid-rest or b) users will need to register and inject it into solid-auth-fetcher. I am fine with either of those alternatives, or something else if someone has a better idea. But we should spell this out rather than simply saying "solid-auth-cli is deprecated, use solid-auth-fetcher instead".

So I would say, the next steps are :

acoburn commented 3 years ago

Much of what is described here has been implemented in the intervening ~9 months, and so this is no longer entirely relevant for the panel. If there is more to discuss on this issue, it can be re-opened