Pre-eduGain integration stopgap measures

[Peter Schober]

James,

* James Miller <jmiller at turnitin.com> [2016-10-28 09:51]:
> We have a customer in Australia who is interested in implementing
> shibboleth and using it to authenticate with our service. They are not
> currently a member of any federation. It appears the AAF federation in
> Australia is an eduGAIN member, but they are not yet exporting their
> metadata for the consumption of other federation (though from what their
> website tells me, they'll be seeking funding to implement that next year).
> 
> We don't necessarily want to wait until the AAF is fully plugged into
> eduGAIN, but we would also like to avoid joining another federation if
> possible. As a stopgap measure, if they joined AAF and we imported the
> metadata for that federation into our SP and they imported the metadata
> from one of the federations we are a member of into their IDP, would that
> work (It seems like it would to me)? Would it be against the rules (it
> seems shady to import metadata of a federation you're not a member of)?

None of these are really questions for this list, which is about the
Shibboleth software, not federations and their many shapes and
colors. I'd recommend asking that question on the REFEDS mailing list
(where the academic Research and Education Federations come together,
cf. mailing lists at https://refeds.org/about but also note the
https://refeds.org/about/refeds-participants-agreement implied).

The AAF has started exporting entities (well, a single one) to
eduGAIN, so what's stopping them from exposting more entities likely
has little to do with technology (and more with business), but I'm
merely speculating, of course.

The customer joining the AAF (if eligible; IIRC this also comes at a
cost) is certainly a good start, esp if the customer indeded to do
that for other reasons anyway.
I'm not aware of "terms of use" concerning the AAF Metadata (e.g. the
Swedish version of the AAF has TOU that state you're acccepting their
federation policy by using their metadata), so maybe watch out for
those.

Other than that I see no issue with you deciding unilaterally to trust
the AAF's processes, signing key and metadata.
Likewise the customer could add metadata for your SP only, provided
via whatever means you're offering. Whether they decide to trust
metadata coming from you direcly or trusting some other federations'
keys and processes and metadata isn't much different.

So the main question to me is whether any of that is any faster,
simpler or more trustworthy than you and the customer exchanging SAML
Metadata bilaterally.
I guess you're the one that likes to avoid that for issues of scale?

Best regards,
-peter