One way to generate the desired custom model is to manually create a WLS domain (using legacy installers, wlst scripts, console UI changes, and so on) that contains all the constructs that are required and is known to work, in terms of the custom use case. The WDT Discover Domain tool can be pointed at this WLS domain to generate a set of model files. These can be scanned and pruned to get the portions that are of custom interest. They can further be parameterized using WDT's properties files or using Helm values.

If WDT properties are used to parameterize, ensure that you add that properties file to the extension point in the custom implementation.

If Helm values are used to parameterize, ensure that you add these values to the appropriate location - project/instance/shape yamls.

# ensure ORACLE_HOME is properly set
cd $ORACLE_HOME
mkdir wdt && cd wdt
wget https://github.com/oracle/weblogic-deploy-tooling/releases/download/weblogic-deploy-tooling-1.6.0/weblogic-deploy.zip
# Replace 1.6.0 with the actual WDT version as per OSM documentation
unzip weblogic-deploy.zip
cd weblogic-deploy/bin
./discoverDomain.sh -oracle_home $ORACLE_HOME \
 -domain_home domain-home \
 -archive_file archive \
 -model_file model \
 -domain_type domain-type \
 -admin_user admin-user \
 -admin_url t3-admin-url

The command extracts the model from the running WLS instance. Alternatively, if it is sufficient to extract the model from the domain configuration files, the admin_user and admin_url parameters can be left out.

This tool is useful in the following scenarios:

• When there is a need to see what attributes and sub-fields are available for a model element
• When there is a need to see if a model fragment is valid

Trying to test a newly written or even a modified model file by incorporating it into an instance creation is cumbersome and often an inefficient way to test your changes. You need to check the Introspector logs to see the details of any errors.

With the Validate Model tool, it is easier to validate the model file, especially if you are building the model iteratively.

The WDT fragment describing a JDBCSystemResource is provided in the $CNTK/samples/customExtension/_custom-jdbc-support.tpl sample file.

The WDT fragment describing a JMS System Resource is provided in the $CNTK/samples/customExtension/_custom-jms-support.tpl sample file.

You can deploy any WebLogic Server deployable entity, such as an application EAR or WAR to an OSM WebLogic domain.

To deploy an entity to an OSM WebLogic Domain:

1. Package the entity, for example, the application ear into an archive file and place it inside the container image used for creating OSM instances.

   Note:

   The WebLogic domain tooling expects application binaries to be available at the correct path within the archive. A script is provided for your convenience that packages the application into the correct path.

   cp application.ear samples/customExtensions
   cd samples/customExtensions
   ./make-custom-archive.sh archive_file_name.zip application.ear

2. Build a new container image:

   cd samples/customExtensions
   builder build -t "image_name:tag" --build-arg base_image=osm_base_image --build-arg archive=archive_file_name.zip .

   builder will be docker or podman.

3. Upload the generated image to your private image repository.
4. Add the domain configuration.
   In addition to copying the archive file into the base image, you must supply custom configuration, which can be passed in by any one of following two mechanisms:

   • Inside the container image.

     This mechanism keeps the ear file together with the domain configuration in one location. This is best suited to applications that can be considered standard or fixed for all variants of a domain that are required (test, development, and production).

     Advantage: You do not need to add the custom domain configuration every time you create a domain.

     Disadvantage: If you want to change the configuration, it requires a change to the base image. In domains that are already up, an image change triggers a full restart of the domain.

     To add the domain configuration using this mechanism:

     1. Save your fragment in a YAML file that includes an index 70 or above. For example, custom-application-extension.70.yaml.
     2. Edit Dockerfile to copy the YAML file to the u01/wdt/models directory along with the archive.
   • Using the extension mechanism.

     This approach allows for per instance control over the application. This is best suited to situations where the application configuration needs to be dictated by the specific domain instance (for example, test vs. production).

     Advantage: Keeps all "variable" (per instance) configuration in one place at domain creation.

     Disadvantage: Domain creation for every instance that uses the application must remember to add the configuration.

     To use the extension mechanism:
     1. Enable the extension mechanism by setting the custom flag to true and add the custom-domain-model to the list of included wdtFiles in the project specification:

        custom:
          enabled: true
          wdtFiles:
           - _custom-domain-model.tpl

     2. Provide the WDT fragment by copying $CNTK/samples/customExtensions/_custom-application-support.tpl to the customExtPath in your source control repository.
     3. Parameterize the WDT fragment. The fragment has already been parameterized.

        appDeployments:
         Application:
         {{- .Values.custom.application_name }}:
         SourcePath: 'wlsdeploy/applications/{{- .Values.custom.binary_name }}.ear'
         ModuleType: ear
         StagingMode: nostage
         PlanStagingMode: nostage
         Target: '@@PROP:CLUSTER_NAME@@'

     4. Provide the values in the instance specification:

        custom:
          enabled: true
          application: true
          #additional values here
          application_name: myApplication
          binary_name: myApp

     5. Add the application flag and set it to true. The fragment is already configured for conditional loading based on the presence of the application flag in the project specification. See $CNTK/charts/osm/templates/_custom-domain-model.tpl in the toolkit.

        custom:
          enabled: true
          application: true

     6. Add the application tpl file to the project specification:

        custom:
          enabled: true
          application: true
          wdtFiles:
           - _custom-domain-model.tpl
           - _custom-application-support.tpl

   You can now create the OSM instance.

