Frequently asked questions

Here is a collection of frequently asked questions about Tidbits:

Security and privacy considerations

Tidbits has been designed to hold personal and private information, so security is important when considering how to deploy Tidbits. Generally, Tidbits relies on procedures outside of the application itself to secure the data, such as encrypting the information that is stored.

There are several places where Tidbits stores potentially sensitive information:

All the data entered into Tidbits is stored in a database. Where the database physically stores the data depends on the database.
Search index
Tidbits maintains a search index in a directory you specify. This index contains essentially a searchable copy of all the data in the database.
Authentication context
Authentication is configured in an XML file deployed as part of the Tidbits application. This file is located at WEB-INF/classes/security-context.xml. Depending on how authentication is configured, this file may contain usernames and passwords for Tidbits users or to connect to some external authentication service, such as an LDAP server.
Database username and password
Technically Tidbits does not know the database username and password used to connect to the database, but the servlet container you deploy Tidbits into must be configured with this connection information.

Data encryption

Tidbits does not encrypt data directly, but it can be configured so that all data is stored in encrypted forms.

Does Tidbits encrypt the data in its database?
No. Tidbits does not provide any encryption capabilities for storing the data. Instead it relies on the security if the database you deploy Tidbits into. Some database systems support encryption, however. For example Apache Derby can be easily configured to encrypt the entire Tidbits database. PostgreSQL can encrypt table columns. Oracle provides many ways to encrypt the database, too. Some operating systems can make use of encrypted disk partitions such as LUKS, or encrypted file systems such as PEFS. See Wikipedia for more options. In short, there are many ways to encrypt the data stored in the Tidbits database, but all of those are outside the scope of what Tidbits itself does.
Does Tidbits encrypt the data stored in the search index?
No. You must ensure you set the appropriate directory permissions for the directory you configure Tidbits to use for its search index. You could store the index on an encrypted file system if you want the index data encrypted (the author has used PEFS — see Wikipedia for more examples).
Does Tidbits encrypt the data while communicating with the database?
No. However, Tidbits uses JDBC to communicate with the database, and many database systems support SSL-encrypted JDBC connections. Consult the documentation for the JDBC driver of your database if you want to encrypt the JDBC communication. Often this might not be an important issue, if the Tidbits application and database run on the same machine, or an embedded database like Derby is used. The JDBC configuration is managed by the servlet container Tidbits runs in, so consult that documentation for help in configuring the JDBC settings.
Does Tidbits encrypt the data while communicating with your web browser?
No. If you want to make your Tidbits application publicly accessible, then you should only allow SSL-encrypted (HTTPS) connections to your Tidbits deployment. This can be accomplished by either running Tidbits behind a web server that is configured with SSL support or by configuring the servlet container (Tomcat, JBoss, etc.) to listen for SSL connections.


Tidbits is quite flexible with respect to how users are authenticated and granted access to the application. Keep in mind that Tidbits is designed so that all users who are granted access are then authorized to view all information stored in Tidbits. That is, the information a user can see is not limited to just the information they created — all users can see all information in Tidbits.

Tidbits relies on the Spring Security framework to handle authentication and authorization. This means you have a great deal of flexibility in how you grant users access to Tidbits. The following sections detail various ways of configuring authentication, which refer to the Tidbits security configuration file WEB-INF/classes/security-context.xml.

No matter what authentication approach is taken, Tidbits only requires that users are granted a ROLE_USER authority to access the application.

Simple user configuration

In this form, usernames and their associated passwords and granted authorities are stored in clear text directly in the security-context.xml file. This approach is only recommended for testing purposes.

<authentication-manager alias="authenticationManager">
    <authentication-provider user-service-ref="detailsService">

<user-service id="detailsService">
    <!-- A login ==  test, password == test -->
    <user name="test" authorities="ROLE_USER" password="test"/>

Simple secure user configuration

In this form, usernames and their associated passwords and granted authorities are stored directly in the security-context.xml file, but the passwords are stored as secure SHA-256 cryptographic hashes. In this way the passwords are secure, but the usernames are still stored in plain text. This method is always preferred over the non-hashed configuration described in the previous section.

<authentication-manager alias="authenticationManager">
    <authentication-provider user-service-ref="detailsService">
        <password-encoder hash="sha-256"/>

<user-service id="detailsService">
    <!-- Login = test, password == test -->
    <user name="test" authorities="ROLE_USER"

There are many ways to generate SHA-256 hashes from password strings, including online web pages that can generate the hash text for you.

LDAP configuration

In this form, a directory service is used to authenticate and authorize users, using the LDAP protocol. Tidbits will authenticate the username and passwords supplied by users with the directory server, and the directory server is expected to then return the granted authorities for that user.

There are two configuration elements to use for LDAP-based authentication: ldap-server and ldap-authentication-provider. The first defines the connection parameters necessary to communicate with the directory server, the second defines how to authenticate users. There are several ways to configure these elements, but here is one approach:

<ldap-server url="ldap://localhost/dc=example,dc=com" 
<authentication-manager alias="authenticationManager">

In this configuration, Tidbits uses the cn=Authenticator,dc=example,dc=com DN to connect to the directory server. That user must have permission to search for users and compare password values, which is configured in the ldap-authentication-provider element. Here users are searched by looking for matching uid attributes within the ou=People,dc=example,dc=com tree. If found, and the supplied password matches, and the user is a member of the cn=Tidbits,ou=Groups,dc=example,dc=com then the user is granted the authorization defined by the businessCategory attribute of that group, which must be USER in order to access Tidbits.

Simply put, this configuration lets any user that is a member of the cn=Tidbits group to access Tidbits.

Here is an example LDIF formatted data for the relevant objects used in this example configuration:

version: 1

dn: cn=Authenticator,dc=example,dc=com
objectClass: person
objectClass: top
cn: Authenticator
sn: Authenticator
userPassword:: e1NIQXLDKuyLdplkdeno83hjd09dsJSu7jPOJSPAOJF8

dn: cn=Test User,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
cn: Test User
sn: User
uid: test
givenName: Test
userPassword:: e1NIQX1rbm5FUEJnRJVa3zRiMFFucXJlK1AwMXRDeVk9

dn: cn=Tidbits,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: Tidbits
uniqueMember: cn=Test User,ou=People,dc=example,dc=com
businessCategory: User Logo