ShibRequestSetting entityIDSelf

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

ShibRequestSetting entityIDSelf

Takeshi NISHIMURA
If you want to configure entityIDSelf using ShibRequestSetting, it must apply to /Shibboleth.sso. That is,

<Location /secure>
     ShibRequestSetting entityIDSelf https://$hostname/shibboleth
</Location>

does NOT work as you would expect.

Best regards,
Takeshi
--
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: ShibRequestSetting entityIDSelf

Cantor, Scott E.
On 8/1/18, 5:50 AM, "users on behalf of Takeshi NISHIMURA" <[hidden email] on behalf of [hidden email]> wrote:

> does NOT work as you would expect.

I guess that depends on what you expect, but it's no different than configuring an override in that regard.

-- 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: ShibRequestSetting entityIDSelf

Takeshi NISHIMURA
I'd expect that an SP entityID in AuthnRequest changes based on the host the user accesses.

E.g.
Access -> entityID
https://sp1.example.org/secure/ -> https://sp1.example.org/shibboleth
https://sp2.example.org/secure/ -> https://sp2.example.org/shibboleth
etc.

NG pattern of configuration:
<Location /secure>
     ShibRequestSetting entityIDSelf https://$hostname/shibboleth
</Location>

OK:
<Location />
     ShibRequestSetting entityIDSelf https://$hostname/shibboleth
</Location>

OK:
<Location /Shibboleth.sso>
     ShibRequestSetting entityIDSelf https://$hostname/shibboleth
</Location>

And I cannot take ShibRequestSetting outside of <Location> because of this error:
> Syntax error on line ...
> ShibRequestSetting not allowed here

Best regards,
Takeshi

On 2018/08/01 21:21, Cantor, Scott wrote:
> On 8/1/18, 5:50 AM, "users on behalf of Takeshi NISHIMURA" <[hidden email] on behalf of [hidden email]> wrote:
>
>> does NOT work as you would expect.
>
> I guess that depends on what you expect, but it's no different than configuring an override in that regard.
>
> -- 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: ShibRequestSetting entityIDSelf

Peter Schober
* Takeshi NISHIMURA <[hidden email]> [2018-08-03 05:58]:
> And I cannot take ShibRequestSetting outside of <Location> because of this error:
> > Syntax error on line ...
> > ShibRequestSetting not allowed here

The context for each directive is documented, though:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig
TL;DR: In common deployments no directive is ever put into server or
vhost context.
-peter
--
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: ShibRequestSetting entityIDSelf

Takeshi NISHIMURA
Thanks! I can find the same in SP3:
https://wiki.shibboleth.net/confluence/display/SP3/Apache

Takeshi

On 2018/08/03 19:28, Peter Schober wrote:

> * Takeshi NISHIMURA <[hidden email]> [2018-08-03 05:58]:
>> And I cannot take ShibRequestSetting outside of <Location> because of this error:
>>> Syntax error on line ...
>>> ShibRequestSetting not allowed here
>
> The context for each directive is documented, though:
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig
> TL;DR: In common deployments no directive is ever put into server or
> vhost context.
> -peter
--
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: ShibRequestSetting entityIDSelf

Cantor, Scott E.
In reply to this post by Takeshi NISHIMURA
On 8/2/18, 11:58 PM, "users on behalf of Takeshi NISHIMURA" <[hidden email] on behalf of [hidden email]> wrote:

> I'd expect that an SP entityID in AuthnRequest changes based on the host the user accesses.

Yes, you can, but because it's *possible* to do those things on a path-based basis, the commands are content and not host level. I just wouldn't advise doing anything but <Location /> with that one, the same as I wouldn't with applicationId before.

-- 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: ShibRequestSetting entityIDSelf

Takeshi NISHIMURA
Thanks Scott.
I understand that entityIDSelf has the same restriction as applicationId, because the former is a special case of the latter.
I didn't think so deeply.

Thanks again,
Takeshi

> 2018/08/03 20:54, Cantor, Scott <[hidden email]> wrote:
>
> On 8/2/18, 11:58 PM, "users on behalf of Takeshi NISHIMURA" <[hidden email] on behalf of [hidden email]> wrote:
>
>> I'd expect that an SP entityID in AuthnRequest changes based on the host the user accesses.
>
> Yes, you can, but because it's *possible* to do those things on a path-based basis, the commands are content and not host level. I just wouldn't advise doing anything but <Location /> with that one, the same as I wouldn't with applicationId before.
>
> -- 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: ShibRequestSetting entityIDSelf

Cantor, Scott E.
On 8/4/18, 5:03 AM, "users on behalf of Takeshi NISHIMURA" <[hidden email] on behalf of [hidden email]> wrote:

> I understand that entityIDSelf has the same restriction as applicationId, because the former is a special case of the
> latter.
> I didn't think so deeply.

To be honest, I didn't either. I'm not sure that it would actually work to try and do this for a specific path alone, because of the handler problem. I think it would take some trickery/advanced stuff to make it work. It was definitely designed for vhosting.

The AssertionConsumerService would need to apply itself the same entityID when it's doing its work, and that would probably require something like a custom AssertionConsumerService element inside the <Sessions> element to advertise a different endpoint to receive the response.

It's like an ApplicationOverride but sort of "done by hand". I'm not sure that buys a whole heck of a lot, if anything that's probably harder than just doing an override to start with. I really didn't consider the implications of trying to do it, so I would agree with you that I think it warrants some documentation when I have a chance. It's a new feature so getting that documented hasn't been a priority.

-- 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]