Basic question re configuration of Embedded Discovery Service

[Keith Hazelton]

On Aug 25, 2012, at 05:16:14, Peter Schober wrote:

> * Keith Hazelton <hazelton at doit.wisc.edu> [2012-08-24 17:33]:
>>>> My question is simple:  Where do I put that discoData file so
>> that it will be found. 
>>> 
>>> You don't, the feed comes from the SP. If you want to build your
>>> own for some reason then you change the feed path in the EDS
>>> config. But I didn't document the feed, not to date anyway.
>> 
>> Then I guess I should be looking at a custom WAYF/DS to do what I
>> want rather than EDS, since I want to have an SP-specific set of
>> IdPs.
> 
> Isn't that exactly what using the feed from the SPs gives you? A feed
> containing all entities known to the SP? If you want to filter out
> some of those completely there are the metadata filters of the SP
> (blacklist, whitelist).
> If you want some entities to be usable by the SP but not to showing up
> in the EDS the EDS has a setting for that as well.
> 
> So IMO you're doing too much (copying files around, constructing your
> own discofeed files) and the reason for all that is not at all clear
> to me.

Yes, Peter, now that I understand the ins and outs of the embedded discovery service, it does most of what I need out of the box, no muss, no fuss.

The ultimate goal of this task for me is to develop a self-service account linking utility for Project Bamboo researchers and users. Project Bamboo is a collaborative research environment for the humanities.  A central Bamboo person service maintains an identity registry for all participants, but depends on Bamboo Federation IdPs to manage user credentials and provide authentication services (a 1-to-1 match with inCommon is not  possible at this stage).  A person initially self-registers with Project Bamboo by authenticating to a federated registration and profile service run by Bamboo. A Bamboo identity is created for them, and a mapping from the IdP + remote_user tuple to the Bamboo internal identifier (BPId) is recorded.  

We envision that an account linking service could proceed as follows:

1) The user browses to a self-service account linking page. This page is Shib-protected, so once the user authenticates, the user's previously registered BPId can be retrieved and saved in an application session variable (note, NOT in the SP session).

2) The page includes a "click HERE to link another of your Identity Provider accounts to Bamboo" item.  If the user clicks this, the SP logout url is invoked with a return parameter to a second service page.  The new page is also shib protected, so another discovery step is invoked, and the user selects a second IdP with which to authenticate.  Note that it would be nice for the second discovery page to indicate to the user that they are in the process of selecting an IdP for the express purpose of pointing a second IdP identity to a Bamboo identity they have previously established.

3) Upon successful re-authentication, the previous BPId (still available in the application session) is retrieved, and a new Bamboo identity registry map entry is made associating the new IdP + remote_user tuple with the same BPId.

Note that it would be a more straightforward UX if the second trip to the discovery service did NOT include the IdP by which the user began the process.  This is where it would be nice if a different data source for discovery could be provided, different from the one produced automagically by the EDS from the Bamboo Federation metadata.  This enhancement is not essential to the operation of the account linking service, of course. 

      More than you wanted to know, but I couldn't resist,   --Keith

> -peter
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net