Interfederation

[Scott Koranda <>]

> 
> On 21 Feb 2013, at 17:59, Steven Carmody
> <>
>  wrote:
> 
> > One of the next questions, tho, is which IC entries do we
> > want to include ?
> 
> The answer to this is going to depend on who we expect to
> consume the file, and what they will use it to replace (if
> anything).  Which is another way of saying that it depends
> on what we think you're prototyping there… although I'm
> personally pretty happy with the idea that one of the points
> of a prototype is to find out what you should really be
> building, not just how to do it.
> 
> > Stated another way, if IC made available an export file,
> > and this mechanism used the IC and UK export files as
> > input, what would IC include in its export file ?
> 
> I hadn't thought about the current activity in terms of
> combining the export aggregates of two federations; it's not
> clear to me who would want to consume such a thing other
> than perhaps another federation.  That is after all exactly
> what an exchange like eduGAIN looks like, and I don't think
> we're trying to build an eduGAIN competitor here.  Not this
> week, anyway (consider it your homework for next week).
> 
> Combining all of InCommon plus the UKf export aggregate
> might be useful for an InCommon member who wanted a single
> place to get all their metadata from.  It's the kind of
> model we're attempting in the UK, where the intention is
> that our production aggregate is a combination of our
> registered entities plus imports from each of our federation
> partners.
> 
> Scott K is going to be able to weigh in with what LIGO
> entities need to consume, but I think I recall that they
> already whitelist selected entities from within InCommon.
> They might therefore be able to make use of something like
> the system you've just built if it had a whitelisting stage
> after the merge.  That's very easy to do, by the way, and I
> can send you a snapshot with an example in it now that I've
> written the InCommon import for the UKf.  Note that the way
> the stages work means that you can whitelist each input with
> the same bean in order to minimise the amount of data you're
> carrying around prior to the merge.
> 

Yes, we currently whitelist at the SP (we use Shibboleth SPs
exclusively right now and it is an easy configuration, I
apologize I do not know if SimpleSAMLphp has the same
capability).

The whitelisting, however, has more to do with my time
constraints that have prevented me from getting the
application (in this case Foswiki) to "behave" correctly when
IdPs do not assert ePPN. I need to use the Shib SP 2.5.x
"session hook" feature to capture the session and then intervene when 
ePPN is not available.

Once that is done I do not plan to whitelist at the SP...the
authorization controls on the SP are good enough.

Ultimately I think what I would want from InCommon is an
ala-carte menu of different aggregate feeds, and for this SP I
would want to choose "InCommon + UK + eduGAIN + GakuNin +
...". 

Or perhaps it would be better to have two feeds and I
configure the SP to download them both:

- InCommon
- InCommon "vetted international partners"

where "vetted international partners" buries a couple years of policy
discussions I suppose.

Thanks,

Scott K