Skip to content

Claims mapping and custom claims #63

@ztmr

Description

@ztmr

The Issue

The email claim we get isn't really an email. When I use GitHub SSO or Passkey, I get stuff like john@github or john@passkey, which breaks a bunch of things:

  • can't correlate these fake emails with actual users
  • apps obviously can't email someone@github
  • same person could end up with different "emails" depending on how they log in

I know this probably comes from how Tailscale itself handles non-email auth methods, but it makes TS-IDP tricky to use in practice.

What I've Tried

I see people are putting proxies in front of TS-IDP to do claims transformation, which works, but that adds unnecessary complexity. tsidp is a perfect fit for small teams and communities, and that is precisely where there are no unified SSO domain, or strict username rules, etc.

Also tried using extraClaims based on the code and related issue, but can't get it to work, no matter what I tried. This would at least let me hardcode something like preferred_username per-user right into the policy -- not great, but good enough workaround:

{
  "src": ["john@passkey"],
  "dst": ["..."],
  "app": {
    "tailscale.com/cap/tsidp": [
      {
        // [the usual options...]

        "includeInUserInfo": true,
        "extraClaims": {
          "preferred_username": "john.doe",
        },
      },
    ],
  },
}

I have tried this with the tsidp build off the original tailscale/tailscale repo, as well as with this repo's release 0.0.1 and 0.0.2 -- where I had to fight the new CAP policy first -- and eventually had some other problems, having to revert back to the tailscale/tailscale code.

Thoughts?

Would be awesome if we could do something like:

  • claims mapping directly in the policy (map john@github → actual useful info)
  • get extraClaims actually working (am I doing it wrong?)
  • maybe add some other useful claims that don't depend on having real emails?

Anyone else hitting this? Any workarounds I'm missing? Or is the proxy approach just the way to go for now?

Metadata

Metadata

Assignees

No one assigned

    Labels

    OAuthRelated to OAuth compatibility and support

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions