entity descriptors from multiple registrars

[Tom Scavo]

Suppose a deployment consumes metadata from multiple sources such that
its metadata store contains entity descriptors from multiple
registrars (i.e., federations). How does Shibboleth distinguish
metadata from different registrars?

For the IdP, I think I know the answer: Install the
mdrpi-match-idp-ext add-on on Shibboleth IdP 2.4 (or later):

https://github.com/ukf/mdrpi-match-idp-ext

What is the answer for the Shibboleth SP?

Thanks,

Tom

[Cantor, Scott]

Post by Tom Scavo
Suppose a deployment consumes metadata from multiple sources such that
its metadata store contains entity descriptors from multiple
registrars (i.e., federations). How does Shibboleth distinguish
metadata from different registrars?
For the IdP, I think I know the answer: Install the
https://github.com/ukf/mdrpi-match-idp-ext
What is the answer for the Shibboleth SP?

None for the moment. I really wasn't paying attention at the time or I
would have argued against creating a custom extension in favor of using an
entity attribute.

I think when you dig into this a little, though, the answer is that I
don't care who the registrar is, but what some particular policy is. And I
think that ought to be expressed directly rather than through implication
based on the registrar, or based on a more far-reaching policy statement
that probably includes many different things, some worth caring about and
some not.

-- Scott

[Tom Scavo]

Post by Cantor, Scott

Post by Tom Scavo
Suppose a deployment consumes metadata from multiple sources such that
its metadata store contains entity descriptors from multiple
registrars (i.e., federations). How does Shibboleth distinguish
metadata from different registrars?
For the IdP, I think I know the answer: Install the
https://github.com/ukf/mdrpi-match-idp-ext
What is the answer for the Shibboleth SP?

None for the moment.

Which answers my question, thanks.

The rest of this message seems to be off-topic for the users list so
I'm open to suggestion where the discussion should take place.

Post by Cantor, Scott
I really wasn't paying attention at the time or I
would have argued against creating a custom extension in favor of using an
entity attribute.

I don't think that's been ruled out. In InCommon, at least, the
previously mentioned extension has not been deployed AFAIK so we're
free to solve the problem any way we like.

Post by Cantor, Scott
I think when you dig into this a little, though, the answer is that I
don't care who the registrar is, but what some particular policy is.

If we think that registrars will support multiple policies, then yes, I agree.

Post by Cantor, Scott
And I
think that ought to be expressed directly rather than through implication
based on the registrar

As you probably know, the MDRPI SAML metadata extension carries the
registrar's policy URL in addition to the registrar's identifier, but
if the policy changes, the URL MUST change (according to the spec) so
I'm not seeing much value in keying off the policy.

Post by Cantor, Scott
or based on a more far-reaching policy statement
that probably includes many different things, some worth caring about and
some not.

I'm not following you there but clearly there is much to talk about
(and my need is immediate). Where should this discussion take place?

Thanks,

Tom

[Cantor, Scott]

Post by Tom Scavo

Post by Cantor, Scott
I think when you dig into this a little, though, the answer is that I
don't care who the registrar is, but what some particular policy is.

If we think that registrars will support multiple policies, then yes, I agree.

By "policy", I meant "specific thing the registrar does that I want to
recognize".

Post by Tom Scavo

Post by Cantor, Scott
And I think that ought to be expressed directly rather than through
implication
based on the registrar

As you probably know, the MDRPI SAML metadata extension carries the
registrar's policy URL in addition to the registrar's identifier, but
if the policy changes, the URL MUST change (according to the spec) so
I'm not seeing much value in keying off the policy.

I think those policies are the macro, but that application decisions will
be based on the micro. That's another way of saying the same thing, a
broad policy URI that changes when any little detail does won't be useful
for app policy.

Post by Tom Scavo
I'm not following you there but clearly there is much to talk about
(and my need is immediate). Where should this discussion take place?

REFEDS, probably. But fundamentally we need use cases and specifics and
apps that care, otherwise we're inventing problems apps don't care about,
like with assurance (IMHO).

-- Scott

[Tom Scavo]

Post by Cantor, Scott

... clearly there is much to talk about
(and my need is immediate). Where should this discussion take place?

REFEDS, probably. But fundamentally we need use cases and specifics and
apps that care, otherwise we're inventing problems apps don't care about,
like with assurance (IMHO).

I definitely have use cases: two NSF-funded R&S SPs where the NSF
dollars are intended to be used for US research, exclusively. My need
is real and immediate. Without a solution, extending our local
implementation of R&S to the international research community is
essentially blocked.

Tom

[Cantor, Scott]

Post by Tom Scavo
I definitely have use cases: two NSF-funded R&S SPs where the NSF
dollars are intended to be used for US research, exclusively. My need
is real and immediate. Without a solution, extending our local
implementation of R&S to the international research community is
essentially blocked.

