What does "federated SAML" actually mean?

Federated SAML refers to the trust relationship established between an identity provider (IdP) and a service provider (SP) so a user can authenticate once at the IdP and have that assertion accepted by the SP. The federation is the signed XML contract: each side trusts the other's metadata and signing certificate. SecureCodingHub becomes part of your federation once you upload the IdP metadata and the IdP knows the SP entity ID.

How do I rotate a SAML certificate without breaking logins?

A SAML certificate rotation is best executed with a brief overlap window. If your IdP supports publishing multiple signing certificates in metadata, add the new certificate before retiring the old one, and have SecureCodingHub re-fetch the IdP metadata so both certificates are trusted during the cutover. After the IdP starts signing with the new key, monitor logins for a day, then remove the old certificate from the metadata. The most common production outage is rotating without overlap, on a Friday.

SAML vs OAuth vs OpenID Connect — which one do I pick?

When teams compare SAML vs OAuth vs OpenID Connect, the practical answer is to follow operational fit. SAML 2.0 is the mature, XML-based federation standard, dominant in enterprise IdPs like ADFS and PingFederate. OAuth 2.0 alone is an authorization framework, not authentication. OpenID Connect layers identity on top of OAuth 2.0 and is the modern default for Azure AD and Okta. Either SAML or OIDC will give you equivalent SSO security with SecureCodingHub.

How do I decode a SAML response to troubleshoot a failure?

To decode a SAML response, capture the base64-encoded SAMLResponse parameter that the IdP posts to the ACS URL — a SAML tracer browser extension is the easiest way to grab it. Base64-decode the value to raw XML and inspect the Issuer, Audience, NameID, and timestamps. Most failures resolve once you compare those four fields against the values configured in the SecureCodingHub SSO settings and your IdP's application configuration.

Настройка SAML 2.0

Настройте единый вход с использованием SAML 2.0 для поставщиков идентификации, поддерживающих протокол SAML. Это руководство охватывает общую настройку SAML, применимую к любому совместимому IdP.

Предварительные условия

SAML 2.0 совместимый поставщик идентификации (Okta, Azure AD, OneLogin, PingFederate и т.д.)
Admin-доступ к Вашему поставщику идентификации для создания и настройки приложений
Учётная запись Администратора организации SecureCodingHub

Детали поставщика услуг

Эти значения нужны при настройке SecureCodingHub в Вашем поставщике идентификации:

Настройка	Значение
SP Entity ID	`https://api.limeplate.com`
ACS URL (Assertion Consumer Service)	`https://api.limeplate.com/api/sch/auth/sso/callback/saml`
SP Metadata URL	`https://api.limeplate.com/api/sch/auth/sso/metadata`
Формат Name ID	`urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`
Binding	`HTTP-POST`

Шаг 1 — Настройте Вашего поставщика идентификации

Создайте новое SAML-приложение

В admin-консоли Вашего поставщика идентификации создайте новое приложение SAML 2.0 для SecureCodingHub.

Установите ACS URL и Entity ID

Скопируйте ACS URL и SP Entity ID из таблицы Деталей поставщика услуг выше в конфигурацию приложения Вашего IdP.

Настройте сопоставление атрибутов

Сопоставьте обязательный атрибут email как NameID. Опционально сопоставьте атрибуты firstName и lastName для автоматического заполнения профиля.

Скачайте или скопируйте URL метаданных IdP

Вам понадобится URL метаданных Вашего IdP (или подписывающий сертификат) на следующем шаге при настройке SecureCodingHub.

Шаг 2 — Настройте SAML в SecureCodingHub

Откройте Настройки SSO

Войдите как Администратор организации и перейдите в Настройки SSO из боковой панели.

Выберите протокол SAML

Выберите SAML как SSO-протокол из выпадающего списка.

Введите URL метаданных IdP

Вставьте URL метаданных Вашего поставщика идентификации. Это позволяет SecureCodingHub автоматически обнаруживать эндпоинты и сертификаты.

Добавьте подписывающий сертификат (опционально)

Если Ваш IdP не выставляет URL метаданных, вставьте подписывающий сертификат IdP напрямую.

Включите SSO и сохраните

Переключите SSO в положение «включено» и нажмите Сохранить для активации SAML-аутентификации для Вашей организации.

app.securecodinghub.com/organization/sso

Протокол

OIDC

OpenID Connect — рекомендуется

SAML

Федерация SAML 2.0

SP entity ID — вставьте это в Ваш IdP

https://api.limeplate.com/api/sch/auth/sso/saml/{orgId}

URL метаданных IdP

https://idp.example.com/app/saml2/sso/metadata

Подписывающий сертификат X.509

-----BEGIN CERTIFICATE----- MIICmzCCAYMCBgF8... ... -----END CERTIFICATE-----

SSO включён

Шаг 3 — Протестируйте

Откройте окно incognito

Используйте private/incognito окно браузера, чтобы избежать конфликтов сессий с Вашей admin-учётной записью.

Перейдите на страницу входа SSO

Перейдите на app.securecodinghub.com и нажмите Войти с SSO.

Введите Ваш корпоративный email

Система обнаружит конфигурацию SSO Вашей организации и перенаправит Вас к Вашему IdP.

Аутентифицируйтесь в Вашем IdP

Завершите поток входа у Вашего поставщика идентификации. Вы должны быть перенаправлены обратно в SecureCodingHub и автоматически вошедшим.

Сопоставление атрибутов

SecureCodingHub читает следующие атрибуты из SAML-утверждения:

