application override but wrong entityID in <Issuer> in the request

Scott Koranda skoranda at gmail.com
Fri May 31 14:38:00 EDT 2013


On Fri, May 31, 2013 at 1:11 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> My Apache configuration includes
>>
>> <Directory /var/www/registry/auth/login>
>>   AuthType shibboleth
>>   ShibRequestSetting applicationId registryApplication
>>   require valid-user
>> </Directory>
>
> That's ok, but won't be sufficient. A different handlerURL will have to be configured and mapped to the application, and since that's a virtual resource, you have to use Location to do it in general.

Got it. Thanks.

For the record I have edited shibboleth2.xml and copied the <Sessions>
element from the default into the <ApplicationOverride> and then added
the new handlerURL.

I then edited the Apache config and did in the <VirtualHost>

<Location /Shibboleth.sso>
  SetHandler shib
  ShibRequestSetting applicationId registryApplication
</Location>

Please let me know if that was not correct (though it has had the
effect I wanted).

>
>> I would have expected the <Issuer> to be the entityID that is
>> prescribed in the <ApplicationOverride>.
>
> How is the session actually being initiated? There's no requireSession setting in your example, so that would lead me to guess you might be using a manual redirect to /Shibboleth.sso/Login, which would put the blame back on the need for a dedicated, and non-default mapped, handlerURL.

It is in flux, frankly, as part of an alpha development and deployment effort.

>
> All that said, you *may* be able to avoid the hassle of an override, depending on the use case. If you need to override the entityID used when communicating with a specific IdP, or a set of IdPs that you can identify by means of a supported matching feature (basically either EntitiesDescriptor or ideally EntityAttribute extension/tag), you can do that with the RelyingParty element.
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRelyingParty
>

Interesting. I will keep that in mind for the future.

Thanks,

Scott K


More information about the users mailing list