Not sure I can map that statement to a specific thing the metadata is
meant to solve. It certainly doesn't tell you the country of origin of an
account holder to know who registered an IdP.

I'm against using metadata and the identity of an IdP for authorization of
users, both before and after interfederation. It's the attributes that
should matter. What these policy controls would hit would be for filtering
of attributes, or if the IdP just didn't pass muster operationally or
something like that.

-- Scott

[Ian Young]

Post by Tom Scavo
I definitely have use cases: two NSF-funded R&S SPs where the NSF
dollars are intended to be used for US research, exclusively.

It seems odd to use the registrar ID for this. You'd be saying, essentially, that any user authenticated by an IdP registered by InCommon was assumed to be engaged in "US research" (however that's defined) but that any user (even the same user) authenticated by an IdP registered by some other registrar was assumed not to be engaged in an eligible activity. That seems like conflating two concepts, particularly in the longer term.

I realise that you may feel there's nothing else available to represent the concept you want; I'm just saying this isn't what the registrationAuthority is supposed to be for at all.

-- Ian

[Peter Schober]

Post by Tom Scavo
I definitely have use cases: two NSF-funded R&S SPs where the NSF
dollars are intended to be used for US research, exclusively.

No idea what that means for services, subjects and their research.
http://dev.maxmind.com/geoip/legacy/mod_geoip2/ ?
Not that virtually being on US soil (as far as GeoIP is concerned)
will tell you what kind of research I'm involved with.

Related to what Scott said about registrar info as Entity Attributes:
DFN-AAI translates @registrationAuthority into entity attributes in
their downstreams, IIRC, so the Shib SP's (and IDP's) built-in match
functors can be used for that, no extensions needed.
Quick short term "fix", I would think.
(And no, I also don't understand what a metadata registrar has to do
with the above mentioned use case. But then I don't understand the use
case. Or its relation to SAML and Shibboleth.)
-peter

[Dave Perry]

What does NSF and R&S stand for btw?

_________________________________________________
Dave Perry
eLearning Technologist, Hull College Group

Room L34 - Queens Gardens Library
Wilberforce Drive, Queen's Gardens, Hull, HU1 3DG
Extension 2230 / Direct Dial 01482 381930

* Need a fast reply? Try elearning-NOSDTyrR4+***@public.gmane.org *


-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Tom Scavo
Sent: 17 September 2014 16:58
To: Shib Users
Subject: Re: entity descriptors from multiple registrars

Post by Cantor, Scott

... clearly there is much to talk about (and my need is immediate).
Where should this discussion take place?

REFEDS, probably. But fundamentally we need use cases and specifics
and apps that care, otherwise we're inventing problems apps don't care
about, like with assurance (IMHO).

I definitely have use cases: two NSF-funded R&S SPs where the NSF dollars are intended to be used for US research, exclusively. My need is real and immediate. Without a solution, extending our local implementation of R&S to the international research community is essentially blocked.

Tom
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

**********************************************************************
This message is sent in confidence for the addressee
only. It may contain confidential or sensitive
information. The contents are not to be disclosed
to anyone other than the addressee. Unauthorised
recipients are requested to preserve this
confidentiality and to advise us of any errors in
transmission. Any views expressed in this message
are solely the views of the individual and do not
represent the views of the College. Nothing in this
message should be construed as creating a contract.

Hull College owns the email infrastructure, including the contents.

Hull College is committed to sustainability, please reflect before printing this email.
**********************************************************************

TEXT

[Allan West]

NSF is the U.S. National Science Foundation http://www.nsf.gov/, a major
granting agency.
I can't find an obvious "R&S" on their site so I'm curious about that, too.
Allan

Post by Dave Perry
What does NSF and R&S stand for btw?
_________________________________________________
Dave Perry
eLearning Technologist, Hull College Group
Room L34 - Queens Gardens Library
Wilberforce Drive, Queen's Gardens, Hull, HU1 3DG
Extension 2230 / Direct Dial 01482 381930
-----Original Message-----
Sent: 17 September 2014 16:58
To: Shib Users
Subject: Re: entity descriptors from multiple registrars

Post by Cantor, Scott

... clearly there is much to talk about (and my need is immediate).
Where should this discussion take place?

REFEDS, probably. But fundamentally we need use cases and specifics
and apps that care, otherwise we're inventing problems apps don't care
about, like with assurance (IMHO).

