Yubikey One-Time Password Authentication
Now that we have a solid understanding of the underlying technology, let's add Yubikey authentication to an existing application. I use Typo to blog. Typo is developed using Ruby on Rails, and you can check out its latest codebase via the project's public Subversion repository. Whether or not you like the structure RoR imposes on the developer, it works to our advantage in this case, because it makes it easy to locate the files we need to modify. Take a look at Figure 5 for a basic outline of the validation routine we will be implementing.
To start, let's drop the Ruby Web services client library, yubico.rb, into the project's lib directory. After adding the corresponding require command to the config/environments.rb file, we can be assured that the library will be available throughout the application.
Two groups of settings are necessary to configure Yubikey authentication. First, there are the site-wide settings, namely the API key and corresponding ID necessary to submit authentication requests to the Web service. There also is a switch for enabling or disabling Yubikey authentication on a blog-wide level. Typo stores these blog-specific settings by serializing them and persisting them to the blogs.settings column. Lucky for us, that means we don't have to make any changes to the database. However, we do need to amend the UI and data model used to store these settings within the application. Listing 1 shows how to add these three Yubikey configuration options to the respective HTML template in the admin user interface. Similarly, Listing 2 shows how to add those same settings to the model. That's all it takes for Rails to render a form to input those settings and store them in the database for each blog. Figure 6 shows the final result.
Listing 1. Typo: Blog-Wide Yubikey Settings HTML
filename: app/views/admin/settings/index.html.erb ... <!-- Yubikey authentication - start --> <fieldset id="authentication" class="set" style="margin-top:10px;"> <legend><%= _("Authentication")%></legend> <ul> <li> <label class="float"><%= _("Require Yubikey OTP")%>:</label> <input name="setting[yubikey_required]" id="yubikey_required" type="checkbox" value="1" <%= 'checked="checked"' if this_blog.yubikey_required%> /> <input name="setting[yubikey_required]" type="hidden" value="0" /> </li> <li> <label for="yubikey_api_id" class="float"><%= _("Yubico API ID")%>:</label> <input name="setting[yubikey_api_id]" id="yubikey_api_id" type="text" value="<%=h this_blog.yubikey_api_id %>" size="6" /> </li> <li> <label for="yubikey_api_key" class="float"><%= _("Yubico API Key")%>:</label> <input name="setting[yubikey_api_key]" id="yubikey_api_key" type="text" value="<%=h this_blog.yubikey_api_key %>" size="50" /> </li> </ul> </fieldset> <!-- Yubikey authentication - end --> ...
Listing 2. Typo: Adding Blog-Wide Yubikey Settings to Model
filename: app/model/blog.rb ... # Authentication setting :yubikey_required, :boolean, false setting :yubikey_api_id, :string, '' setting :yubikey_api_key, :string, '' ...
Second, there are two user-specific settings: Yubikey ID and Yubikey Required. The former is necessary to associate a Typo account with a user's unique public Yubikey ID; whereas the latter allows users to enable Yubikey authentication selectively for their accounts only. Now, let's make both options available from the user's preference settings within the application's admin interface. To make the new options appear in the UI, I added a new section to the partial HTML template that renders the form for editing user options (Listing 3). Thanks to RoR's ActiveRecord support, we don't need to write any code to save these new options to the database; however, we do need to make sure that we add the correspondingly named fields to the user table to which all values on this screen are being persisted. In Rails, this is done by adding a database migration, which is nothing more than an abstract way of describing an incremental modification to the database. In our case, we are adding the fields yubikey_id and yubikey_required to the user table by creating the migration shown in Listing 4. Now, all you need to do is run the rake utility from the command line and tell it to upgrade the database: rake db:migrate. The nice thing about Rails' migrations is that they are database-provider independent. The migration we created in Listing 4 can be used with any of the underlying databases that Typo supports. At the time of this writing, this includes MySQL, PostgreSQL and SQLite. Finally, you can admire the new settings in the account-specific options in Figure 7.
- Not So Dynamic Updates
- New Products
- Users, Permissions and Multitenant Sites
- Security in Three Ds: Detect, Decide and Deny
- Flexible Access Control with Squid Proxy
- Non-Linux FOSS: MenuMeters
- Tighten Up SSH
- DevOps: Everything You Need to Know
- Solving ODEs on Linux
- diff -u: What's New in Kernel Development