Azure AD OIDC SSO Integration

Prerequisites

Set up OIDC configuration within Microsoft Entra ID (formerly Azure AD) by selecting the type as Web and with the redirect URI pointing to your deployment, as seen in the image below.

Redirect URL - {base_url}/api/sso/azuread/callback

register an application - screenshot

Once the registration is successful, create a new client secret and copy the secret value immediately after it is created without refreshing the page.

create a new client secret - screenshot

🚧 Be careful

You will not be able to access the client secret later because it is shown ONCE and not repeated

Creating a new client secret

Masked client secret value

Setting up token permissions to the application

Configured Token Permissions includes acct, email, family_name, given_name and groups

Setting up API permissions to the application

Configured API Permissions includes Directory.Read.All, email, GroupMember.Read.All, offline_access, openid, profile and User.Read

Application Permissions

In Authentication, fill the details as shown below

Under Implicit Grant and Hybrid Flows, 'Access tokens' and 'ID tokens' are enabled. Under Supported Account Types, 'Accounts in this organizational directory only' is selected.

Up until this point, our application configuration is complete. The following section now deals with Fiddler side of changes.

Configure Azure SSO with Fiddler

The following details are required to configure Azure SSO with Fiddler:

• OpenID Connect metadata document sso-azuread-identity-metadata

• Application (client) ID sso-azuread-client-id

• Newly created client secret sso-azuread-client-secret

• Directory (tenant) ID sso-azuread-client-tenant-id

OpenID Connect metadata Document can be found under Endpoints under the overview section.

OpenID Connect metadata Document can be found under Endpoints under the overview section.

The following details can be obtained from the OpenID Connect metadata document URI.

• Response Types Supported sso-azuread-response-type

• Response Modes Supported sso-azuread-response-mode

• Issuer sso-azuread-issuer

• Scopes Supported sso-azuread-scope

Deployment instructions

Step 1 Create a <secret-filename>.yaml file with the following template

apiVersion: v1
kind: Secret
metadata:
  name: fiddler-sso-azuread-credentials
  namespace: <NAMESPACE_NAME>
stringData:
  sso-azuread-identity-metadata: <IDENTITY_METADATA_URL> # the format follows `https://login.microsoftonline.com/<TENANT_ID>/v2.0/.well-known/openid-configuration`
  sso-azuread-client-id: <CLIENT_ID>
  sso-azuread-client-tenant-id: <TENANT_ID> # this is found from the ISSUER_URL like https://login.microsoftonline.com/<TENANT_ID>/v2.0 
  sso-azuread-client-secret: <CLIENT_SECRET>
  sso-azuread-validate-issuer: <VALIDATE_ISSUER> # set to "true"
  sso-azuread-issuer: <ISSUER_URL> # find this from running `cat "OpenID Connect metadata document.json" | jq '.issuer'`
  sso-azuread-scope: <SCOPES> # set to "openid,offline_access,profile,email"
  sso-azuread-response-type: <RESPONSE_TYPE> # set to "code id_token"
  sso-azuread-response-mode: <RESPONSE MODE> # set to "form_post"
  sso-azuread-validate-issuer: <VALIDATE_ISSUER> # set to "true"
type: Opaque

📘 If you use stringData above, you do not need to manually base64 encode all entries

📘 Do not use doubles quotes

Don’t use doubles quotes anywhere in values in above yaml. In above example, it is written set to “true” - the value is true and not “true”.

Step 2 Update the Kubernetes secret in the namespace of that cluster using the above file.

kubectl apply -f <secret-filename>.yaml -n fiddler

Step 3 Update the Helm variable fiddler.auth.sso.provider and fiddler.auth.sso.azuread.secretName with azuread and fiddler-sso-azuread-credentials value. If you are using the helm values file, use the following settings.

fiddler:  
  auth:  
    sso:  
      provider: azuread  
      azuread:  
        secretName: fiddler-sso-azuread-credentials

📘 Once the deployments are updated, the new SSO settings will be applied.

Troubleshooting

• If users are suddenly unable to log in to Fiddler, despite it working previously, check whether the client secret has expired. By default, the client secret typically expires after 6 months (unless a higher value is set at the time of creation). If it has expired, generate a new one and update the Helm configuration sso-azuread-client-secret to restore SSO functionality.