Detailed explanation of Django CAS solutions

CAS single sign-in is mainly to solve the problem of unified login between the main system and the subsystem. After logging in with any subsystem successfully, authentication is no longer required after logging in to other subsystems, so that users do not need to log in and authenticate repeatedly. There are many solutions for CAS single sign-on, and most of them adopt a session method. This article combines personal practice and focuses on the django cas token solution.

In this solution, both the cas client and the server use open source projects, and the server isdjango-mama-cas, and the client isdjango-cas-ng。

CAS Server

The server is much simpler than the client, just download and configure step by step according to the github steps.

download

pip install django-mama-cas

Configuration

# 
INSTALLED_APPS = (
  'mama_cas',
)

# important!  , service is the client's IP, an array, you can add SERVICE's HOST:PORT after it.MAMA_CAS_SERVICES = [
  {
    'SERVICE': 'http://127.0.1.1:8000',
    'CALLBACKS': [
      'mama_cas.callbacks.user_model_attributes',   # Return all Fields except password      # 'mama_cas.callbacks.user_name_attributes', # Return only username    ],
    'LOGOUT_ALLOW': True,
    'LOGOUT_URL': 'http://127.0.1.1:8000/accounts/callback',
  },
]

# 
url(r'', include('mama_cas.urls')),

Client

First of all, there are some basic client configurations, such as server ip, etc., but django-cas-ng is authenticated by session by default, and we need to authenticate by token. So if you want to continue to use django-cas-ng to solve the problem, then you either check whether it has a native supported interface or change the source code. Changing the source code may not be very friendly, so I first studied the native support of django-cas-ng. I accidentally found that view-wrappers-example can inherit its native login interface and do some encapsulation. We completely inherit the native login method and then add our token-related code. So we write the login method we write the login method we encapsulated in, not the default one.

# 
INSTALLED_APPS = (
  # ... other installed apps
  'django_cas_ng',
)

AUTHENTICATION_BACKENDS = (
  'django_cas_ng.',
)

# Note: This is the address of the cas serverCAS_SERVER_URL = 'http://127.0.0.1:8000'

# Save all user data returned by the CAS server.CAS_APPLY_ATTRIBUTES_TO_USER = True

# 
import view import *
url(r'^accounts/login$', cas_login, name='cas_login'),

#
from django_cas_ng import views as baseviews
from  import csrf_exempt

@csrf_exempt
def cas_login(request, **kwargs):
  r = (request, **kwargs)
  if not .is_anonymous():
    token = get_token(request)
    if token:
      r.set_cookie('token', token)
    else:
      print 'Get token error'
  else:
    print('User is anonymous')
  return r

def get_token(request, *args, **kwargs):
  user = 
  try:
    request_hash = AuthToken.get_request_hash(request)
    try:
      token = generate_token()  # function used to geneate token, this place won't show more detail codes
      ()
    except IndexError:
      pass
  except Exception as e:
    print e
    return False
  return 

I won't describe the method of generating tokens in detail. Here we mainly provide an idea. We inherit the native login method of django-cas-ng, and then generate the token and put it in the session.

Summarize

This article mainly provides an idea for the CAS Token solution. If it is integrated into existing projects, it will definitely encounter many detailed problems. However, it will never be separated from the essence. First, we must be familiar with the tools we use, and then be good at developing according to our own customized needs on this basis. Look at the documents and source code more, and we may make new discoveries every time.

Refer

Quickly build CAS service using django-mama-cas
Django implements CAS+OAuth2

The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.