Package: django-simple-sso.naudit
=================
django-simple-ssoThis repository is a trivial fork fromdivio/django-simple-sso.
The intention of this fork is to keep all the changes up to date on the pypi repository in an automated way.
Any (code) change performed on this repository would be transformed into a PR ondivio/django-simple-sso.|pypi| |build| |coverage|DocumentationSeeREQUIREMENTSin thesetup.py <https://github.com/divio/django-simple-sso/blob/master/setup.py>_
file for additional dependencies:|python| |django|Django Simple SSO Specification (DRAFT)TerminologyServerThe server is a Django website that holds all the user information and
authenticates users.ClientThe client is a Django website that provides login via SSO using theServer.
It does not hold any user information.KeyA unique key identifying aClient. This key can be made public.SecretA secret key shared between theServerand a singleClient. This secret
should never be shared with anyone other than theServerandClientand
must not be transferred unencrypted.WorkflowUser wants to log into aClientby clicking a "Login" button. The
initially requested URL can be passed using thenextGET parameter.TheClient's Python code does a HTTP request to theServerto request a
authentication token, this is called theRequest Token Request.TheServerreturns aRequest Token.TheClientredirects the User to a view on theServerusing theRequest Token, this is theAuthorization Request.If the user is not logged in the theServer, they are prompted to log in.The user is redirected to theClientincluding theRequest Tokenand aAuth Token, this is theAuthentication Request.TheClient's Python code does a HTTP request to theServerto verify theAuth Token, this is called theAuth Token Verification Request.If theAuth Tokenis valid, theServerreturns a serialized Django User
object.TheClientlogs the user in using the Django User recieved from theServer.RequestsGeneralAll requests have asignatureandkeyparameter, seeSecurity.Request Token RequestClient: PythonTarget:ServerMethod: GETExtra Parameters: NoneResponses:200: Everything went fine, the body of the response is a url encoded
query string containing with therequest_tokenkey holding theRequest Tokenas well as thesignature.400: Bad request (missing GET parameters)403: Forbidden (invalid signature)Authorization RequestClient: Browser (User)Target:ServerMethod: GETExtra Parameters:request_tokenResponses:200: Everything okay, prompt user to log in or continue.400: Bad request (missing GET parameter).403: Forbidden (invalidRequest Token).Authentication RequestClient: Browser (User)Target:ClientMethod: GETExtra Parameters:request_token: TheRequest Tokenreturned by theRequest Token Request.auth_token: TheAuth Tokengenerated by theAuthorization Request.Responses:200: Everything went fine, the user is now logged in.400: Bad request (missing GET parameters).403: Forbidden (invalidRequest Token).Auth Token Verification RequestClient: PythonTarget:ServerMethod: GETExtra Parameters:auth_token: TheAuth Tokenobtained by theAuthentication Request.Responses:200: Everything went fine, the body of the response is a url encoded
query string containing theuserkey which is the JSON serialized
representation of the Django user to create as well as thesignature.SecurityEvery request is signed using HMAC-SHA256. The signature is in thesignatureparameter. The signature message is the urlencoded, alphabetically ordered
query string. The signature key is theSecretof theClient. To verify
the signature thekeyparamater holding thekeyof theClientis
also sent with every request from theClientto theServer.ExampleGET Request with the GET parameterskey=bundle123and the private keysecret key:fbf6396d0fc40d563e2be3c861f7eb5a1b821b76c2ac943d40a7a63b288619a9The User objectThe User object returned by a successfulAuth Token Verification Requestdoes not contain all the information about the Django User, in particular, it
does not contain the password.The user object contains must contain at least the following data:username: The unique username of this user.email: The email of this user.first_name: The first name of this user, this field is required, but may
be empty.last_name: The last name of this user, this field is required, but may
be empty.is_staff: Can this user access the Django admin on theClient?is_superuser: Does this user have superuser access to theClient?is_active: Is the user active?ImplementationOn the serverAddsimple_sso.sso_servertoINSTALLED_APPS.Create an instance (potentially of a subclass) ofsimple_sso.sso_server.server.Serverand include the return value of theget_urlsmethod on that instance into your url patterns.On the clientCreate a new instance ofsimple_sso.sso_server.models.Consumeron theServer.Add theSIMPLE_SSO_SECRETandSIMPLE_SSO_KEYsettings as provided by
theServer'ssimple_sso.sso_server.models.Clientmodel.Add theSIMPLE_SSO_SERVER_URLsetting which is the absolute URL pointing to
the root where thesimple_sso.sso_server.urlswhere include on theServer.Add thesimple_sso.sso_client.urlspatterns somewhere on the client.Optional steps & features[Keep alive / Single Sign Out]: To enable a simple single signout, you just have to
add the middlewaresimple_sso.sso_client.middleware.PostAuthenticationMiddlewaresomewhere afterdjango.contrib.auth.middleware.AuthenticationMiddlewareor your
equivalentAuthenticationMiddleware.If you want to reflect any logout on the client on your remote server (and other clients
connected to it) just add'simple_sso.sso_client'on theINSTALLED_APPSon yoursettings.py.
This will trigger a call to the server on each user logout that will enforce the logout on the server.Keep alive / single sign out have the following custom settings:SSO_KEEP_ALIVE: This setting is defaulted to60(seconds). This means that every
60 seconds the validity of a logged user would be checked to the server. If the user have
been logged out for some reason, that state would be reflected on client.You can set this to 0 or any negative number to force the verification check on
each request. However, take into account that overhead on client and server sides.SSO_TOKEN_TIMEOUT: This setting is defaulted to300seconds (5 minutes). This sets
how long a token can be usable for authentication purposes. In most cases 5 minutes would
be more than enough.SSO_TOKEN_VERIFY_TIMEOUT: This setting is defaulted to3600seconds (1 hour). This
sets how long a token can be usable for verifying purposes. When the token expires the SSO
session expires too and the client will enforce the browser to generate a new token.
In some scenarios this timeout might be increased to the session expiration timeout.Running TestsYou can run tests by executing::virtualenv env
source env/bin/activate
pip install -r tests/requirements.txt
python setup.py test.. |pypi| image::https://badge.fury.io/py/django-simple.sso.svg:target:http://badge.fury.io/py/django-simple.sso.. |build| image::https://travis-ci.org/divio/django-simple.sso.svg?branch=master:target:https://travis-ci.org/divio/django-simple.sso.. |coverage| image::https://codecov.io/gh/divio/django-simple.sso/branch/master/graph/badge.svg:target:https://codecov.io/gh/divio/django-simple.sso.. |python| image::https://img.shields.io/badge/python-3.5+-blue.svg:target:https://pypi.org/project/django-simple.sso/.. |django| image::https://img.shields.io/badge/django-2.2,%203.0,%203.1-blue.svg:target:https://www.djangoproject.com/