Recreate a WebLogic Server 14.1.2 ‘Azure AD SAML Domain with a Custom Mapper’ Using WDT

GitHub repository: https://github.com/puneethbuilds-middleware/weblogic-azure-saml-group-mapper

This article demonstrates an on-premises, reproducible test for recreating a WebLogic Server 14.1.2 domain that acts as a SAML 2.0 Service Provider (SP) with Microsoft Entra ID (Azure AD) as the Identity Provider (IdP).

The test uses WebLogic Deploy Tooling (WDT) to discover a configured source domain and then creates a second domain from the resulting model, variables file, and archive. It also proves that WebLogic creates the Azure IdP partner automatically at first AdminServer startup.

The custom mapper is the public AzureGroupMapper from How to Add Azure Groups as Principals to a WebLogic Subject. It maps an Entra group claim to a WebLogic group principal.

What WDT does — and what WebLogic does

WDT does not create a SAML IdP partner directly from the model. It packages and restores the SAML partner properties file, metadata file, and domain-library artifacts.

On first AdminServer startup, WebLogic reads DOMAIN_HOME/security/saml2idppartner.properties, imports the metadata, creates the partner, and writes an initialization marker.

Tested software and example names

• WebLogic Server14.1.2 / WLS 12.2.14 with latest SPB
• WDT4.4.2
• Domain nameAzure-IDP_WLS-SP
• SAML2 Identity AsserterAzure_IA
• IdP partnerAzureAD1
• Mapper classexample.weblogic.saml.AzureGroupMapper

Replace paths, credentials, Entra tenant details, certificate material, and endpoint URLs with values from your own environment.

Prerequisites

Build the public Azure group mapper

Follow the linked Azure-groups article to obtain or build azure-group-mapper.jar. The mapper implements both of these WebLogic interfaces:

com.bea.security.saml2.providers.SAML2IdentityAsserterNameMapper
com.bea.security.saml2.providers.SAML2IdentityAsserterAttributeMapper

Its class name is:

example.weblogic.saml.AzureGroupMapper

The mapper reads an allowlisted Entra group claim and returns WLSGroupImpl principals.

Copy the JAR and its configuration file to a controlled location in the source domain, for example:

DOMAIN_HOME/lib/azure-group-mapper.jar
DOMAIN_HOME/config/azure-group-mapper.properties

The configuration file and group mappings are described in the mapper article.

Put the mapper on the server classpath

The SAML Identity Asserter must see the mapper when AdminServer starts. For a shell-started domain, add the JAR to PRE_CLASSPATH in DOMAIN_HOME/bin/setUserOverrides.sh:

PRE_CLASSPATH="${DOMAIN_HOME}/lib/azure-group-mapper.jar${PRE_CLASSPATH:+:${PRE_CLASSPATH}}"
export PRE_CLASSPATH

JAVA_OPTIONS="${JAVA_OPTIONS} -Dazure.saml.mapper.config=${DOMAIN_HOME}/config/azure-group-mapper.properties"
export JAVA_OPTIONS

Restart AdminServer after changing its classpath. Placing a JAR only in DOMAIN_HOME/lib can result in Security:096628 when WebLogic validates the mapper class.

Configure a source Azure SAML SP domain

Login to WebLogic 14.1.2 and configure it as a SAML Service Provider using your Azure/Entra IdP metadata.

At minimum, the source domain needs:

• a SAML 2.0 Identity Asserter authentication provider, named Azure_IA in this example;
• SAML Service Provider services enabled on AdminServer;
• an Azure IdP metadata XML file;
• the public mapper JAR on the AdminServer classpath; and
• a SAML Authentication provider if group principals are used for authorization.

Verify normal SAML sign-on against Azure before proceeding to discovery.

1. Add the SAML initialization input files

Before discovery, create these files in the source domain:

DOMAIN_HOME/security/
├── Azure-IDP_WLS-SP_IDPMetadata.xml
└── saml2idppartner.properties

Use this saml2idppartner.properties file:

saml2.idp.partners=AzureAD1

AzureAD1.description=Azure AD Identity Provider
AzureAD1.metadata.file=Azure-IDP_WLS-SP_IDPMetadata.xml
AzureAD1.enabled=true
AzureAD1.virtualUserEnabled=true
AzureAD1.redirectUris=/saml-sso-diagnostics/
AzureAD1.wantAssertionsSigned=true
AzureAD1.processAttributes=true
AzureAD1.mapperClassName=example.weblogic.saml.AzureGroupMapper

Two details are important:

• AzureAD1.metadata.file must exactly match the metadata filename in DOMAIN_HOME/security.
• Use mapperClassName, with a capital N.

processAttributes=true is required for the attribute-mapper portion of AzureGroupMapper to run.

2. Discover the source domain with WDT

Before discovery, ensure the JAR exists at:
DOMAIN_HOME/lib/azure-group-mapper.jar

WDT will then add it to the archive at the path referenced by domainLibraries.

Run discovery from the WDT bin directory:

cd /Users/puneeth/Downloads/weblogic-deploy/bin

./discoverDomain.sh \
  -oracle_home /path/to/Oracle_Home \
  -domain_home /path/to/user_projects/domains/Azure-IDP_WLS-SP \
  -model_file Azure-IDP_WLS-SP.yaml \
  -variable_file Azure-IDP_WLS-SP.properties \
  -archive_file Azure-IDP_WLS-SP.zip

WDT creates three artifacts:

• ArtifactPurposeAzure-IDP_WLS-SP.yaml
• Discovered domain modelAzure-IDP_WLS-SP.properties
• Variables referenced by the modelAzure-IDP_WLS-SP.zip.Archive containing files required to recreate the domain

