tracking issue for MVP IAM work

[davepacheco]

(Original source. NOTE: some of the work in that doc is not part of Omicron (e.g., RSS parts) and so isn't mentioned here.)

NOTE: Unless a bullet item says otherwise, it's talking about support in Nexus and the API, not support in the CLI and console. CLI and console support are covered in separate bullet points towards the bottom.

• Initial Silos work
  • Introduce concept of Silos #814
  • lookup API should use the correct Silo #850 / use the correct Silo for resource lookups #937
• support for assigning roles to Silo users and resources
  • need to represent role assignments for resources #890
  • add support for assigning roles on Organizations #1002
  • IAM: support assigning roles on Projects #1042
  • IAM: support assigning roles on Silos #1044
  • IAM: support assigning roles on the Fleet #1051
• ssh key management
  • SSH public keys #954
  • Pass SSH public keys through to cloud-init #974
• Integration with customer IDP
  • Support for SAML as a Silo IdP, part 1 #1139
  • Support for SAML as a Silo IdP, part 2 #1210 (includes JIT provisioning (auto-create users on SAML login) and SAML login flow)
  • [DRAFT] Add support for Silo groups #1358
  • get user's display name from IdP #3527
  • implement SAML logout flow #3528
  • Test with PingFederate
• support for silo with local users and passwords #1699
  • initial implementation of local-only users #1784
  • password authentication for local-only users #1841
• set up Recovery Silo and user during rack initialization #2943
• users/groups APIs: read-only for SAML Silos, plus maybe "delete" for administrators
  • add API for listing silo users #1261
  • initial implementation of local-only users #1784
  • Bulk user fetch for list of IDs #1209
  • Group detail and list of users #2051
• Device (CLI, API) authn:
  • API client authentication and token granting #1194
  • need expiration for device authn access tokens #2302
  • implement OAuth refresh tokens #2306
• service accounts
• silo login flow, console and API DNS names
  • populate Silo DNS names in external DNS #2918
  • authn should validate that the user belongs to this endpoint's Silo #3529
  • console needs a password login page for "local only" Silos (Serve unauthed console page at /login/{silo_name}/local #3217 / Username/password login page console#1533)
• Console support for above features
  • role assignments for Organization and Project
  • role assignments for Fleet and Silo
  • ssh keys
  • Silos, IdP setup
• CLI support for above features
  • support --resolve for name resolution and --cacert to specify a ca cert oxide.rs#221
  • Merge strategy for integration workflow oxide.rs#219
  • non-required POST body parameters ignored by progenitor oxide.rs#34
• resolve flow for unprivileged users #1354
• all of authz, tracked under tracking issue for authz work #419
• Strong silo isolation #1340
  • Fleet privileges should not cascade into Silos #1580
  • better flesh out operator privileges in other Silos #1681
  • Depending on the outcome of 1681, enforce that Silo, Organization, and Project policies cannot refer to identities outside the Silo. See Fleet privileges should not cascade into Silos #1580. (edit: updated 1681 to include this)
  • Depending on the outcome of 1681, disallow fleet administrators from reading or modifying the policy on the Silo. See Fleet privileges should not cascade into Silos #1580 for details. Since fleet admins need to be able to modify which group is the "admin" group for a Silo, they may wind up changing the policy, but would not have carte blanche to change it however they like. (edit: updated 1681 to include this)
• want way to delegate Fleet access #3275
• cleanup / bugs
  • stop using Display/FromStr for database representations of per-resource roles #1080
  • clean up "test-privileged", "test-unprivileged" users #1087
  • spoof authn should look up the user's silo #1090
  • authz: fix several bugs #1110
  • clean up Polar file: non-functional changes #1112
  • clean up Polar file: minor functional changes #1113
  • should not be able to assign roles to users you can't see #1332
  • Duplicate (user, role) pairs in resource policy PUT body cause 500 #1185
  • decide whether we want to change "Fleet" in the authz subsystem to something else ("global", "region", or "az?). The way it's used is more like "az" or "region" but it's not yet clear which. This is most important for when roles are assigned on this resource -- everything else we could presumably change later, but that's going to be stored in the database.
  • authz check for modifying resource policy needs work
  • consider revisiting policy representation -- see considerations raised in need to represent role assignments for resources #890
  • consider whether we ought to re-work the schema for roles and role assignments with an eye towards custom roles in the future. For example, we might use uuids to identify roles (rather than (resource_type, role_name) tuple) in the role_assignments table
  • audit the exemption list in the role policy test
  • remove built-in silo, move built-in users to the test suite #2305

CC @jmpesp what have I missed?

[david-crespo]

Do any of these bullets represent being able to list users in a group? I don't see one.

Say you're on a project access page and some group has read access on that project. I would want to be able to click on the group and see who is in it. While we're using the JIT model for users, this list would necessarily be limited to users we're aware of because they've logged in. That might be confusing if there's a user you expect to see because you know they're in the group on the IdP side, but they don't show up because they've never logged into Oxide.

[davepacheco]

Good call. I don't think there was anything there that covered that. I added this as "list users in groups, list groups associated with a user".

While we're using the JIT model for users, this list would necessarily be limited to users we're aware of because they've logged in. That might be confusing if there's a user you expect to see because you know they're in the group on the IdP side, but they don't show up because they've never logged into Oxide.

Yup. I don't think there's much we can do in the API to mitigate this but maybe we can do something in the console? e.g., a small "expecting to see somebody else here?" link to a help page?

[david-crespo]

Right, good idea. We can at least explain it.

[benjaminleonard]

We need an unauthed endpoint that returns a silo's display name and its associated IdPs to implement the login screen on console. We do need to know which silo you're in right? Will this get unblocked when we have subdomains for silos?

[davepacheco]

We need an unauthed endpoint that returns a silo's display name and its associated IdPs to implement the login screen on console. We do need to know which silo you're in right? Will this get unblocked when we have subdomains for silos?

Yeah, Silos already have their own DNS names, though people don't necessarily use them in development. In a real system, we'll know which Silo you're in based on the DNS name you came in through (really the TLS SNI name, but those are generally the same thing). I'm not yet clear on what we'll do in development for this, where people often aren't using TLS nor DNS.

Even though we should know the Silo name already, for SAML, login starts when you GET /login/{silo_name}/saml/{idp_name} and ends with POST /login/{silo_name}/saml/{idp_name}. For password login, it ends with POST /login/{silo_name}/saml. So I figured we'd serve the password login page at GET /login/{silo_name}/local and we'll know where to POST the credentials. For SAML, we at least discussed having redirects so that GET /login/{silo_name}/saml redirects you to the GET for some default IdP. We could also have redirects from GET /login, since we should know the silo name already. I think these shouldn't be blockers? What do you think?

[benjaminleonard]

In theory we could redirect to the SAML page automatically, but I think it's a better user experience if you're hitting a page where the user triggers it themself. 99% of the time I imagine thats just them clicking the only button there. As I understand it, multiple IdPs on a single silo is uncommon but also trivial to support with this UI:

Those login endpoints sound good to me but @david-crespo and @zephraph are much more qualified to speak to that than I am. If we had those then the minimum we could return to serve this page would be: silo_name (which we already have and just need to make accessible without being authed) and associated idp_name[].

For dogfood would be move everything over to the IdP silo? So we don't have two silos on a single DNS name?

[davepacheco]

As I understand it, multiple IdPs on a single silo is uncommon but also trivial to support with this UI:

Yeah, as I understand it, it would be easy from the UI perspective. It's nasty internally and we want to avoid it (see all the stuff in RFD 234). I can still see it being useful to see a landing page like that, though, so you know what you're even logging into.

If we had those then the minimum we could return to serve this page would be: silo_name (which we already have and just need to make accessible without being authed) and associated idp_name[].

I'm not sure how best to convey these. @david-crespo or @zephraph have thoughts about all this?

For dogfood would be move everything over to the IdP silo? So we don't have two silos on a single DNS name?

Yeah...I believe that right now, we have a DNS "A" record that points the dogfood DNS name to the Nexus IP. It works in terms of TLS for whatever Silos we've uploaded that certificate for. But it's working a little bit by accident because we haven't finished this work. Nexus doesn't know what Silo you're coming in for in that configuration. It just doesn't care because it doesn't use that information yet.

(Another reason we don't want customers to do this is that we want to be in charge of DNS so that we can change IPs if we need to. At some point I think we want to change the dogfood DNS name to be a CNAME for the DNS name provided by the rack's own external DNS server. I think that's mostly unrelated, though.)

In order to keep using the same DNS name for Dogfood, we'll have to implement support for what I'd call "DNS aliases", where you can specify that the rack should serve one Silo's endpoints (e.g., "the-silo.sys.some-internal-dns-name.example") at some other DNS name (e.g., "the-silo.company.example"). I believe this is not needed for FCS so we'll have to decide whether we want to do this feature anyway and use it in Dogfood or change the Dogfood DNS name to just use the rack-provided naming scheme.

[davepacheco]

I've created issues for the open non-cleanup items so I think we can close this one.

@benjaminleonard I think we ended up addressing what you wanted?