Interfederation

[Tom Scavo <>]

On Tue, Mar 4, 2014 at 9:06 AM, Scott Koranda 
<>
 wrote:
>
> On Tue, Mar 4, 2014 at 7:28 AM, Tom Scavo 
> <>
>  wrote:
>
>> Honestly, I think Federated Security Incident
>> Response needs its own working group.
>
> Jim Basney and I had a call last week with the CIC IdM working group.
> We are spinning up a new effort that will implement the federated identity
> incident response policy developed by that same group in 2011 for
> CIC schools.
>
> The CIC will take the lead and then ask InCommon to review what it has done
> and consider adopting it to some extent. It is my understanding this model
> has been used before.

My two cents: a TAC-sponsored working group will help move FSIR
forward in InCommon.

>> 2) I know about the LIGO use case involving SAML artifact. It's a
>> legitimate use case but AFAIK it's very much the exception rather than
>> the rule, and so requiring artifact support of all IdPs in the
>> Federation doesn't seem to be justified.
>
> I am not asking that IdPs be required to support SAML artifact
> and attribute query.
>
> I am asking that InCommon continue to make possible and allow
> IdPs that do support those profiles to continue to publish those
> endpoints in the InCommon metadata feeds.

Of course, I didn't mean to imply otherwise. The document you are
reading is making a deployment recommendation to the "long tail" of
InCommon IdPs. Therefore that deployment needs to be as simple as
possible.

>> If you really need artifact
>> at your SP, put a simple IdP Proxy in front of your service that
>> supports artifact.
>
> That would reduce the usefulness of the InCommon federation
> to supporting the LIGO research mission by requiring additional
> infrastructure.

This is a basic federation strategy. For example, the above suggestion
is no different than what we see happening with multifactor
authentication. An SP that feels it needs strong authentication should
take steps to protect itself by deploying multifactor at the SP, or at
an IdP Proxy "close to" the SP.

> If InCommon continues to allow (but not require) IdPs to publish artifact 
> and
> attribute query endpoints than this is not an issue.

Sounds good :-)

>> 3) I don't know about the LIGO use case involving attribute query. Can
>> you explain that briefly?
>
> Until international interfederation is well supported many researchers
> across international boundaries will be "multi-homed" with identities
> in multiple VOs in order to accomplish their research. The multiple
> identities are serviced by multiple IdPs.
>
> The LIGO IdP is the authoritative source for a number of LIGO
> attributes that a research may need to take with him or her to other
> VOs and their infrastructure even when they are forced to authenticate
> using a non-LIGO IdP.
>
> It can be easier to arrange for attribute query to the LIGO IdP than
> it is to get all the IdPs and SPs to be internationally
> interfederated.

Do you mean a standalone attribute query to the LIGO IdP? May I ask,
do you have this working in production? With what SP(s)?

Thanks,

Tom