authorization: Filter resources by users and groups

Currently, every user with 'admin' role can perform any operation on any virtual
machine.

In order to add more security, Kimchi will only allow users listed in
the VM metadata - along with those with 'admin' role - to be able to
perform actions on it. A VM may contain a list of system users and groups
associated with it. If a user is not listed to access a VM, they will
not be able to see it or to perform any operation on it.

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
Signed-off-by: Crístian Viana <vianac@linux.vnet.ibm.com>
authorization: Restrict Collection access based on admin_methods parameter

GET and POST are the allowed methods for a Collection
If you want to restrict access to the Collection based on the request
method, you must set the self.admin_method parameter accordingly
Kimchi will restrict all the POST request to a Collection, ie, only the
admin can create new resources in the Collection

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
authorization: Restrict access to Resource instance

An user only can perform actions to a Resource if it is not protected or
if the logged user is listed in the resource users and groups parameters.
Also update the tests to reflect those changes.

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
authorization: Update control files to set role_key and admin_methods

Each resource or collection must specify the role_key and admin_methods
values if it wants to be protected.

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
authorization: Remove authorization config from UrlSubNode

UrlSubNode is used to automatically load the application configuration
and set kimchiauth tool when needed.

If we use it to also handle the authorization configuration, we won't be
able to specify different configuration to collection and its resource
as Kimchi uses the same base URL to both.

Example:
@UrlSubNode("vms", True, ["POST", "PUT", "DELETE"], 'guests')
It meant that all the methods listed were exclusive for admin users.
Which it is not correct, as a user assigned to a VM can also perform POST,
PUT and DELETE actions.

To be able to distinguish the configuration for resource and collection, the
autorization mechanism was moved to controller.

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
Return some groups for every user in mockmodel

In the current mockmodel implementation, the "environment" returns None
as the group list for all system users.

In order to make the mockmodel environment more dynamic, every user will
belong to the same list of groups - instead of none.

Signed-off-by: Crístian Viana <vianac@linux.vnet.ibm.com>
Move "fake_user" credentials to mockmodel

The "fake_user" credentials are used along with the mockmodel. Instead
of having it declared on a test file, move the declaration to a more
generic place.

Move the "fake_user" credentials from the test files to the mockmodel.

Signed-off-by: Crístian Viana <vianac@linux.vnet.ibm.com>
List "admin" as a valid system user in mockmodel

The mockmodel environment reports a static list of users available on
the system. Currently, it does not include the fake user which is used
by the mockmodel authentication.

In order to make the code consistent, the user which authenticates to
the mockmodel environment should be listed as a valid system user.

Signed-off-by: Crístian Viana <vianac@linux.vnet.ibm.com>
authorization: Update test cases based on last changes

Signed-off-by: Crístian Viana <vianac@linux.vnet.ibm.com>