Authentication

Authentication refers to how we identify the client that is connecting to Concerto. This document contains a basic overview of how the software will determine who the connecting user is, and how it will know that they are who they say they are.

Overview

Many aspects of Concerto require authentication. In Concerto 2, authentication will come in three flavors:

1. User Authentication
2. Screen Authentication
3. API Keys

The authenticated entity will be known as an “accessor”, and the associated record (User, Screen, etc.) will be available to the application for presentation of user data and so that authorization checks may be performed.

Concerto uses Devise to authenticate accessors. To manage authorization rules, it uses CanCan.

Note that by itself, Concerto faces the security vulnerabilities associated with transmitting passwords and cookies in the clear over a network. On a local intranet this may not be a problem, but for a publicly accessible deployment, it is strongly recommended that your webserver be configure so that Concerto is only accessible through HTTPS. This will make the system much more secure.

User Authentication

To Authenticate Users utilizes Devise’s password based authentication by default, with user identity being stored in the session after login. Other Authentication methods supported by Devise will be pretty straightforward to swap in, though we don’t have documentation on how to do this yet.

Requirements

1. Save user data to session, and access with a consistent API
2. Provide seamless login, logout, and registration flows with appropriate credentials
3. Support locally stored passwords out-of-the box
4. Straightforward modifications to support alternate authorization methods:
   • Passwords entered into the site but verified elsewhere (such as an LDAP backend)
   • Third-party authentication/single sign-on (CAS, OpenID, etc.)

Screen Authentication

Concerto supports three levels of screen authentication.

1. No authentication – any one could access the screen through a browser. For this to work, the Screen must be marked as public, and the global “Public Concerto” configuration (from the Permissions tab of Concerto Settings page) must be checked. Ideally, we would like to move away from this going forward.
2. Authorized Screens – These screens are configured with a secret token that allows them to “log in” to the server to access data securely. These
3. Legacy Screens – This option is available only for screens imported from a Concerto v1 install. Screens are identified by including a MAC address or other identifier in the frontend URL.

Authorized Screens

The workflow for authorizing a screen is very straightforward.

1. When a new screen is setup, it is started with a full-screen browser pointed at `http://concerto.example.com/frontend`. This page will display a 6-character authentication code, for example “abc123”.
2. To register the screen, the administrator logs in to the Concerto panel from their own PC, laptop, or mobile device. They click “Create Screen” from the screens page, or edit an existing screen. After filling out other relevent details, they choose the “Authenticated Screen” security option, and type the code from the screen (“abc123”).
3. The screen recognizes that it has been remotely authorized, and loads up the full frontend: template, content

Behind the scenes, this process allowed the server to issue a secret token to the screen. That token is stored in a cookie that never expires, meaning that unless cookies are deleted on that PC, it will remember its identity even after being restarted.

For screens that have different authentication needs, there is also a special Screen API for authorization. This is how Bandshell Clients (the full concerto computer image) will connect. In lieu of a really detailed explanation, the following series of requests used to authorize a screen should explain the process. No cookies are used.

$ curl http://localhost:3000/frontend.json -w "\n"
{"screen_temp_token":"6cc161"}

$ curl http://localhost:3000/frontend.json?screen_temp_token=6cc161 -w "\n"
{"screen_temp_token":"6cc161"}

$ # Notice that the token has not been authenticated yet.
$ # The screen will poll until it is.

$ curl http://localhost:3000/frontend.json?screen_temp_token=6cc161 -w "\n"
{"screen_temp_token":"6cc161"}

$ # Now, the administrator enters the token into their browser.
$ # On the next poll, the screen sees the permanent token:

$ curl http://localhost:3000/frontend.json?screen_temp_token=6cc161 -w "\n"
{"screen_auth_token":"c11de0b4dca565b2f77dec46e2f3bc1e"}

$ # Now HTTP Basic auth comes in to play, and the screen can use it to
$ # get information about itself before moving on to the frontend.
$ curl -u screen:c11de0b4dca565b2f77dec46e2f3bc1e http://localhost:3000/frontend.json -w "\n"
{"screen_id":1,"screen_url":"http://localhost:3000/screens/1","frontend_url":"http://localhost:3000/frontend/1"}

$ # The same authorization parameters will work on other screen API pages,
$ # such as the concerto-hardware views.

API Authentication

Concerto does not have an API yet! But when we do, this is what we’re thinking:

In general, credentials should be provided with each request, rather than relying on the client to store cookies for session-based authentication.

Common practices for API authentication seem to either use a long secret key to identify the requestor, or HTTP basic. Either of these methods could be enhanced with SSL. Our requirements will develop as we gain a better understanding of what an API to Concerto 2 will provide.