Hi Guido, On 14:30 Thu 13 Feb , Guido Trotter wrote: > > 2. It's also easy to monkey-patch RemoteApiHandler.Authenticate to > > provide our own authentication and authorization for individual > > requests. This allows even more fine-grained control, by inspecting > > the RAPI call request and body. > > > > I wonder if we should have Authentication in RAPI and Authorization at > the LU level, thus not requiring RAPI to understand the request > bodies.
Certainly. It occurred to me as well that the current implementation does not distinguish authentication from authorization. With a quick glance at the code, it seems that adding an extra authorization check right before submitting the opcode should be straightforward and much more elegant than deserializing the request body twice. > > What would make things a lot easier from Ganeti's side, would be to > > allow the admin to specify a "middleware" module, providing a single > > RemoteApiHandler class (deriving from the original class) to use instead > > of the original, as a command line argument or via an environment > > variable. This would in turn require a documented and relatively stable > > API for the RemoteApiHandler class, which would become kind of > > semi-public. > > > > We could do that or just implement a pluggable interface that is > called by RAPI for AAA without the need to override the class. This > would have the advantage of making it possible to provide that with > other systems as well, do you think it's worth it? Yes, we could. I would still prefer it to be a pluggable Python interface rather than external programs though. Regards, Apollon
