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

[Christopher Bongaarts]

On 9/13/2012 7:43 AM, Tom Scavo wrote:

>> 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.
>
> I'm curious, are the attribute filter elements targeted at specific
> SPs via entityID? Are there groups of SPs with identical attribute
> requirements?

Usually they are targeted by entityID.  A few of them are glommed 
together metadata-wise and then permitted by the EntitiesDescriptor name 
("group").  The latter is used more often for sites that need their own 
RelyingParty definition, to avoid needing to touch that file as much.

There are a lot of SPs that just use our default release (uid, isGuest, 
ePPN, something else I'm forgetting).  For services that converted from 
our old SSO system, that covers what they used to get by default.

We generate seperate policies for them rather than rely on a default 
policy to make it easier to see what they have access to and to make 
changes when needed.  Also, if we add more attributes to the default 
release policy in the future, this prevents the new attributes from 
showing up at older SPs uninvited (and thus potentially polluting their 
shibd.log files with unmapped attribute warnings).

>>    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).
>
> Are you referring to Duke or someone else?

I wasn't gonna name names, but they are the ones I had I mind... ;)

> FYI, the InCommon Federation Manager is being re-engineered to enable
> campuses to manage local federation metadata. (Now you know why I
> asked the questions above :) Is this something UofM might be
> interested in using?

Possibly, yes.  The main functionality we would need for local use is to 
be able to safely authorize individuals to add or update metadata for 
their own entityIDs without stepping on other people's, and to be able 
to "push" generation of the new metadata file on short notice.

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