Add OAuth or OpenID support

[strange pewter]

Lots of larger servers have other services for their staff-members like e-mail, grafana (where they store logs), documentation, etc.
Same is true for me. Which is why I am trying to allow one account to access all.
I have started implementing Authentik as an SSO (single-sign-on) solution and it has worked well with everything but txadmin.
Thus I'd love if OAuth/OpenID could be added in a future version.

[cobalt tree]

Not gonna be a thing.

this entire subject is complex

and the only people who realistically need SSO are the ones with huge teams

at this point you are making enough money

there is a reason why almost every SaaS out there charges for SAML/SSO features in their "Enterprise" tier

[strange pewter]

That's a stretch.
Also so far I've not implemented, or yet came to a service I needed, that only offered SSO to enterprise users...

I completely understand if the feature is too niche or to complex to implement.
But please don't tell me how much I make or how wealthy I stand.
I am not the typical server that you describe me as, making bucks by selling addon cars or pay-to-win features.

[cobalt tree]

the fuck are you smoking

But please don't tell me how much I make or how wealthy I stand.
i was obviously generalizing

That's a stretch.
Absolutely fucking not.
I literally worked years as an security/auth architect at a fortune 500, and i've dealt with over 100 (maybe way more) enterprise authentication/authorization integrations

[strange pewter]

I see my mistake. English is not my mother tongue 😅
In german "you" is always direct.

[cobalt tree]

and SSO is really not much relevant unless you have a large team where having old employees maintaining auth becomes a problem

[strange pewter]

I take back what I said

[cobalt tree]

in fact i was the one who always halted projects for rolling their own auth instead of using the corporate SSO solutions

And honestly it's not even that hard to implement, we already use cfx's OIDC endpoint

and we were going to add discord auth

until i realized that it would only annoy me at #old-txadmin-19h1-23h2 with people who didn't know how to set up their callback urls

[cobalt tree]

i see

[strange pewter]

I feel that 😭

I'd also like to give you a different perspective to why I personally decided to transition to an SSO solution.
Currently we are about 8 team-members where managing permissions is not too complicated (only nextcloud + txadmin).

I have changed for three reasons:

• So that when I use the multiple services (which I solely use right now) I wouldn't have to log in all the time and maintain different passwords.
• It would save a bit of time to maintain future users
• It would save time for team-members since they only need one login instead of two.

So all in all it's more about me wanting to optimize and tinker instead of saving cost/time (I'd imagine it's gonna be the same amount of work for both models at this point of time).

[cobalt tree]

i do see the value in it, just not enough to deal with maintaining this kind of feature for tx,whose vase majority of servers either only have a single account or the second account has all the permissions

[strange pewter]

I'd like to add some information on how I suggest this be accomplished (if in the future you chose to):

• The token name from the OAuth Client Credentials is checked against tx's known admin names and if matched the specific account is authenticated
• Thus all permission-setup would remain on tx and would not have to be implemented with OAuth specs (which I don't think it's intended for)
• If the name is not known either a profile with no permissions is created or the request is denied.

This would also work incredibly well with a group framework in tx.

• TX Users still have their default permission assignments
• You have TX Groups which can have permissions
• You can assign TX Groups to TX Users. Users will inherit all permissions from groups
• (Optional) You can define a parent group for a group so that all parent permissions are inherited
• In this scenario on every login with OAuth TX-Groups will be overridden with the token groups from OAuth. Group-names which don't exist in tx will be ignored.
• In this scenario unknown TX Users (no name match) will have a tx-account created with the specific groups.
• (Optional) A discord-attribute which will override a TX-Users discord property value.

[cobalt tree]

noted, thanks

[gilded pike]

I also need this functionality so I tried to implement it to make a pr but it bored me, the provideurs system has to be reimplemented everywhere because cfx.re is hard coded everywhere 😭

[strange pewter]

Looking into this further there is one critical functionality that would be missing automation-wise.
Accounts disabled would not be removed from tx, only their sso login disabled. Thus if someone set a password, they could still login.
LDAP (Lightweight Directory Access Protocol) would help in this case. However as far as I am aware it is very old 😅

Ideally this would be implemented similarily to how nextcloud allows it. Accounts are created with uid and displayname via ldap automatically and synced with it periodically. Accounts that disappear in ldap are disabled in nextcloud and purged after a grace-period. OAuth then allow you to log in using the shared uid.

LDAP is not a must-have with OAuth but would be nice addition. Having SSO integrated would already be a major step towards better user-managment and automation.
Maybe a setting to disallow users that were created via oauth from defining other authentications would help but the session-time will be difficult as the time-period between account removed from SSO (potentialy the time the user is removed) until their actual inability to log into txadmin would allow for abuse.

[gilded pike]

imo oauth2 users should not be able to connect other than via their provider. This would avoid any problems.

[strange pewter]

That would also work. Maybe another option for admins to "upgrade" accounts to native auth (i.e. enabling local auth but still permitting OAuth login)

[graceful furnace]

The correct way to write is txAdmin instead of TX-Admin.

[strange pewter]

To sum it up since I've gained more expirience and I would like to better explain how the systems work together / in my suggestion:

• LDAP will handle the accounts / account info sharing with txadmin. Basically txadmin periodically asks ldap what users exist and then creates txadmin-pseudo-users (A user in txadmin that has no direct authorisation via txadmin) or txadmin-linked-users (A user that may log in through txadmin but is linked to ldap) with the appropriate attributes:

  • UUID
  • Name
  • Groups

• OAuth would then authenticate these users to log in. It would send the authorised uuid which would then be mapped with the information already present through ldap.

  • Alternatively this could work with "auto-provisioning" instead: If a user uses OAuth with valid info, an account is created. However removing that user automatically is not possible in this case afaik. (All in all I suggest against this)

• If one would go with linked-users then one cuild input the uuid or name like it is done with discord/cfx. However most IdPs advise against names. A link through OAuth would be more user-friendly for the uuid approach.

  • This is not necessary with pseudo-users as they are already linked with the ldap information.

[gilded pike]

any news?