fedora-qa / releasestream

#2 Authentication
Opened by adamwill. Modified

Open
Close Issue

...we may need it. There's a few options.

  • We can try and integrate with FAS/AAA. There's a Flask module for FAS and presumably will be for AAA, but not a Falcon one. Not sure if I want to rewrite to Flask just for that. I feel like this is probably overkill because we don't really need super-advanced full-fat auth for this thing, we don't expect people to be sitting there trying to "log in" to it, that's not the idea. We expect a fairly small range of things to be permanently authorized to send POSTs to it, that's about it.

  • We can try and set up some kind of simple token-based auth in the app, using maybe JWT, and have a simple mechanism for generating tokens. Like, just have a tiny CLI command to generate them and have them stored in a flat file, with the rule being if you can write to that file on the server, you can grant and revoke tokens. That should be sufficient for our purposes, which should be "allow a fairly small number of things running inside infra that do release cycle-y things to POST to this".

  • We can fudge it like we do for resultsdb and have the app not handle auth at all, but have the WSGI server do it. For resultsdb we use Apache as the WSGI server and have it do IP-based access control, allowing IPs in the known ranges of infra machines to submit results. We could do that for this too, in the same way it'd be ugly but simple and probably good enough. You can only cause so much havoc by publishing fake messages, really, and only people who could cause a machine inside infra to submit an HTTP post to the server could do it. If we go with this, so far as this app itself is concerned we'd just document that it doesn't do authentication at all but expects the WSGI server to handle it, and close this ticket.

Ping @kevin @smooge @puiterwijk - thoughts?

There are several Falcon extensions that we could conceivably use:

  • falcon-auth (dormant for two years, has basic, token, JWT and Hawk backends)
  • falcon-authentication (ditto falcon-auth, claims to be a "maintained fork" of falcon-auth but actually they both went inactive around the same time and diverged slightly before going inactive)
  • falcon-auth2 (active four months ago, only has basic auth built in, there's a ticket to add a JWT backend, "inspired by" the first two)
  • falcon-jwt (dormant for four years, may not even work any more? JWT only, unrelated to the others AFAICS)
  • falcon-jwt-checker (similarly dormant four years, JWT-only)

haven't tried digging into any of them too much yet.
Edited by adamwill

Please note that the access tokens issues by Ipsilon aren't JWT's (yet, that could be changed in the future, but unsure yet).
Instead of that, Ipsilon implements RFC7662 ("OAuth 2.0 Token Introspection") for a Protected Resource (e.g. "releasestream") to validate the access token provided.
This is a very simple API that you could relatively easily implement in this codebase.

It comes down to:
1. Extract the access token (it should be in the Authorization HTTP header as Bearer <value>. Note that for mod_wsgi you need to enable PassAuthorization).
2. Remove the Bearer prefix.
3. Send an HTTP POST with the following fields: token (the token), token_type_hint (optional, "bearer"), and the client ID/secret as Basic auth username/password.
4. Parse the response as json, where you need to check a few things

To check:
1. Whether the active field is set to the json bool true
2. Whether the scope field (space-separated strings) contains the scope you want to use

After that, you can use the sub field from the token as their username to check if they're authorized.

Thanks. When thinking about JWTs I was actually thinking about skipping Ipsilon / FAS entirely, since we don't really need authentication by a person anyway. Usually what's going to need authorization to submit events is a system, and probably only a few of them. So I was thinking about just issuing individual JWTs for systems that need to report events, on an ad-hoc basis.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/quality/releasestream/issues/2

Please continue any further discussion there.
Metadata
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.