Skip to Content.
Sympa Menu

interfed - Re: [inc-interfed] Additional MDUI interest points/ MDUI in action

Subject: Interfederation

List archive

Re: [inc-interfed] Additional MDUI interest points/ MDUI in action


Chronological Thread 
  • From: Chris Phillips <>
  • To: "" <>
  • Subject: Re: [inc-interfed] Additional MDUI interest points/ MDUI in action
  • Date: Mon, 15 Apr 2013 14:51:06 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Authentication-results: sfpop-ironport07.merit.edu; dkim=neutral (message not signed) header.i=none


In regards to CAF's eduGAIN pieces, we're working on having a model where
we have todays CAF feed and an 'inter-federation' feed. This will allow us
to suppress CAF entities from the eduGAIN set and partition the two.
CAF has a model where we want IdPs in CAF to release ePTId to the
federation by default to allow simple services to easily integrate with
ePTId as an identifier.
Because of this, we need the feed to be separate. (There's certainly a
long conversation about the meaning of being in federation metadata or
tagging things in it that could be had here -- release none, some, many
etc vs meaning of being fed metadata etc)

All this said, I think one way for the LIGO SP to test the best experience
for SPs is to join CAF to experience what it would be in an
inter-federation context with eduGAIN. It's free, and just provide eduGAIN
compliant metadata and request to be promoted and we can push it up to
eduGAIN.

The return path would then be to consume CAF + our inter federation
metadata stream and be able to write the necessary access policy that the
LIGO SP wants. This double dips and gets Scott K the IdPs he was asking
for (in CAF metadata) plus the eduGAIN experience.
I know Scott is striving for a single point to fetch metadata and to fully
test this. In that model, what Ian suggested would emulate that use case.
Have Steven's aggregator consume/fetch eduGAIN and CAF data and THEN offer
it to the LIGO SP.

That would emulate the 'all my federation metadata comes from inCommon'
kind of test. There may be some drawbacks, but I'll have to ponder that
for a bit.
I don't know if inCommon would want to emulate the model of one metadata
file or multiple files. The Shibboleth SP config is not hard to add the
2nd trust from my observation.

I know folks are busy for a few weeks, so let me know if you want to go
down this path, and if so, we can get things going for LIGO.
From my perspective it's an very easy and least effort(free) test to have
one SP that wants our IdPs anyways to join and try the eduGAIN route.


Chris.





On 13-04-15 12:54 PM, "Ian Young"
<>
wrote:

>
>On 10 Apr 2013, at 16:19, Scott Koranda
><>
> wrote:
>
>> either by extending the current pilot project we having going that
>> involves the UK metadata feed or by LIGO joining CANARIE (I am not
>> sure which yet since it would depend on more input from others
>> including yourself),
>
>One option which would take advantage of CAF's existing eduGAIN-related
>technology would be to get the IdPs you're interested in into their
>eduGAIN aggregate and have Steven's aggregator consume that and pass it
>along to the LIGO SPs. I'm discussing something along these lines with
>Leif at the moment, to try and solve a UK/SE use case with the minimum
>amount of extra work.
>
>The right way to handle the reverse path would depend on how non-CAF
>metadata is presented to CAF members, which perhaps Chris can fill us in
>on. Obviously the UK approach of (eventually) pushing everything into
>the production aggregate means least work all round, but there are
>alternative routes.
>
> -- Ian
>
>
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.16.

Top of Page