Random thoughts/crazy idea: Drop SSL certs

[Dennis Gilmore]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150427/6962895d/attachment.sig>