Transport option not being respected by MDQ metadata provider.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Transport option not being respected by MDQ metadata provider.

Krishna Mohan

Hi All,

 

We have a service provider 3.0.4 on windows and trying to configure MDQ metadata provider using a webproxy.

We are not seeing the webproxy being utilized, when it tries to load metadata. Below is the configuration and the logs.

 

Did we miss something or is there a bug?

 

         <MetadataProvider type="MDQ" id="incommon" ignoreTransport="true" cacheDirectory="inc-mdq-cache"

maxCacheDuration="86400" minCacheDuration="60"

baseUrl="https://mdq.incommon.org/">

<TransportOption provider="CURL" option="10004">xxxx-webproxy.xxxx.internal:xxxx</TransportOption>

<MetadataFilter type="Signature" certificate="inc-md-cert-mdq.pem"/>

</MetadataProvider>

 

 

2019-11-15 15:33:38 DEBUG XMLTooling.SOAPTransport.CURL [1] [default]: getting connection handle to https://mdq.incommon.org/entities/urn%3Amace%3Aincommon%3Aucop.edu

2019-11-15 15:33:38 DEBUG XMLTooling.SOAPTransport.CURL [1] [default]: nothing free in pool, returning new connection handle

2019-11-15 15:33:38 DEBUG XMLTooling.SOAPTransport.CURL [1] [default]: sending SOAP message to https://mdq.incommon.org/entities/urn%3Amace%3Aincommon%3Aucop.edu

2019-11-15 15:33:39 DEBUG XMLTooling.libcurl [1] [default]:   Trying 13.225.146.95...

 

2019-11-15 15:33:39 DEBUG XMLTooling.libcurl [1] [default]: TCP_NODELAY set

 

2019-11-15 15:33:44 DEBUG XMLTooling.libcurl [1] [default]: After 4976ms connect time, move on!

 

2019-11-15 15:33:44 DEBUG XMLTooling.libcurl [1] [default]: connect to 13.225.146.95 port 443 failed: Timed out

 

2019-11-15 15:33:44 DEBUG XMLTooling.libcurl [1] [default]:   Trying 13.225.146.99...

 

2019-11-15 15:33:44 DEBUG XMLTooling.libcurl [1] [default]: TCP_NODELAY set

 

2019-11-15 15:33:46 DEBUG XMLTooling.libcurl [1] [default]: After 2484ms connect time, move on!

 

2019-11-15 15:33:46 DEBUG XMLTooling.libcurl [1] [default]: connect to 13.225.146.99 port 443 failed: Timed out

 

2019-11-15 15:33:46 DEBUG XMLTooling.libcurl [1] [default]:   Trying 13.225.146.72...

 

2019-11-15 15:33:46 DEBUG XMLTooling.libcurl [1] [default]: TCP_NODELAY set

 

2019-11-15 15:33:47 DEBUG XMLTooling.libcurl [1] [default]: After 1242ms connect time, move on!

 

2019-11-15 15:33:47 DEBUG XMLTooling.libcurl [1] [default]: connect to 13.225.146.72 port 443 failed: Timed out

 

2019-11-15 15:33:47 DEBUG XMLTooling.libcurl [1] [default]:   Trying 13.225.146.61...

 

2019-11-15 15:33:47 DEBUG XMLTooling.libcurl [1] [default]: TCP_NODELAY set

 

2019-11-15 15:33:48 DEBUG XMLTooling.libcurl [1] [default]: After 617ms connect time, move on!

 

2019-11-15 15:33:48 DEBUG XMLTooling.libcurl [1] [default]: connect to 13.225.146.61 port 443 failed: Timed out

 

2019-11-15 15:33:48 DEBUG XMLTooling.libcurl [1] [default]: Failed to connect to mdq.incommon.org port 443: Timed out

 

2019-11-15 15:33:48 DEBUG XMLTooling.libcurl [1] [default]: Closing connection 0

 

2019-11-15 15:33:48 ERROR OpenSAML.MetadataProvider.Dynamic [1] [default]: error while resolving (urn:mace:incommon:ucop.edu): CURLSOAPTransport failed while contacting SOAP endpoint (https://mdq.incommon.org/entities/urn%3Amace%3Aincommon%3Aucop.edu): Failed to connect to mdq.incommon.org port 443: Timed out

 

Thanks,

Krishna


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Transport option not being respected by MDQ metadata provider.

Rod Widdowson
> Did we miss something or is there a bug?

The documentation [1] doesn't specify <TransportOptions> as a valid child for the DynamicMetadataProvider, just for the XML
MetadataProvider and the code confirms this.

I'd defer to others but it looks from the code like it would be possible, but incredibly ugly, to wire the configuration in.

[1] https://wiki.shibboleth.net/confluence/display/SP3/DynamicMetadataProvider



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Transport option not being respected by MDQ metadata provider.

Cantor, Scott E.
On 11/16/19, 6:25 AM, "users on behalf of Rod Widdowson" <[hidden email] on behalf of [hidden email]> wrote:

> The documentation [1] doesn't specify <TransportOptions> as a valid child for the DynamicMetadataProvider, just for
> the XML MetadataProvider and the code confirms this.

I believe that code uses the same HTTP code as the SOAP client, that's influenced by the top level TransportOption elements placed inside the root SPConfig element, but it's been a while and I wouldn't trust my memory other than to say it doesn't hurt anything to try it.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Transport option not being respected by MDQ metadata provider.

Krishna Mohan
Thank you Scott. Appears to work when TransportOption elements is placed inside the root SPConfig element just before closing the SPConfig.

~Krishna

-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Saturday, November 16, 2019 7:26 PM
To: Shib Users <[hidden email]>
Subject: Re: Transport option not being respected by MDQ metadata provider.

On 11/16/19, 6:25 AM, "users on behalf of Rod Widdowson" <[hidden email] on behalf of [hidden email]> wrote:

> The documentation [1] doesn't specify <TransportOptions> as a valid
> child for the DynamicMetadataProvider, just for the XML MetadataProvider and the code confirms this.

I believe that code uses the same HTTP code as the SOAP client, that's influenced by the top level TransportOption elements placed inside the root SPConfig element, but it's been a while and I wouldn't trust my memory other than to say it doesn't hurt anything to try it.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Transport option not being respected by MDQ metadata provider.

Cantor, Scott E.
On 11/18/19, 3:31 PM, "users on behalf of Krishna Mohan" <[hidden email] on behalf of [hidden email]> wrote:

> Thank you Scott. Appears to work when TransportOption elements is placed inside the root SPConfig element just
> before closing the SPConfig.

We'll update the documentation. I don't think it would be practical to support them inline because of how it all works, but it's worth a look.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]