Hardcoded "azure" provider shortcut leads to unexpected behaviour

[TheToddLuci0]

The convenience alias for azure in opkssh add leads to non-intuitive behavior when using an enterprise / entra account. It is currently hard-coded to a tenant id that works with personal addresses, but not enterprise ones. This, in turn, means that if an unwitting admin (me) runs opkssh add bob@example.com azure, an entry is created with the baked in 9188040d-6c67-4c5b-b112-36a304b66dad tenant id, rather than my actual tenant.

Ideally, there would be some mechanism to load my tenant id, and use that. The three options that come to mind are:

• Parse /etc/opk/providers to look for an entry for login.microsoftonline.com
  • Don't totally love this, since it means that if multiple microsoft providers exist, there is now a requirement to remember which one gets loaded (First? Last? The one with the fewest unique characters?)
• Add a key to the config for along the lines of default_tenant, and sub that in
• if RFC: Provider configuration file spec #115 is accepted, and yaml becomes the provider format, remove all the current hard-coded shortcuts, and instead load all providers in the yaml file as shortcuts based on their name
  • I believe this isn't currently possible, since the current config doesn't store a top-level name for the providers

opkssh/main.go

Lines 103 to 104 in 3073c23

	case "azure", "microsoft":
	inputIssuer = "https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"

Additionally, the Azure docs should probably be updated to include note about the current behavior.

[EthanHeilman]

@TheToddLuci0 Thanks for this bug report. I'm looking into it

[EthanHeilman]

@TheToddLuci0 Would you be interested in putting a PR together to fix this? Maybe a quick PR to update the Azure docs and then a longer PR to actually address the issue?

I see your point about this being confusing. I hope it didn't cause to much of a problem for you. I can see this being annoying to debug.

Parse /etc/opk/providers to look for an entry for login.microsoftonline.com

This won't work because users many not have the ability to read /etc/opk/providers. It is only readable by root and opksshuser. We could change this to make it readable by everyone. Maybe that is ok.

Add a key to the config for along the lines of default_tenant, and sub that in

If you by config you mean /etc/opk/config.yml we run into the same read permissions issue as /etc/opk/providers.

if #115 is accepted, and yaml becomes the provider format, remove all the current hard-coded shortcuts, and instead load all providers in the yaml file as shortcuts based on their name.

This is the best argument I've heard for the yaml provider config! If we did the /etc/opk/providers.d/ pattern then the alias would be the filename, e.g. /etc/opk/providers.d/azure.yml defines the provider alias for azure. This would also solve the issue of colliding provider aliases. If it is just the filename, filenames are unique, so you can't create two colliding aliases.

This would let you create an auth_id like

# email/sub principal issuer 
alice alice@example.com google
root alice@hotmail.com azure

opkssh when verifying a user does have permission to read /etc/opk/providers.d/* and would simply match replace google with what is found in /etc/opk/providers.d/google.yml. We'd keep the ability to specify the exact issuer URI for backwards compatibility.

Perhaps we could even make /etc/opk/providers.d/readable by everyone so thatopkssh add alice alice@example.com aaazooorwould return an error if /etc/opk/providers.d/aaazooor.yml` does not exist.

[TheToddLuci0]

This won't work because users many not have the ability to read /etc/opk/providers. It is only readable by root and opksshuser. We could change this to make it readable by everyone. Maybe that is ok.

I was approaching this from the perspective of a sysadmin, completely forgetting that users can enroll their own per-user config. That said, a quick perusal of the OPKSSH docs seem to indicate that all the "common" providers use public Oauth configs, meaning that everything in that file is considered public. (Un?)fortunately, there does exist support for client secrets, meaning that there could be sensitive data in there. A potential solution there would be allowing the client secret to be loaded from a separate location, though that does add some complexity.

A better solution might be to (again, relying on #115) grant world execute on the directory, but not read on the files. This would let anyone list the files (and therefore, the providers), but not retrieve the potentially secret information within. This would only require the "support /etc/opk/providers.d" portion of #115 , not the switch to YAML portion.

For example, the install script could do something along the lines of

chown root:opksshuser /etc/opk/providers.d
chmod 651 /etc/opk/providers.d

a quick PR to update the Azure docs

Opened, #446

a longer PR to actually address the issue

I can take a look, but unfortunately I've only written about 15 lines of Go in my life, so I make no promises

[EthanHeilman]

(Un?)fortunately, there does exist support for client secrets, meaning that there could be sensitive data in there. A potential solution there would be allowing the client secret to be loaded from a separate location, though that does add some complexity.

OPKSSH does not support non-public clients. Google requires a client secret even for public clients, but this client secret is public so there is no sense in keeping it private.

Because enterprises want to keep policy information confidential and because I was always configure for least authority I defaulted all the files in /etc/opk/ to 640 (only owner or group can read). This decision is currently causing other headaches for me, for instance the audit command needs to be run as root to detect misconfigurations, but non-root users might want to use it as well. I've been debating changing /etc/providers to 644 (everyone can read), but this causes backwards compatibility issues since older versions of opkssh will be upset if permissions are 644 rather than 640.

Moving to /etc/opk/providers.d/ solves the backwards compatibility issue, the duplicate alias issue and the opkssh audit issue.