Sample Azure-IDP_WLS-SP.yaml file:

# Azure-IDP_WLS-SP.yaml

domainInfo:
  AdminUserName: '@@PROP:AdminUserName@@'
  AdminPassword: '@@PROP:AdminPassword@@'
  domainLibraries:
    - wlsdeploy/domainLibraries/azure-group-mapper.jar

topology:
  Name: Azure-IDP_WLS-SP

  Server:
    AdminServer:
      SSL:
        Enabled: true

      SingleSignOnServices:
        PublishedSiteUrl: http://localhost:7001/saml2
        ServiceProviderSingleLogoutRedirectUri:
          - http://localhost:7001/saml-sso-diagnostics/
        ServiceProviderEnabled: true
        ServiceProviderPreferredBinding: HTTP/POST
        EntityId: Azure-IDP_WLS-SP

  SecurityConfiguration:
    Realm:
      myrealm:
        AuthenticationProvider:
          SAML_Auth:
            SAMLAuthenticator:
              ControlFlag: OPTIONAL

          Azure_IA1:
            SAML2IdentityAsserter: {}

          DefaultIdentityAsserter:
            DefaultIdentityAsserter: {}

          DefaultAuthenticator:
            DefaultAuthenticator:
              ControlFlag: OPTIONAL

appDeployments:
    Application:
        weblogic-remote-console-app:
            SourcePath: '@@WL_HOME@@/server/lib/wls-remote-console.war'
            ModuleType: war
            Target: AdminServer
            SecurityDDModel: DDOnly
        JCS_SSO_Test_application:
            SourcePath: wlsdeploy/applications/JCS_SSO_Test_application/
            ModuleType: war
            Target: AdminServer
            SecurityDDModel: DDOnly
        saml-sso-diagnostics:
            SourcePath: wlsdeploy/applications/saml-sso-diagnostics.war
            ModuleType: war
            Target: AdminServer
            SecurityDDModel: DDOnly

Sample Azure-IDP_WLS-SP.properties file:

AdminPassword=<weblogic_password>
AdminUserName=weblogic

The WDT variables file is not the SAML partner properties file. saml2idppartner.properties is a WebLogic initialization file that WDT packages in the archive.

3. Inspect the WDT archive

Before creating a new domain, inspect the archive:

unzip -l Azure-IDP_WLS-SP.zip | grep -E 'saml2|IDPMetadata|azure-group-mapper'

Confirm that it contains the initialization input files:

wlsdeploy/security/saml2/saml2idppartner.properties
wlsdeploy/security/saml2/Azure-IDP_WLS-SP_IDPMetadata.xml

Also confirm that the mapper JAR is included in the domain-library content.

4. Set the Admin user and password for the new domain

The discovered model refers to the Admin credentials through variables, for example:

domainInfo:
  AdminUserName: '@@PROP:AdminUserName@@'
  AdminPassword: '@@PROP:AdminPassword@@'

Before running createDomain.sh, edit Azure-IDP_WLS-SP.properties and supply credentials for the new domain:

AdminUserName=weblogic
AdminPassword=<choose-a-strong-password>

For an automated deployment, use WDT-supported secret handling instead of a clear-text password file.

5. Create a new test domain

Create the recreated domain under a different parent directory. Never overwrite the source domain used for discovery.

cd /Users/puneeth/Downloads/weblogic-deploy/bin

./createDomain.sh \
  -oracle_home /path/to/Oracle_Home \
  -domain_parent /path/to/user_projects/recreated-domains \
  -model_file Azure-IDP_WLS-SP.yaml \
  -variable_file Azure-IDP_WLS-SP.properties \
  -archive_file Azure-IDP_WLS-SP.zip

After WDT completes, verify that the recreated domain has the SAML inputs:

ls /path/to/user_projects/recreated-domains/Azure-IDP_WLS-SP/security

Expected files include:

Azure-IDP_WLS-SP_IDPMetadata.xml
saml2idppartner.properties

Ensure the recreated domain also has the mapper JAR and its setUserOverrides.sh configuration before starting AdminServer.

6. Start AdminServer and validate the automatic import

Start the recreated domain’s AdminServer. WebLogic reads the IdP partner properties file during startup and writes this marker after processing it:

DOMAIN_HOME/security/saml2idppartner.initialized

In the Administration Console, validate the imported partner at:

Security Realms > myrealm > Providers > Authentication > Azure_IA > Identity Provider Partners > AzureAD1

Verify that:

• AzureAD1 exists and is enabled;
• the issuer and SSO details are populated from Azure metadata;
• Identity Provider Name Mapper Class Name is example.weblogic.saml.AzureGroupMapper; and
• Process Attributes is enabled.

Finally, sign in with an Entra user belonging to a configured group. The authenticated WebLogic subject should contain the mapped WLSGroupImpl principal, as described in the public mapper article.

Summary

This test establishes a portable WDT workflow for a WebLogic 14.1.2 Azure SAML Service Provider domain:

1. Prepare a source domain and public Azure group mapper.
2. Place SAML initialization files under DOMAIN_HOME/security.
3. Run WDT Discover to produce the model, variables file, and archive.
4. Set the target-domain Admin credentials in the variables file.
5. Run WDT Create Domain.
6. Start AdminServer and let WebLogic import the Azure IdP partner.

The same archive structure can later be used as the basis of a WebLogic Kubernetes Operator model-in-image deployment, provided the mapper JAR is included in the runtime image and visible on the server classpath.