keycard 0.2.4 → 0.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 289f06e8e7d3002eba8c6aa13bedf6be9fd2cd643f2923ce8cb5185aeaec6fda
-  data.tar.gz: 885e1c86b158ff4778764ea0d2a5ee6bd18ff133e811af47032b42b7a56f0e24
+  metadata.gz: 3a653bd311fdb43e3c4f202e8761582c459ffa1c4e85a1e7309e337e8dd6e1f0
+  data.tar.gz: 846d43693d28a97cdd4a9fca88e0ee51c6a6289ac389122e078ccc9a8193a40f
 SHA512:
-  metadata.gz: 1c510e8be9b90985c08d54c07489368b14911c28d595abe51748acea4ec9f2b5914a06c3425d97afc7e9eeae18c8a7a02b1ca8a3850bc0795f88fb897918b384
-  data.tar.gz: d60d7e51da879687dd570c26382947a619f9978309de7cb797bde095e11043e71c28783e85847f22c12beff652b685db8b0dcdeb55b715197ea502fb0f6c7d4f
+  metadata.gz: 6b9185d2dc8a350988c52bfd56c3417840969d89167ee7824132ddc505630b99a4bbc757edd1ea8b644e67da856a3ca78fe88a927334d0ecd7cc16c606de423a
+  data.tar.gz: 343cab74ac29ded2ff832c19c141fd0d14dc6fdb7d0da3fb0ba7e32006ba29a0550445a1d42c204d15e569c2797c142a02769e8360cfa9ac8e72c375b2a0f9ad

data/.gitignore

@@ -3,6 +3,8 @@
 /_yardoc/
 /coverage/
 /doc/
+/docs/_build/
+/docs/_yard/
 /pkg/
 /spec/reports/
 /tmp/

data/README.md

