Использование ApplicationOverride в Shibboleth SP вызывает вторичное приложение в качестве отдельной службы, т.е. вы установили, что этот entityID уникален. В случае вторичного API я бы не стал защищать его с помощью Shibboleth, то есть зачем защищать его с помощью Shibboleth SP (который создан для обеспечения аутентификации на основе IdP), если вы делаете вызовы RESTful с сайта, который уже аутентифицирован,Я думаю, вам нужно переосмыслить рабочий процесс аутентификации ... более разумная идея:
(1) Получить сеанс для site.com из IdP с использованием SAML / Shibboleth,
(2) Создайте сеанс приложения на основе сеанса SP (просмотрите сеансы в потоке SAML, на самом деле их несколько, а не только сеанс SP). Не говоря уже о том, что Shibboleth создан для Аутентификации, а не Авторизации.
(3) Выполните вызов API REST на основе любого механизма безопасности API, который вы хотите ... т.е. вы можете построить JWT на основе данных утверждения SAMLи убедитесь, что он действителен в конечной точке API, потому что вы знаете сертификаты.
Веб-поток SAML на самом деле не создан для API, как вы пытаетесь использовать его здесь ... 302, который вы пытаетесьчтобы избавиться от этого, это должно быть в рабочем процессе SAML.