User Security and Authentication

By default Sunstone works with the core authentication method (user and password) although you can configure any authentication mechanism supported by OpenNebula. In this section you will learn how to enable other authentication methods and how to secure the Sunstone connections through SSL.

Authentication Methods

Authentication is two-fold:

  • Web client and Sunstone server. Authentication is based on the credentials stored in the OpenNebula database for the user. Depending on the type of these credentials the authentication method can be: sunstone, x509 and opennebula (supporting LDAP or other custom methods).
  • Sunstone server and OpenNebula core. The requests of a user are forwarded to the core daemon, including the original user name. Each request is signed with the credentials of a special server user. This authentication mechanism is based either on symmetric key cryptography (default) or x509 certificates. Details on how to configure these methods can be found in the Cloud Authentication section.

The following sections detail the client-to-Sunstone server authentication methods.

Basic Auth

In the basic mode, username and password are matched to those in OpenNebula’s database in order to authorize the user at the time of login. Rack cookie-based sessions are then used to authenticate and authorize the requests.

To enable this login method, set the :auth: option of /etc/one/sunstone-server.conf to sunstone:

:auth: sunstone

OpenNebula Auth

Using this method the credentials included in the header will be sent to the OpenNebula core, and the authentication will be delegated to the OpenNebula auth system using the specified driver for that user. Therefore any OpenNebula auth driver can be used through this method to authenticate the user (e.g. LDAP). The sunstone configuration is:

:auth: opennebula

x509 Auth

This method performs the login to OpenNebula based on a x509 certificate DN (Distinguished Name). The DN is extracted from the certificate and matched to the password value in the user database.

The user password has to be changed by running one of the following commands:

oneuser chauth new_user x509 "/C=ES/O=ONE/OU=DEV/CN=clouduser"

or the same command using a certificate file:

oneuser chauth new_user --x509 --cert /tmp/my_cert.pem

New users with this authentication method should be created as follows:

oneuser create new_user "/C=ES/O=ONE/OU=DEV/CN=clouduser" --driver x509

or using a certificate file:

oneuser create new_user --x509 --cert /tmp/my_cert.pem

To enable this login method, set the :auth: option of /etc/one/sunstone-server.conf to x509:

:auth: x509

The login screen will not display the username and password fields anymore, as all information is fetched from the user certificate:

image0

Note that OpenNebula will not verify that the user is holding a valid certificate at the time of login: this is expected to be done by the external container of the Sunstone server (normally Apache), whose job is to tell the user’s browser that the site requires a user certificate, and to check that the certificate is consistently signed by the chosen Certificate Authority (CA).

Warning

The Sunstone x509 auth method only handles the authentication of the user at the time of login. Authentication of the user certificate is a complementary setup, which can rely on Apache.

Remote Auth

This method is similar to x509 auth. It performs the login to OpenNebula based on a Kerberos REMOTE_USER. The USER@DOMAIN is extracted from the REMOTE_USER variable and matched to the password value in the user database. To use Kerberos authentication, users need to be configured with the public driver. Note that this will prevent users authenticating through the XML-RPC interface; only Sunstone access will be granted to these users. To update existing users to use Kerberos authentication, change the driver to public and update the password as follows:

oneuser chauth new_user public "new_user@DOMAIN"

New users with this authentication method should be created as follows:

oneuser create new_user "new_user@DOMAIN" --driver public

To enable this login method, set the :auth: option of /etc/one/sunstone-server.conf to remote:

:auth: remote

The login screen will not display the username and password fields anymore, as all information is fetched from the Kerberos server or a remote authentication service.

Note that OpenNebula will not verify that the user is holding a valid Kerberos ticket at the time of login: this is expected to be done by the external container of the Sunstone server (normally Apache), whose job is to tell the user’s browser that the site requires a valid ticket to login.

Warning

The Sunstone remote auth method only handles the authentication of the user at the time of login. Authentication of the remote ticket is a complementary setup, which can rely on Apache.

Two Factor Authentication

With this method, not only does it request a username and password, it also requires a token generated by any of these applications: Google Authentication, Authy or Microsoft Authentication.

To enable this, you must follow these steps:

  • Log in sunstone, and select menu Setting. Inside find and select the tab Auth

image_setting

  • Inside find and select the button Manage two factor authentication

image_setting_auth

image_setting_2fa

Internally sunstone adds the field TWO_FACTOR_AUTH_SECRET.