@@ -1,5 +1,6 @@
 [![Build Status](https://travis-ci.org/mlibrary/keycard.svg?branch=master)](https://travis-ci.org/mlibrary/keycard?branch=master)
 [![Coverage Status](https://coveralls.io/repos/github/mlibrary/keycard/badge.svg?branch=master)](https://coveralls.io/github/mlibrary/keycard?branch=master)
+[![Documentation Status](https://readthedocs.org/projects/keycard/badge/?version=latest)](https://keycard.readthedocs.io/en/latest/?badge=latest)
 
 # Keycard
 

data/bin/rake

@@ -0,0 +1,29 @@
+#!/usr/bin/env ruby
+# frozen_string_literal: true
+
+#
+# This file was generated by Bundler.
+#
+# The application 'rake' is installed as part of a gem, and
+# this file is here to facilitate running it.
+#
+
+require "pathname"
+ENV["BUNDLE_GEMFILE"] ||= File.expand_path("../../Gemfile",
+  Pathname.new(__FILE__).realpath)
+
+bundle_binstub = File.expand_path("../bundle", __FILE__)
+
+if File.file?(bundle_binstub)
+  if File.read(bundle_binstub, 300) =~ /This file was generated by Bundler/
+    load(bundle_binstub)
+  else
+    abort("Your `bin/bundle` was not generated by Bundler, so this binstub cannot run.
+Replace `bin/bundle` by running `bundle binstubs bundler --force`, then run this command again.")
+  end
+end
+
+require "rubygems"
+require "bundler/setup"
+
+load Gem.bin_path("rake", "rake")

data/docs/Makefile

@@ -0,0 +1,24 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+SPHINXPROJ    = Keycard
+AUTOBUILD     = sphinx-autobuild
+SOURCEDIR     = .
+BUILDDIR      = _build
+
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+auto:
+	@$(AUTOBUILD) ${@:2} "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+.PHONY: auto help Makefile
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

data/docs/authentication.rst

@@ -0,0 +1,210 @@
+Identity and Authentication
+===========================
+
+Users can be identified in any number of ways and carry with them
+attributes that determine the entirety of "who they are". Typical needs
+include identifying a person by username or email address, and building a
+profile of attributes such as geographical region (as determined by IP address),
+or University status (student, staff, etc.). The identifiers and attributes are
+intrinsic to the user and do not, by themselves, grant any permissions within
+an application. Likewise, these attributes cannot be granted within an
+application, but only inspected.
+
+This document gives an overview of authentication terminology and scenarios
+from an application perspective. Not all of these concepts are strictly in the
+domain of Keycard (for example, we mention some typical authorization rules as
+they relate to different user types). This background is presented here to
+establish the environment within which Keycard operates and functionality it
+seeks to support. How to use Keycard in an application is documented elsewhere
+(TODO: complete examples and link API).
+
+Authentication Glossary
+-----------------------
+
+There are many overlapping concepts and terms regarding identity, privacy,
+security, and technology. These definitions give building blocks for the
+discrete combination scenarios that require (or support) different business
+rules.
+
+As far as classifying users, there are three dimensions to consider. A user may
+have only one status in a given dimension:
+
+* **Identification** -- Anonymous, Unnamed, Named
+* **Affiliation** -- Unaffiliated, Affiliated
+* **Account Status** -- Nonmember, Member
+
+* **Anonymous** -- individually indistinguishable from other people except
+  circumstantially (e.g., visiting from the same IP address)
+* **Identified** -- a person whose identity has been verified; importantly, the
+  identity may not be known to all parties
+* **Unnamed** -- identified, but only opaquely; that is, the person (principal)
+  is not revealed to the application, though the specific affiliation is,
+  usually an organizational role or roles
+* **Named** -- personally identified; that is, a resolvable identifier for the
+  person (principal) is revealed, possibly along with name information
+* **Session** -- a period of usage that is considered to be conducted by the
+  same person
+* **Principal** -- a person with an organizational account (but not necessarily
+  an application account)
+* **Partner** -- an organization with some agreement with the application
+  providers, in order to authenticate its users and offer access on its behalf
+* **Affiliate** -- a person with at least one affiliation relationship with a
+  partner; asserted by the organization (e.g., a university asserts that a
+  person is a faculty member)
+* **Visitor** -- a person with no identification or affiliation whatsoever;
+  effectively unrecognized by any means
+* **Guest** -- a person with some identification or affiliation; recognized, but
+  transient, that is, not holding an account of any sort
+* **Member** -- a person with identification; recognized, holding an account;
+  Visitors and Guests are considered non-members
+
+Not all combinations are sensible for determining business rules. For example,
+membership requires some form of identification, so there can be no anonymous
+members.
+
+To aid consideration of the rules for an application, this table names all of
+the unique combinations, which are further defined below. It does not imply
+that all applications should have seven user types, but that each combination
+has unique characteristics that may need to be handled differently. A given
+application may exclude certain types or treat different types the same in many
+ways. For example, an application may completely disregard identification for
+Guests, treating them all the same.
+
+.. csv-table::
+   :header: "", "Unaffiliated Nonmember", "Unaffiliated Member", "Affiliated Nonmember", "Affiliated Member"
+   :stub-columns: 1
+
+   "Anonymous", "Visitor (Public)", "--", "Unknown Guest", "--"
+   "Unnamed", "--", "--", "Unnamed Guest", "Private Member"
+   "Named", "--", "Local Account", "Named Guest", "Member"
+
+
+
+Authentication Scenarios / User Types
+-------------------------------------
+
+Visitor
+~~~~~~~
+
+A person with no recognized identification or affiliation whatsoever. The user
+is effectively unauthenticated by any means.
+
+Anyone who can connect to the application (at the very least by obscuring their
+identity and any affiliation) may act as a visitor, so there should be no
+restrictions that apply to other users that do not apply to visitors. Entry or
+modification of data should be permitted only under scrutiny, where vandalism
+is of no concern and appropriate auditing and moderation are in place.
+
+A visitor may have a session to enhance user experience, but all session data
+should be transient and discarded after an appropriate inactivity period, if
+stored server-side.
+
+Visitor (Public)
+................
+All Visitors are anonymous and should be treated as "any public user". This
+typically means that they have access to a limited set of resources and cannot
+receive any personalization features.
+
+Guest
+~~~~~
+
+A person with some recognized identification or affiliation. The user is
+authenticated, but transient – that is, not holding an account of any sort.
+This type of user is typically permitted access to restricted materials based
+on agreements between organizations.
+
+There may be useful distinctions applied or features available for different
+types of Guest. For example, the text may be personalized for a Named Guest, or
+additional features may be provided to Unnamed Guests with the "faculty"
+designation.
+
+Unknown Guest
+.............
+A user connecting from a recognized affiliate network, but with no
+identification. All that can be asserted is that the user has a generic
+affiliation implying that the person can access organizational computing
+resources. This may be by way of public computers, campus networking,
+or VPN access, as examples.
+
+Unnamed Guest
+.............
+A person with specified affiliation and a persistent identifier. The identifier
+is opaque, but stable; that is, the same identifier presented over time implies
+that the user is the same person. It is expressly not human-friendly and should
+not be displayed.
+
+Keycard calls this persistent ID the user_pid. Generally, the affiliate will
+not present different identifiers for the same person, but that is outside of
+the control and knowledge of the application. It should be assumed that
+different IDs represent different people.
+
+The affiliation may be multi-valued and is *scoped*, meaning that it applies
+within a security domain. Common semantics assert that a person has roles like
+member and staff, or member and student, scoped to the entire affiliate
+organization. An example of one scoped affiliation would be
+``faculty@umich.edu``.
+
+Named Guest
+...........
+A person with specified affiliation and both persistent and enterprise
+identifiers. The persistent identifier is as for Unnamed Guests. The enterprise
+identifier is name-based, meaning that it based on some account name for the
+person used within the affiliate organization. It is expressly personally
+identifiable, and often human-friendly, meaning that other people may recognize
+it and it would be suitable for display.
+
+Keycard calls the enterprise ID the ``user_eid``. It is single-valued and
+often, but not always, matches an email address for the person. Generally, this
+ID is stable between sessions, but there is no guarantee that it will not be
+reassigned at some point.
+
+Member
+~~~~~~
+
+A person with recognized identification and an account for application features
+such as content ownership. The user is authenticated and persistent.
+
+The reasons to maintain Members may vary between application. For example,
+those with a narrower audience may prefer the semantics that anyone
+individually authenticated becomes a Member automatically to simplify data
+modeling and reporting. Those with very broad audiences may choose to have many
+Guests and only a few Members to reduce the number of dormant or single-use
+accounts.
+
+Local Account
+.............
+A user (person or machine user) that is only known the application, not an
+identity authority. The application must manage any authentication directly.
+This may not even be an interactive account, but used as a means to record
+ownership or action by the system consistently alongside human users, for
+example.
+
+Some applications may have a dedicated super user with a special login
+procedure, where others may manage those tasks by designating human Members as
+administrative users.
+
+Private Member
+..............
+A person with specified affiliation and a privacy-preserving, persistent
+identifier. This Member is very similar to an Unnamed Guest, but has been given
+an account for some application purpose. Some applications may choose to have
+only Unnamed Guests or Private Members, not both types.
+
+The authentication information does not include anything personally
+identifiable, so the application must decide whether to ask the user to supply
+items like a display name or email address, or to deal with the lack of
+human-friendly information in another way. For example, an application that
+only maintains a set of favorite items for the user may find no need to provide
+meaningful display to that member others as to whose favorites they are. By
+contrast, an application that tracks and attributes comments to a Member would
+generally need some label for the commenter.
+
+Member
+......
+A person with specified affiliation and both persistent and enterprise
+identifiers. This Member is similar to a Named Guest, but has been given an
+account for some application purpose. This Member fits the classical definition
+of "named user"; that is, account and display information is maintained, likely
+in order to grant individual permissions and display name information to other
+users.
+

data/docs/conf.py

@@ -0,0 +1,46 @@
+# -*- coding: utf-8 -*-
+
+import guzzle_sphinx_theme
+from recommonmark.parser import CommonMarkParser
+
+# -- General configuration ------------------------------------------------
+project = u'Keycard'
+copyright = u'2018, Regents of the University of Michigan'
+author = u'Noah Botimer'
+version = u'0.2.4'
+release = u'0.2.4'
+
+
+extensions = ['guzzle_sphinx_theme']
+templates_path = ['_templates']
+master_doc = 'index'
+
+source_parsers = {
+    '.md': CommonMarkParser,
+}
+source_suffix = ['.rst', '.md']
+
+language = None
+exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
+pygments_style = 'sphinx'
+todo_include_todos = False
+
+
+# -- Options for HTML output ----------------------------------------------
+html_theme_path = guzzle_sphinx_theme.html_theme_path()
+html_theme = 'guzzle_sphinx_theme'
+html_static_path = ['_static']
+
+# Guzzle theme options (see theme.conf for more information)
+html_theme_options = {
+    "project_nav_name": "Keycard",
+}
+
+html_sidebars = {
+    '**': [
+        'logo-text.html',
+        'globaltoc.html',
+        'searchbox.html',
+    ]
+}
+

data/docs/index.rst

@@ -0,0 +1,37 @@
+.. title:: Keycard, authentication for Ruby applications
+
+Keycard Documentation
+=====================
+
+Keycard is both a Ruby library and an abstract model for authentication and
+directory information for users of an application.
+
+Keycard is primarily concerned with establishing identity and supplemental
+attributes of users. It provides a data model for user information and
+conveniences for building applications that will be deployed with reverse
+proxies and single sign-on systems. It is well-suited to enterprise deployments
+where there are external login and directory systems.
+
+Authorization needs are not covered by Keycard at all. See Checkpoint_ for a
+library that can store grants based on the Keycard attributes and enforce
+policies against them.
+
+Table of Contents
+-----------------
+
+.. toctree::
+    :maxdepth: 2
+
+    authentication.rst
+    runtime_context.rst
+
+.. _Checkpoint: https://github.com/mlibrary/checkpoint
+
+
+Naming
+------
+Keycard takes its name from physical keycards, where a person presents a card
+to a reader. The card may hold any number of attributes, including personal
+identification, staff classification, or clearance levels. The reader (or
+attached system) is left to make any authorization decisions or present the
+information to a person to do so.

data/docs/requirements.txt

@@ -0,0 +1,4 @@
+sphinx>=1.6.5,<1.7.0
+sphinx-autobuild>=0.7.1,<0.8.0
+guzzle_sphinx_theme>=0.7.11,<0.8.0
+recommonmark>=0.4.0,<0.5.0

data/docs/runtime_context.rst

@@ -0,0 +1,42 @@
+Runtime Context
+===============
+
+An application can be run in different environments and configurations for
+different purposes like development, testing, staging, or public use. There are
+many overlapping terms in use, so, for our purposes here, we use the term
+*Runtime Context* to give labels to the scenarios where the infrastructure is
+different, and in what ways.
+
+Development Context
+-------------------
+
+This means that the application is running with direct access by the client,
+generally from a workstation. There is no front-end server, so all
+authentication must be managed by the application. The Rails environment is
+generally set to ``development``.
+
+A proxy managing single sign-on may be emulated either at the Rack or
+application level if needed. Generally, there is some bit of UI or cookie/param
+handling exposed only in development mode to influence how the requests appear
+to the application, or there is a login form for local accounts.
+
+Deployment Context
+------------------
+
+This means that the application is deployed to dedicated infrastructure. There
+is a front-end server (proxy) that may or may not manage single sign-on. The
+Rails environment is generally set to ``production``.
+
+A typical configuration is to have an Apache web server proxying all traffic,
+with either a module for Cosign, CAS, or Shibboleth configured. There is often
+a fixed path (e.g., ``/login``) that is intercepted to require SSO
+authentication. If the user is authenticated, the request is forwarded on with
+headers in place. If the user cannot authenticate, the app never receives  the
+login path request. For Shibboleth scenarios, there is a Service Provider that
+is set up for the endpoint (application URL).
+
+With Shibboleth, it is also possible to have the headers present on each
+request when there is an active session with the Service Provider. Some special
+care must be taken here that sessions are initiated and terminated properly and
+when desired (usually on login and logout requests).
+

data/keycard.gemspec

@@ -26,14 +26,14 @@ Gem::Specification.new do |spec|
 
   spec.add_dependency "sequel"
 
-  spec.add_development_dependency "bundler", "~> 1.16"
-  spec.add_development_dependency "coveralls", "~> 0.8"
+  spec.add_development_dependency "bundler"
+  spec.add_development_dependency "coveralls"
   spec.add_development_dependency "pry"
-  spec.add_development_dependency "rake", "~> 12.0"
-  spec.add_development_dependency "rspec", "~> 3.0"
-  spec.add_development_dependency "rubocop", "~> 0.52"
-  spec.add_development_dependency "rubocop-rails", "~> 1.1"
-  spec.add_development_dependency "rubocop-rspec", "~> 1.16"
+  spec.add_development_dependency "rake"
+  spec.add_development_dependency "rspec"
+  spec.add_development_dependency "rubocop"
+  spec.add_development_dependency "rubocop-rails"
+  spec.add_development_dependency "rubocop-rspec"
   spec.add_development_dependency "sqlite3"
-  spec.add_development_dependency "yard", "~> 0.9"
+  spec.add_development_dependency "yard"
 end

data/lib/keycard/digest_key.rb

@@ -0,0 +1,59 @@
+# frozen_string_literal: true
+
+require "digest"
+require "securerandom"
+
+# A typical digest or api key, ready to be encrypted.
+class Keycard::DigestKey
+  class HiddenKeyError < StandardError; end
+  HIDDEN_KEY = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX".freeze
+
+  # To simply mint a new key, call #new without any parameters.
+  # For wrapping existing, deserialized keys, pass the digest to the constructor.
+  # @param digest [String] The value of the hashed key
+  # @param key [String] Use this if you'd like to specify the unhashed key.
+  #   If a digest is also provided, this parameter is ignored.
+  def initialize(digest = nil, key: nil)
+    if digest
+      @digest = digest
+    else
+      @key = key || SecureRandom.uuid
+    end
+  end
+
+  # A string representation of this key. For hidden keys, this returns an
+  # obfuscated value.
+  # @return [String]
+  def to_s
+    @key || HIDDEN_KEY
+  end
+
+  # The unhashed value of the key.
+  # @return [String]
+  # @raise [HiddenKeyError] This exception is raised if the unhashed key is
+  #   not available.
+  def value
+    if @key
+      @key
+    else
+      raise HiddenKeyError, "Cannot display hashed/hidden keys"
+    end
+  end
+
+  # The result of hashing the key
+  # @return [String]
+  def digest
+    @digest ||= Digest::SHA256.hexdigest(@key)
+  end
+
+  def eql?(other)
+    digest == if other.is_a?(self.class)
+                other.digest
+              else
+                other.to_s
+              end
+  end
+  alias == eql?
+
+end
+

data/lib/keycard/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Keycard
-  VERSION = "0.2.4"
+  VERSION = "0.3.0"
 end

data/lib/keycard.rb

@@ -13,6 +13,7 @@ module Keycard
   end
 end
 
+require "keycard/digest_key"
 require "keycard/db"
 require "keycard/railtie" if defined?(Rails)
 require "keycard/institution_finder"

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: keycard
 version: !ruby/object:Gem::Version
-  version: 0.2.4
+  version: 0.3.0
 platform: ruby
 authors:
 - Noah Botimer
@@ -9,7 +9,7 @@ authors:
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2018-07-20 00:00:00.000000000 Z
+date: 2019-03-06 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: sequel
@@ -29,30 +29,30 @@ dependencies:
   name: bundler
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '1.16'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '1.16'
+        version: '0'
 - !ruby/object:Gem::Dependency
   name: coveralls
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '0.8'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '0.8'
+        version: '0'
 - !ruby/object:Gem::Dependency
   name: pry
   requirement: !ruby/object:Gem::Requirement
@@ -71,72 +71,72 @@ dependencies:
   name: rake
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '12.0'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '12.0'
+        version: '0'
 - !ruby/object:Gem::Dependency
   name: rspec
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '3.0'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '3.0'
+        version: '0'
 - !ruby/object:Gem::Dependency
   name: rubocop
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '0.52'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '0.52'
+        version: '0'
 - !ruby/object:Gem::Dependency
   name: rubocop-rails
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '1.1'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '1.1'
+        version: '0'
 - !ruby/object:Gem::Dependency
   name: rubocop-rspec
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '1.16'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '1.16'
+        version: '0'
 - !ruby/object:Gem::Dependency
   name: sqlite3
   requirement: !ruby/object:Gem::Requirement
@@ -155,16 +155,16 @@ dependencies:
   name: yard
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '0.9'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '0.9'
+        version: '0'
 description: 
 email:
 - botimer@umich.edu
@@ -183,11 +183,21 @@ files:
 - README.md
 - Rakefile
 - bin/console
+- bin/rake
 - bin/setup
 - db/migrations/1_create_tables.rb
+- docs/Makefile
+- docs/_static/.gitkeep
+- docs/_templates/.gitkeep
+- docs/authentication.rst
+- docs/conf.py
+- docs/index.rst
+- docs/requirements.txt
+- docs/runtime_context.rst
 - keycard.gemspec
 - lib/keycard.rb
 - lib/keycard/db.rb
+- lib/keycard/digest_key.rb
 - lib/keycard/institution_finder.rb
 - lib/keycard/railtie.rb
 - lib/keycard/request.rb