No Peer Endpoint...

[Dominic Forrest]

Thankyou.  I think I'll go back to basics on this and start agin on CentOS….   I appreciate your help but fear I may have some future questions…


Dom


On 5 Apr 2013, at 14:51, Peter Schober <peter.schober at univie.ac.at> wrote:

> I don't have an explanation yet. The snipplets you've sent so far seem
> to be OK. The IdP seems to load the SP's metadata and vice versa. The
> metadata for the SP looks fine.
> So something in your deployment is off.
> 
> Note that you're running on an unsupported (by the Shibboleth project)
> platform and did not follow the locally installed documentation.
> I'm pretty sure Ubuntu (taking it from Debian) mentions to run the
> shib-keygen command after installation, in which case your SP's
> metadata would have also contained its public key. Jfyi.
> 
> * Dominic Forrest <dom.forrest at gmail.com> [2013-04-05 15:22]:
>>        <metadata:MetadataProvider id="URLMD" xsi:type="metadata:FileBackedHTTPMetadataProvider"
>>                          metadataURL="https://sp.zzz.com/Shibboleth.sso/Metadata"
>>                          backingFile="/opt/shibboleth-idp/metadata/some-metadata.xml">
>>            <metadata:MetadataFilter xsi:type="metadata:ChainingFilter">
>>                    <metadata:MetadataFilter xsi:type="metadata:EntityRoleWhiteList">
>>                    <metadata:RetainedRole>samlmd:SPSSODescriptor</metadata:RetainedRole>
>>                </metadata:MetadataFilter>
>>            </metadata:MetadataFilter>
>>        </metadata:MetadataProvider>
> 
> Jfyi, the metadata generated from the SP will never contain anything
> else but an SPSSODescriptor, so you can remove the filter (and the
> surrounding chaining filter as it would be empty then).
> 
> Maybe the IdP is not yet actually using the changed relying-partyx.xml
> config (requires a restart of the context or container) -- is the
> backingFile specified above being generated properly?
> 
>> <!--
>> This is example metadata only. Do *NOT* supply it as is without review,
>> and do *NOT* provide it in real time to your partners.
>> -->
> 
> Yes, so much for that.
> 
> Note that your IdP logged:
> 
>  No return endpoint available for relying party https://sp.zzz.com
> 
> but your SP config had:
> 
>  entityID="https://sp.xxx.com"
> 
> I suppose that's just because you don't want to use RFC 2606 host
> names in emails and you messed up the pseudonymization in your
> examples. (The SP's metadata also had zzz.)
> 
>> What I do not understand is how this is being generated by the SP
>> however t appears I would be better saving this locally on the IDP
>> and (with help) editing as appropriate?
> 
> Not your issue currently and will only come up later. I thought there
> was a wiki page for that (which then should be linked from that XML
> comment) but can't fint it atm.
> Ignore that for now, or search the list archives.
> -peter
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net