Shibboleth Developers

["Spencer W. Thomas" <>]

I'm not completely sure if I want to jump into this fray or not.  But,
here goes anyway.

Firstly, I can't read Scott's document, because we're not a member of
OASIS, so I can't log in to their site.  So these comments are solely
based on my experience and what I've read in this forum.  And, they
represent my opinion, not necessarily that of JSTOR (although my opinion
has had a lot to do with the direction we are currently taking at JSTOR.)

We decided, based on discussions here and F2F, that we wanted to "hide"
Shibboleth, and that home-site discovery could be useful for more than
just Shibboleth-enabled sites.  Ideally, we'd be able to record a
home-site login method for any site providing such, whether by
Shibboleth, Athens, proxy server, or whatever.

This decision puts some serious constraints on how the discovery service
can be implemented.  It can't be in the middle of the Shibboleth authn
"arc," for one.  It can't be organized by "federation" (which I never
thought was a good idea).  And it has to use "neutral" terminology.

For our first cut, we're taking only the low-hanging fruit -- Shibboleth
and Athens.  The UI, and much of the code, is based on the
multi-federation WAYF published here:
<https://spaces.internet2.edu/display/SHIB/DiscoveryService#DiscoveryService-DeployMe>.
 
Rather than organizing sites by federation, they're organized
geographically.  For now, a single level of "country" works.  At some
point, we'll probably have to subdivide some countries into states or
provinces or what-have-you.  You can see it "in action" here:
<http://shibpilot.jstor.org/start-session>.

Now, this can work only because it's based on our internal site metadata
(along with Shib metadata for the Shib-enabled sites). In particular,
the geographical information comes directly from our own database. 
Also, the information about whether a particular site can use Shib or
Athens to auth to JSTOR comes from our own database.  So you won't see
too many Shib sites in the list, because only a few have set up with us
to use Shib, to date.  (And those are from the InQueue federation, as
our InCommon registration is still in process.)

When the user selects their "home organization" from the DS, their
browser will be forwarded to the appropriate log in URL.  For Shib
sites, it's the IdP's SSO page.  For Athens, it's the Athens/JSTOR log
in screen.  An interesting thing happens here:  All Athens sites are
forwarded to the same screen, it really doesn't matter which one you
choose.  The selected site has no affect on the forwarding, as Athens
determines the user's organization according to their login ID.  (And I
just realized that this probably isn't going to work well with those
sites that use the Shib->Athens gateway -- but it's no worse than our
current solution -- and for them we should enable Shib access, anyway.)

I'd like to see us add metadata to support sites that use proxy servers
as well.  Our support staff have proxy server information for many of
the organizations that participate in JSTOR.  In theory at least, we
could enter that information into a database, and forward users to the
organization's proxy logon screen from the DS.

We tried to ask ourselves, "what would best serve our users?" under the
constraint of "can be implemented".  I'm sure that our current solution
is not an endpoint, but a starting point.   But it's also a solution
that can be implemented only by us, because we are the only organization
that has (all) the information that is needed to implement it.  As a
side note: for Shib and Athens, this is information that we must have
and hold, because we need to map from the Athens Org ID or the
Shibboleth IdP identifier to our internal participant identifier. 

The bottom line, from my perspective is that it's not clear to me that
3rd-party discovery services will be of much use to us, especially when
we're trying to support auth methods other than Shibboleth within the
same DS.


=Spencer Thomas
JSTOR