Canonical usernames and linking accounts about jellyfin-plugin-sso

[strazto]

Here's a discussion I had about implementing user-facing views for user self-service

It was good news, the task seems straightforward

https://matrix.to/#/!YOoxJKhsHoXZiIHyBG:matrix.org/$ylce8_G_pQ5ygkH5Rz5cQHWZy4atA3TO_ntprzYNxd4?via=matrix.org&via=t2bot.io&via=kde.org

Matthew Strasiotto
Howdy! Continuing a discussion with Cody Robibero:
So I've implemented admin config client-side view for my plugin, it lives here
https://github.com/9p4/jellyfin-plugin-sso/tree/main/SSO-Auth/Config
I basically used trakt, ldapauth , and jellyfin-webs library views as references
Developing this admin config view is pretty straightforward for now
I want a user self-service view.
I don't think I can use pluginconfigpage API to register it, I think that's only for admin views
Cody Robibero
The view itself doesn't require permissions
Matthew Strasiotto
Ohhh, okay
Cody Robibero
It's the api the makes the requirements
Matthew Strasiotto
Does the link appear in the side menu for non-admins?
No Biggie if not
Cody Robibero
In 10.8 you can add a line to a json file with the link
Matthew Strasiotto
That makes my task much more straightforward!
Yep, that's what I thought
Cody Robibero
https://jellyfin.org/docs/general/clients/web-config.html#custom-menu-links
Though the server admin would need to set it
Matthew Strasiotto
Cody Robibero
Though the server admin would need to set it
That's no problem, the plugin is maturing anyway, and I get a feeling that someone will probably add user-side config for the custom menu link setting to jf eventually
(I would imagine that setting eventually living next to the disclaimer and branding stuff)
Awesome! All I need to do is use built-in self service endpoints as a reference for how to check role/permissions, and then implement a separate plugin config view that communicates with those endpoints

https://github.com/jellyfin/jellyfin/blob/433853b24cc9c3e931885818b515537befc946f3/Jellyfin.Api/Controllers/UserController.cs#L249-L305

Cody Robibero
That sounds about right
Matthew Strasiotto
So I guess presently if I manually type in the URL for a plugin config page on a non-admin account, the page will load correctly and everything will work until the ApiClient tries to access an endpoint that it doesn't have permission for
Awesome
Cody Robibero
Correct

[9p4]

My vision is that SSO can be used to sign into an existing account when the usernames differ.

Furthermore, there has to be something for "Sign in with Google" to have better username support.

All providers can add metadata about the user (full name, etc)

[strazto]

My vision is that SSO can be used to sign into an existing account when the usernames differ.

Furthermore, there has to be something for "Sign in with Google" to have better username support.

hm, yeah. Personally I now use google as a SSO provider for my authentik instance, so it no longer affects me.

There are a few options for something like this -

• Allow configurable UID Claim in provider config.
  • Users can instead claim on some other property, for example, email address
  • There are plenty of caveats to this, and google warns against it
  • The main problem is that most "human-friendly" properties on a google OIDC payload are either:
    • non-unique to the account
    • not-guaranteed to be immutable
      • email address is an example of this
  • Although configurable UID claim might have some use-case (idk what right now), it's probably not a good solution
• Allow some form of user-name registration flow when authenticating a new user via OIDC provider
  • This is probably more robust, but likely involves rolling-our-own UI
    • DIY UI probably relies on #21
    • We probably want this to be as simple as possible
  • This raises the question:
    • How flexible is jellyfin's user-model when it comes to storing custom metadata + attributes?
      Answer: Not very
    • Where do we store this relationship?
      Answer: Probably in the plugin config, though I'm unsure of how resilient this would be to concurrency, but maybe that doesn't matter.
    • How should we structure this relationship?
      • A given provider has a 1-n relationship with users, perhaps each provider has a hashmap of canonical name -> jellyfin ID?
  • Does jellyfin allow plugins to provide user-facing configuration pages, so that we can give a UI to link existing accounts to providers?
    • If not, we will likely have to DIY this UI, and use the new custom menu item feature to let users access it https://jellyfin.org/docs/general/clients/web-config.html#custom-menu-links

All providers can add metadata about the user (full name, etc)

By "providers" do you mean OIDC providers, or Jellyfin Identity Providers? I know OIDC providers can give plenty of metadata, but I don't know much about jellyfin ID providers

[9p4]

By "providers" do you mean OIDC providers, or Jellyfin Identity Providers? I know OIDC providers can give plenty of metadata, but I don't know much about jellyfin ID providers

OIDC/SAML providers putting name, etc into JF.

[strazto]

@9p4 I think I'd like your eyes on #34
In particular, I'm not sure about the best way to build an an endpoint for linking pre-existing users to idenity providers.

The current endpoint is probably not good enough - rigth now it just lets users manually set their canonical name for a given provider.

I think instead, we need something which initiates the flow, but the callback can differentiate between linking and auth requests, and we can validate the response based on that.

I kind of feel like there should be a GET endpoint that actually initiates the flow, client-side flow,

• and then the client-side flow initiates the flows with the provider,
• and accepts the callbacks they need to, except that, this time, (ideally)
• the client passes some extra state to the provider which is passed back on callback to the client (Does saml and oidc support this) which flags that we're just linking here, not authorizing.

EDIT
Actually, for OIDC, we can just use statemanager to differentiate auth requests from linking requests and delegate the correct method.

For SAML, I'm less clear on the correct way to distinguish these flows.

EDIT

I actually think we can implement linking endpoints that mirror the existing
/sso/{mode}/Auth/{provider} endpoints, instead:
/sso/{mode}/Link/{provider}/{jellyfinUserId}

Just like with /sso/{mode}/Auth/{provider}, we generate a js client that includes the OIDC / SAML state data (XML, or state id), which queries our endpoint, /sso/{mode}/Link/{provider}/{jellyfinUserId}, but:

• We also add the {jellyfinUserId} to the generated page
• our endpoint requires basicAuth,
  • because the user already has a session, it can use the AssertCanUpdateUser helper to verify the user has permission to create this link
• Our endpoint then verifies the auth response data

Third edit (lol)

Actually, for saml requests, we can use relayState to keep state & track the kind of request it is, and for OIDC, we can track whether each request is linking or not within the TimedAuthroizeState object

[9p4]

I think that the auth and linking would be ideally combined. On first login, the linking request will be created. Then, every other login would automatically work.

[strazto]

I think that the auth and linking would be ideally combined. On first login, the linking request will be created. Then, every other login would automatically work.

That's what I wound up making, I believe

[9p4]

Ah I must have misunderstood the code. I'll have to take a more careful look through.

[strazto]

Ah I must have misunderstood the code. I'll have to take a more careful look through.

Either that, or an old revision, I wound up re-doing it to go from linking req to flow, without an api call that explicitly links