Content
View differences
Updated by Jan Sandbrink over 1 year ago
Our goal of this EPIC is to allow setting up the integration between OpenProject (OP) and Nextcloud (NC) in a way, that does not require users to visit consent screens from both applications. Instead of mutually being OAuth Client and server for one another, OP and NC can be set-up to agree on a common OpenID Connect identity provider (IDP) from which they obtain user-bound tokens to call each other's API.
From the user's perspective this improves the UX, while we are hopefully able to lay the technical foundation for similar authentication patterns for future/other integrations.
This Epic covers two similar, but slightly different use cases:
* The IDP issues "wide use" access tokens
1. OP obtains access and refresh token during single-sign-on of the user
2. OP recognizes that the token already grants access for API calls to NC
3. OP uses the token directly to make API requests in the user's name
* The IDP issues "narrow use" access tokens
1. OP obtains access and refresh token during single-sign-on of the user
2. OP recognizes that the token does not grant access to NC, but that the IDP is capable of token exchange
3. OP exchanges the token for a token capable of making requests to NC
4. OP uses the obtained token to make requests in the user's name
We want to successfully integrate this feature with the following IDPs:
* Keycloak (supports both use cases)
* Nextcloud as OIDC provider (may only support the use case with "wide use" access tokens in the beginning)
In order to make it as easy as possible for new users we need to come up with a good, detailed plan. It involves at least:
* A compatible OIDC/OAuth 2.0 OIDC Identity Provider
* e.g. Keycloak or Nextcloud with the OIDC app
* Nextcloud
* Nextcloud core accept/verify and store those sessions on incoming API requests
* Nextcloud app
* to accept/verify (ideally handled by core) incoming API requests for API endpoints that are provided by the app
* uses such sessions for outgoing requests to OpenProject
* OpenProject
* Allowing OpenProject to be configured to use that special type of setup
* Provide railguards and helpers to avoid/detect configuration errors
* Accept/verify these tokens on incoming API requests
* Store tokens associated to a user
* Make the the file storage connection use those tokens when emitting requests to Nextcloud
* Take special care of the background jobs (they currently use a Nextcloud app password as there is no user session)
> This plan is still pretty rough. This is an integration topic with high complexity but definitely worth the effort. I recommend to work with proofs of concept in the beginning. It also requires that all three involved parties are working closely together.
This is an Enterprise Edition feature as SSO already is an Enterprise Feature and this one depends on SSO.
From the user's perspective this improves the UX, while we are hopefully able to lay the technical foundation for similar authentication patterns for future/other integrations.
This Epic covers two similar, but slightly different use cases:
* The IDP issues "wide use" access tokens
1. OP obtains access and refresh token during single-sign-on of the user
2. OP recognizes that the token already grants access for API calls to NC
3. OP uses the token directly to make API requests in the user's name
* The IDP issues "narrow use" access tokens
1. OP obtains access and refresh token during single-sign-on of the user
2. OP recognizes that the token does not grant access to NC, but that the IDP is capable of token exchange
3. OP exchanges the token for a token capable of making requests to NC
4. OP uses the obtained token to make requests in the user's name
We want to successfully integrate this feature with the following IDPs:
* Keycloak (supports both use cases)
* Nextcloud as OIDC provider (may only support the use case with "wide use" access tokens in the beginning)
In order to make it as easy as possible for new users we need to come up with a good, detailed plan. It involves at least:
* A compatible OIDC/OAuth 2.0
* e.g. Keycloak or Nextcloud with the OIDC app
* Nextcloud
* Nextcloud core accept/verify and store those sessions on incoming API requests
* Nextcloud app
* to accept/verify (ideally handled by core) incoming API requests for API endpoints that are provided by the app
* uses such sessions for outgoing requests to OpenProject
* OpenProject
* Allowing OpenProject to be configured to use that special type of setup
* Provide railguards and helpers to avoid/detect configuration errors
* Accept/verify these tokens on incoming API requests
* Store tokens associated to a user
* Make the the file storage connection use those tokens when emitting requests to Nextcloud
* Take special care of the background jobs (they currently use a Nextcloud app password as there is no user session)
> This plan is still pretty rough. This is an integration topic with high complexity but definitely worth the effort. I recommend to work with proofs of concept in the beginning. It also requires that all three involved parties are working closely together.
This is an Enterprise Edition feature as SSO already is an Enterprise Feature and this one depends on SSO.