We started from a simple outline focused on "one identity provider":
  # Enabling authentication with RHBK

1. Enabling authentication with GitHub
2. etc

 
But special cases appeared afterwards: customers authenticate with a main Idp (RHBK, Azure), but need to also authenticate to external services, usually the Git provider, usually GitHub. The provider centric approach does not work anymore.

Now we better identify the successive jobs to be done, and the mix-and-match scenario.
 
Therefore a better organization for the entire title could be:

1. Enable or disable authentication with the guest user (to work without an idp on development environments)
2. Share a secret with your Identity provider to enable secure communication (one or many)
   1. RHBK
   2. LDAP
   3. GitHub
   4. Azure
   5. GitLab
3. Import users from your identity provider to the RHDH software catalog (one main source of truth, can be completed by optional secondary idp)
   1. RHBK
      1. Optional: create a custom transformer
   2. LDAP
      1. Optional: create a custom transformer
   3. GitHub
      1. Optional: create a custom transformer
   4. Azure
      1. Optional: create a custom transformer
   5. GitLab
      1. Optional: create a custom transformer
4. Enable authentication with your (main) identity provider (pick one)
   1. RHBK
   2. GitHub
   3. Azure
   4. GitLab
5. Enable authentication with external services (multiple services; different from: integrate with other services, which require more config, and is in another title)
   1. Enable authentication with your secondary identity provider
      1. GitHub to exemplify a generic procedure
   2. Enable Service To Service authentication
      1. Using static tokens
      2. Using JWKS
      3. Set access restrictins to external services tokens
6. Enable auto-logout for inactive users
7. Troubleshoot authentication issues