在搜索代码之前,请确保已阅读文档.http://docs.djangoproject.com/en/1.2/topics/auth/#other-authentication-sources个
还要阅读提供的Django源代码.
您想要创建三个东西.
用于捕获令牌的中间件.这是大部分工作发生的地方.它判断令牌,对其进行身份验证(通过与身份管理器确认),然后让用户登录.
用于查找用户的身份验证后端.这是一个存根.它所做的一切就是根据需要创建用户.您的身份管理器将提供详细信息.您只是在Django的本地DB上缓存用户的当前版本.
这是中间件(编辑后).
from django.contrib.auth import authenticate, login
class CookieMiddleware( object ):
"""Authentication Middleware for OpenAM using a cookie with a token.
Backend will get user.
"""
def process_request(self, request):
if not hasattr(request, 'user'):
raise ImproperlyConfigured()
if "thecookiename" not in request.COOKIES:
return
token= request.COOKIES["thecookiename"]
# REST request to OpenAM server for user attributes.
token, attribute, role = identity_manager.get_attributes( token )
user = authenticate(remote_user=attribute['uid'][0])
request.user = user
login(request, user)
identity_manager.get_attributes
是我们编写的一个单独的类,用于验证令牌并从IM源获取有关用户的详细信息.当然,出于测试目的,这不得不被嘲笑.
这里有一个后端(编辑)
class Backend( RemoteUserBackend ):
def authenticate(**credentials):
"""We could authenticate the token by checking with OpenAM
Server. We don't do that here, instead we trust the middleware to do it.
"""
try:
user= User.objects.get(username=credentials['remote_user'])
except User.DoesNotExist:
user= User.objects.create(username=credentials['remote_user'] )
# Here is a good place to map roles to Django Group instances or other features.
return user
这不会实质性地改变身份验证或授权的装饰者.
为了确保这一点,我们实际上从我们的
请注意,中间件针对每个请求运行.有时,可以将令牌传递给backed authenticate
方法.如果令牌存在于本地用户数据库中,则可以在不联系身份管理器的情况下继续请求.
但是,我们在身份管理器中有复杂的规则和超时,所以我们必须判断每个令牌以确保它是有效的.一旦中间件确定令牌有效,我们就可以允许后端进行任何额外的处理.
这不是我们的活动代码(它有点太复杂,很难做出好的示例.)