Django REST Framework中的可配置SAML SSO身份验证

时间:2019-01-03 00:25:18

标签: django django-rest-framework single-sign-on saml-2.0 multi-tenant

寻找对Django REST Framework(DRF)中的用例的了解,并支持客户定义的身份验证方法:TokenAuthentication(默认情况下),SAML 2.0 SSO,OAuth2联合登录。该方法是针对每个客户帐户设置的。我知道我将为DRF中的所有用户启用SAML 2.0支持,但是我看不到如何让我们软件中的每个用户帐户都使用他们自己的Auth引擎,方法和设置。 DRF似乎想要一个全有或全无的配置。

我知道django-saml2-auth plugin和这个StackOverflow问题SAML SSO Authentication with 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似乎仍然缺少一种定义每个帐户的身份验证过程的方法。假设我通过Okta使用SAML2,您使用OneLogin,另一个人使用OAuth2提供程序,并且大多数客户使用默认的本机TokenAuthentication。我们都是同一DRF应用程序中的所有用户。但是我看不到一种基于帐户定义身份验证引擎的方法。

我知道有一种可能的暴力破解方法,它可以自定义要执行的登录操作以执行可能是非标准的登录操作,然后查询客户的配置,然后使用本机或联合身份提供程序。但是,我希望有更多的DRF精打细算的人知道其他启用该功能的策略。

我了解到存在鸡肉和鸡蛋综合症,除非您对提出请求的客户有所了解,否则您将不知道他们的配置是什么。对于启用SAML的企业客户,我们很可能需要支持其他登录URL。这样,您可以加载客户的配置。也许我们会做一些类似的事情来使用URL:www.myproduct / login / the_customer_company。作为Django REST框架的新手,我不清楚如何在Django settings.py或urls.py中连接不同的身份验证方法?默认的新用户配置将基于TokenAuthentication,但客户可以根据请求配置SAML并使用其他URL(包括公司名称)。希望我的问题很清楚。我看到了如何配置DRF以使用SAML SSO而不是TokenAuthentication,但是我想允许客户配置设置。

DRF和django-saml2-auth方法似乎是“全有或全无”,并为应用程序提供了单个身份验证提供程序映射。我很乐意为那个限制做错事!

1 个答案:

答案 0 :(得分:0)

要实现这一目标的一种选择是使用可以充当身份代理的身份提供者(IdP),例如Keycloak。通过这种配置,您的Django应用将通过单个IdP进行SAML身份验证。然后可以根据客户需求为其支持的任何上游SAML / OAuth身份提供程序配置IdP。

如何将用户吸引到正确的上游身份提供商,并仍然具有良好的用户体验,将有一些选择。最明显的两个方法是为每个用户组配置一个自定义URL,并在登录时将该URL重定向到正确的IdP登录页面。或者,您可能在Django站点上有一个登录页面,询问他们的登录名/电子邮件地址(无密码),当他们输入时,它会查找与该用户关联的IdP URL,然后将其发送到正确的位置。

虽然这不是解决该问题的Django模块/代码解决方案,但它简化了Django方面的身份验证,并将身份验证与专门设计用于进行身份验证的外部服务解耦,从而为应用程序提供了更大的灵活性(可能还有更多优势)安全)。