InCommon metadata support

[Tom Scavo <>]

On Wed, Mar 2, 2016 at 12:56 PM, Wessel, Keith 
<>
 wrote:
>
> By pulling InCommon and eduGAIN metadata from the MDQ server, I simply 
> meant I followed the instructions on the InCommon wiki for configuring a 
> dynamic http metadata client. I did this on our test IDP.

Sorry, that didn't make sense when I read it before. That's because I
didn't know your test IdP was really a second IdP, as noted below:

> Our test IDP, probably unwisely but historically, has a different entity ID 
> and SAML cert than our production one.

Ah, that's a complete horse of a different color. Since your test IdP
is not aligned with your production IdP, I guess it doesn't really
matter if the two have different metadata configs (since they already
diverge).

> Sounds like, if I change this and use the /etc/hosts trick to send local 
> requests to my test IDP, I can at least, as Scott said, kick the tires.

I read Scott's recommendation as: Keep your production IdP and your
test IdP in sync. If you want to migrate both of them to mdq-beta,
that's your decision. In any case, you can hedge your bets by
configuring a chaining MetadataProvider.

> What I didn't realize was that folks were using this beta MDQ server in 
> their production IDPs with the InCommon production aggregate as a fallback 
> aggregate.

If IdP operators are using mdq-beta in production, I don't know about
it, and moreover, I can't really recommend it. As you said earlier,
it's a beta server after all.

> I'll need to float that past a few folks around here, but that certainly 
> seems like a good way to participate in the pilot. So, I think that's the 
> answer I was looking for.

I'm afraid you may have jumped to a conclusion that I (on behalf of
InCommon Operations) can not recommend. At this point, it's safe to
recommend that all InCommon IdPs point to one of the aggregates on
md.incommon.org. If that recommendation changes, you will be the first
to know :-)

Tom

> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Tom Scavo
> Sent: Wednesday, March 02, 2016 8:05 AM
> To: 
> 
> Subject: Re: [Metadata-Support] How to test the per-entity metadata server 
> from an IDP
>
> Hi Keith,
>
> On Tue, Mar 1, 2016 at 6:05 PM, Wessel, Keith 
> <>
>  wrote:
>>
>> I finally configured our test IDP to pull InCommon and eduGAIN metadata 
>> from the MDQ server instead of the full aggregate.
>
> Can you explain what you mean by this? (or simply post your
> MetadataProvider here)
>
>> I'd like to test this out and leave it in place for a while on our test 
>> IDP. Problem is this: obviously, none of the SPs that the MDQ server knows 
>> about will know about our test IDP: it's not the IDP our campus has 
>> published in InCommon.
>
> This is true of the main InCommon aggregate as well. OTOH, if you
> follow our advice in the wiki [1] the published metadata for your
> production IdP and your test IdP should be identical. If so, this is a
> non-issue.
>
>> And since there's no command-line tool in the IDP at this point that one 
>> can use to display metadata on a given entity from the IDP's metadata 
>> resolver, there's not much I can do with my new setup at all.
>
> Yes, that would be a nice feature of the software :-) Is there a
> documented RFE along these lines?
>
>> Clearly, I'm not going to point my production IDP cluster at a service for 
>> metadata when that service is considered beta.
>
> That pretty much says it all. Since your test IdP is intended to
> replace your production IdP at some point, the two should align with
> respect to MetadataProvider. It's not advisable to let them diverge in
> this way (or in any way).
>
>> Any thoughts on how an IDP operator can kick the tires on the MDQ server 
>> and be an active participant in the pilot?
>
> That's a different question. As we mentioned in the message to the
> participants list yesterday, we need to think about that. I'm not
> exactly sure how to answer this question at this point.
>
> Tom
>
> [1] https://spaces.internet2.edu/x/GYtHBQ