Add IAM overview document for operators (#119)

* Add IAM overview document for operators Signed-off-by: Arvid Requate <[email protected]> * Feedback from review Signed-off-by: Arvid Requate <[email protected]> * Workaround for link checker not finding .md files Signed-off-by: Arvid Requate <[email protected]> * fix link on index Signed-off-by: Max Wolfs <[email protected]> --------- Signed-off-by: Arvid Requate <[email protected]> Signed-off-by: Max Wolfs <[email protected]> Co-authored-by: Max Wolfs <[email protected]>
SovereignCloudStack · Dec 12, 2023 · 547fd5e · 547fd5e
1 parent 68cf597
commit 547fd5e
Show file tree

Hide file tree

Showing 3 changed files with 78 additions and 2 deletions.
diff --git a/docs/05-iam/index.md b/docs/05-iam/index.md
@@ -0,0 +1,75 @@
+# Introduction on Identity Management and Federation in SCS
+
+Sovereign Cloud Stack wants to make it possible for operators to delegate
+administration of user identities to the organizational entities that the
+users are part of. Usually that's customer organizations but it could also
+be the operator itself. Federation protocols like OpenID Connect can be used
+to achieve that goal. To simplify connecting the different parts of SCS
+to customer owned IAM solutions, the SCS reference implementation offers
+Keycloak as central Identity Provider (IdP) service.
+
+## Deployment
+
+Keycloak can be deployed by running
+
+```
+osism apply keycloak
+```
+
+The required Keycloak client configuration that allows Keystone to obtain
+OIDC token from Keycloak needs to be deployed by running
+
+```
+osism apply keycloak-oidc-client-config
+```
+
+After these steps Keystone should be able to obtain token using the
+Device Authorization Grant with PKCE, which is configured by default in the
+`wsgi-keystone.conf` deployed in SCS.
+
+## Accessing Keycloak
+
+Currently deployed on the manager node, by default under `https://keycloak.<yourdomain>`.
+Details TODO.
+
+## Identity Mapping
+
+The idea is that customer can create groups with specific names in their own IAM.
+These shall be mapped to a claim `groups` to be included in the OIDC token.
+Via the Keystone [mapping](https://docs.openstack.org/keystone/latest/admin/federation/mapping_combinations.html)
+they shall be mapped to roles on OpenStack projects.
+[The corresponding section for Developers](https://docs.scs.community/dev-docs/operations/iam/identity-federation-in-scs) may be interesting for more technical details.
+Please be aware that currently there are still some technical challenges to be solved
+within the OpenStack Keystone mapping engine and the mapping rules to make this work
+seamlessly.
+
+## SCS to SCS federation
+
+Federation between separate deployments of SCS is possible via the IdP by
+means of OpenID Connect.
+The section on [inter SCS federation setup](https://docs.scs.community/docs/iam/intra-SCS-federation-setup-description-for-osism-doc-operations) explains the required steps in some detail.
+
+### Prerequisites and Requirements
+
+- Knowledge: Familiarity with Keycloak, OIDC federation, and basic SSL and web security principles is pivotal.
+- Software: The core software component is the OpenID-Connect identity provider, configured to function optimally with OpenStack environments. While the SCS reference implementation focusses on Keycloak as IdP, with appropriate configuration adjustments any OAuth 2.0 compliant IdP should be suitable as an alternative. Each implemntation may have its own pros and cons.
+
+### Features
+
+- Horizon Web SSO
+- OpenStack CLI use via the Device Authorization Grant
+
+### Limitations
+
+- Keystone currently still has limitations in its mapping engine, which are addressed by the SCS development team as we
+  see possibilities and alignement with upstream OpenDev development plans. Automatically creating `ephemeral` users in
+  their specific OpenStack domains, as specified in their OIDC token is one example, currently beeing worked on. Please
+  check carefully if the technical results meet the security demands of your specific environment.
+
+### Current state and future Outlook
+
+Currently SCS exemplifies deploying Keycloak on the management plane. This shall be moved to a Kubernetes based
+management plane to improve scalability and architecture.
+
+In the near future, the Container layer shall be able to make use of the IdP to allow federated users to access Kubernetes.
+In the mid term, workloads on Kubernetes shall be able to make use of OAuth tokens to access resources on the IaaS layer.
diff --git a/sidebarsDocs.js b/sidebarsDocs.js
@@ -363,7 +363,8 @@ const sidebarsDocs = {
       type: 'category',
       label: 'Identity and Access Management (IAM)',
       link: {
-        type: 'generated-index'
+        type: 'doc',
+        id: 'iam/index'
       },
       items: [
         'iam/intra-SCS-federation-setup-description-for-osism-doc-operations'

diff --git a/src/pages/index.tsx b/src/pages/index.tsx
@@ -142,7 +142,7 @@ export default function Home(): JSX.Element {
                   title="IAM Layer"
                   body="Working on Keycloak federated identity provider within our Team IAM."
                   buttonText="Learn More"
-                  url="/docs/category/identity-and-access-management-iam"
+                  url="/docs/iam"
                 />
               </div>
             </div>