Adds wildcard support for email addresses

[Jonhu]

Issues:
#41
#461

Example on how a basic wildcard identification could be done in /etc/opk/auth_id .
I explicitly did not implement the whole regex schema as the use case has to be proven first and it'd be a bit more work to do good.

To clarify:
Currently *@example.com is both a wildcard and a valid email address and thus has a double use and cannot be explicitly granted access. This would of course be bad for someone who has that address but wouldn't compromise security.
Another option would be to include another column in the auth_id table to allow for wildcards on domain level.

@EthanHeilman any thoughts?

[EthanHeilman]

Thanks for putting this together. Very excited to have wildcard matching, a lot of users have been asking for it.

I explicitly did not implement the whole regex schema as the use case has to be proven first and it'd be a bit more work to do good.

I don't think we should ever have the full regex schema in auth_id. Humans are bad at thinking about regexes and it would be a massive footgun. I plan on adding the ability for people to call out to a policy program or script so that they can build their own complex policies. I do think the auth_id should have functionality like wild cards.

Currently *@example.com is both a wildcard and a valid email address and thus has a double use and cannot be explicitly granted access. This would of course be bad for someone who has that address but wouldn't compromise security.

This PR #68 is adding group claim matches using the kube authentication syntax

root oidc:groups:developer https://accounts.google.com

We could extend this syntax to other claims like email or sub.

root oidc:email:alice@example.com https://accounts.google.com

Using this approach we could add

root oidc-match-end:email:@example.com https://accounts.google.com

Which would be equivalent to *@example.com without having to worry about emails that have * in them. If went down this route, we should have all sorts of useful relationships

%u oidc-match:email:%u@example.com https://accounts.google.com

This would allow any email address which matches with the username such as alice alice@example.com. Similar to the idea suggested here: #41

As a security precaution we'd want to reject any email address which started with oidc-match-end:email similar to rejecting any ID Token with *@example.com

I'm still thinking this through, what do you think?

[Jonhu]

Sounds good! It's more expressive and in the same sense I was also thinking about separating Email and Sub so that is then also done. The fallback behavior is then to treat everything that doesn't have the kube config URN as "EmailOrSub"?

Which would be equivalent to *@example.com without having to worry about emails that have * in them. If went down this route, we should have all sorts of useful relationships

%u oidc-match:email:%u@example.com https://accounts.google.com

I'm not sure if I'm a fan of the substitutions. Everything that is not explicitly in here and subject to change over the lifetime of a system has nasty security implications. That also is true for wildcards but there we are explicitly allowing everything. In this example a user would want the current users, but does he really want to also add "root" or "opksshuser" ?

Nevertheless I guess this can be abandoned then.

[EthanHeilman]

My comments below are not a request to add substitutions to this PR. I don't think substitutions should be in this PR. I plan to roll these ideas and discussions into an issue to consider the future design for substitutions.

I'm not sure if I'm a fan of the substitutions. Everything that is not explicitly in here and subject to change over the lifetime of a system has nasty security implications.

@Jonhu I agree and I'm trying to think about the least footgun way to solve this. Let me give you the requirements and rather a solution:

Many organizations and many universities have the pattern username@example.edu and then username for linux, windows, etc... If they have 20,000 students they don't want a auth_id file that is 20,000 lines long that looks like:

alice alice@example.edu https://accounts.google.com
bob bob@example.edu https://accounts.google.com
carol carol@example.edu https://accounts.google.com
...

Now if they have a student named Randel Oot (R. Oot), they have a pattern and notice if they gave him root@example.edubad things would happen. So he gets the email randel.oot@example.edu or something like that. But what if the system for adding new emails is compromised, someone could create a root@example.edu and then get root on everything. That's bad and they need a mechanism to prevent that.

So you really want to say, do this substitution for everything but root, backup, etc etc...

Now one solution which has been proposed is to have an AuthorizedKeysCommand for opkssh. This would let anyone represent any complex policy by writing a script. I think we have to build that at some point because it is so useful, but it is also more configuration work for the admin.

What are your thoughts?

[EthanHeilman]

The fallback behavior is then to treat everything that doesn't have the kube config URN as "EmailOrSub"?

yes

[EthanHeilman]

Nevertheless I guess this can be abandoned then.

I don't think you should to abandon this PR, if that is what you are asking. You are mostly done it is just a syntax issue.

[Jonhu]

Many organizations and many universities have the pattern username@example.edu and then username for linux, windows, etc... If they have 20,000 students they don't want a auth_id file that is 20,000 lines

Yeah this gets quite complex.
I'd argue that such an org should have user permissions based on groups, otherwise they have the configuration nightmare anyway. With the proposed syntax something like %tempuser oidc:groups:developer https://accounts.google.com could enable users to log in as a temporary user with expiry date set to token expiry with useradd --expiredate and given group permissions?

As long as we maintain auditable logs who was who for how long this should be an opinionated solution that works without those edge cases.
Of course if you' still want to log in as a static user you have to be explicit. You could also use a wildcard and manage it with x user accounts and restricted access to your provider.

Now one solution which has been proposed is to have an AuthorizedKeysCommand for opkssh. This would let anyone represent any complex policy by writing a script.

I think this would be beneficial for those cases too and would also allow for substitutions if someone really wants it.

I don't think you should to abandon this PR, if that is what you are asking. You are mostly done it is just a syntax issue.

Ah I've read #68 wrong - I'll adjust it here!

On that then: how do we deal with multiple matches in the auth_id file? I'm not a fan of ordering within the file - would an explicit > implicit prioritization work? Something like static user with email > static user with group > static user with wildcard email.

[EthanHeilman]

On that then: how do we deal with multiple matches in the auth_id file? I'm not a fan of ordering within the file - would an explicit > implicit prioritization work? Something like static user with email > static user with group > static user with wildcard email.

Ordering shouldn't matter. Since auth_id is an allow list, the first match which allows the requested principle lets them log in. If they match multiple times we don't care because they only need to match once. This is also how SSH auth_id works.

[aaron-riact]

ah, wildcard support for emails, just what I was looking for. Can this be taken out of draft now?

[EthanHeilman]

@Jonhu Are you still working this?

@aaron-riact If you want an immediate solution you can use the policy plugin system that will do email wildcarding

https://github.com/openpubkey/opkssh/blob/main/docs/policyplugins.md#example-policy-configs

[aaron-riact]

https://github.com/openpubkey/opkssh/blob/main/docs/policyplugins.md#example-policy-configs

amazing 😍 . Thanks @EthanHeilman

[EthanHeilman]

@aaron-riact Open an issue if you run into any problems. I want the policy plugin experience to be easy to setup and use