Last updated: July 20, 2021
Read time: 5 Minutes
Burp Suite Enterprise Edition allows you to manage user authentication centrally via SAML-based single sign-on (SSO). This is especially useful for cloud-based deployments. Once configured, users will be able to log in using their existing credentials, removing the need to create and manage dedicated user accounts in Burp Suite Enterprise Edition. Each user's permissions are then determined by the groups to which they belong.
To configure SAML SSO, you need to establish a trusted connection between the service provider (Burp Suite Enterprise Edition) and your SAML identity provider. Integration with the following providers has been fully tested:
Configuring this connection requires you to perform steps both within the Burp Suite Enterprise Edition web UI and in the administration settings for your identity provider. For exact details of how to perform some of these steps, you may need to consult your identity provider's documentation.
The first step is to add Burp Suite Enterprise Edition to your identity provider's list of trusted applications. Please note that this process has various names depending on your identity provider. If you are using Okta or Azure Active Directory, this is known simply as "adding an application". ADFS. however, refers to "adding a relying party trust".
Some identity providers, including Azure AD, will only let you add Burp Suite Enterprise Edition as a trusted application if you have enabled HTTPS on your web server.
For on-premise installations of Burp Suite Enterprise Edition, you can do this from the "Network" settings page by selecting the "Enable TLS" option.
For cloud-based deployments, you need to add an HTTPS listener to the load balancer that Kubernetes controls.
As you will need to enter some details about your identity provider, we recommend gathering this information before you start the configuration in Burp Suite Enterprise Edition. Exactly where you can find this information will depend on your identity provider, but it should be easily available.
Unfortunately, the terminology used by different identity providers can vary dramatically. Where possible, we have provided some commonly used alternative names for the required information.
You will need the obtain the following:
Issuervalue in SAML responses. This is usually a URL. Alternative names include "Federation service identifier" and "Identity provider issuer".
Once you have gathered the required details about your identity provider, the next step is to enter this information in Burp Suite Enterprise Edition.
To complete the configuration, you need to perform some additional steps that are specific to your identity provider.
If you are using an identity provider other than the ones mentioned, you will need to configure how the security groups are sent to Burp Suite Enterprise Edition. The details of this will vary between providers, but here is an example of a group attribute statement, where the group name is "Scan viewers":
<AttributeStatement><Attribute Name="http://schemas.xmlsoap.org/claims/Group"><AttributeValue>Scan viewers</AttributeValue></Attribute></AttributeStatement>
Burp Suite Enterprise Edition also provides optional support for single logout (SLO). When enabled, logging out of Burp Suite Enterprise Edition will automatically log users out of the identity provider as well. This helps prevent users from inadvertently remaining logged in to multiple applications. If you do not enable this option, users will remain logged in to the identity provider even after logging out of Burp Suite Enterprise Edition.
When Burp Suite Enterprise Edition generates a single logout message, it signs it in case the receiving party uses a signature to validate the message.
To configure single logout:
Some identity providers, such as Okta, require single logout messages to be signed in order to verify that they came from a trusted source. In this case, you may also need to upload the certificate that you generated to your identity provider.