Ищем пример использования в Django REST Framework (DRF) и поддерживаемый пользователем метод аутентификации: TokenAuthentication (по умолчанию), SAML 2.0 SSO, федеративный вход OAuth2. Метод устанавливается для каждой учетной записи клиента. Я знаю, что включил бы поддержку SAML 2.0 для всех пользователей в DRF, но я не понимаю, как заставить каждую учетную запись пользователя в нашем программном обеспечении использовать свой собственный механизм аутентификации, метод и настройки. DRF, кажется, хочет, чтобы все или ничего конфигурации.
Мне известны оба плагина django-saml2-auth и этот вопрос StackOverflow Аутентификация SSL SAML с помощью Django REST Framework
django-saml2-auth - отличный плагин, который, вероятно, участвует в решении, но я не вижу примеров того, как использовать несколько разных методов аутентификации для каждой учетной записи в вашем приложении.
Подробнее:
Я хочу разрешить для каждого клиента метод поддержки настроек учетной записи, позволяющий выбрать один из нескольких методов аутентификации, например TokenAuthentication (по умолчанию) или SSO, и предоставляющий параметр SAML 2.0 или Oauth2. Каждая учетная запись может выбрать из включенных методов. DRF, кажется, ожидает, что один поставщик аутентификации будет включен. Пока не доходит, как это сделать в этих рамках. В настоящее время используется TokenAuthentication в качестве системы аутентификации по умолчанию. TokenAuthentication останется поставщиком по умолчанию для большинства учетных записей. Мне нужно иметь возможность позволить более искушенным корпоративным клиентам менять методологию аутентификации. Это проблема. Добавить SAML2 просто. Использовать OAuth2 просто. Разрешить любому из них быть выбранными учетными записями, при этом каждая учетная запись имеет свой собственный рабочий процесс аутентификации. Это совсем другое требование, чем в случае использования, который решает django-saml2-auth. Этот плагин может быть включен в решение, но здесь, похоже, ограничением является модель, которую DRF использует для определения поставщика аутентификации. Я отсканировал документы DRF и django-saml2-auth, код и примеры. Ничто из того, что я видел, не предвидит этого.
Моя текущая рабочая теория состоит в том, что я мог бы сделать это с небольшим творческим размышлением. Возможно, существует другое сопоставление URL, в котором используется другой метод входа в систему / аутентификации. Зарегистрированный токен данных, который должен быть предоставлен в последующих вызовах, может иметь собственный метод проверки, который работает со всеми поддерживаемыми протоколами без больших новых блоков кода. Таким образом, мой инстинкт заключается в том, что проблема заключается в сопоставлении процесса входа в систему с чем-то, что не является универсальным и требует некоторого предварительного выбора конфигурации учетной записи. Мое предлагаемое решение есть в URL-адресе входа для корпоративных случаев. Но в DRF, похоже, все еще отсутствует метод определения процесса аутентификации для каждой учетной записи. Скажем, я использую SAML2 через Okta, Вы используете OneLogin, Другой человек использует провайдера OAuth2, и большинство клиентов используют собственную TokenAuthentication по умолчанию. Мы все пользователи в одном приложении DRF. Но я не вижу способа определить механизм аутентификации на основе учетной записи.
Я знаю, что возможен грубый метод настройки метода, вызываемого для выполнения действия входа в систему, которое может быть нестандартным, запроса конфигурации для клиента, а затем использования нативного или федеративного поставщика удостоверений. Тем не менее, я надеюсь, что есть больше гроккингов DRF, которые знают о других стратегиях для включения этой функции.
Я понимаю, что в этом есть синдром курицы и яйца, пока вы не узнаете что-то о клиенте, делающем запрос, вы не узнаете, какова его конфигурация. Скорее всего, нам потребуется поддержка другого URL-адреса входа для корпоративных клиентов, которые включают SAML. Таким образом, вы можете загрузить конфигурацию клиента. Возможно, мы бы использовали что-то вроде использования URL-адреса примерно так: www.myproduct / login / the_customer_company. Будучи новичком в Django REST Framework, я не очень ясно, как подключить различные методы аутентификации в Django settings.py или urls.py? Конфигурация нового пользователя по умолчанию останется на основе TokenAuthentication, но по запросу клиент может настроить SAML и использовать другой URL-адрес, включая название компании. Надеюсь, мой вопрос понятен. Я вижу, как настроить DRF для использования единого входа SAML вместо TokenAuthentication, но я хочу разрешить настраиваемые пользователем параметры.
Подходы DRF и django-saml2-auth, по-видимому, "все или ничего" и обеспечивают отображение одного поставщика аутентификации для приложения. Я бы хотел ошибиться с этим ограничением!