Authentication design

Hi all,

before starting any serious development, I’d like to present my thought regarding authentication.

Currently, there is no proper user management in Cristal, and we are either accessing backend resources as guest or with hard-coded test credentials.
We want to move to a proposer implementation of authentication where users can connect to backends securely while using account they have access to in the backends.

Use Cases and ReQuirements

  • UC1: a backend can be without authentication (e.g., the filesystem backend)
  • UC2: a user can authenticate to a backend
  • UC3: a user can log out of a backend
  • RQ1: we must not store user’s credentials locally (i.e., Cristal must never ask for a user password)
  • RQ2: the authentication workflow must work in Single Page App mode as well as in the Electron App
  • RQ3: if Cristal is directly embeded in the UI of the backend, it must be possible to directly use the currently logged in user

Architecture

While each backend could provide its own authentication mechanism, we should aim for using open and popular authentication protocols such as OAuth2 or OpenID.
For instance, the two main backends we currently support have support for those protocols. Sadly, the extensions allowing the use of OAuth2/OpenID are not packaged by default.

Thanks.
Let me know if you have in mind design considerations that are not explained in this post.

PS: Some resources I found interesting when documenting myself

OIDC is becoming more and more important, so I guess we might discuss moving that to xwiki-platform one day (when its implementation of various common OIDC extensions is more complete, probably, as the extension is still very active).

1 Like

This makes me realize one more requirement:

  • RQ3: if Cristal is directly embeded in the UI of the backend, it must be possible to directly use the currently logged in user

This would be useful for instance if Cristal is directly used as the front-end of XWiki.