On Mon, Apr 27, 2015 at 03:45:00PM +0200, Pierre-Yves Chibon wrote:
The following only works under the assumption that it is.
So SSL certs are basically a certain type of API token. Everyone has one,
specific to koji and the lookaside cache, time limited and gives us a way of
doing authentication and authorization server side.
So on this they behave just like any other API token, but using SSL certs has
some pros and downs:
It is not an API token in the sense that the key is not transfered via
TLS, so if there are bugs in TLS like Poodle, they do not expose the
token.
cons:
- One per client
- Hard to invalidate iiuc (ie: if someone's machine is compromised/lost it is
hard to make this user's certificate invalide)
This is not the case currently afaik. If one creates a new certificate,
the old one is revoked and our systems honor this.
- Relies on the master certificate that expires every X years
making everyone
generate a new client certificate
The expiration of the master certificate does not require the client
certificate to be regenerated as long as the same master key is used.
Also it is easily possible to move to a new master CA while keeping the
old CA valid for a migration time (e.g. the duration of normal client
certificates).
On the otherside, recently we have been more and more feeling the
need for a
centralized API authentication place. Something along the line of a personalized
0Auth. This has also pros and cons.
pros
- API token per user and per application
This is something I would like very much, but also with a fine-grained
permissions system. E.g. allowing to create a token that can only be
used to retire pkgs in pkgdb could be used to automate retiring pkgs
without using credentials that can also a everything else.
Regards
Till