Skip to content

Update identity docs #23

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
m-bull wants to merge 1 commit into
base: devel
Choose a base branch
from
Open

Update identity docs #23

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 7 additions & 13 deletions docs/configuration/06-platform-identity.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,14 @@

In Azimuth, there are two kinds of users:

* **Platform Users** who are able to access one or more platforms deployed by Azimuth.
* **Platform Users** who are able to access one or more platforms deployed by Azimuth, but
are not necessarily able to sign into Azimuth.
* **Platform Admins** who are able to sign in to Azimuth, manage the deployed
platforms in a tenancy and administer access to those platforms.

Only Platform Admins need to have an OpenStack account. Each Azimuth tenancy has an
associated **Identity Realm** that provides the Platform Users for that tenancy and is
administered by the Platform Admins for the tenancy. This allow access to platforms to be
administered by the Platform Admins for the tenancy. This allows access to platforms to be
granted for users that do not have an OpenStack account.

This separation of Platform Users from OpenStack accounts opens up a wide range of use cases
Expand All @@ -21,7 +22,7 @@ workshop using Jupyter notebooks for teaching. In this case, they definitely don
to grant every workshop attendee access to OpenStack, as these users may not be trusted.

Using Azimuth, a trusted project member can deploy a JupyterHub in Azimuth (i.e. as a
Platform Admin) and create users in their Identity Realm for the workshop attendees.
Platform Admin) and create users in their Identity Realm for each of the workshop attendees.
These users can be granted access to JupyterHub for the duration of the workshop, and
at the end of the workshop their access can be revoked.

Expand Down Expand Up @@ -56,17 +57,10 @@ groups described above.

!!! note

This means that all users that can access the Azimuth tenancy by signing in with an
OpenStack account (i.e. Platform Admins) automatically get access to all the platforms
Copy link
Contributor Author

@m-bull m-bull Mar 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed reference to "old/new" method to try and remove "time" from the docs to stop them ageing to quickly.

in the tenancy. This matches the behaviour of the previous shared cookie authentication,
so existing Azimuth users will still be able to use their existing workflows.
All users that can access the Azimuth tenancy by signing in with an OpenStack account
(i.e. Platform Admins) automatically get access to all the platforms in the tenancy.

However the new approach uses an industry standard protocol designed specifically for
federated identity in an untrusted environment, and as such eliminates a potential
security flaw in the previous shared cookie approach that could leak unscoped OpenStack
tokens to a malicious application exposed via Zenith.

When a platform is deployed in an Azimuth tenancy a group is created in the corresponding
When a platform is deployed in an Azimuth tenancy, a group is created in the corresponding
identity realm, and access to the platform is controlled by membership of this group. Each
Zenith service for the platform has a child group under the platform group that can be
used to grant access to a single service within a platform.
Expand Down