How can bots authorize against the new Fedora Chat matrix server?

Project Discussion
1

This might be a little off topic, but I have written a “zinebot” sorta for the fun of it and maybe to help me with running the Fedora Magazine meetings once the Fedora Matrix server is up. I’ve got it working against my own test Matrix server. But one question I have is how authentication will work on the Fedora Matrix server. On my test system, I’m using the following to login with a username and password:

our $tkn = $mtrx->login(
   'user_id' => USERNAME,
   'password' => PASSWORD,
)->get()->{'access_token'};

Will that sort of thing work with Fedora’s Matrix server or will something fancier have to be done with Kerberos tickets or OpenID tokens?

1 Like
2

I would absolutely love to be able to provide keytabs or something for this. Let’s break this out into a separate topic and see if we can get people from Infra to answer. :slight_smile:

1 Like
3

Well, not sure. It definitely won’t work with login/pass or keytab, but it could be via OAUTH token or ODIC setup. Would have to check with someone like @puiterwijk on the best/most practical way. We definitely want to make sure a bot doesn’t have the same name as a user, etc.

1 Like
4

So here is an absolutely terrible approach that @kevin will no doubt improve upon. But it should work :slight_smile:

  1. Register a Fedora account for the bot
  2. Log in to Element-web as the bot, accept necessary ToS etc
  3. Go to Settings > Help & About > Access Token
  4. Close the tab (don’t logout, it destroys the token)
  5. Use the access token for API calls

This obviously won’t work for frameworks that want to do the login for you and don’t allow specifying a token, but otherwise it should work - I’ve used this approach while testing a half-baked Matrix API wrapper for R :slight_smile: - but more importantly it works for Maubot too, as that maps clients to plugins using the access token to login.

EDIT: Disclaimer: I have not tested this with an SSO login, ansible.im doesn’t have SSO. But the access token is a fairly core part of the Matrix spec, so I’d be suprised if it doesn’t work.

1 Like
5

That is an absolutely terrible approach. But it does also work with the custom bot I’ve written using Net::Async::Matrix.

Would running a separate homeserver just for bots be unreasonable (e.g. “botnet.im”)? Maybe with some policies like “long random (app)passwords will be provided” and “passwords might be force reset on suspicion of compromise”? Maybe even require wireguard keys to access the ports if you are really paranoid?

Just some thoughts/ideas. Thanks.

P.S.: I can confirm that it works with the token received via SSO.

P.P.S.: I’m not actually sure how bridging/federation works. I’m assuming that a bot connected to one homeserver can access/post-to a room hosted on another homeserver. But maybe it doesn’t work that way.

2 Likes
6

I did warn you :rofl:. Good to know it works with SSO though, thanks for testing!

7

We do have the fedoraproject.org administrative homeserver, and we have five accounts on that. We could use one or more of those five for bots.

8

That’s an interesting idea. So fedoraproject.org is a separate homeserver? Behind the scenes I discovered that fedora.im used the fedora.ems.host homeserver.

So many bots would share one account? Maybe if all the account can do is the bare minimum of reading and posting text in public rooms that wouldn’t be unreasonable. I would still think you would want some additional means of allowing/blocking different users. Is the “administrative homeserver” publicly accessible? If not, and you can require that connections be made over wireguard, then the wireguard keys could be used to control who has access at any given time (I’m thinking that wireguard keys could be used sort of like ssh keys but to grant access to networks/ports rather than user accounts).

9

Yes, I was going to suggest just making normal accounts for bots and using their auth token.
I don’t know that there’s any great need to make bots use fedoraproject.org accounts up, with the possible exception of a admin bot that needed an account on that server to manage rooms, etc.

Any bots folks run should of course be well behaved and non distruptive, or it would be treated just like a distruptive user. :wink:

1 Like