:PROPERTIES:
:ID:       64f9dd41-188c-47de-867e-fa70a2ee9e18
:END:
#+title: IROH-Auth PTO knowledge sharing
#+Author: Yann Esposito
#+Date: [2024-07-29]

- tags :: [[id:ce893df9-32a4-44e0-9eb5-b9817141ee6a][cisco]]
- source ::

* IROH-Auth Maintenance

** Daily tasks ; scripts

1. create a global OAuth2 master client creds
2. configure it into a =~/.cisco.sh.gpg= containing

   #+begin_src bash
   IROH_CLIENT_ID="client-xxxxx"
   IROH_CLIENT_SECRET="client-xxxxx"
   IROH_PROVISIONING_CLIENT_ID="client-xxxxx"
   IROH_PROVISIONING_CLIENT_SECRET="client-xxxxx"
   #+end_src

   and then

   ~gpg -dq ~/.cisco.sh.gpg|source~

3. Connect to all admin VPN
4. Use the scripts; here are the most useful and recently used ones:

   #+begin_src
   iroh-scripts/
   ├── add-admin-to-org
   ├── add-ai-assistant
   ├── add-flag.sh
   ├── remove-flag.sh
   ├── get-client
   ├── patch-client
   ├── add-scopes-to-client ;; <- takes care of scopes in the org
   ├── add-scopes-to-org
   ├── ai-direct-onboard    ;; <- just onboard but do not show; need feature-flag
   └── client-pass
   xdr-provisioning/
   ├── add-flag.sh
   ├── add-xdr-flag.sh
   ├── full-reprovision.sh
   ├── re-provision.sh
   ├── sc-provision.sh ;; <- never used for real one of my task to check, not sure I could
   ├── sx-only-provision.sh
   ├── tsv-to-commands.sh
   └── xdr-provision.sh
   #+end_src

*** Recent daily tasks

- add XDR flag to some QA org
- remove XDR flag to some PROD org (from Danny)
- patch clients from different sources, mixed with webhooks?

** Provisioning & Onboardings

Too many Provisioning APIs

- SXSO migration ⇒ ~/iroh/provisioning~
- PIAM pre-universal ⇒ ~/iroh/provisioning/platform~
- PIAM universal (real) ⇒ ~/iroh/external-provisioning~ only PIAM tokens
- PIAM universal copy for QA ⇒ ~/iroh/provisioning/universal-provisioning~

After SX EOL: TWO Provisioners;
  - PIAM via universal provisioning API and
  - SE via PIAM pre-universal API.

*** Onboarding

- XDR:                         PIAM Onboarding: CSC, SXO, DI, SCA
- SC-UI (sometime called SCM): SE   Onboarding: SE, CSC, Orbital, DI

The onboarding conf is mostly what you would put in the ~clj-http/post~.
Recent bugs/weakness:
  - body template... ⇒ risk to break content-type and/or parsing as json
  - body passed in the request ⇒ no control on this thing....
  - Universal Provisioning  ⇒ separate but similar onboarding service... THAT'S
    BAD... PR in progress, probably not able to finish

*** Current risks/potential bugs

**** PIAM Universal Provisioning

Universal Provisioning callback.
Flow is:

1. PIAM -> IROH (provides IROH a /CALLBACK_URL/)
2. IROH -> External Onboarding Service
3. External Onboarding Service -> IROH: save body in callback-response
4. After all onboarding have answered, send response to /CALLBACK_URL/ provided by PIAM

Wanderson told me, in EU, some does not have any callback url, but PIAM did not
have these as error on their side.

If an error occurs, we should still respond to PIAM otherwise it is an error on
their side, even if things went well on ours.
There is a cron job, generally just changing the state in the store, will be
enough for the cron job to take care of the rest and return the answer to PIAM.
There is also an endpoint to trigger the cron manually of course.

**** SE Provisioning

We added the onboarding ~orbital~ but SE is sending a specific body via the
onboarding API to Orbital. So you cannot use the onboarding for orbital directly.

SE is mostly alone in dealing with the provisioning.
Their client should have all mandatory scopes, but there is a risk they want more.


* SX EOL quickly

** The flags

In order to not show the feature-flag mixed with the scopes, there is a new
field ~flags~ inside the ~Org~.

A single flag has some effect: ~sc~.
If you have this flag, you cannot use SX and are redirected to SC.
After SX EOL, this flag will not have any effect.

Plan to add a flag with effect with ~sx~ so QA could still use SX in TEST for 1
year after SX EOL.


*** Managing the flags

https://stunning-barnacle-e4478e20.pages.github.io/admin-ui/

Use FF-UI or the scripts

Note the scopes required to add/remove the flag.
Changed, with should be given to TAC, to should not be given to TAC.
The APIs are hidden under the provisioning APIs both for: ~flags~ and ~feature-flag-scopes~.

If possible let's deprecate ~feature-flag-scopes~ even if probably the xdr
feature-flag will be there forever.

** Redirections

There are new dynamically built fields ~apps~ and ~main-app~.

- ~apps~ the application the user can use
- ~main-app~ the application the user should default to when we have different choices.

There is a new ~apps~ section in the ~config~ to know which URL we can use for apps.

#+begin_src clojure
{:global
 {:apps
  {:sc
   {:module-type-ids-allow-list
    ;; would be better with aliases in the config, now with aero we can do it
    #{"03d8591b-8374-5666-8fcc-eaea9188193c"
      "b6a282ad-be30-4382-b27f-7346320e3b84"
      "b7f21c6b-701a-4b45-8a3d-449001844efe"
      "b95d5cd0-5bcb-45f6-921c-e2777468f6b0"}
    :url "https://secure-client.us.security.cisco.com"}
   :sx
   {:module-type-ids-allow-list :all,
    :url "https://securex.us.security.cisco.com"}
   :xdr
   {:module-type-ids-allow-list :all,
    :url "https://xdr.us.security.cisco.com"}}
  }
#+end_src

This is used by both the UI and the backend to decide where to redirect users.
The rules are a bit complex, but we try our best to prevent a redirect hop via a
UI if we have enough details.

** Change SX EOL API

https://iroh-adm.test.iroh.site/admin/maintenance/index.html#/ReleaseBehaviorManagement/put_admin_maintenance_release_behaviors__deadline_id_