image_template_user_auth

  • To disable 2FA, go to the setting, Auth and select the button disable.

image_setting_auth_disable

Configuring an SSL Proxy

OpenNebula Sunstone runs natively just on normal HTTP connections. If the extra security provided by SSL is needed, a proxy can be set up to handle the SSL connection that forwards the request to the Sunstone server and returns the answer to the client.

This set up needs:

  • A server certificate for the SSL connections
  • An HTTP proxy that understands SSL
  • OpenNebula Sunstone configuration to accept requests from the proxy

If you want to try out the SSL setup easily, the following lines provide an example to set a self-signed certificate to be used by a web server configured to act as an HTTP proxy to a correctly configured OpenNebula Sunstone.

Let’s assume the server where the proxy is going to be started is called cloudserver.org. Therefore, the steps are:

Step 1: Server Certificate (Snakeoil)

We are going to generate a snakeoil certificate. If using an Ubuntu system follow the next steps (otherwise your mileage may vary, but not a lot):

  • Install the ssl-cert package
apt-get install ssl-cert
  • Generate the certificate
/usr/sbin/make-ssl-cert generate-default-snakeoil
  • As we are using lighttpd, we need to append the private key to the certificate to obtain a server certificate valid to lighttpd
cat /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/certs/ssl-cert-snakeoil.pem > /etc/lighttpd/server.pem

Step 2: SSL HTTP Proxy

lighttpd

You will need to edit the /etc/lighttpd/lighttpd.conf configuration file and

  • Add the following modules (if not present already)
    • mod_access
    • mod_alias
    • mod_proxy
    • mod_accesslog
    • mod_compress
  • Change the server port to 443 if you are going to run lighttpd as root, or any number above 1024 otherwise:
server.port               = 8443
  • Add the proxy module section:
#### proxy module
## read proxy.txt for more info
proxy.server               = ( "" =>
                                ("" =>
                                 (
                                   "host" => "127.0.0.1",
                                   "port" => 9869
                                 )
                                 )
                             )


#### SSL engine
ssl.engine                 = "enable"
ssl.pemfile                = "/etc/lighttpd/server.pem"

The host must be the server hostname of the computer running the Sunstone server, and the port the one that the Sunstone Server is running on.

nginx

You will need to configure a new virtual host in nginx. Depending on the operating system and the method of installation, nginx loads virtual host configurations from either /etc/nginx/conf.d or /etc/nginx/sites-enabled.

  • A sample cloudserver.org virtual host is presented next:
#### OpenNebula Sunstone upstream
upstream sunstone  {
        server 127.0.0.1:9869;
}

#### cloudserver.org HTTP virtual host
server {
        listen 80;
        server_name cloudserver.org;

        ### Permanent redirect to HTTPS (optional)
        return 301 https://$server_name:8443;
}

#### cloudserver.org HTTPS virtual host
server {
        listen 8443;
        server_name cloudserver.org;

        ### SSL Parameters
        ssl on;
        ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
        ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;

        ### Proxy requests to upstream
        location / {
                proxy_pass              http://sunstone;
                proxy_set_header        X-Real-IP $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        X-Forwarded-Proto $scheme;
        }
}

The IP address and port number used in upstream must be the ones the server Sunstone is running on. On typical installations the nginx master process is run as user root so you don’t need to modify the HTTPS port.

Step 3: Sunstone Configuration

Edit /etc/one/sunstone-server.conf to listen at localhost:9869.

:host: 127.0.0.1
:port: 9869

Once the proxy server is started, OpenNebula Sunstone requests using HTTPS URIs can be directed to https://cloudserver.org:8443, that will then be unencrypted, passed to localhost, port 9869, satisfied (hopefully), encrypted again and then passed back to the client.

Note

To change the serveradmin password, follow the next steps:

oneuser passwd 1 --sha256 <PASSWORD>
echo 'serveradmin:PASSWORD' > /var/lib/one/.one/oneflow_auth
echo 'serveradmin:PASSWORD' > /var/lib/one/.one/ec2_auth
echo 'serveradmin:PASSWORD' > /var/lib/one/.one/onegate_auth
echo 'serveradmin:PASSWORD' > /var/lib/one/.one/occi_auth
echo 'serveradmin:PASSWORD' > /var/lib/one/.one/sunstone_auth

Restart Sunstone after changing the password.