On Monday, April 27, 2015 01:48:37 PM Ryan S. Brown wrote:
On 04/27/2015 12:50 PM, Dennis Gilmore wrote:
On Monday, April 27, 2015 06:23:38 PM Pierre-Yves Chibon wrote:
On Mon, Apr 27, 2015 at 05:59:14PM +0200, Till Maas wrote:
On Mon, Apr 27, 2015 at 03:45:00PM +0200, Pierre-Yves Chibon wrote:
[snip]
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.
This is really something that would be cool to get :)
This is not something that can really be done with certs etc. it would require a fundamental change in how all the tools deal with permissions.
Why isn't this possible with certs? Seems like an application/tools authorization problem, not an authentication mechanism problem. One of my workplaces had an internal system for distributing certs that provided access for users and service accounts. The ou/cn/dn/groups system has all the semantics you need to express complex permissions.
API tokens don't give delegation/permissions for free, though I do admit that certificate expiry leaves...things to be desired.
Koji for instance has very limited knowledge of permissions and does not have a fine tuned permission setup. you could issue a cert for doing one thing, but koji has no way to enforce that. its also not possible with other types of authentication and authorization. in the above example. there is no way that you can enforce the "use this token only to retire packages" its a all or nothing thing currently. I was trying to say that the apps need much much more work than just issuing different certs/tokens etc
Dennis