Documents, ACLs, and Permissions
Sheetster contains a sophisticated and granular security subsystem which manages users, groups, and ACLs to any server resource.

The available ACL permissions for a resource are:

NO_ACCESS_LEVEL = -1
APPEND_LEVEL = 0
READ_LEVEL = 1
UPDATE_LEVEL = 2
CREATE_LEVEL = 3
DELETE_LEVEL = 4
OWNER_LEVEL = 5

Each level encompasses the permissions of the former level, so that a Group assigned the CREATE permission to a resource will also have the ability to UPDATE (edit) and READ the resource, but will be unable to delete it.

The exception to this rule is the special "APPEND" permission. Groups assigned the APPEND permission for a resource are able to view generated Sheetster Forms and insert posted Sheetster Form data.... but have no other access to the resource.

For example, a user can be granted or denied access to any article by id, RESTful web service, web page, or even individual spreadsheet cells (Enterprise Edition Only).

The security is completely group-based, thus to assign or remove access to a resource, a user simply needs to be added to or removed from a group that has the appropriate ACL.

Management of Document sharing and permissions is handled through the Web App UI, and controlled by document owners.

In addition to the assigned Group-based permissions for a resource, the articles and spreadsheets also have 3 sharing "states":

Private - can only be accessed by the article owner
Shared - can only be accessed by the article owner and groups that have been explicitly assigned permissions
Public - accessible by any signed on user

Anonymous User Access

Often you will want to provide access to Sheetster documents, forms, gadgets, and files to the public without the need for a login or other authentication.

For example, you may wish to place a Chart gadget on a blog, or a product feature matrix spreadsheet on a product detail page.

In both of these cases, you would not want to require a viewer to signup and log into your Sheetster Server.

To allow access to these resources, at the same time providing security and granular control over private data, Sheetster has implemented an "Anonymous" or "nobody" user, and an "Everyone" or "public" group.

The "nobody" user, and any other user assigned to the "Everyone" group, automatically have read-only access to the following:

read-only access to documents assigned the "public" sharing permission
read-only access to Sheetster Forms with append-only access to Sheetster Forms data.

NOTE: If for any reason you wish to disable ALL anonymous un-authenticated access to your server, simply change the name/and or password for the "nobody" user in the e360 Web App database.

Anonymous access is a special user belonging to the Everyone Group that has READ permission to all Public resources. Since Anonymous is the only user that does not need to explicitly login to the system, this psuedo-user allows application users readonly access to public resources on the server such as public information for a corporate website.

The combination of Public sharing status of an article, and READ access given to the Everyone group which contains the Anonymous user allows for public access to content without authentication.

Direct Access to Security Data

Admins and programmers have fine-grained control over this functionality using the com.extentech.security.* package of Java classes, as well as the following database tables in the Web App database:

GROUPS
CONTACTS
ACLS

Other Security Considerations

Server Security

Sheetster is a JEE application/web server and thus subject to the same considerations and security measures as any other web server.

It is important that no sensitive documents are uploaded or put into accessible virtual directories without proper understanding of the security mechanisms available.

As a web server, it is vital to protect the installation and configuration data directories ("/resources/*, WEB-INF/*") at the OS level using appropriate directory permissions and users.

Since configuration data and administrator user information is accessed over unencrypted JDBC, tunneling or Intranet architecture may be preferable in a security sensitive deployment.

Furthermore, the Sheetster web application data is stored in a JDBC database, such as MySQL or HypersonicSQL (default) -- thus proper handling of database connection credentials is vital to protecting the underlying document content.

Console Security

The Sheetster Administration Console is password protected, and connects to the configuration database over unencrypted JDBC.

To use encryption to connect to the JDBC server, you will need to create a certificate for the server.

The process of creating a self-signed cert.

Since configuration data and administrator user information is accessed over unencrypted JDBC, tunneling or Intranet architecture may be preferable in a security sensitive deployment.

SSL/HTTPS

A recommended configuration is to run multiple Sheetster instances behind a Load Balanced Apache Proxy.

How to setup Sheetster load balancing using an Apache proxy

The Apache proxy can also be configured with SSL to allow for secure HTTPS connections.

With SSL enabled on the front-facing Apache server, multiple Sheetster instances can be run securely behind the firewall, without the need for passing passwords, user data, or configuration data over the wire in cleartext.

Encryption, Authentication & Accessing Spreadsheet Web Services

Currently, Sheetster supports the following authentication mechanisms:

Cleartext (basic auth) login over HTTPS
Encrypted session-based user tokens

NOTE: The following information is under review and subject to change.

Basic-Auth Login over HTTPS

NOTE: The server will authorize basic-auth requests whether the connection is encrypted or not. It is incumbent upon administrators to secure the connection before sending cleartext login information over the network.

Encrypted Session Auth Tokens

Sheetster can also use authentication tokens to allow for secure logins between service calls.

To get an auth token programmatically in Java, use the following code:

String UPX = com.extentech.security.UserFactory.cryptUserPass("username|password","password");
To login and get an auth token for your session, use the following REST call:

/workbook/id/-2/xml/system/login/0?username=&password=
This REST call returns an encrypted auth token which can be used for subsequent authentication without the need for username and password parameters:

/workbook/id/-2/json/system/listdocuments/0?sessionAuthTicket=3D3D34A323422A2B234234