Skip to Content.
Sympa Menu

interfed - Re: [inc-interfed] comments re "New InCommon IdPs"

Subject: Interfederation

List archive

Re: [inc-interfed] comments re "New InCommon IdPs"

Chronological Thread 
  • From: Scott Koranda <>
  • To:
  • Subject: Re: [inc-interfed] comments re "New InCommon IdPs"
  • Date: Tue, 4 Mar 2014 08:53:26 -0600

On Tue, Mar 4, 2014 at 8:34 AM, 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.

I won't speak for Jim but I simply do not have enough time to help with that
at this time. I have started the conversation with the CIC so I am
going to continue
on that path for now but certainly a TAC-sponsored WG led by someone else
concurrently or later would be great.

>>> 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.

Understood. Thanks.

Frankly IdPs that advertise support for artifact but do not actually support
it is a problem in the InCommon metadata, so hiding that option initially
is IMHO a good idea.

IdPs that want to support it should have to take some action to expose
the functionality.

If there could be some type of "InCommon blessed" Shibboleth IdP deployment
or configuration (as asked by Steven) having it not include artifact
or attribute query by default would
also be helpful I think.

>>> 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?

Not yet in production, no. We have so far primarily focused on
consuming federated identities and using COmanage to support an
attribute authority to assert (upon query) attributes that non-LIGO
IdPs will not (or cannot) release or that are only authoritative from
a VO.

We will soon need to extend effort "going the other way". I want to
have the flexibility for the LIGO IdP to support attribute query and
it would be helpful for that endpoint to be published in InCommon and,
soon, then find its way into eduGAIN metadata.

> With what SP(s)?

The SPs are those that will be run by LIGO sister projects such as the
KAGRA gravitatonal wave detector being built in Japan, or other
astronomy and astrophysics projects.


Scott K for LIGO

> Thanks,
> Tom

Archive powered by MHonArc 2.6.16.

Top of Page