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:
- Database
- 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.
Authentication
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">
</authentication-provider>
</authentication-manager>
<user-service id="detailsService">
<!-- A login == test, password == test -->
<user name="test" authorities="ROLE_USER" password="test"/>
</user-service>
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"/>
</authentication-provider>
</authentication-manager>
<user-service id="detailsService">
<!-- Login = test, password == test -->
<user name="test" authorities="ROLE_USER"
password="9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"/>
</user-service>
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 url="ldap://localhost/dc=example,dc=com"
manager-dn="cn=Authenticator,dc=example,dc=com"
manager-password="450934jerpiojr0937o"/>
<authentication-manager alias="authenticationManager">
<ldap-authentication-provider
group-search-filter="(&(uniqueMember={0})(cn=Tidbits,ou=Groups,dc=example,dc=com))"
group-search-base="ou=Groups"
user-search-base="ou=People"
user-search-filter="uid={0}"
group-role-attribute="businessCategory"
/>
</authentication-manager>
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