Переход с GitHub Enterprise SAML на GitHub Organization SAML

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

Вопрос или проблема

Я пытаюсь перенести нас от настройки интеграции нашего IdP (MS Entra) на уровне предприятия к управлению им на уровне отдельной организации.

Мы используем личные аккаунты GitHub, а не управляемых пользователей, поэтому процесс должен быть простым; снять галочку require saml на экране предприятия, установить галочку require saml для каждой организации и обновить их настройки SAML в соответствии с соответствующими приложениями Entra, затем попросить всех пользователей снова войти в систему и включить SSO Auth для их PAT токенов и SSH ключей.

Однако, давно мы использовали Okta в качестве нашего IdP, и это было настроено на уровне организации. Кажется, когда мы перешли на Entra (на уровне предприятия), конфигурация организации не была удалена – просто переопределена; поэтому теперь, когда мы убираем SAML на уровне предприятия, вместо того чтобы убрать необходимость в IdP и просто позволить мне зайти как владельцу, организация возвращается к своим (более не действительным) настройкам Okta и, следовательно, не позволяет мне войти, так как перенаправляет меня на несуществующий URI авторизации.

Восстанавливая настройки SAML предприятия, я могу снова войти, но нахожусь в безвыходной ситуации, где я не могу обновить настройки SAML организации, пока SAML настроен для предприятия, но я не могу зайти в организацию, чтобы изменить ее настройки без SAML предприятия.

Claude.ai предложил выполнить gh api -X DELETE /orgs/<MyOrg>/saml/provider, пока SAML все еще включен на уровне предприятия, но это вернуло:

{
  "message": "Not Found",
  "documentation_url": "https://docs.github.com/rest",
  "status": "404"
}

Выполнив gh api /orgs/<myOrg>, я получил ожидаемый JSON, что подтвердило успешную аутентификацию.

Выполнив:

gh api graphql -f query='
 query($org: String!) {
   organization(login: $org) {
     samlIdentityProvider {
       id
     }
   }
 }' -f org="<myOrg>"

Получил:

{
  "data": {
    "organization": {
      "samlIdentityProvider": null
    }
  },
  "errors": [
    {
      "type": "FORBIDDEN",
      "path": [
        "organization",
        "samlIdentityProvider"
      ],
      "locations": [
        {
          "line": 4,
          "column": 5
        }
      ],
      "message": "The Organization's SAML identity provider is disabled when an Enterprise SAML identity provider is available."
    }
  ]
}
gh: The Organization's SAML identity provider is disabled when an Enterprise SAML identity provider is available.

… Это подразумевает, что причиной 404 может быть та же причина, по которой я не могу обновить это через сайт; т.е. пока SAML на уровне предприятия включен, Org SAML как будто не существует.

Любые советы по выходу из этой безвыходной ситуации будут очень полезны.

Ответ или решение

Переход с GitHub Enterprise SAML на GitHub Organization SAML может представлять собой довольно сложную задачу, особенно в вашем случае, когда использовались два различных поставщика удостоверений (IdP). Вы описали ситуацию, в которой сталкиваетесь с проблемой, заключающейся в конфликте между этими конфигурациями, что делает невозможным доступ к организации без конфигурации Enterprise SAML. Разобраться в этой дилемме поможет более подробное рассмотрение технологии, примеров и возможных применений.

Теория

Для начала, важно понимать разницу между уровнями SAML в GitHub. Настройки SAML на уровне Enterprise предоставляют единую точку аутентификации для всех организаций в данном корпоративном наборе, тогда как SAML на уровне Organizations позволяет каждому подразделению настраивать аутентификацию IDP индивидуально для своих нужд. Обычно, на таком уровне используется Enterprise SAML, чтобы средствовать централизованному управлению пользователями и упрощению процессов аутентификации в больших корпоративных структурах.

Когда вы переключаетесь с Enterprise SAML на Organization SAML, изменения в настройках аутентификации должны быть выполнены последовательно и продуманно. Однако в случаях, как ваш, где исторически использовались разные IdP, могут возникать проблемы, связанные с некорректной переадресацией или устаревшими конфигурациями, которые конфликтуют с новыми настройками.

Пример

Ваш конкретный случай — это классический пример проблемы переписки конфигурации. Okta, будучи вашим ранним IdP на уровне Organization, вероятно, оставила некоторые следы своих настроек даже после перехода на Entra на уровне Enterprise. Это привело к тому, что при отключении Enterprise SAML, система пытается использовать старые настройки Okta, которые уже не действительны, что и препятствует доступу к организации.

Вы пробовали удалить настройки SAML через API GitHub, но получили ответ "Not Found", что, скорее всего, связано с тем, что настройки для организации в контексте обмена SAML неактивны, пока настроена SAML для системы Enterprise.

Применение

Для решения вашего вопроса, необходимо предпринять несколько шагов и изысканий:

Проверка текущих конфигураций IdP: Убедитесь, что в вашей системе вы действительно используете только Entra и что все старые приложения Okta деактивированы или удалены.
Последовательность переключения: Попробуйте вернуть Enterprise SAML обратно и затем переходите на Org SAML, временно обеспечив возможность конфигурации Organization SAML перед отключением Enterprise SAML. Возможно, потребуется временная пауза в обеспечении SSO, чтобы получить доступ к настройкам.
Консультация с поддержкой GitHub: Ваш случай может потребовать более глубокой интеграции службы поддержки, чтобы очистить устаревшие конфигурации. GitHub может иметь внутренние инструменты или процессы, чтобы очистить подобные конфликты.
Делегирование прав: Возможно создание временного пользователя с прямым доступом к организации через обычную аутентификацию до полная реализации SSO, чтобы предусмотреть связь с IdP и гибкость его изменения.
Обновление документации: Обновите внутреннюю документацию по управлению IdP и SSO на случай будущих изменений или переключений, чтобы процессы могли быть повторены без сбоев.

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