Использование --sso и -u / -p не выполняет одно и то же в бэкэнде, и нет гарантии, что пользователь, который может войти в систему через SSO, также настроен для входа в систему как пользователь, хранящийся непосредственно в UAA , UAA имеет несколько источников, из которых могут быть загружены пользователи, такие как SAML, LDAP и внутренние в UAA. Когда вы используете флаг --sso, вы обычно входите через пользователя от поставщика SAML вашей компании. Когда вы используете флаги -u / -p, это, как правило, LDAP или UAA, что-то, что UAA проверяет напрямую.
Для того, чтобы то, что вы пытаетесь сделать, работало, вам нужно иметь доступного пользователя. с происхождением в SAML (для --sso) и пользователем в происхождении LDAP или UAA (внутренним), и технически это будут два отдельных пользователя (несмотря на то, что они могут иметь одинаковые учетные данные).
В любом случае, если вы обычно входите в систему с флагом --sso и хотите автоматизировать работу, вам действительно нужно получить клиента UAA, для которого установлен тип предоставления учетных данных клиента. Затем вы можете использовать cf auth CLIENT_ID CLIENT_SECRET --client-credentials для автоматизации входа в систему.
Как правило, вы не хотите, чтобы ваша учетная запись пользователя в любом случае была привязана к конвейерам и автоматизированным сценариям. Если вы покидаете компанию, и ваш пользователь деактивируется, то все ломается :) Вы хотите служебную учетную запись, и это в основном клиент, которому разрешен тип предоставления учетных данных клиента в UAA.
Надеюсь, это поможет!