[one-users] How to allow regular users to login to the cloud remotely, safely and using the cloud concurrently?

[Anders Branderud]

Hello again!

I solved the other problem. I was expecting that the user should be asked to
give a password when logging in to OpenNebula through the oneadmin-account,
but apparently this wasn't the case. I succeed to login as another user
through the oneadmin-account.

Could you give me any ideas of what's the best way to implement this (I am
doing a bachelor's thesis) [I know how to implement most of the below and I
will ask specifically after the following paragraphs what I need help with.
Problem description that I have written):

ICT at Royal Institute of Technology [KTH]- a university of Stockholm in
> Sweden - have 16 computers that they are not using, which they bought from
> PDC at KTH couple of years ago. One of the goals is to install OpenNebula
> [explained below] on them all, with one of the computers being the front
> end. I call this cluster of nodes Cloudelia.
>
> The system should follow the following requirements:
> In this system we have administrators and ordinary users (‘user’). The
> administrators have the right to grant other KTH users the privilege to
> become administrators. In order for a user to use the system, authentication
> needs to be done to ensure that it has a KTH-account. When an administrator
> sees an get permission-request from an user and is deciding on whether to
> approve the user or not, it must be able to rely on than an
> authentication-mechanism ensures that the user really is the user with the
> specific KTH-user name shown in the interface. This ensures that any user
> outside of KTH with an intent to use Cloudelia in a malicious way doesn’t
> get access to the system.
>
> An administrator is presented with information of all KTH-users that have
> requested and are waiting for to get permission to use OpenNebula for a
> certain course. The administrator can grant permission to any number of
> these users at a time, and upon granting permission these users will get
> access to Cloudelia as Open Nebula-’regular users’ [explained below] using
> the login details they provided upon requesting permission to Cloudelia. An
> administrator can see a list of all the users of a certain course and can
> change the permission rights of an user.
>
> The described procedure of handling the accounts reduces the work load of
> the administratiors. One advantage is that they don’t need to set up
> accounts for each user one at a time, by manually assigning them user names,
> passwords and entering the commands required in OpenNebula for creating an
> Open Nebula-regular user.



> [More information of my proposed solution is found here: Link<https://docs.google.com/document/d/1Y6X2jUlQR2Uwf-3G7Zk2C9Y8ERgA-EddwBvKpRbnBZI/edit?hl=en#>
> ]
>

* More specifically I wonder how to solve this:*
When the administrator has approved a student to get permission to access
the cloud, and his/her OpenNebula account including password has been
created: How should the student access the cloud? Could you suggest to me a
safe way that can handle multiple users at the same time?

The cloud stands in a server hall, so the user should access the cloud
through some remote access.
How do I allow the user to get access to the cloud when he/she
provides his/her username and password.
What kind of interface for the user to provide his/her username and
password is the smoothest solution?
Many users will access the cloud at the same time.

Thanks for your help!

--Kind Regards, Anders Branderud

[Personal blog] www.proofexistencegod.com  : Logical reasons - based on
scientific premises - for the existence of a Creator and that He hasn't left
His sapient creatures without an Instruction Manual - Torah ['books of
Moses'] - to ascertain, and aspire to, His purpose.

[Company] Anders Branderud IT Solutions - www.abitsolutions.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20110505/7b3283cc/attachment-0002.htm>