The OSM cloud native toolkit provides out-of-the-box configuration for a WebLogic domain using OpenLDAP as the authenticator. Using a different provider (even a different LDAP provider) requires different WDT metadata, which is a significant undertaking. The configuration required to support an alternate WLS provider would need to be investigated and developed independently using an existing WebLogic domain. Oracle's WDT Discover Domain Tool can analyze an existing domain and generate the corresponding WDT model. The WDT model fragment can then be used to configure the OSM domain using the toolkit extension mechanism.

After the WDT is determined, it is provided during the creation process in the same way as other WDT metadata fragments. This section describes the process for setting up external authentication for OSM cloud native.

To set up external authentication:

1. Disable OpenLDAP by editing the project specification in customExPath:

   authentication:
     openldap:
       enabled: false

2. Copy $OSM_CNTK/samples/_custom-domain-model.tpl to your source control repository at customExtPath.
3. Enable the extension mechanism by setting the custom flag to true in the project specification and including the _custom-domain-model.tpl

   custom:
     enabled: true
     wdtFiles:
      - _custom-domain-model.tpl

4. Determine and provide the WDT model fragment for the security provider in the WebLogic domain. Once you know the WDT fragment that needs to be supplied, save it into a file in your source control repository at the customExtPath (_custom-provider-support.tpl).

   For OSM cloud native, a custom authentication provider offers integration with an additional identity store, for example, Active Directory. This is in addition to the default authentication providers offered by WebLogic, DefaultAuthenticator and DefaultIdentityAsserter, which are required by OSM.

   The following WDT model fragment is automatically combined with the DefaultAuthenticator and DefaultIdentityAsserter defined in OSM's default WDT model. Because of this, the custom authentication provider appears last among all authentication providers. Since the order of the authentication providers determines the order that they are queried, this means that users are authenticated against WebLogic's embedded LDAP first, and if no such user exists then the custom authentication provider is queried. This means that when a human user logs in, they are first checked against the machine users in embedded LDAP (which will not find a match) and then checked against the custom authentication provider.

   {{- define "osm.custom-provider-support" -}}
   topology:
    SecurityConfiguration:
     Realm:
      myrealm:
       AuthenticationProvider:
        YouLDAPProviderStartHere:
        .... <specific details here>
    
   {{- end }}
   

   Oracle recommends that you keep this order. If required, you can query the custom provider first by using the following pattern:

   {{- define "osm.custom-provider-support" -}}
   topology:
    SecurityConfiguration:
     Realm:
      myrealm:
       AuthenticationProvider:
        '!DefaultAuthenticator':
        '!DefaultIdentityAsserter':
        YouLDAPProviderStartHere:
        .... <specific details here>
     
        DefaultAuthenticator:
         DefaultAuthenticator:
          ControlFlag: SUFFICIENT
          UseRetrievedUserNameAsPrincipal: true
        DefaultIdentityAsserter:
         DefaultIdentityAsserter:
   {{- end }}

   This is WDT syntax that deletes the default providers specified in OSM's default WDT model, adds the custom provider, and recreates the default providers.

   Note:

   In this configuration, the ControlFlag for the custom provider must be SUFFICIENT.
5. (Optional) Update any parameters that should not be hard coded in the WDT fragment. Add these values to the project specification under the "custom" section.
6. Load the model fragment by editing your custom_extension_path/ _custom-domain-model.tpl file:

   {{- define "osm.custom-domain-model" -}}
   {{- $root := . }}
   custom-provider-support.index.yaml: |+
     {{- include "osm.custom-provider-support" $root | nindent 2 }}
   {{- end }}
    
    
   ## If you would like conditional inclusion of the fragment...something like this instead
    
    
   {{- define "osm.custom-domain-model" -}}
   {{- $root := . }}
   {{- if .Values.custom.provider.flag}}
   custom-provider-support.index.yaml: |+
     {{- include "osm.custom-<provider>-support" $root | nindent 2 }}
   {{- end }}
   {{- end }}

   Note:

   Remember the yaml naming convention that is specified by wdt - filename.yaml. The index used determines the loading order when there are multiple yaml files. Indexes below 70 are reserved for internal Oracle use.
7. Add the tpl file that has the authentication provider WDT into the project specification:

   custom:
     enabled: true
     wdtFiles:
      - _custom-domain-model.tpl
      - _custom-provider-support.tpl

   You can now create an OSM instance.