Authentication via OAuth2/SAML2

OAuth2/SAML2 let users authenticate against enterprise directories.

Auth0

In the same way as with other identity providers, it’s now possible to leverage Auth0 to authenticate users on DefectDojo.

  1. Inside your Auth0 dashboard create a new application (Applications / Create Application / Single Page Web Application).

  2. On the new application set the following fields:

  3. Copy the following info from the application:

    • Domain
    • Client ID
    • Client Secret
  4. Now, edit the settings (see Configuration) with the following information:

        DD_SOCIAL_AUTH_AUTH0_OAUTH2_ENABLED=True
        DD_SOCIAL_AUTH_AUTH0_KEY=(str, '**YOUR_CLIENT_ID_FROM_STEP_ABOVE**'),
        DD_SOCIAL_AUTH_AUTH0_SECRET=(str,'**YOUR_CLIENT_SECRET_FROM_STEP_ABOVE**'),
        DD_SOCIAL_AUTH_AUTH0_DOMAIN=(str, '**YOUR_AUTH0_DOMAIN_FROM_STEP_ABOVE**'),
        
  5. Restart DefectDojo, and you should now see a Login with Auth0 button on the login page.

Google

New to DefectDojo, a Google account can now be used for Authentication, Authorization, and a DefectDojo user. Upon login with a Google account, a new user will be created if one does not already exist. The criteria for determining whether a user exists is based on the users username. In the event a new user is created, the username is that of the Google address without the domain. Once created, the user creation process will not happen again as the user is recalled by its username, and logged in. In order to make the magic happen, a Google authentication server needs to be created. Closely follow the steps below to guarantee success.

  1. Navigate to the following address and either create a new account, or login with an existing one: Google Developers Console

  2. Once logged in, find the key shaped button labeled Credentials on the left side of the screen. Click Create Credentials, and choose OAuth Client ID:

    image

  3. Select Web Applications, and provide a descriptive name for the client.

    image

  4. Add the pictured URLs in the Authorized Redirect URLs section. This part is very important. If there are any mistakes here, the authentication client will not authorize the request, and deny access.

  5. Once all URLs are added, finish by clicking Create

  6. Now with the authentication client created, the Client ID and Client Secret Key need to be copied over to the settings. Click the newly created client and copy the values:

    image

  7. Edit the settings (see Configuration) with the following information:

        DD_SOCIAL_AUTH_GOOGLE_OAUTH2_ENABLED=True,
        DD_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY=(str, '**YOUR_CLIENT_ID_FROM_STEP_ABOVE**'),
        DD_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET=(str, '**YOUR_CLIENT_SECRET_FROM_STEP_ABOVE**'),
        

    To authorize users you will need to set the following:

        SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS = ['example.com', 'example.org']
        

    or

        SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS = ['<email@example.com>']
        

OKTA

In a similar fashion to that of Google, using OKTA as a OAuth2 provider carries the same attributes and a similar procedure. Follow along below.

  1. Navigate to the following address and either create a new account, or login with an existing one: OKTA Account Creation

  2. Once logged in, enter the Applications and click Add Application:

    image

  3. Select Web Applications.

    image

  4. Add the pictured URLs in the Login Redirect URLs section. This part is very important. If there are any mistakes here, the authentication client will not authorize the request, and deny access. Check the Implicit box as well.

    image

  5. Once all URLs are added, finish by clicking Done.

  6. Return to the Dashboard to find the Org-URL. Note this value as it will be important in the settings file.

    image

  7. Now, with the authentication client created, the Client ID and Client Secret Key need to be copied over to the settings. Click the newly created client and copy the values:

    image

  8. Edit the settings (see Configuration) with the following information:

        DD_SOCIAL_AUTH_OKTA_OAUTH2_ENABLED=True,
        DD_SOCIAL_AUTH_OKTA_OAUTH2_KEY=(str, '**YOUR_CLIENT_ID_FROM_STEP_ABOVE**'),
        DD_SOCIAL_AUTH_OKTA_OAUTH2_SECRET=(str, '**YOUR_CLIENT_SECRET_FROM_STEP_ABOVE**'),
        DD_SOCIAL_AUTH_OKTA_OAUTH2_API_URL=(str, 'https://{your-org-url}/oauth2/default'),
        

If during the login process you get the following error: The ‘redirect_uri’ parameter must be an absolute URI that is whitelisted in the client app settings. and the redirect_uri HTTP GET parameter starts with http:// instead of https:// you need to add SOCIAL_AUTH_REDIRECT_IS_HTTPS = True in the settings.

Azure Active Directory

You can now use your corporate Azure Active Directory to authenticate users to Defect Dojo. Users will be using your corporate Azure AD account (A.K.A. Office 365 identity) to authenticate via OAuth, and all the conditional access rules and benefits from Azure Active Directory will also apply to the Defect Dojo Authentication. Once the user signs in, it will try to match the UPN of the user to an existing e-mail from a user in Defect Dojo, and if no match is found, a new user will be created in Defect Dojo, associated with the unique id/value of the user provided by your Azure AD tenant. Then, you can assign roles to this user, such as ‘staff’ or ‘superuser’

  1. Navigate to the following address and follow instructions to create a new app registration

  2. Once you register an app, take note of the following information:

    • Application (client) ID
    • Directory (tenant) ID
    • Under Certificates & Secrets, create a new Client Secret
  3. Under Authentication > Redirect URIs, add a WEB type of uri where the redirect points to

  4. Edit the settings (see Configuration) with the following information:

        DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY=(str, 'YOUR_APPLICATION_ID_FROM_STEP_ABOVE'),
        DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET=(str, 'YOUR_CLIENT_SECRET_FROM_STEP_ABOVE'),
        DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID=(str, 'YOUR_DIRECTORY_ID_FROM_STEP_ABOVE'),
        DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_ENABLED = True
        
  5. Restart your Dojo, and you should now see a Login with Azure AD button on the login page which should magically work

