From e50f5fff79f01ef475e4cd428376155c0c66a3ee Mon Sep 17 00:00:00 2001
From: Gregor Noczinski <gregor@noczinski.eu>
Date: Tue, 27 Aug 2024 16:54:15 +0200
Subject: [PATCH] Changes

---
 doc/usecases.md | 47 +++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 43 insertions(+), 4 deletions(-)

diff --git a/doc/usecases.md b/doc/usecases.md
index 47b7c7a..1f6d44e 100644
--- a/doc/usecases.md
+++ b/doc/usecases.md
@@ -2,10 +2,12 @@
 
 As Bifröst is very flexible how it can be configured (see [configuration documentation](configurations/README.md)), here some use-cases which can be fulfilled by it:
 
-1. [Off-Board users within 15 minutes of the organization](#bastion-server-secured-via-sso)
-1. [Drop-in-Replacement](#drop-in-replacement)
+1. [Off-board users within 15 minutes of the organization](#offboard)
+2. [On-board users within 15 minutes in the organization](#onboard)
+3. [Drop-in-Replacement](#drop-in-replacement)
 
-## Off-Board users within 15 minutes of the organization
+<a id="offboard"></a>
+## Off-board users within 15 minutes of the organization
 
 ### Problem
 
@@ -31,7 +33,44 @@ How do you ensure you really removed this user everywhere?
 3. Have user's public keys stored at shared users or even the `root` user.
 
 #### Do
-Use the [OpenID Connect authorization](authorizations.md#oidc)
+Use the [OpenID Connect authorization](authorizations.md#oidc).
+
+As the users always authorized by your [Identity Provider (IdP)](https://openid.net/developers/how-connect-works/), and this is always evaluated when someone tries to access the service via SSH, it will also immediately reject the authorization to this service.
+
+No need to access any of these services directly to remove/de-authorize these users.
+
+If the [environments are configured accordingly](environments.md) (which is the default) all user's files and processes will be removed/killed automatically, too.
+
+<a id="onboard"></a>
+## On-board users within 15 minutes in the organization
+
+This is quite similar to [Off-board users within 15 minutes of the organization](#offboard), but obviously reverse.
+
+### Problem
+
+1. Assume you're part of an organization.
+2. Assume this organization has more than _just_ 10 people who might be able to access SSH resources.
+3. Assume you've to on-board an employee, now.
+4. Assume you should ensure that this employee is ab to have access to all services, now.
+
+In cases of SSH servers, this often results in running through all servers and either:
+* Share the server shared-user passwords,
+* Add user's public key to a shared user,
+* Add a dedicated user (with password or authorized key),
+* or change the [Ansible](https://www.ansible.com/) or [Puppet](https://www.puppet.com/) configuration apply it at every machine.
+
+How this should be done now (not days or weeks)?<br>
+"Did I really give him access everywhere?"
+
+### Solution
+
+Use the [OpenID Connect authorization](authorizations.md#oidc).
+
+There is no need to create them somewhere on the server itself. The [OIDC authorization](authorizations.md#oidc) will resolve them using the configured [Identity Provider (IdP)](https://openid.net/developers/how-connect-works/) - that's it!
+
+No need to access any of these services directly to create/authorize these users.
+
+If the [environments are configured accordingly](environments.md) (which is the default) all user's resources (like home directory) will be created automatically.
 
 ## Drop-in-Replacement