Is Shibboleth a match to replace our multi-factor authentication system ?

[Christopher Bongaarts]

On 9/11/2012 3:33 PM, Patrick Rynhart wrote:

> At our University we have an in-house developed multi-factor
> authentication system, the purpose of which is to allow both current and
> former students to log into a subset of our websites (e.g. Alumni).  On
> such sites, we have a custom auth module / plug-in on such sites to
> facilitate this process.
>
> We are finding it difficult to maintain this system, and - as such -
> would like to move towards a standard, enterprise class system as a
> replacement.  I was wondering whether Shibboleth would be a potential
> match as a technology ?

Could be.  We have been transitioning away from our own locally 
developed web SSO system (which also supported two-factor via one-time 
passcode tokens) to Shib.

To properly integrate our two-factor system, we developed our own custom 
LoginHandler that can work against LDAP for standard username/passwords 
as well as RADIUS for our two-factor system.  In general, if you want to 
do anything complicated with login handling, you'll need to write a 
LoginHandler.  Fortunately there are examples in the delivered code as 
well as the wiki, and people to help on the Shib Dev listserv.

One of the primary benefits for us using Shib for local SSO was to 
eliminate the need for maintaining both halves of the system.  Now we 
just need to maintain the LoginHandler (not a ton of code - the IdP 
itself handles most of the heavy lifting), and the service provider side 
can usually use the Shib code out of the box (or simpleSAMLphp, or 
OIOSAML, or commercial stuff).

To reemphasize one point that both Scott and Peter pointed out - if you 
run an IdP for lots of local SPs, you'll need to become very familiar 
with metadata.  When the number of SPs we handled was small, we were 
able to manually add new SPs as they came along by hand to the IdP 
configuration files.  After we hit a certain point in growth, it became 
necessary to automate some of the configuration process.   We now sanity 
check the metadata for well-formedness, automatically generate attribute 
filter fragments with "default" attribute release policies that are 
easily edited, and do version control checkins so we can track history. 
  Other institutions have developed nicer solutions with web interfaces 
for metadata submission and updating, some of whom have mentioned the 
possibility of releasing rough code for general use/adaptation (nudge 
nudge).

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%