> diff --git a/doc/design-rapi-pam.rst b/doc/design-rapi-pam.rst > new file mode 100644 > index 0000000..b5bc5ed > --- /dev/null > +++ b/doc/design-rapi-pam.rst > @@ -0,0 +1,132 @@ > +=============================================== > +RAPI authentication and authorization using PAM > +=============================================== > + > +.. contents:: :depth: 4 > + > +This design document describes a way of :doc:`rapi` authentication > +and authorization refactoring by using pluggable authentication modules
s/using/using the/ > +(PAM). > + > +Current State > +============= > + > +Currently :doc:`rapi` supports authentication using *basic* https > +protocol. The users are stored in a file (usually s/\*basic\* https protocol/\*basic auth\* over https/ ? > +``/var/lib/ganeti/rapi/users``) and have either read or write rights. > +Please read :ref:`rapi-users` for more details. > + > +.. _motivation: > + > +Motivation > +========== > + > +During the GanetiCon 2015 the following features were requested by the s/the GanetiCon 2015/GanetiCon 2015/ > +community: > [...] > +Switching Between the Old and the New Implementations > +----------------------------------------------------- > + > +As the changes introduced should be backwards compatible, a new > +configure flag ``--enable_pam_rapi`` will be introduced. Really a configure flag? Why not a run-time option of the daemon? Note that this very patch series actually implements a run-time option of the RAPI daemon, and not a flag at configure time. > +Other Changes > +============= > + > +As writing PAM module is an universal solution for the authorization > +problem, sometimes such flexibility is not necessary or not > +available because of disabled PAM. In that case it is still possible > +to provide granular access to the RAPI. > + > +For that purpose ``RAPI-Auth:username`` will be added to the reason > +trail just before sending a job for a further processing. That will > +allow to configure a filter that will reject job subsets initiated > +by some specific user i.e. add a user to a blacklist. See > +:doc:`design-optables` for more information about job filters. > + > +Another proposal is to introduce a new s/Another poposal is/Additionally, we propose/ Note that "Another porposal" can be read as indicating an alternative way of action, whereas you actually propose to do both suggestions. > +:ref:`filter predicate <filter-predicates>`, ``username`` that will > +contain the authenticated user's login and thus will make it possible to > +define an allowed user set for each operation. -- Klaus Aehlig Google Germany GmbH, Dienerstr. 12, 80331 Muenchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschaeftsfuehrer: Matthew Scott Sucherman, Paul Terence Manicle
