Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamically grant ircd oper status to registered account #2106

Open
luxaritas opened this issue Dec 14, 2023 · 0 comments
Open

Dynamically grant ircd oper status to registered account #2106

luxaritas opened this issue Dec 14, 2023 · 0 comments

Comments

@luxaritas
Copy link

Right now, in order to have server-wide oper privileges, you need to create an entry in the opers section of the server config, including a username and password to use with OPER. Since users may already be authenticated with an account, it would be more convenient in some circumstances if the following could be supported:

  • In the config file, in addition to password and certificate, you could configure account as a method to verify oper privileges (that is, if a user is logged into an account with a given username, they would automatically be given the permissions of the relevant oper class)
  • A new command could be used which would allow server ops to grant an account op privileges of a given oper class (without having to edit the config file)
  • A similar method to (or extension of) auth-script could update oper privileges of an account. For example, you could imagine imagine adding an additional property to the object returned by auth-script that would be an array called operClasses to update the classes the account is part of every time they log in, or a script that could be called at some interval to retrieve opers and their classes. Alternatively, you could argue that it would be better to implement this by creating an oped bot that could be used to update op status in an event-driven fashion, though it would need to be affirmed that this mechanism could handle situations where an external account is given privileges, but does not yet have an ircd account. SAML (support SAML #502) and OAuth (support OAUTHBEARER #2004) both provide mechanisms for specifying roles/permissions, so that should also be considered in how this would be implemented.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant