RemoteUserInternal

n614cd at gmail.com n614cd at gmail.com
Thu Jun 27 16:14:39 UTC 2024


Reason for only exposing the Unsolicited URL is, this is going to be setup to help a number of legacy application migrate over time to a full SSO solution; and not have it part of the core IdP infratsurcture.

The reason I picked the RemoteUserInternal was to reduce browser bounce. Since I know the path of the users entering the system.

That was it. Thanks.

Tim

-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Thursday, June 27, 2024 11:26 AM
To: n614cd at gmail.com; 'Shib Users' <users at shibboleth.net>
Subject: Re: RemoteUserInternal

> I will only have one exposed URI Context which would be the'
> IdP Initiated SSO, passing in the REMOTE_USER header (I can provide 
> the details of how this protected if curious).

RemoteUser is almost always what you want, and that requires protecting the servlet URL and not the whole IdP, but if you really want every request to the IdP to be authenticated up front, you can do it that way.

The internal variants are basically for non-browser ECP support.

> I went back through the documentation; and I think I am missing 
> something basic.

You're missing that you imported some piece of metadata from a vendor that has AuthnRequestsSigned set to true, which is incompatible with a flow involving no AuthnRequest to begin with. I added a sentence to the docs about it, I had thought it was already noted.

-- Scott








More information about the users mailing list