You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Introduction on Identity Management and Federation in SCS
2
+
3
+
Sovereign Cloud Stack wants to make it possible for operators to delegate
4
+
administration of user identities to the organizational entities that the
5
+
users are part of. Usually that's customer organizations but it could also
6
+
be the operator itself. Federation protocols like OpenID Connect can be used
7
+
to achieve that goal. To simplify connecting the different parts of SCS
8
+
to customer owned IAM solutions, the SCS reference implementation offers
9
+
Keycloak as central Identity Provider (IdP) service.
10
+
11
+
## Deployment
12
+
13
+
Keycloak can be deployed by running
14
+
15
+
```
16
+
osism apply keycloak
17
+
```
18
+
19
+
The required Keycloak client configuration that allows Keystone to obtain
20
+
OIDC token from Keycloak needs to be deployed by running
21
+
22
+
```
23
+
osism apply keycloak-oidc-client-config
24
+
```
25
+
26
+
After these steps Keystone should be able to obtain token using the
27
+
Device Authorization Grant with PKCE, which is configured by default in the
28
+
`wsgi-keystone.conf` deployed in SCS.
29
+
30
+
## Accessing Keycloak
31
+
32
+
Currently deployed on the manager node, by default under `https://keycloak.<yourdomain>`.
33
+
Details TODO.
34
+
35
+
## Identity Mapping
36
+
37
+
The idea is that customer can create groups with specific names in their own IAM.
38
+
These shall be mapped to a claim `groups` to be included in the OIDC token.
39
+
Via the Keystone [mapping](https://docs.openstack.org/keystone/latest/admin/federation/mapping_combinations.html)
40
+
they shall be mapped to roles on OpenStack projects.
41
+
[The corresponding section for Developers](https://docs.scs.community/dev-docs/operations/iam/identity-federation-in-scs) may be interesting for more technical details.
42
+
Please be aware that currently there are still some technical challenges to be solved
43
+
within the OpenStack Keystone mapping engine and the mapping rules to make this work
44
+
seamlessly.
45
+
46
+
## SCS to SCS federation
47
+
48
+
Federation between separate deployments of SCS is possible via the IdP by
49
+
means of OpenID Connect.
50
+
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.
51
+
52
+
### Prerequisites and Requirements
53
+
54
+
- Knowledge: Familiarity with Keycloak, OIDC federation, and basic SSL and web security principles is pivotal.
55
+
- 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.
56
+
57
+
### Features
58
+
59
+
- Horizon Web SSO
60
+
- OpenStack CLI use via the Device Authorization Grant
61
+
62
+
### Limitations
63
+
64
+
- Keystone currently still has limitations in its mapping engine, which are addressed by the SCS development team as we
65
+
see possibilities and alignement with upstream OpenDev development plans. Automatically creating `ephemeral` users in
66
+
their specific OpenStack domains, as specified in their OIDC token is one example, currently beeing worked on. Please
67
+
check carefully if the technical results meet the security demands of your specific environment.
68
+
69
+
### Current state and future Outlook
70
+
71
+
Currently SCS exemplifies deploying Keycloak on the management plane. This shall be moved to a Kubernetes based
72
+
management plane to improve scalability and architecture.
73
+
74
+
In the near future, the Container layer shall be able to make use of the IdP to allow federated users to access Kubernetes.
75
+
In the mid term, workloads on Kubernetes shall be able to make use of OAuth tokens to access resources on the IaaS layer.
Copy file name to clipboardExpand all lines: standards/certification/certified-clouds.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,7 @@ This is a list of clouds that we test on a nightly basis against our `scs-compat
7
7
|[gx-scs](https://github.com/SovereignCloudStack/docs/blob/main/community/cloud-resources/plusserver-gx-scs.md)| Dev environment provided for SCS & GAIA-X context | plusserver GmbH ||[HM](https://health.gx-scs.sovereignit.cloud:3000/)|
8
8
|[pluscloud open - prod1](https://www.plusserver.com/en/products/pluscloud-open)| Public cloud for customers | plusserver GmbH ||[HM](https://health.prod1.plusserver.sovereignit.cloud:3000)|
9
9
|[pluscloud open - prod2](https://www.plusserver.com/en/products/pluscloud-open)| Public cloud for customers | plusserver GmbH ||[HM](https://health.prod1.plusserver.sovereignit.cloud:3000)|
10
+
|[pluscloud open - prod3](https://www.plusserver.com/en/products/pluscloud-open)| Public cloud for customers | plusserver GmbH ||[HM](https://health.prod1.plusserver.sovereignit.cloud:3000)|
10
11
|[Wavestack](https://www.noris.de/wavestack-cloud/)| Public cloud for customers | noris network AG/Wavecon GmbH ||[HM](https://health.wavestack1.sovereignit.cloud:3000/)|
11
12
|[REGIO.cloud](https://regio.digital)| Public cloud for customers | OSISM GmbH ||[Dashboard](https://apimon.services.regio.digital/public-dashboards/17cf094a47404398a5b8e35a4a3968d4?orgId=1&refresh=5m)|
0 commit comments