fleet admins cannot create identity providers

[davepacheco]

After #1580, fleet admins no longer seem to be able to create identity providers. See #1580 (comment).

[davepacheco]

I can see a few approaches for fixing this:

1. Treat "list IdPs" and "create IdP" as operations that "modify" the Silo (rather than an ad hoc "list_identity_providers" action and a "create child" action, which is what I think they do today).
2. Treat "the list of IdPs" as a first-class synthetic resource, similar to what we do with ConsoleSessionList and others. This is a little different than the existing ones because they're all singletons, whereas this would be nested under the Silo. But this way we could naturally model these as "list child" and "create child" actions under this synthetic resource. The advantage of this vs. openapi macro prototype #1 is that with openapi macro prototype #1, we're baking policy into code (i.e., the code "knows" that this operation is authorized by a different action on a different resource -- namely, the Silo). This is a pretty simple leap though.
3. Create an ad hoc "create identity provider" action at the Silo level, similar to what we have for "list identity providers". I don't like this option. One reason is that we only have one set of actions today for all resources, so this action shows up for all resources even though it's meaningless on many of them. I think there's also value in a uniform set of actions -- I think this is part of what's confusing about AWS (that they have so many different actions).

I'm planning to go with #2 if it's as straightforward as I hope that it is but I'd like feedback (CC @jmpesp and @plotnick)

[plotnick]

Option (2) sounds good to me as well. I agree that we should try to keep a small, uniform set of actions if possible, and that replacing the list_identity_providers action would be a win. Please ping me if you need a ✋, another set of 👀, or a rubber 🦆.

[davepacheco]

Thanks!

I reproduced this by updating the test_create_a_saml_idp() to not grant the "Silo Admin" privilege to "test user". Here are the relevant log entries for the failure:

[2022-08-15T17:51:26.479178848Z] DEBUG: 942aefba-86a4-45c5-9b7e-d46caf897cf1/dropshot_external/102 on ivanova: roles (req_id=cbd2232c-c2b8-4e8a-9053-40702f22b6fd, actor_id=001de000-05e4-4000-8000-000000004007, authenticated=true, uri=/silos/saml-silo/saml-identity-providers, method=POST, remote_addr=127.0.0.1:45113, local_addr=127.0.0.1:56908)
    roles: RoleSet { roles: {(Fleet, 001de000-1334-4000-8000-000000000000, "admin")} }
[2022-08-15T17:51:26.555667862Z] DEBUG: 942aefba-86a4-45c5-9b7e-d46caf897cf1/dropshot_external/102 on ivanova: authorize result (req_id=cbd2232c-c2b8-4e8a-9053-40702f22b6fd, actor_id=001de000-05e4-4000-8000-000000004007, authenticated=true, uri=/silos/saml-silo/saml-identity-providers, method=POST, remote_addr=127.0.0.1:45113, local_addr=127.0.0.1:56908, result=Err(Forbidden), action=CreateChild)
    resource: Silo { parent: Fleet, key: 7052bed8-3fe3-4114-a75e-6f4008c1d2e3, lookup_type: ByName("saml-silo") }
    --
    actor: Some(Actor::SiloUser { silo_user_id: 001de000-05e4-4000-8000-000000004007, silo_id: 001de000-5110-4000-8000-000000000000, .. })

This shows pretty clearly that the user only has "Fleet Admin" and we're failing the "POST /silos/saml-silo/saml-identity-providers" request because they cannot CreateChild on the Silo.