Problem with SP configuration with ApplicationOverride

[Cantor, Scott]

On 12/12/13, 2:10 PM, "Paulo Rodrigues" <paulo.rodrigues at rnp.br> wrote:

>As far as I could grasp from the documentation, this seems to be the way
>to go:

Most of that is old pre-2.4 cruft that doesn't need to be there.

The override itself:

>    <ApplicationOverride id="app2"
>        entityID="https://host2.rnp.br" homeURL="https://host2.rnp.br"
>        REMOTE_USER="inetOrgPerson-mail uid eppn persistent-id
>targeted-id">
>        <CredentialResolver type="File"
>            key="/etc/certs/host2.rnp.br.key"
>certificate="/etc/certs/host2.rnp.br.crt"
>            keyName="host2.rnp.br" />
>    </ApplicationOverride>

Do you really need a second keypair? That's not ideal, though it does get
around one of the bugs in ADFS if that's a requirement.

>Now, this has been published successfully in the Federation - albeit
>/Shibboleth.sso/Metadata returns same entityId and ID attributes when
>requested from host1 and host2),

That means you have no override configured. So you haven't mapped the
second vhost to the alternate applicationId.

>but when I go to https://host2/login and authenticate in the IdP I
>receive the dreaded
>No peer endpoint available to which to send SAML response.

Because you don't actually have an override. Defining the override is only
half the job, you still have to map content to that id in Apache with
ShibRequestSetting applicationId app2

-- Scott