SAML-атрибут	Поле SecureCodingHub	Обязательное
`NameID` (формат email)	Email	Да
`givenName` (`…/claims/givenname`)	Имя (первая часть — конкатенируется с фамилией в единое отображаемое имя)	Нет
`surname` (`…/claims/surname`)	Имя (вторая часть — соединяется с givenName во время провижининга)	Нет

Истечение сертификата: SAML-сертификаты истекают. Установите напоминание в календаре, чтобы ротировать Ваш сертификат до истечения и избежать перебоев входа.

Чтение SAML-ответа в реальной жизни

Когда SAML отказывает, самый быстрый путь к диагнозу — это инспектировать фактический SAML-ответ, а не симптом в браузере. Установите расширение браузера SAML tracer, воспроизведите неудачный вход и посмотрите на POST, который IdP отправляет на ACS URL. Три поля говорят Вам почти всё. Элемент Issuer должен соответствовать entityID, опубликованному в Ваших метаданных IdP. Элемент Audience, вложенный внутри Conditions, должен соответствовать SP Entity ID, настроенному в SecureCodingHub. Subject NameID должен быть email-адресом пользователя в указанном Вами формате.

Помимо этих полей, проверьте идентификатор InResponseTo, если Ваш IdP его поддерживает, подтвердите, что ответ подписан (элемент ds:Signature присутствует), и проверьте, что временные метки NotBefore и NotOnOrAfter согласуются с текущими часами. Значительная разница часов между IdP и SP вызывает тихий отказ от иначе валидных утверждений. Если ответ выглядит правильно сформированным, но утверждение всё ещё отклоняется, скопируйте base64-кодированное значение SAMLResponse из tracer и декодируйте его офлайн. Чтение сырого XML против спецификации SAML 2.0 — самый надёжный способ найти отсутствующий атрибут или неправильно настроенное утверждение.

Когда просить помощи у команды IdP vs команды SP

Большинство тикетов поддержки SAML можно отсортировать менее чем за минуту, если Вы знаете, на какой стороне федерации живёт ошибка. Как правило, несоответствия audience и issuer — это проблемы на стороне SP: конфигурация SecureCodingHub ожидает значения, которые IdP не производит, или она была настроена против другого SP entity ID, чем тот, под которым IdP подписывает. Они решаются регулировкой настроек SSO SecureCodingHub или SP Entity ID и ACS URL в конфигурации приложения IdP. Обратитесь к стороне SecureCodingHub в первую очередь.

Проблемы сопоставления claim и атрибутов обычно на стороне IdP. Если пользователи приземляются в SecureCodingHub с отсутствующими именами, неправильными email-адресами или неожиданными назначениями ролей, IdP эмитирует атрибуты, которые SP не может потребить. Admin IdP должен добавить или переименовать claims в конфигурации приложения. Сбои сертификатов и подписей разделены: если сертификат IdP истёк или был ротирован, это исправление на стороне IdP. Если SecureCodingHub перестал доверять ранее валидной подписи, метаданные или сертификат, хранимые на стороне SP, устарели и нуждаются в обновлении. Когда есть сомнения, захватите вывод SAML tracer и поделитесь им с обеими командами; сам ответ показывает, на чьей стороне следующий шаг. См. Обзор SSO для руководства по выбору протокола.

SAML 2.0: часто задаваемые вопросы

Что на самом деле означает «федеративный SAML»?

Федеративный SAML относится к доверительным отношениям, установленным между поставщиком идентификации (IdP) и поставщиком услуг (SP), так что пользователь может аутентифицироваться один раз в IdP и иметь это утверждение принятым SP. Федерация — это подписанный XML-контракт: каждая сторона доверяет метаданным и подписывающему сертификату другой. SecureCodingHub становится частью Вашей федерации, как только Вы загрузите метаданные IdP, а IdP узнает SP entity ID.

Как ротировать SAML-сертификат, не сломав входы?

Ротация SAML-сертификата лучше всего выполняется с коротким окном перекрытия. Если Ваш IdP поддерживает публикацию нескольких подписывающих сертификатов в метаданных, добавьте новый сертификат до удаления старого, и заставьте SecureCodingHub повторно получить метаданные IdP, чтобы оба сертификата были доверенными во время перехода. После того, как IdP начнёт подписывать новым ключом, мониторьте входы в течение дня, затем удалите старый сертификат из метаданных. Самый распространённый продакшен-отказ — ротация без перекрытия, в пятницу.

SAML vs OAuth vs OpenID Connect — какой выбрать?

Когда команды сравнивают SAML vs OAuth vs OpenID Connect, практический ответ — следовать операционной совместимости. SAML 2.0 — это зрелый XML-стандарт федерации, доминирующий в корпоративных IdP, таких как ADFS и PingFederate. OAuth 2.0 один — это фреймворк авторизации, а не аутентификация. OpenID Connect добавляет идентификацию поверх OAuth 2.0 и является современным выбором по умолчанию для Azure AD и Okta. И SAML, и OIDC дадут Вам эквивалентную безопасность SSO с SecureCodingHub.

Как декодировать SAML-ответ для устранения сбоя?

Чтобы декодировать SAML-ответ, захватите base64-кодированный параметр SAMLResponse, который IdP отправляет на ACS URL — расширение браузера SAML tracer — самый лёгкий способ его захватить. Base64-декодируйте значение в сырой XML и инспектируйте Issuer, Audience, NameID и временные метки. Большинство сбоев разрешаются, как только Вы сравните эти четыре поля со значениями, настроенными в настройках SSO SecureCodingHub и конфигурации приложения Вашего IdP.