dj-sso-client
is the a Django application works as SSO client side of dj-sso-server
(https://github.com/feifangit/dj-sso-server)
pip install dj-sso-client
Modify following settings in
settings.py
of your projectAUTHENTICATION_BACKENDS
, adddjssoclient.authbackend.SSOAuthBackend
as the backendsAUTH_USER_MODEL
, setdjssoclient.SSOUser
as user model
AUTHENTICATION_BACKENDS = ('djssoclient.authbackend.SSOAuthBackend',)
AUTH_USER_MODEL = 'djssoclient.SSOUser'
Add following
dj-sso-client
settings base on your demandSSO_API_AUTH_SETTING
: set API key, SEC key and remote SSO provider URL. This setting is used by underneathdj-api-auth
module to proejct API accessing.SSO_API_AUTH_SETTING = { "apikey": "f4a05287", "seckey": "6a4eeaea54d54f51af703e79c6096d51", "url": "https://dj-sso-sample.herokuapp.com", }
SSO_REMOTE_URL_PREFIX
(optional): SSO path in remote SSO provider. default/sso/
SSO_USER_STORAGE``(optional): SSOUser storage solution, there are 2 storage backends in ``dj-sso-client
already. default: SSOUserDBStoragedjssoclient.userstorage.SSOUserDBStorage
: store user data in databasedjssoclient.userstorage.SSOUserCacheStorage
: store user data in cache. You will get better performance.
SSO_SETTING_CACHE
(optional): if you selectedSSOUserCacheStorage
as your user storage backend, and you have more than one cache insettings.py
, you can pick up the cache name here. default:default
The default django.core.cache.backends.locmem.LocMemCache
stores data per process. In multi-process production environment (gunicorn on multi-core server), it may cause problem while using SSOUserCacheStorage
as your user storage engine.
Please use dedicate cache system (Memcached or Redis) as cache backend to avoid this problem.
SSOUser
is the user model to store user data. It can be used as database model class if you selected SSOUserDBStorage
to be your user storage engine.
class SSOUser(AbstractBaseUser):
username = models.CharField(unique=True, max_length=50)
extras = models.TextField(default="{}")
...
extra user attributes : attributes not exists in the SSOUser
class. (attributes except username
, password
, last_login
etc.)
All extra user attributes can be access by getattr
method or .
operator. And they are stored in class member extras
in JSON format.
We already have a SSO provider (dj-sso-server
) application running on Heroku: http://dj-sso-sample.herokuapp.com/ . Run the example application in folder example/ssoclient/
locally.
The API key using in the example application is binding with localhost:8000
, so make sure you're accessing local application by localhost:8000
rather than the 127.0.0.1:8000
.
fresh login
- make sure you're not logged in on http://dj-sso-sample.herokuapp.com/, you should see
please log in with ...
- click sso login on local application, you will be redirected to http://dj-sso-sample.herokuapp.com/sso/....
- you will see user information after be redirected to local application.
- on http://dj-sso-sample.herokuapp.com/ , your status is still not logged-in
login with existing logged account
- log in with user name
user1
and password123
on http://dj-sso-sample.herokuapp.com/ - click sso login on local application, you will be redirected to http://dj-sso-sample.herokuapp.com/sso/...., but you will see a different login page with fresh login.
- select
continue with current user? user1
- you will be logged in as
user1
at local application
switch account
- if you select
switch account
and login withuser2
/456
from step 3 in previous sample - you will be logged in as
user2
at local application - your login status on http://dj-sso-sample.herokuapp.com/ will NOT be changed (still logged in as
user1
)
- example: work as an extra auth method