Gitlab

In a similar fashion to that of Google and OKTA, using Gitlab as a OAuth2 provider carries the same attributes and a similar procedure. Follow along below.

  1. Navigate to your Gitlab settings page and got to the Applications section

  2. Choose a name for your application

  3. For the Redirect URI, enter the DefectDojo URL with the following format

  4. Edit the settings (see Configuration) with the following information:

        DD_SOCIAL_AUTH_GITLAB_KEY=(str, 'YOUR_APPLICATION_ID_FROM_STEP_ABOVE'),
        DD_SOCIAL_AUTH_GITLAB_SECRET=(str, 'YOUR_SECRET_FROM_STEP_ABOVE'),
        DD_SOCIAL_AUTH_GITLAB_API_URL=(str, 'https://gitlab.com'),
        DD_SOCIAL_AUTH_GITLAB_OAUTH2_ENABLED = True
        

    Additionally, if you want to import your Gitlab projects as DefectDojo products, add the following line to your settings:

        DD_SOCIAL_AUTH_GITLAB_PROJECT_AUTO_IMPORT = True
        
  5. Restart DefectDojo, and you should now see a Login with Gitlab button on the login page.

SAML 2.0

In a similar direction to OAuth, this SAML addition provides a more secure perogative to SSO. For definitions of terms used and more information, see the plugin plugin homepage.

  1. Navigate to your SAML IdP and find your metadata

  2. Edit the settings (see Configuration) with the following information:

        DD_SAML2_ENABLED=(bool, **True**),
        # If the metadata can be accessed from a url, try the
        DD_SAML2_METADATA_AUTO_CONF_URL=(str, '<https://your_IdP.com/metadata.xml>'),
        # Otherwise, downlaod a copy of the metadata into an xml file, and
        # list the path in DD_SAML2_METADATA_LOCAL_FILE_PATH
        DD_SAML2_METADATA_LOCAL_FILE_PATH=(str, '/path/to/your/metadata.xml'),
        # Fill in DD_SAML2_ATTRIBUTES_MAP to corresponding SAML2 userprofile attributes provided by your IdP
        DD_SAML2_ATTRIBUTES_MAP=(dict, {
            # format: SAML attrib:django_user_model
            'Email': 'email',
            'UserName': 'username',
            'Firstname': 'first_name',
            'Lastname': 'last_name'
        }),
        # May configure the optional fields
        

NOTE: DD_SAML2_ATTRIBUTES_MAP in k8s can be referenced as extraConfig (e.g. DD_SAML2_ATTRIBUTES_MAP: 'Email'='email', 'Username'='username'...)

  1. Checkout the SAML section in dojo/dojo/settings/settings.dist.py and verfiy if it fits your requirement. If you need help, take a look at the plugin documentation.

  2. Restart DefectDojo, and you should now see a Login with SAML button on the login page.

NOTE: In the case when IDP is configured to use self signed (private) certificate, than CA needs to be specified by define environments variable REQUESTS_CA_BUNDLE that points to the path of private CA certificate.

Advanced Configuration

The https://github.com/IdentityPython/djangosaml2 plugin has a lot of options. For details take a look at the plugin documentation. All default options in DefectDojo can overwritten in the local_settings.py. If you want to change the organization name, you can add the following lines:

if SAML2_ENABLED:
    SAML_CONFIG['contact_person'] = [{
        'given_name': 'Extra',
        'sur_name': 'Example',
        'company': 'DefectDojo',
        'email_address': 'dummy@defectdojo.com',
        'contact_type': 'technical'
    }]
    SAML_CONFIG['organization'] = {
        'name': [('DefectDojo', 'en')],
        'display_name': [('DefectDojo', 'en')],
    },

Migration from django-saml2-auth

Up to relase 1.15.0 the SAML integration was based on https://github.com/fangli/django-saml2-auth. Which the switch to djangosaml2 some parameters has changed:

  • DD_SAML2_ASSERTION_URL: not necessary any more - automatically generated
  • DD_SAML2_DEFAULT_NEXT_URL: not necessary any more - default forwarding from defectdojo is used
  • DD_SAML2_NEW_USER_PROFILE: not possible any more - default profile is used, see User Permissions
  • DD_SAML2_ATTRIBUTES_MAP: Syntax has changed
  • DD_SAML2_CREATE_USER: Default value changed to False, to avoid security breaches

User Permissions

When a new user is created via the social-auth, only the default permissions are active. This means that the newly created user does not have access to add, edit, nor delete anything within DefectDojo. There are two parameters in the System Settings to influence the permissions for newly created users:

Default group

When both the parameters Default group and Default group role are set, the new user will be a member of the given group with the given role, which will give him the respective permissions.

Staff user

Newly created users are neither staff nor superuser by default. The is_staff flag of a new user will be set to True, if the user’s email address matches the regular expression in the parameter Email pattern for staff users.

Example:

.*@example.com will make alice@example.com a staff user, while bob@partner.example.com or chris@example.org will be non-staff users.

Other Providers

In an effort to accommodate as much generality as possible, it was decided to implement OAuth2 with the social-auth ecosystem as it has a library of compatible providers with documentation of implementation. Conveniently, each provider has an identical procedure of managing the authenticated responses and authorizing access within a given application. The only difficulty is creating a new authentication client with a given OAuth2 provider.