Single-Sign-On Authentication

The Advanced Authentication allows you to configure different authentication scenarios, including integration with external authentication sources.

External authentication sources

The Advanced Authentication allows integration with various external authentication source, including SAML 2.0, Google Apps and Facebook.

SAML 2.0

The Advanced Authentication integration allows you to integrate with an Identity Provider which supports SAML 2.0. Portal can create users automatically when they first access the system and you can configure if these newly created users should be automatically enabled or not.

Settings

To enable the SAML 2.0 integration, a number of settings have to be configured. First of all, you will have to add the Saml2 authentication backend to the [enable_extras] section ``/etc/cantemo/portal/portal.conf`:

AUTHENTICATION_BACKENDS = portal.plugins.advancedauth.backends.AdvancedAuthSaml2Backend,
    portal.vidispine.authentication.VidispineBackend,
    django.contrib.auth.backends.ModelBackend

You will have to add the following section to /opt/cantemo/portal/portal/localsettings.py:

LOCAL_APPS = tuple()
from os import path
import saml2
import saml2.saml

hostname = 'portal.example.com'

saml_basedir = '/etc/cantemo/portal/saml'
SAML_CONFIG = {
    # full path to the xmlsec1 binary programm
    'xmlsec_binary': '/usr/bin/xmlsec1',

    # your entity id, usually your subdomain plus the url to the metadata view
    'entityid': 'http://%s/advancedauth/saml2/metadata/' % hostname,

    # directory with attribute mapping
    'attribute_map_dir': path.join(saml_basedir, 'attributemaps'),

    # this block states what services we provide
    'service': {
        # we are just a lonely SP
        'sp': {
            "allow_unsolicited": True,
            'name': 'Cantemo Portal SP',
            'name_id_format': saml2.saml.NAMEID_FORMAT_EMAILADDRESS,
            'endpoints': {
                # url and binding to the assetion consumer service view
                # do not change the binding or service name
                'assertion_consumer_service': [
                    ('http://%s/advancedauth/saml2/acs/' % hostname,
                     saml2.BINDING_HTTP_POST),
                    ],
                # url and binding to the single logout service view
                # do not change the binding or service name
                'single_logout_service': [
                    ('http://%s/advancedauth/saml2/ls/' % hostname,
                     saml2.BINDING_HTTP_REDIRECT),
                    ('http://%s/advancedauth/saml2/ls/post/' % hostname,
                     saml2.BINDING_HTTP_POST),
                    ],
            },

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

            # 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
                'https://localhost/simplesaml/saml2/idp/metadata.php': {
                    'single_sign_on_service': {
                        saml2.BINDING_HTTP_REDIRECT:
                            'https://localhost/simplesaml/saml2/idp/SSOService.php',
                    },
                    'single_logout_service': {
                        saml2.BINDING_HTTP_REDIRECT:
                            'https://localhost/simplesaml/saml2/idp/SingleLogoutService.php',
                    },
                },
            },
        },
    },

    # where the remote metadata is stored
    'metadata': {
        'local': [path.join(saml_basedir, 'saml2-metadata-idp.xml')],
    },

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

    # certificate
    'key_file': path.join(saml_basedir, 'server.key'),  # private part
    'cert_file': path.join(saml_basedir, 'server.crt'),  # public part

    # own metadata settings
    'contact_person': [
        {'given_name': 'John',
         'sur_name': 'Doe',
         'company': 'Acme Inc',
         'email_address': 'johndoe@example.com',
         'contact_type': 'technical'},
        {'given_name': 'Jane',
         'sur_name': 'Doe',
         'company': 'Acme Inc',
         'email_address': 'janedoe@example.com',
         'contact_type': 'technical'}
    ],
    # you can set multilanguage information here
    'organization': {
        'name': [('Acme Inc', 'en')],
        'display_name': [('Acme Inc', 'en')],
        'url': [('http://www.example.com', 'en')],
    },
    'valid_for': 24,  # how long is our metadata valid
}

SAML_ATTRIBUTE_MAPPING = {
    'uid': ('username', ),
    'mail': ('email', ),
    'givenName': ('first_name', ),
    'sn': ('last_name', ),
}

SAML_CREATE_UNKNOWN_USER = True

LOCAL_APPS += ('djangosaml2',)

You may want to change a few settings above, to fit your needs and local configuration.

Next, you should place the metadata xml from your Idp in /etc/cantemo/portal/saml/saml2-metadata-idp.xml and create a certificate to be used by Portal when signing SAML 2.0 requests. The following commands may be used in the directory /etc/cantemo/portal/saml/:

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

This will generate the files server.key and server.crt which are referenced in the SAML configuration above.

Below is an example output from these commands:

>>> openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
..............................................................................................+++
.+++
e is 65537 (0x10001)

>>> openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]: SE
State or Province Name (full name) [Some-State]: Stockholm
Locality Name (eg, city) []: Stockholm
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Codemill AB
Organizational Unit Name (eg, section) []: Infrastructure
Common Name (e.g. server FQDN or YOUR name) []: portal.cantemo.com
Email Address []: info@cantemo.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


>>> openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=SE/ST=Stockholm/L=Stockholm/O=Codemill AB/OU=Infrastructure/CN=portal.cantemo.com/emailAddress=info@cantemo.com
Getting Private key

Now you should be able to restart portal.

This will make the changes you made above go into effect, and you should be able to download the Service Provider configuration with the following command:

curl http://portal.example.com/advancedauth/saml2/metadata/

This file needs to be sent to you Idp administrators who will use it to configure the application integration.

If you want the user to automatically be sent to the single-sign-on page you can configure the setting LOGIN_URL in the [site] section in portal.conf:

LOGIN_URL = /advancedauth/saml2/login/

If the Idp is set up to allow single logout then the LOGIN_URL setting in the [site] section in ``portal.conf` can be set to replace the Logout link in the Portal GUI to initiate a single logout:

LOGOUT_URL = /advancedauth/saml2/logout/

Google Apps

This integration is available using the OpenID Connect (OIDC) Authentication plugin instead of Single-Sign-On Authentication.

Basic usage

When a user comes to the login screen they will now have the additional option to log in using the configured Single-Sign-On methods.

../../_images/login_screen.png

When the user clicks the SAML link on the login page they will be redirected to the login screen of the identity provider.

When a new user logs in for the first time an inactive user will be created and an email will be sent to the email address configured for the admin user, allowing the admin to approve the new user before they gain access to the system. This requires that email sending has been configured in portal.conf