Remote SP Server

[Rick Hoodenpyle]

Thank you Scott! I kind of figured this out, but wanted to check.
Basically, I have about 60 customers on AWS servers and am trying to make
it easier to deploy these servers from an AMI. About 25 of them have
Shibboleth SP setup on them so I was trying to find a way that I could have
no need to have the Shibboleth SP directly on the servers. As it is now, I
would have to have 2 AMIs with one of them having Shibboleth SP installed
and then I would have to copy files the IdP Metadata, Shibboleth2.xml,
attribute-map.xml and the .pem files, restart the Shibboleth Service, and
perform an IISRESET to recovery from a disaster. The software that I am
working with is coded for Shibboleth SP so I have to use Shibboleth as the
middle man. I love Shibboleth SP and have had very few issues getting it
setup, but trying to make my life easier for the future. :-)

Thanks again,

Rick Hoodenpyle



On Wed, Aug 30, 2023 at 6:32 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> > Is it possible to have the Shibboleth SP on a different server than the
> > Windows IIS server? Or does the Service have to be run on the IIS
> Server? If
> > it is possible, does anyone have instructions on how you would set this
> up?
>
> That depends on what you mean. Taken literally, no, because that's
> physically impossible with any authentication solution.
>
> https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334319/OneOrMany
>
> Less pedantically/literally, it is possible but unsupported and very
> non-scalable to deploy the daemon service elsewhere and run only the filter
> on the IIS host. The documentation covers that in the Listener settings but
> it is not advisable, and also requires a private network netween the two
> because the traffic is cleartext.
>
> If there is a V4 with the daemon in Java, which is subject to budget
> planning outcomes right now, it will be a formally supported and scalable
> option to do that split, though the traffic will still be cleartext because
> securing it would require dependencies that we are not going to layer the
> code on to prevent a future SP from being as unsustainable as the current
> one has become.
>
> Most of the time people are trying to do this to solve clustering
> challenges, but that's not necessary, there are generally better ways to
> address that problem, though no magic bullets as clustering is and will
> always be hard and painful.
>
> -- Scott
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230830/eb81dad6/attachment.htm>