mirror of
https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk.git
synced 2025-12-06 07:21:36 +01:00
chore(docs): Merge info repo contents
This commit is contained in:
committed by
Thorsten Roßner
parent
3fcfa00503
commit
790baebf71
BIN
.opencode/screenshots/01-portal-desktop.png
Normal file
BIN
.opencode/screenshots/01-portal-desktop.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 96 KiB |
BIN
.opencode/screenshots/02-dateien-desktop.png
Normal file
BIN
.opencode/screenshots/02-dateien-desktop.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 232 KiB |
BIN
.opencode/screenshots/03-projekte-desktop.png
Normal file
BIN
.opencode/screenshots/03-projekte-desktop.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 370 KiB |
BIN
.opencode/screenshots/04-wiki-desktop.png
Normal file
BIN
.opencode/screenshots/04-wiki-desktop.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 321 KiB |
170
LICENSES/CC-BY-SA-4.0.txt
Normal file
170
LICENSES/CC-BY-SA-4.0.txt
Normal file
@@ -0,0 +1,170 @@
|
|||||||
|
Creative Commons Attribution-ShareAlike 4.0 International
|
||||||
|
|
||||||
|
Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
|
||||||
|
|
||||||
|
Using Creative Commons Public Licenses
|
||||||
|
|
||||||
|
Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
|
||||||
|
|
||||||
|
Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors.
|
||||||
|
|
||||||
|
Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described.
|
||||||
|
|
||||||
|
Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public.
|
||||||
|
|
||||||
|
Creative Commons Attribution-ShareAlike 4.0 International Public License
|
||||||
|
|
||||||
|
By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
|
||||||
|
|
||||||
|
Section 1 – Definitions.
|
||||||
|
|
||||||
|
a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
|
||||||
|
|
||||||
|
b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
|
||||||
|
|
||||||
|
c. BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License.
|
||||||
|
|
||||||
|
d. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
|
||||||
|
|
||||||
|
e. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
|
||||||
|
|
||||||
|
f. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
|
||||||
|
|
||||||
|
g. License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
|
||||||
|
|
||||||
|
h. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
|
||||||
|
|
||||||
|
i. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
|
||||||
|
|
||||||
|
j. Licensor means the individual(s) or entity(ies) granting rights under this Public License.
|
||||||
|
|
||||||
|
k. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
|
||||||
|
|
||||||
|
l. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
|
||||||
|
|
||||||
|
m. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
|
||||||
|
|
||||||
|
Section 2 – Scope.
|
||||||
|
|
||||||
|
a. License grant.
|
||||||
|
|
||||||
|
1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
|
||||||
|
|
||||||
|
A. reproduce and Share the Licensed Material, in whole or in part; and
|
||||||
|
|
||||||
|
B. produce, reproduce, and Share Adapted Material.
|
||||||
|
|
||||||
|
2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
|
||||||
|
|
||||||
|
3. Term. The term of this Public License is specified in Section 6(a).
|
||||||
|
|
||||||
|
4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
|
||||||
|
|
||||||
|
5. Downstream recipients.
|
||||||
|
|
||||||
|
A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
|
||||||
|
|
||||||
|
B. Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.
|
||||||
|
|
||||||
|
C. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
|
||||||
|
|
||||||
|
6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
|
||||||
|
|
||||||
|
b. Other rights.
|
||||||
|
|
||||||
|
1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
|
||||||
|
|
||||||
|
2. Patent and trademark rights are not licensed under this Public License.
|
||||||
|
|
||||||
|
3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
|
||||||
|
|
||||||
|
Section 3 – License Conditions.
|
||||||
|
|
||||||
|
Your exercise of the Licensed Rights is expressly made subject to the following conditions.
|
||||||
|
|
||||||
|
a. Attribution.
|
||||||
|
|
||||||
|
1. If You Share the Licensed Material (including in modified form), You must:
|
||||||
|
|
||||||
|
A. retain the following if it is supplied by the Licensor with the Licensed Material:
|
||||||
|
|
||||||
|
i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
|
||||||
|
|
||||||
|
ii. a copyright notice;
|
||||||
|
|
||||||
|
iii. a notice that refers to this Public License;
|
||||||
|
|
||||||
|
iv. a notice that refers to the disclaimer of warranties;
|
||||||
|
|
||||||
|
v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
|
||||||
|
|
||||||
|
B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
|
||||||
|
|
||||||
|
C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
|
||||||
|
|
||||||
|
2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
|
||||||
|
|
||||||
|
3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
|
||||||
|
|
||||||
|
b. ShareAlike.In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
|
||||||
|
|
||||||
|
1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
|
||||||
|
|
||||||
|
2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
|
||||||
|
|
||||||
|
3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.
|
||||||
|
|
||||||
|
Section 4 – Sui Generis Database Rights.
|
||||||
|
|
||||||
|
Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
|
||||||
|
|
||||||
|
a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
|
||||||
|
|
||||||
|
b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
|
||||||
|
|
||||||
|
c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
|
||||||
|
For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
|
||||||
|
|
||||||
|
Section 5 – Disclaimer of Warranties and Limitation of Liability.
|
||||||
|
|
||||||
|
a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.
|
||||||
|
|
||||||
|
b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.
|
||||||
|
|
||||||
|
c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
|
||||||
|
|
||||||
|
Section 6 – Term and Termination.
|
||||||
|
|
||||||
|
a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
|
||||||
|
|
||||||
|
b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
|
||||||
|
|
||||||
|
1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
|
||||||
|
|
||||||
|
2. upon express reinstatement by the Licensor.
|
||||||
|
|
||||||
|
c. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
|
||||||
|
|
||||||
|
d. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
|
||||||
|
|
||||||
|
e. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
|
||||||
|
|
||||||
|
Section 7 – Other Terms and Conditions.
|
||||||
|
|
||||||
|
a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
|
||||||
|
|
||||||
|
b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
|
||||||
|
|
||||||
|
Section 8 – Interpretation.
|
||||||
|
|
||||||
|
a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
|
||||||
|
|
||||||
|
b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
|
||||||
|
|
||||||
|
c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
|
||||||
|
|
||||||
|
d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
|
||||||
|
|
||||||
|
Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
|
||||||
|
|
||||||
|
Creative Commons may be contacted at creativecommons.org.
|
||||||
@@ -28,7 +28,7 @@ SPDX-License-Identifier: Apache-2.0
|
|||||||
openDesk is a Kubernetes based, open-source and cloud-native digital workplace suite provided by the
|
openDesk is a Kubernetes based, open-source and cloud-native digital workplace suite provided by the
|
||||||
*Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH*.
|
*Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH*.
|
||||||
|
|
||||||
For production use the [openDesk Enterprise Edition](./README-EE.md) is required.
|
For production use, [openDesk Enterprise Edition](./README-EE.md) is recommended.
|
||||||
|
|
||||||
openDesk currently features the following functional main components:
|
openDesk currently features the following functional main components:
|
||||||
|
|
||||||
|
|||||||
@@ -24,6 +24,6 @@ SPDX-FileCopyrightText = "2024 Zentrum für Digitale Souveränität der Öffentl
|
|||||||
SPDX-License-Identifier = "Apache-2.0"
|
SPDX-License-Identifier = "Apache-2.0"
|
||||||
|
|
||||||
[[annotations]]
|
[[annotations]]
|
||||||
path = "helmfile/files/portal-tiles/*"
|
path = ".opencode/screenshots/*"
|
||||||
SPDX-FileCopyrightText = "2024 Google LLC"
|
SPDX-FileCopyrightText = "2025 Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH"
|
||||||
SPDX-License-Identifier = "Apache-2.0"
|
SPDX-License-Identifier = "CC-BY-SA-4.0"
|
||||||
275
docs/baseline-requirements.md
Normal file
275
docs/baseline-requirements.md
Normal file
@@ -0,0 +1,275 @@
|
|||||||
|
<!--
|
||||||
|
SPDX-FileCopyrightText: 2024 Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH
|
||||||
|
SPDX-License-Identifier: Apache-2.0
|
||||||
|
-->
|
||||||
|
|
||||||
|
<h1>Baseline Requirements</h1>
|
||||||
|
|
||||||
|
* [Preamble / Scope](#preamble--scope)
|
||||||
|
* [Software bill of materials (SBOMs)](#software-bill-of-materials-sboms)
|
||||||
|
* [Artifact SBOMs](#artifact-sboms)
|
||||||
|
* [Source code SBOMs](#source-code-sboms)
|
||||||
|
* [License Compliance](#license-compliance)
|
||||||
|
* [Software supply chain security](#software-supply-chain-security)
|
||||||
|
* [Container architectural basics](#container-architectural-basics)
|
||||||
|
* [Security](#security)
|
||||||
|
* [IT-Grundschutz](#it-grundschutz)
|
||||||
|
* [Accessibility](#accessibility)
|
||||||
|
* [Data protection](#data-protection)
|
||||||
|
* [Functionality and features](#functionality-and-features)
|
||||||
|
* [Non-overlapping](#non-overlapping)
|
||||||
|
* [User lifecycle](#user-lifecycle)
|
||||||
|
* [Pull: LDAP](#pull-ldap)
|
||||||
|
* [Push: Provisioning](#push-provisioning)
|
||||||
|
* [Authentication](#authentication)
|
||||||
|
* [Top bar](#top-bar)
|
||||||
|
* [Look and feel](#look-and-feel)
|
||||||
|
* [Central navigation](#central-navigation)
|
||||||
|
* [Functional Administration](#functional-administration)
|
||||||
|
* [Theming](#theming)
|
||||||
|
* [Central user profile](#central-user-profile)
|
||||||
|
* [Footnotes](#footnotes)
|
||||||
|
|
||||||
|
# Preamble / Scope
|
||||||
|
|
||||||
|
This document lays out the requirements for open-source products that should become part of openDesk.
|
||||||
|
|
||||||
|
As this is a comprehensive set of requirements most new components will not adhere to all of them.
|
||||||
|
|
||||||
|
This document can be used to assess the status and possible gaps for a component which might itself be the basis for a decision if a component should be integrated into openDesk by working on closing the identified gaps.
|
||||||
|
|
||||||
|
> **Note**<br>
|
||||||
|
> Even an already integrated application might not adhere to all aspects of the documented requirements yet.
|
||||||
|
> Closing the gaps for existing applications therefore is an openDesk priority.
|
||||||
|
|
||||||
|
# Software bill of materials (SBOMs)
|
||||||
|
|
||||||
|
openDesk is looking into options for in-depth SBOM creation first for container images and later for source code. It is still expected by the suppliers to provide artifact and source code SBOMs in a standardized manner, ideally in the openCode preferred [SPDX 2.2.1](https://spdx.org/rdf/ontology/spdx-2-2-1/) format.
|
||||||
|
|
||||||
|
**Reference:** https://gitlab.opencode.de/bmi/opendesk/deployment/SBOM/-/tree/main/sboms/0.5.74
|
||||||
|
|
||||||
|
## Artifact SBOMs
|
||||||
|
|
||||||
|
There are various free tools like [syft](https://github.com/anchore/syft) available to generate SBOMs for container images. It is expected that this kind of artifact SBOMs is provided (and signed) for all containers delivered to be integrated into openDesk.
|
||||||
|
|
||||||
|
**Reference:** As part of [openDesk's standard CI](https://gitlab.opencode.de/bmi/opendesk/tooling/gitlab-config) a container image SBOM is derived from the container's content and gets signed. Both artifacts (SBOM and signature) are placed next to the image in the related registry ([e.g.](https://gitlab.opencode.de/bmi/opendesk/components/platform-development/images/semantic-release/container_registry/827)).
|
||||||
|
|
||||||
|
## Source code SBOMs
|
||||||
|
|
||||||
|
Today's software development platforms like GitLab or GitHub provide dependency list/graph features that are the basis for your source code SBOMs. These features are usually based on analysis of language-specific package manager dependency definition files. As part of a supplier's software development process, it is expected that source code SBOMs are at least created on the level of the already defined software dependencies within the source code tree of the component.
|
||||||
|
|
||||||
|
**Reference:** Currently we do not have source code SBOMs in place.
|
||||||
|
|
||||||
|
# License Compliance
|
||||||
|
|
||||||
|
All parts of openDesk Community Edition must be open source with source code (also) published or at least publishable on openCode.
|
||||||
|
|
||||||
|
openCode provides some boundaries when it comes to open source license compliance openDesk has to adhere to:
|
||||||
|
|
||||||
|
- The components must be published under a license listed in the [openCode license allow list](https://wikijs.opencode.de/de/Hilfestellungen_und_Richtlinien/Lizenzcompliance#h-2-open-source-lizenzliste).
|
||||||
|
- Delivered artifacts (container images) must contain only components licensed under the aforementioned allow list. A container must not contain any artifact using a license from the [openCode license block list](https://wikijs.opencode.de/de/Hilfestellungen_und_Richtlinien/Lizenzcompliance#h-3-negativliste-aller-nicht-freigegebenen-lizenzen).
|
||||||
|
|
||||||
|
Deviations from the above requirements must be documented in the openDesk license deviation report.
|
||||||
|
|
||||||
|
**Reference:** https://gitlab.opencode.de/bmi/opendesk/deployment/SBOM/-/blob/main/sboms/openDesk%20Deviation%20Report-0.5.74.md
|
||||||
|
|
||||||
|
# Software supply chain security
|
||||||
|
|
||||||
|
ZenDiS plans to provide secured key storage as a service on openCode.
|
||||||
|
|
||||||
|
openDesk is going to implement [SLSA v1.0](https://slsa.dev/spec/v1.0/).
|
||||||
|
|
||||||
|
The minimum requirement for all of openDesk's functional components is that all component artifacts (i.e. container images, Helm charts) are signed and their signature can be verified based on the ZenDiS-provided secure key store.
|
||||||
|
|
||||||
|
**Reference:** The [openDesk standard CI](https://gitlab.opencode.de/bmi/opendesk/tooling/gitlab-config) ensures that each container image being built and each Helm chart being released is signed. In the case of container images, the related SBOMs are signed as well.
|
||||||
|
|
||||||
|
# Container architectural basics
|
||||||
|
|
||||||
|
Note: openDesk is operated as a Kubernetes (K8s) workload.
|
||||||
|
|
||||||
|
openDesk applications should adhere to best practices for K8s application/container design. While there are dozens of documents about these best practices please use them as references:
|
||||||
|
- https://cloud.google.com/architecture/best-practices-for-building-containers
|
||||||
|
- https://cloud.google.com/architecture/best-practices-for-operating-containers
|
||||||
|
|
||||||
|
As some applications were initially created years before K8s was introduced they naturally might take different approaches.
|
||||||
|
|
||||||
|
You will find below some of the most common best practice requirements, some of which are auto-tested as part of the openDesk deployment automation:
|
||||||
|
|
||||||
|
- Containers come with readiness and liveness probes.
|
||||||
|
- Containers are stateless and immutable (read-only root file system), state should be placed into a database (or similar).
|
||||||
|
- Allow horizontal scaling (auto-scaling is of course nice to have).
|
||||||
|
- Provide resource requests and limits (we do not want to limit CPU though).
|
||||||
|
- Provide application-specific monitoring endpoints and expose the health of the application.
|
||||||
|
- Write your logs to STDOUT/STDERR and ideally provide JSON-based logs.
|
||||||
|
- Use one service per container (microservice pattern).
|
||||||
|
- Minimize the footprint of your container e.g. removing unnecessary tools, ideally providing a distroless container.
|
||||||
|
- Allow restrictive setting of the security contexts (see [security-context.md](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/blob/main/docs/security-context.md) for reference).
|
||||||
|
- Support for external secrets.
|
||||||
|
- Support for externally provided/self-signed certificates.
|
||||||
|
|
||||||
|
**Reference:** Some of these requirements are tested and/or documented within the deployment automation:
|
||||||
|
- CI executed Kyverno tests: https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/tree/main/.kyverno/policies
|
||||||
|
- Generated documentation regarding security contexts: https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/blob/main/docs/security-context.md
|
||||||
|
|
||||||
|
# Security
|
||||||
|
|
||||||
|
openDesk should be compliant with the "Deutsche Verwaltungscloud Strategie" (DVS). While this is a moving target it references some already established standards like the BSI's [IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/it-grundschutz-kompendium_node.html) and [C5](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/C5_AktuelleVersion/C5_AktuelleVersion_node.html). These standards address hundreds of requirements which are published at the given links. So here's just a summary to understand the approach of the broadest requirements from IT-Grundschutz.
|
||||||
|
|
||||||
|
**Reference:** [Deutsche Verwaltungscloud-Strategie – Rahmenwerk der Zielarchitektur](https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/cio-bund/steuerung-it-bund/beschluesse_cio-board/2023_11_Beschluss_CIO_Board_DVS_Rahmenwerk_Anlage.pdf)
|
||||||
|
|
||||||
|
## IT-Grundschutz
|
||||||
|
|
||||||
|
The IT-Grundschutz catalog knowns a lot of modules ("Bausteine"), but not all of them apply to all components, as there are some related to hardware or some just relevant for the operator while openDesk is "just" the software platform. The first step for an IT-Grundschutz evaluation of a component (or the platform as a whole) requires defining which modules are applicable. Other modules apply to all components e.g. [APP.4.4 Kubernetes](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/06_APP_Anwendungen/APP_4_4_Kubernetes_Edition_2023.pdf), [SYS.1.6 Containerisierung](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/07_SYS_IT_Systeme/SYS_1_6_Containerisierung_Edition_2023.pdf) and [CON 2 Datenschutz](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_2_Datenschutz_Edition_2023.pdf).
|
||||||
|
|
||||||
|
Within each module are multiple requirements ("Anforderungen") that are usually composed of multiple partial requirements ("Teilanforderungen"). Each requirement has a given category:
|
||||||
|
- B for basic ("Basis") - the requirement must be fulfilled.
|
||||||
|
- S for standard ("Standard") - the requirement should also be fulfilled, if not there must be a good reason why it is not the case that does not tamper the security of the overall system. There is only a defined amount of deviations allowed for standard requirements.
|
||||||
|
- H for high ("Hoch") - in certain scenarios you have extended security requirements, in that case, the high requirements must be fulfilled. openDesk is working towards making that possible.
|
||||||
|
|
||||||
|
Different requirements address different roles in IT-Grundschutz.
|
||||||
|
|
||||||
|
- Supplier: processes & product (component -> e.g. Open-Xchange, OpenProject)
|
||||||
|
- Provider: processes & product (platform -> openDesk)
|
||||||
|
- Operator: processes & product (service)
|
||||||
|
- Customer: processes.
|
||||||
|
|
||||||
|
As a supplier of an openDesk component, you will focus on the "Supplier" requirements, while the outcome (your product) must enable the Provider to fulfill the requirements that lay with its responsibility for the openDesk platform. Operators use openDesk to provide a service, therefore the openDesk platform must enable an Operator to fulfill the related requirements. Finally, the service must enable the customer to align with the scope of the IT Grundschutz catalog. So it will happen that a requirement from e.g. the customer level needs a specific capability by the product (Supplier's responsibility), a defined core configuration from the platform (Provider's responsibility), or a certain service setup from the Operator.
|
||||||
|
|
||||||
|
We are aware that IT-Grundschutz is a complex topic and are working towards a streamlined process to reduce overhead as much as possible and ensure to maximize the use of synergies.
|
||||||
|
|
||||||
|
**Reference:** https://gitlab.opencode.de/bmi/opendesk/documentation/it-grundschutz
|
||||||
|
|
||||||
|
# Accessibility
|
||||||
|
|
||||||
|
Accessibility is a key requirement for software that is being used in the public sector. Therefore the products of the suppliers are expected to adhere to the relevant standards.
|
||||||
|
|
||||||
|
Please find more context about the topic on the [website of the German CIO](https://www.cio.bund.de/Webs/CIO/DE/digitaler-wandel/it-barrierefreiheit/vorgaben-und-richtlinien/vorgaben-und-richtlinien-node.html) followed by a more detailed look at the actual accessibility standard [WCAG 2.1](https://www.barrierefreiheit-dienstekonsolidierung.bund.de/Webs/PB/DE/gesetze-und-richtlinien/wcag/wcag-artikel.html).
|
||||||
|
|
||||||
|
Each vendor must provide a certificate that their product - or the parts of the product relevant for openDesk - complies with at least WCAG 2.1 AA or [BITV 2.0](https://www.bundesfachstelle-barrierefreiheit.de/DE/Fachwissen/Informationstechnik/EU-Webseitenrichtlinie/BGG-und-BITV-2-0/Die-neue-BITV-2-0/die-neue-bitv-2-0_node.html). As the certification and related product improvements are time-consuming the focus of openDesk is that a supplier provides a plan and certification partner (contract) that shows the supplier is working towards the certification. While the aforementioned standard states the priority is the "A" level requirements, the "AA" level must be met at the end of the process.
|
||||||
|
|
||||||
|
> **Note**<br>
|
||||||
|
> Please keep in mind that WCAG 2.2 and 3.0 are work in progress. If you already work on accessibility improvements you might want to take these standards already into consideration.
|
||||||
|
|
||||||
|
**Reference:** In the past the [accessibility evaluations](https://gitlab.opencode.de/bmi/opendesk/info/-/tree/main/24.03/Barrierefreiheit) have been executed by Dataport. But they do not do certifications.
|
||||||
|
|
||||||
|
# Data protection
|
||||||
|
|
||||||
|
Each component must be able to operate according to the [EU's General Data Protection Regulation (GDPR)](https://gdpr.eu/). This requires some key messages to be answered when it comes to personal data[^1]:
|
||||||
|
|
||||||
|
- Who are the affected data subjects?
|
||||||
|
- What personal data (attributes) from the subjects is being processed?
|
||||||
|
- Who is the controller and processor of the subject's data?
|
||||||
|
- Which processing activities involve which data attributes?
|
||||||
|
- How can the data be deleted?
|
||||||
|
- Are personal data-related activities traceable?
|
||||||
|
- How can data be provided uniformly to affected people?
|
||||||
|
- What does a data privacy-friendly configuration look like?
|
||||||
|
|
||||||
|
While this can be answered by each component that will be in the spotlight for the suppliers, we also need an aligned overall picture for openDesk that at least has the platform-specific user lifecycle and cross-application interfaces in focus.
|
||||||
|
|
||||||
|
Note: The topics of availability, integrity, and confidentiality of personal data are also being addressed by the IT-Grundschutz module "CON 2". It has to be ensured that it is not in contradiction to what is being done in the general area of data protection.
|
||||||
|
|
||||||
|
**Reference:** https://gitlab.opencode.de/bmi/opendesk/documentation/datenschutz
|
||||||
|
|
||||||
|
# Functionality and features
|
||||||
|
|
||||||
|
## Non-overlapping
|
||||||
|
|
||||||
|
To avoid having functionality twice in openDesk it might be required to disable certain functionality within a component. There needs to be an assessment for each new component if it has overlapping functionality and how to deal with that.
|
||||||
|
|
||||||
|
**Reference:** The contact management from Nextcloud is done in OX, so Nextcloud has its internal contact management disabled, as well as most of the Nextcloud Talk functionality, due to the presence of Element and Jitsi.
|
||||||
|
|
||||||
|
## User lifecycle
|
||||||
|
|
||||||
|
With a central Identity- and Access Management (IAM) also the user lifecycle (ULC) that addresses account create-update-delete actions with support for "inactive" accounts must be harmonized within the platform.
|
||||||
|
|
||||||
|
The focus is to have all the account information in all applications including the account's state, profile picture ([reference](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/issues/27)) and - where required - the user's group memberships. This cannot be done purely by pushing that data through OIDC claims when a user logs in to an application therefore two ways of managing an account are applicable and described in the following subchapters.
|
||||||
|
|
||||||
|
Note: Allowing ad hoc updates of account data through OIDC claims during login is still encouraged.
|
||||||
|
|
||||||
|
### Pull: LDAP
|
||||||
|
|
||||||
|
Applications can access the IAM's LDAP to access all data necessary for managing their part of the ULC.
|
||||||
|
|
||||||
|
**Reference:** Most applications use LDAP access as per https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/blob/main/docs/components.md?ref_type=heads#identity-data-flows
|
||||||
|
|
||||||
|
> **Note**<br>
|
||||||
|
> The direct access to LDAP is going to be deprecated for most use cases. openDesk is looking into active provisioning of the user/group data into the applications using [SCIM](https://scim.cloud/).
|
||||||
|
|
||||||
|
### Push: Provisioning
|
||||||
|
|
||||||
|
Some applications require active provisioning of the centrally maintained IAM data. As the actual provisioning is part of the openDesk provisioning framework it is necessary to define the ULC flow regarding its different states to get a matching provisioning connector implemented. This is done collaboratively between the supplier and openDesk product management.
|
||||||
|
|
||||||
|
**Reference:** New applications will make use of the [provisioning framework](https://gitlab.opencode.de/bmi/opendesk/component-code/crossfunctional/univention/ums-provisioning-api). At the moment to only active (push) provisioned component is OX AppSuite fed by the [OX-connector](https://github.com/univention/ox-connector/tree/ucs5.0).
|
||||||
|
|
||||||
|
## Authentication
|
||||||
|
|
||||||
|
The central IdP ensures the single sign-on and logout workflows. As standard openDesk uses [Open ID Connect](https://openid.net/). It can be configured to provide additional user information from the IAM when required by a component.
|
||||||
|
|
||||||
|
Minimum requirements regarding the OIDC support in an application besides the actual login flow:
|
||||||
|
|
||||||
|
- Back-channel logout: [OIDC Back-Channel Logout](https://openid.net/specs/openid-connect-backchannel-1_0.html) must be supported by the components unless there is a significant reason why it technically cannot be supported, in that case [OIDC Front-Channel Logout](https://openid.net/specs/openid-connect-frontchannel-1_0.html) is the alternative.
|
||||||
|
- IdP Session Refresh: Ensure that your application regularly checks the IdP session for its validity and invalidates the local session when there is no longer an IdP session.
|
||||||
|
|
||||||
|
**Reference:** Most applications are directly connected to the IdP and are using OIDC: https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/blob/main/docs/architecture.md#identity-data-flows
|
||||||
|
|
||||||
|
## Top bar
|
||||||
|
|
||||||
|
The top bar of all applications should provide a common UX.
|
||||||
|
|
||||||
|
### Look and feel
|
||||||
|
|
||||||
|
The current status is subject to review, but the basics will most likely stay the same. Ensure that the top bar can be customized (or adheres to a given openDesk standard) in various settings:
|
||||||
|
|
||||||
|
- Size (height) of the bar.
|
||||||
|
- Foreground and -background colors, including hover/active.
|
||||||
|
- Size and color of the bar's bottom line.
|
||||||
|
- Logo position, size, and link including the link's target.
|
||||||
|
- Icon position and size of the central navigation.
|
||||||
|
- Ideally have the user's menu on the right-hand side of the top bar using the user's profile picture.
|
||||||
|
- Have the search option/bar as the leftmost option in the right content section of the top bar or even allow the search bar to be rendered in the center of the top bar.
|
||||||
|
|
||||||
|
**Reference:** This is available in current deployments, see e.g. Nextcloud, Open-Xchange, and XWiki.
|
||||||
|
|
||||||
|
### Central navigation
|
||||||
|
|
||||||
|
From the top bar, the user can access the central navigation. A menu that gets its contents from the portal, rending the categories and (sub-)applications available to the logged-in user.
|
||||||
|
|
||||||
|
When implementing the central navigation into an application there are two options to access the user's data from the portal:
|
||||||
|
|
||||||
|
- Frontend-based: Issuing an IFrame-based silent login against the intercom service (ICS) to get a session with the ICS, followed by a request for the JSON containing the user's central navigation contents through the ICS.
|
||||||
|
- Backend-based: Requesting the JSON using a backend call to the portal providing the user's name and a shared secret.
|
||||||
|
|
||||||
|
**Reference:** This is available in current deployments in all applications except for Jitsi, Collabora, and CryptPad.
|
||||||
|
|
||||||
|
## Functional Administration
|
||||||
|
|
||||||
|
While applications usually support technical and functional administration the technical part should be in the responsibility of the operator and is usually done at (re)deployment time. Therefore the administrative tasks within an application should be limited to functional administration.
|
||||||
|
|
||||||
|
Example for "technical administration":
|
||||||
|
- Configuring the SMTP relay for an application to send out emails.
|
||||||
|
|
||||||
|
Example of "functional administration":
|
||||||
|
- Creating and maintaining users and groups.
|
||||||
|
|
||||||
|
**Reference:** OpenProject took the approach that all settings pre-defined in the deployment are still rendered in the admin section of OpenProject, but can not be changed.
|
||||||
|
|
||||||
|
## Theming
|
||||||
|
|
||||||
|
Theming should be controlled with the deployment and affect all components that support branding options.
|
||||||
|
|
||||||
|
**Reference:** https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/issues/27
|
||||||
|
|
||||||
|
## Central user profile
|
||||||
|
|
||||||
|
The user profile is maintained centrally, therefore the applications should make use of that central data and not allow local editing of the data within the application except for data that is required by the application and cannot be provided by the central IAM.
|
||||||
|
|
||||||
|
The data can still be rendered but must not be tampered with in any way within an openDesk application outside of the IAM, as it would either cause inconsistent data within the platform or the changed data being overwritten, which is at least unexpected by the user.
|
||||||
|
|
||||||
|
The user's preferred language and theme (light/dark) are also selected in the IAM's portal and the setting should be respected in all applications.
|
||||||
|
|
||||||
|
**Reference:** No reference yet.
|
||||||
|
|
||||||
|
# Footnotes
|
||||||
|
|
||||||
|
^1: For definitions see [GDPR Article 4](https://gdpr.eu/article-4-definitions/).
|
||||||
@@ -57,13 +57,13 @@ Before you investigate any app-specific configuration, it is recommended that yo
|
|||||||
|
|
||||||
# Default branch, `develop` and other branches
|
# Default branch, `develop` and other branches
|
||||||
|
|
||||||
The `main` branch is configured to be the default branch, as visitors of the project on Open CoDE should see that
|
The `main` branch is configured to be the default branch, as visitors of the project on openCode should see that
|
||||||
branch by default.
|
branch by default.
|
||||||
|
|
||||||
Please use the `develop` branch to diverge your branch(es) from. See the [workflow guide](./docs/workflow.md)
|
Please use the `develop` branch to diverge your branch(es) from. See the [workflow guide](./docs/workflow.md)
|
||||||
for more details on naming conventions.
|
for more details on naming conventions.
|
||||||
|
|
||||||
There is a CI bot that automatically creates a merge request once you initially push your branch to Open CoDE.
|
There is a CI bot that automatically creates a merge request once you initially push your branch to openCode.
|
||||||
Of course, the merge request will target the `develop` branch, be in status `draft`, and you are set as the assignee.
|
Of course, the merge request will target the `develop` branch, be in status `draft`, and you are set as the assignee.
|
||||||
|
|
||||||
If you do not plan to merge from the branch you have pushed, please close the auto-created MR.
|
If you do not plan to merge from the branch you have pushed, please close the auto-created MR.
|
||||||
@@ -76,7 +76,7 @@ Besides the deployment automation itself, some tools work with the contents of t
|
|||||||
|
|
||||||
- **Linting**: Ensures consistency of the file contents for the other tools.
|
- **Linting**: Ensures consistency of the file contents for the other tools.
|
||||||
- **Renovate**: Automatically create MRs that update the components to their latest version.
|
- **Renovate**: Automatically create MRs that update the components to their latest version.
|
||||||
- **Mirror**: Mirror artifacts to Open CoDE.
|
- **Mirror**: Mirror artifacts to openCode.
|
||||||
|
|
||||||
Please find details on these tools below.
|
Please find details on these tools below.
|
||||||
|
|
||||||
@@ -134,8 +134,8 @@ Checks for newer versions of the given artifact and creates an MR containing the
|
|||||||
> **Note:**<br>
|
> **Note:**<br>
|
||||||
> The mirror is scheduled to run every hour at 42 minutes past the hour.
|
> The mirror is scheduled to run every hour at 42 minutes past the hour.
|
||||||
|
|
||||||
openDesk strives to make all relevant artifacts available on Open CoDE so there is a mirroring process
|
openDesk strives to make all relevant artifacts available on openCode so there is a mirroring process
|
||||||
configured to pull artifacts that do not originate from Open CoDE into projects called `*-Mirror` within the
|
configured to pull artifacts that do not originate from openCode into projects called `*-Mirror` within the
|
||||||
[openDesk Components section](https://gitlab.opencode.de/bmi/opendesk/components).
|
[openDesk Components section](https://gitlab.opencode.de/bmi/opendesk/components).
|
||||||
|
|
||||||
The mirror script takes the information on what artifacts to mirror from the annotation inside the two yaml files:
|
The mirror script takes the information on what artifacts to mirror from the annotation inside the two yaml files:
|
||||||
|
|||||||
@@ -39,7 +39,7 @@ You will have to select an existing user account that will be used as a service
|
|||||||
|
|
||||||
Please note that the account that shall serve as the service account requires a Microsoft 365/Exchange online license (mailbox).
|
Please note that the account that shall serve as the service account requires a Microsoft 365/Exchange online license (mailbox).
|
||||||
|
|
||||||
> **Notes**<br>
|
> **Note**<br>
|
||||||
> If you want to designate your admin account as a service account, you have to provide the admin with a license.
|
> If you want to designate your admin account as a service account, you have to provide the admin with a license.
|
||||||
|
|
||||||
***2. Register the audriga app in your tenant***
|
***2. Register the audriga app in your tenant***
|
||||||
|
|||||||
@@ -135,7 +135,7 @@ apps:
|
|||||||
## Private registries
|
## Private registries
|
||||||
|
|
||||||
By default, Helm charts and container images are fetched from OCI registries. These registries can be found in most cases
|
By default, Helm charts and container images are fetched from OCI registries. These registries can be found in most cases
|
||||||
in the [openDesk/component section on Open CoDE](https://gitlab.opencode.de/bmi/opendesk/components).
|
in the [openDesk/component section on openCode](https://gitlab.opencode.de/bmi/opendesk/components).
|
||||||
|
|
||||||
For untouched upstream artifacts that do not belong to a functional component's core, we use upstream registries
|
For untouched upstream artifacts that do not belong to a functional component's core, we use upstream registries
|
||||||
like Docker Hub.
|
like Docker Hub.
|
||||||
|
|||||||
@@ -130,7 +130,7 @@ Users get roles assigned based on their responsibilities and the tasks they need
|
|||||||
|
|
||||||
openDesk defines [templates](https://gitlab.opencode.de/bmi/opendesk/components/platform-development/images/opendesk-nubus/-/blob/main/udm/udm-data-loader/65-usertemplate.yaml) for the *User* and *Administrator* roles. The templates can be used to create users with these roles by an *openDesk Administrator* using the [administration portal](https://docs.opendesk.eu/administration/).
|
openDesk defines [templates](https://gitlab.opencode.de/bmi/opendesk/components/platform-development/images/opendesk-nubus/-/blob/main/udm/udm-data-loader/65-usertemplate.yaml) for the *User* and *Administrator* roles. The templates can be used to create users with these roles by an *openDesk Administrator* using the [administration portal](https://docs.opendesk.eu/administration/).
|
||||||
|
|
||||||
> **Notes**<br>
|
> **Note**<br>
|
||||||
> Additional/custom templates can be created using the UDM REST API.
|
> Additional/custom templates can be created using the UDM REST API.
|
||||||
|
|
||||||
### *openDesk User*
|
### *openDesk User*
|
||||||
|
|||||||
@@ -49,7 +49,7 @@ The following section should provide a high-level view of the involved parties i
|
|||||||
- Focus areas
|
- Focus areas
|
||||||
- Development of upstream products
|
- Development of upstream products
|
||||||
- Development of integrative functionality relevant to openDesk and others
|
- Development of integrative functionality relevant to openDesk and others
|
||||||
- Providing source code and the artifacts required to install openDesk to Open CoDE
|
- Providing source code and the artifacts required to install openDesk to openCode
|
||||||
- Hand over to _openDesk platform development_
|
- Hand over to _openDesk platform development_
|
||||||
- Helm charts
|
- Helm charts
|
||||||
- Container images
|
- Container images
|
||||||
@@ -383,7 +383,7 @@ We only allow verified commits; please read on about the options you have to mak
|
|||||||
|
|
||||||
[^1]: Migrations are in general not supported before openDesk hits [technical release](https://gitlab.opencode.de/bmi/opendesk/deployment/sovereign-workplace/-/releases) v1.0.0
|
[^1]: Migrations are in general not supported before openDesk hits [technical release](https://gitlab.opencode.de/bmi/opendesk/deployment/sovereign-workplace/-/releases) v1.0.0
|
||||||
|
|
||||||
[2]: These approval rules are not available in the Gitlab Free Tier, which is one of the main reasons why deployment automation is not developed on Open CoDE.
|
[2]: These approval rules are not available in the GitLab Free Tier, which is one of the main reasons why deployment automation is not developed on openCode.
|
||||||
|
|
||||||
[^3]: As long as migrations/upgrade paths are not provided - see also footnote #1 - this step is optional.
|
[^3]: As long as migrations/upgrade paths are not provided - see also footnote #1 - this step is optional.
|
||||||
|
|
||||||
|
|||||||
@@ -3,7 +3,7 @@
|
|||||||
---
|
---
|
||||||
repositories:
|
repositories:
|
||||||
# openDesk OpenProject Bootstrap
|
# openDesk OpenProject Bootstrap
|
||||||
# Source: Set when repo is managed on Open CoDE
|
# Source: Set when repo is managed on openCode
|
||||||
- name: "openproject-bootstrap-repo"
|
- name: "openproject-bootstrap-repo"
|
||||||
keyring: "../../files/gpg-pubkeys/opencode.gpg"
|
keyring: "../../files/gpg-pubkeys/opencode.gpg"
|
||||||
verify: {{ .Values.charts.openprojectBootstrap.verify }}
|
verify: {{ .Values.charts.openprojectBootstrap.verify }}
|
||||||
|
|||||||
102
publiccode.yml
Normal file
102
publiccode.yml
Normal file
@@ -0,0 +1,102 @@
|
|||||||
|
# SPDX-FileCopyrightText: 2024-2025 Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH
|
||||||
|
# SPDX-License-Identifier: Apache-2.0
|
||||||
|
#
|
||||||
|
# This repository adheres to the publiccode.yml standard by including this
|
||||||
|
# metadata file that makes public software easily discoverable.
|
||||||
|
# More info at https://github.com/italia/publiccode.yml
|
||||||
|
---
|
||||||
|
publiccodeYmlVersion: "0.4"
|
||||||
|
applicationSuite: "openDesk"
|
||||||
|
categories:
|
||||||
|
- "email-management"
|
||||||
|
- "contact-management"
|
||||||
|
- "document-management"
|
||||||
|
- "instant-messaging"
|
||||||
|
- "knowledge-management"
|
||||||
|
- "office"
|
||||||
|
- "project-management"
|
||||||
|
- "task-management"
|
||||||
|
- "time-management"
|
||||||
|
- "video-conferencing"
|
||||||
|
name: "openDesk"
|
||||||
|
platforms:
|
||||||
|
- "web"
|
||||||
|
developmentStatus: "stable"
|
||||||
|
softwareVersion: "1.2.1"
|
||||||
|
releaseDate: "2025-03-21"
|
||||||
|
softwareType: "standalone/web"
|
||||||
|
url: "https://gitlab.opencode.de/bmi/opendesk/"
|
||||||
|
logo: "openDesk-logo-rgb-color.svg"
|
||||||
|
maintenance:
|
||||||
|
type: "contract"
|
||||||
|
|
||||||
|
contractors:
|
||||||
|
- name: "B1 Systems"
|
||||||
|
email: "info@b1-systems.de"
|
||||||
|
website: "https://www.b1-systems.de/"
|
||||||
|
until: "2026-08-31"
|
||||||
|
|
||||||
|
contacts:
|
||||||
|
- name: "René Fischer"
|
||||||
|
email: "opendesk@zendis.de"
|
||||||
|
affiliation: >-
|
||||||
|
Zentrum für Digitale Souveränität der Öffentlichen Verwaltung
|
||||||
|
(ZenDiS) GmbH
|
||||||
|
|
||||||
|
legal:
|
||||||
|
license: "Apache-2.0"
|
||||||
|
mainCopyrightOwner: >-
|
||||||
|
2025 Zentrum für Digitale Souveränität der Öffentlichen Verwaltung
|
||||||
|
(ZenDiS) GmbH
|
||||||
|
intendedAudience:
|
||||||
|
countries:
|
||||||
|
- "de"
|
||||||
|
scope:
|
||||||
|
- "government"
|
||||||
|
- "local-authorities"
|
||||||
|
localisation:
|
||||||
|
availableLanguages:
|
||||||
|
- "de"
|
||||||
|
- "en"
|
||||||
|
localisationReady: true
|
||||||
|
roadmap: "https://opendesk.eu/produkt/"
|
||||||
|
description:
|
||||||
|
de:
|
||||||
|
features:
|
||||||
|
- "Produktivität"
|
||||||
|
- "Kollaboration"
|
||||||
|
- "Kommunikation"
|
||||||
|
genericName: "Kollaboration & Kommunikation"
|
||||||
|
longDescription: >
|
||||||
|
openDesk ist die anpassungsfähige Office- und Kollaborations-Suite,
|
||||||
|
die speziell für Ihre Bedürfnisse in der Öffentlichen Verwaltung entwickelt wurde.
|
||||||
|
|
||||||
|
|
||||||
|
Mit Schwerpunkt auf Datensouveränität, Sicherheit und reibungslose Zusammenarbeit
|
||||||
|
bietet openDesk alle vertrauten Werkzeuge für den Verwaltungsalltag.
|
||||||
|
openDesk vereint alle essenziellen Büro-Anwendungen unter einer einzigen
|
||||||
|
benutzerfreundlichen Oberfläche.
|
||||||
|
|
||||||
|
|
||||||
|
openDesk ist die Weiterentwicklung des „Souveränen Arbeitsplatzes“,
|
||||||
|
einer Initiative des Bundesministeriums des Innern und für Heimat.
|
||||||
|
Durch openDesk erhält die Öffentliche Verwaltung mehr Kontrolle über
|
||||||
|
ihre digitalen Werkzeuge und kann flexibler auf sich ändernde Anforderungen reagieren.
|
||||||
|
Bund, Länder und Kommunen erhalten mit openDesk eine Office-Komplettlösung,
|
||||||
|
die betreiberunabhängig in jedem Browser und auf allen Endgeräten funktioniert.
|
||||||
|
shortDescription: >
|
||||||
|
Die anpassungsfähige Office- und Kollaborations-Suite für die Öffentliche Verwaltung.
|
||||||
|
screenshots:
|
||||||
|
- ".opencode/screenshots/01-portal-desktop.png"
|
||||||
|
- ".opencode/screenshots/02-dateien-desktop.png"
|
||||||
|
- ".opencode/screenshots/03-projekte-desktop.png"
|
||||||
|
- ".opencode/screenshots/04-wiki-desktop.png"
|
||||||
|
videos:
|
||||||
|
- ".opencode/screenshots/openDesk_Intro.mp4"
|
||||||
|
documentation: "https://docs.opendesk.eu/user"
|
||||||
|
usedBy:
|
||||||
|
- "Robert Koch-Institut"
|
||||||
|
- "Bundesamt für Seeschifffahrt und Hydrographie"
|
||||||
|
- "Föderale IT-Kooperation (FITKO)"
|
||||||
|
- "ZenDiS"
|
||||||
|
...
|
||||||
Reference in New Issue
Block a user