Canopy has a number of different authentication options available. They are explained in this document, along with how to configure them.

Local user database

By default, Canopy uses a local user database for storing user accounts and credentials. This is based on Django’s auth module, and the standard configuration uses PBKDF2 for password storage. The authentication details are managed via the Canopy Users admin interface:


For further details on how Django stores user passwords, see the Django documentation.

LDAP/Active Directory (Premium)

Integration with LDAP/AD is supported in Canopy.

We assume that you have knowledge of LDAP/AD authentication and sufficient permissions/capabilities to set up the LDAP/AD server side requirements. This aspect of the configuration is not considered within the scope of this document.


Canopy already installs the necessary components for our premium users to make use of LDAP/AD authentication.


Configuration of AD/LDAP is done via the inclusion of the following configuration:

# Example settings for Windows AD auth

Single sign-on (Premium)

Single sign-on (SSO) is available in Canopy as of version 3.0.1. Our implementation is based on top of SAML2, which means that any SAML2 based SSO solution should be readily supported.

We assume that you have background knowledge of SAML2 and the SSO system you are integrating with. If you have any specific questions, please open a ticket or email us at


Canopy already installs the necessary components for our premium users to make use of SAML2. Configuration of external SAML2 systems is not covered in this document.


The Canopy SAML configuration files are located under /etc/canopy/saml. The following configuration files are present:


SAML ini file for enable/disabling SAML integration

SAML configuration file

These additional files are included, but are unlikely to be required for typical set ups:


Default attribute mapping setup


The canopy.ini file is used to configure the basic settings for SAML integration and to enable/disable use of SAML.


The above configuration is pretty straightforward. The most important aspect (apart from enabling/disabling) is which SAML_ATTRIBUTE_MAPPING should be used for the unique identifier. Canopy requires the email address at the moment, although the UUID could also be used if supported in the SAML provider.


The following sample configuration is provided for integration with a SAML Service Provider.

import saml2
import saml2.saml

    # full path to the xmlsec1 binary program
    'xmlsec_binary': '/usr/bin/xmlsec1',

    # your entity id, usually your subdomain plus the url to the metadata view
    'entityid': '',

    # directory with attribute mapping
    'attribute_map_dir': '/etc/canopy/saml/attributemaps',

    # this block states what services we provide
    'service': {
        # we are just a lonely SP
        'sp': {
            'name': 'Federated Django sample SP',
            'name_id_format': saml2.saml.NAMEID_FORMAT_PERSISTENT,
            'allow_unsolicited': True,
            'endpoints': {
                # url and binding to the assetion consumer service view
                # do not change the binding or service name
                'assertion_consumer_service': [
                # url and binding to the single logout service view
                # do not change the binding or service name
                'single_logout_service': [

            # attributes that this project need to identify a user
            'required_attributes': ['uid', 'email'],

            # attributes that may be useful to have but not required
            'optional_attributes': ['eduPersonAffiliation'],

            # in this section the list of IdPs we talk to are defined
            'idp': {
                # we do not need a WAYF service since there is
                # only an IdP defined here. This IdP should be
                # present in our metadata

                # the keys of this dictionary are entity ids
                '': {
                    'single_sign_on_service': {
                        saml2.BINDING_HTTP_REDIRECT: '',
                    'single_logout_service': {
                        saml2.BINDING_HTTP_REDIRECT: '',

    # where the remote metadata is stored
    'metadata': {
        'local': ['/etc/canopy/saml/metadata.xml'],

    # set to 1 to output debugging information
    'debug': 1,

    # Signing
    'key_file': '/etc/canopy/saml/mycert.key',  # private part
    'cert_file': '/etc/canopy/saml/mycert.pem',  # public part

    # own metadata settings
    'contact_person': [
        {'given_name': 'Luke',
         'sur_name': 'Skywalker',
         'company': 'Jedi Knights LLP',
         'email_address': 'luke@jedi.knights',
         'contact_type': 'technical'},
        {'given_name': 'Leia',
         'sur_name': 'Skywalker',
         'company': 'Jedi Knights LLP',
         'email_address': 'leia@jedi.knights',
         'contact_type': 'administrative'},
    # you can set multilanguage information here
    'organization': {
        'name': [('CheckSec', 'en'), ('El CheckSec', 'es')],
        'display_name': [('CheckSec', 'en'), ('CheckSec', 'es')],
        'url': [('', 'en'), ('', 'es')],
    'valid_for': 24,  # how long is our metadata valid

Multi-factor authentication (Coming soon - all users)

Multi-factor authentication will be added to Canopy in an upcoming release. We intend to support the following solutions initially:

  • Google Authenticator

  • Yubikey

  • RSA