Поскольку SAML и OpendID Connect (OIDC) представляют собой принципиально разные методы обработки аутентификации / единого входа, могут ли они работать бок о бок в одном приложении?
Протокол они разные. Но они служат той же цели, выполняя аутентификацию и авторизацию. Когда вы говорите приложение, мы обычно думаем о приложении конечного пользователя. Например, веб-приложение, автономное настольное приложение или мобильное приложение. В таком приложении я не вижу необходимости поддерживать несколько протоколов. С точки зрения реализации и ремонтопригодности такое приложение легко поддерживает один протокол authN и authZ.
Но если вы думаете о серверной части, особенно о ваших API-интерфейсах, предоставляющих данные и службы, вам придется поддерживать несколько протоколов authN и authZ. Например, ваш сервис может использоваться приложениями, использующими SAML, и некоторыми приложениями, использующими OpenID Connect. Таким образом, эти приложения будут поставляться либо с утверждениями SAML, либо с токенами OpenID Connect, которые вам необходимо будет проверить. В данном случае это не миграция, а добавление поддержки нескольких методов authN и authZ.
Сказал, что обычно поставщики удостоверений поддерживают несколько протоколов. Например, Azure AD поддерживает SAML 2.0 и OpenID Connect. Поэтому, когда ваше приложение поступает к вашим внутренним API / службам, запросы могут поступать либо с SAML, либо с OpenID Connect. Вам нужно будет выполнить идеальные проверки с помощью слоя фильтрации для обнаружения, проверки и проверки запросов.
Основные поставщики средств управления идентификаторами, такие как Okta, имеют множество документов о том, как внедрить SAML или OIDC, но я не смог найти никого или каких-либо документов, в которых упоминалось бы, какой уровень усилий требуется при переходе с одного на другой. Кто-нибудь это сделал? Что было задействовано?
При разработке приложений полезно изолировать вещи, связанные с authN и authZ, от основной логики. Таким образом, вы получите возможность легко изменить метод / протокол. В конце концов, вы хотите определить конечного пользователя, который использует приложение, и получить определенные для него разрешения. Так что изменить протокол, чтобы оживить идентификацию, не так уж и сложно. Но имейте в виду, что будет некоторая работа, например, проверка токена OpenID Connect, обработка истечения срока действия токена и тому подобное. Используйте библиотеки, чтобы упростить жизнь
Для новых приложений рекомендуется перейти на OpenID Connect. Но вам может быть сложно перенести все свои приложения (в зависимости от их сложности). Так что поддержка обоих в серверной части идеальна. Кроме того, старайтесь всегда сохранять и получать данные удостоверения от поставщика удостоверений. Таким образом, изменить протокол будет легко, поскольку они (поставщики удостоверений) поддерживают несколько протоколов.
person
Kavindu Dodanduwa
schedule
08.02.2018
