ContentSetting discoveryURL

[Cantor, Scott]

> My use case is not protect a certain location, but just use shibboleth for
> authentication. The rest of the site is handled by WSGI/Django (and static files).
> Sorry, I should have included this in my description.

I don't know how you're initiating the sessions. If all the session initiation leading to discovery were happening by way of manual redirect to /Login, then the discoveryURL applied to just the handler would work. So I have to assume that's not what you're doing, and the requests are made to other URLs that do not have the same settings applied and the session is being initiated with an active rule triggering discovery at that point.

> When calling /Shibboleth.sso/Login I get the correct entityID. The entityID in
> the generated metadata is correct, too. Where would the entityID be not
> correct? What would be the correct approach for my use case then?

They have to be mutually correct or incorrect, they come from the same place.

> Testwise I applied protection for the entire vhost and then the discoveryURL
> was indeed correct with one exception: When I directly called
> /Shibboleth.sso/Login I got the discoveryURL defined in shibboleth2.xml.

Member support is the only way I can dig into issues like that. I can take a bug report and quickly counter any claims that something's not working as intended, but apart from doing that and closing it out as invalid, it probably won't help much. But it's always possible there's a bug.

Apache is tricky with settings and you probably have something overriding or conflicting in some way that's not obvious.

-- Scott