IdP Admin Tools: a follow up (with description of Duke's system for SP registration)

[Erdos, Marlena]

Dear All,

Some weeks ago, I inquired on this list about administration tools for the
IdP.   I want to follow up now with some hopefully useful on Duke's system
for SP registration for internal-to-Duke apps.  (Why Duke?  Because what
they are doing struck me as possibly widely useful.  Plus, while Duke's
system isn't unique in overall design, it seemed to be the most mature of
the non-vendor admin tools I came across. )


Before I launch into the discussion of Duke's system,  I want to thank
everyone that responded to my inquiry! I also want to mention that my
write-up is based on a conversation I had with Duke's Shilen Patel.  He
also OK'd sending the write up to this list.  Thank you Shilen!

Now onto Duke's system.

Unlike some schools, Duke does not force applications (SPs) to participate
in InCommon.  Rather, SP owners go through a web application both to
register their applications and request the user attributes they need.

 
Duke's system for registration consists of this web application, a backend
database that holds the SP registration information,  and a process
(daemon) that reads the database and updates the IdP's configuration file
for controlling attribute release to SPs ("attribute-filter.xml"). This
process also updates the metadata file (for Duke's internal SPs).

 
Here is the url for new registrations:
https://wiki.duke.edu/display/OITSHIB/3.+New+Registration

Note that these internal-to-Duke SPs do not need to implement or use a
DiscoveryService (aka "Where are you from (WAYF)" service) because only
the Duke IdP is relevant for these SPs.


 
 
SPs and Attribute Release/

 
On the new SP registration page, the user gets to request they attributes
they want.   Two attributes are automatically released and don't need to
be requested.  These are eduPersonPrincipal name and
eduPersonScopedAffiliation:

 
eduPersonPrincipal name is Duke's "net id" concatenated with "@duke.edu."
 Their net id can be a human-friendly name such as "rob" or can be a set
of initials (say). While they have an internal numeric unique id, they
avoid releasing it, since their Registrar has deemed it "sensitive."

 
eduPersonScopedAffiliation:  The user's broad roles at Duke: student,
faculty, staff.   This attribute can be multi-valued.

 
After the user fills out the registration form, including the request for
attributes, the web application compares the attributes requested to a
list it holds of public attributes.
 

If the requested attributes are public information, the web application
writes a "new registration" record to the database; the
attribute-filter-modifying process apparently polls the database fairly
often and will pick up the new registration and then modify the
attribute-filter.xml file and the metadata file.

 
Notably, the attribute-filter-modifying process creates a new entry for
every SP rather than trying to do any sort of grouping.  This means that
Duke has a very large attribute-filter.xml file -- with over one thousand
separate entries for SPs.  This apparently works just fine.

 
If the user requested attributes that are not public, the web application
does two things: It sends a "pending registration" record to the database
and it sends an email to IdM staff at Duke.  The IdM staff goes through an
approvals process with HR or the Registrar as appropriate.

 
If the IdM folks get an approval for release of the non-public attribute,
they modify the database entry so that the entry gets changed from
"pending" to "new."  The attribute-filter-modifying process will pick up
the new registration and then modify the attribute-filter.xml file and
also update the metadata file.
 

Voila!

Again, my thanks to all who responded about IdP admin tools.

My best,
Marlena
Harvard University Information Technology
Innovation & Architecture