The SP includes a plugin for storing persistent information, including user sessions, in a database using an ODBC driver.
Before trying to use this extension, strongly consider whether it's really necessary. Most applications worth clustering are not going to be able to rely on the SP's built-in session functionality. It's there primarily for simple web sites and smaller applications.
Even if you do need clustered sessions, a better option may be to run a single
shibd instance and share it using a private network between the machines. It's a single point of failure, but so is a database in most cases.
Included below are the basic steps for getting a database session storage system setup. (If you have experience with a specific database, please provide any information down below.) The thing to remember is that the plugin is written to work with a fully ACID database that is providing 100% serializable transactions. This means taking locks on reads to prevent another transaction from updating the record until the plugin is done with it. To my knowledge, only a few databases do that (and Oracle isn't one of them). The result will be a lot of trial and error to adjust other settings to compensate, so expect problems.
The odbc-store.so extension requires a database to store the shared sessions. The odbc-store.so extension does not automatically create any tables for itself. The rough SQL DDL for the database is the following:
You may need to adjust data types when moving between database systems, but this has to be done carefully to maintain compatibility. The SQL itself is not yet pulled out of the plugin code, so you can't change it without changing the code.
Once the tables exist, you need to prepopulate the
version table with the right information, which at the moment should be 1 and 0:
ODBC Connection Strings
The primary piece of information the SP configuration will need is the connection string to use. The string has to be self-contained, and needs to identify the database server, the database or tablespace, and the username and password to connect with. All of this is driver specific, and may involve setting up other files on the machine to create an alias for the database server. See below for specific database tips.
The default configuration file comes with some comments to help set this up. You'll need to uncomment the
<Extensions> element containing the
odbc-store.so extension. Then you'll need to comment out the four elements grouped together that manage in-memory storage and uncomment the four below them that are labeled with the ODBC comment.
Finally, apart from adjusting any of the timeout controls, you'll have to put the right connection string into the
Microsoft SQL Server
This is the primary test platform, and has been tested under only light load on both Windows and CentOS 5 (x86_64). On Linux, the FreeTDS client and ODBC driver from the OS were used.
The simplest way to set this up is to use the SQL Server or FreeTDS client and define a server alias so you can give the server a logical name. A typical connection string would then be:
Creating the database with the default DDL worked fine.
A bug report indicates that shibd is unstable on Red Hat 6 using the MySQL driver. The stack traces suggest crashes in the driver layer, and since the same SP code is stable on Red Hat 5, that points to a regression in the Red Hat supplied code.
Tested under light load on CentOS 5 (x86_64) using TCP to connect to a database on the same box. The latest ODBC driver from MySQL was used (although the installation of the RPM wasn't perfect).
The connection string may look like as simple as this:
The cryptic OPTION argument above tells ODBC to look for MySql configuration files for connection data. Hence you should create a MySql config file (ie.
/etc/mysql/conf.d/odbc.cnf) accordingly, and make it readable by the user running shibd (eg.
Alternatively, you can also specify the DSN in the main config file, though it's insecure:
Creating the database with the default DDL worked fine. I used the InnoDB MySQL table type, which is somewhat (but not fully) transactional.
In general, MySQL presents a lot of problems because it doesn't take transactions seriously. It claims to support ACID behavior, but it mixes code for data storage with higher level code that doesn't honor those requirements, and tells you bluntly that many errors will result in only partial transaction rollback. It also has storage engines that operate like Oracle does, by not taking locks when told to. As such, I don't know how the plugin will behave under exceptional conditions.
- In PostgreSQL the datetime data type is called timestamp which requires a small change to the reference SQL from above:
- GOTCHA: be sure that your pg_hba.conf file is setup to allow IPv4 MD5 authentication from the network location of your Shibboleth-SP host:
- On RHEL/CentOS Linux, the odbc-store.so extension (/usr/lib64/shibboleth/odbc-store.so) uses /usr/lib64/libpq.so.
- You will need to install the postgresql-libs package which provides /usr/lib64/libpq.so.5 and create a symlink (symbolic link) from the installed libpq to the location where odbc-store.so expects it:
- Configure the connection string in the shibboleth2.xml file:
- After adding the "db" storage service, configure the session initiator and logout initiator to use ss:db (db storage service) for the relay state.