I definitely have use cases: two NSF-funded R&S SPs where the NSF dollars are intended to be used for US research, exclusively. My need is real and immediate. Without a solution, extending our local implementation of R&S to the international research community is essentially blocked.
Tom
--
**********************************************************************
This message is sent in confidence for the addressee
only. It may contain confidential or sensitive
information. The contents are not to be disclosed
to anyone other than the addressee. Unauthorised
recipients are requested to preserve this
confidentiality and to advise us of any errors in
transmission. Any views expressed in this message
are solely the views of the individual and do not
represent the views of the College. Nothing in this
message should be construed as creating a contract.
Hull College owns the email infrastructure, including the contents.
Hull College is committed to sustainability, please reflect before printing this email.
**********************************************************************
TEXT

[Cantor, Scott]

Post by Allan West
NSF is the U.S. National Science Foundation http://www.nsf.gov/, a major
granting agency.
I can't find an obvious "R&S" on their site so I'm curious about that, too.

Research and Scholarship (i.e., the only thing that's managed to pry any
attributes out of most InCommon IdPs, by and large).

-- Scott

[Andy Bennett]

Hi,

Post by Tom Scavo

Post by Cantor, Scott

... clearly there is much to talk about
(and my need is immediate). Where should this discussion take place?

REFEDS, probably. But fundamentally we need use cases and specifics and
apps that care, otherwise we're inventing problems apps don't care about,
like with assurance (IMHO).

I definitely have use cases: two NSF-funded R&S SPs where the NSF
dollars are intended to be used for US research, exclusively. My need
is real and immediate. Without a solution, extending our local
implementation of R&S to the international research community is
essentially blocked.

At Knodium we're doing some work to try to map IDPs and their scopes to
real life institutions. However, our authorization policies still rely
on attributes so without something like an affiliation or entitlement to
tell you so, I don't see how you can achieve this.

In particular, the staff@ and student@ affiliations don't tell you
anywhere near as much as you might hope. PhD students are an interesting
edge case.


Your use cases seems to have parallels with "journal access", for which
the "common-lib-terms" entitlement is commonly used. Perhaps you need a
"was-given-nsf-dollars" entitlement?





Regards,
@ndy

[Andy Bennett]

Hi,

Post by Tom Scavo
I definitely have use cases: two NSF-funded R&S SPs where the NSF
dollars are intended to be used for US research, exclusively. My need
is real and immediate. Without a solution, extending our local
implementation of R&S to the international research community is
essentially blocked.

Having thought about this over lunch, I'm guessing that your assumption
is, given you have to be a US academic institution to register an IDP in
InCommon, that an InCommon IDP authentication authorizes the principal
as someone who is a US academic researcher?


Given that those SPs don't want to serve principals from other
federations, why can't you use the InCommon metadata only in the SP
configuration?


Would it be possible to accept a *.edu scope in an affiliation attribute
to identify US registered academic principals?


How strict do you need to be? Would it suffice to have a self
certification during first login?





Regards,
@ndy

[Tom Scavo]

Post by Andy Bennett

Post by Tom Scavo
I definitely have use cases: two NSF-funded R&S SPs where the NSF
dollars are intended to be used for US research, exclusively. My need
is real and immediate. Without a solution, extending our local
implementation of R&S to the international research community is
essentially blocked.

Having thought about this over lunch, I'm guessing that your assumption
is, given you have to be a US academic institution to register an IDP in
InCommon, that an InCommon IDP authentication authorizes the principal
as someone who is a US academic researcher?

Yes, basically.

Post by Andy Bennett
Given that those SPs don't want to serve principals from other
federations, why can't you use the InCommon metadata only in the SP
configuration?

Assumptions about the entities comprising a given metadata aggregate
are breaking down as we speak. Interfederation, in particular eduGAIN,
are challenging any preconceived ideas we have about the nature of the
aggregate. To make matters worse, there is a pilot project spinning up
(also as we speak) that focuses on per-entity metadata, so clearly any
significance we attach to the aggregate itself may not hold in the
future.

Post by Andy Bennett
Would it be possible to accept a *.edu scope in an affiliation attribute
to identify US registered academic principals?

Maybe. An entity attribute would be better, but like Scott says, we
need to better understand the use case.

Post by Andy Bennett
How strict do you need to be? Would it suffice to have a self
certification during first login?

Right, that's a good question. The short answer is I don't know. I'll
keep plugging away at this use case and see what gives.

Thanks,

Tom

[Cantor, Scott]

Post by Tom Scavo

Post by Andy Bennett
Having thought about this over lunch, I'm guessing that your assumption
is, given you have to be a US academic institution to register an IDP in
InCommon, that an InCommon IDP authentication authorizes the principal
as someone who is a US academic researcher?

Yes, basically.

But that's just not the case.

Post by Tom Scavo

Post by Andy Bennett
Would it be possible to accept a *.edu scope in an affiliation attribute
to identify US registered academic principals?

Maybe. An entity attribute would be better, but like Scott says, we
need to better understand the use case.

No, you need a *user* attribute. This isn't about the IdP at all.

-- Scott