---
schema_version: "1"
id: 0ea25fc1a6cf1604ec31ac60aeeef3d753d07fbab0e99ae7822ca58d37f0335e
title: Developing a Custom Policy Using the Event Authentication Extension
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-gateway/policies-custom-set-authentication-example.md
canonical_url: https://docs.mulesoft.com/mule-gateway/policies-custom-set-authentication-example
source_site: docs.mulesoft.com
content_type: documentation
content_hash: fdcfbd1d1b33c8015311f1921d45e9b4a59a0b7c9c4b2e921c8b2ea332e5d7d0
description: MuleSoft Documentation Site
latest: true
---
---
product: Mule Gateway
---

# Developing a Custom Policy Using the Event Authentication Extension

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can use an Event Authentication Extension to propagate a client ID property, using the
authentication data of the Mule event. To develop and implement a custom policy using the Event
Authentication Extension, you must understand the steps involved:

1.  Evaluate your use case based on the [use case](#use_case) provided.

2.  [Set up your project](#set-up-the-project).

3.  [Create the YAML configuration file](#create_the_YAML).

4.  [Implement your custom policy](#implement_the_policy).

5.  [Upload your custom policy to Exchange](#upload_to_exchange).

6.  [Apply your custom policy](#apply_custom_policy).

## The Use Case

ProTeams is a sports-management application that enables its users to manage team and sports
activities. ProTeams users can perform actions on behalf of their teams, such as participating in
chats with other teams, organizing exhibitions or friendly matches, and confirming tournament dates.

Each team has a client application in Anypoint Platform, and uses a Client ID Enforcement policy to
validate requests to their site. To keep the team management tasks hidden from the players, separate
IDs are created for managers and for players.

Team owners and managers can proxy for the players for specific tasks if required. Players can also
perform tasks for the team, such as setting up practice matches or initiate chat messages with team
members.

Because every user ID is mapped to the team’s client ID, it is propagated with every transaction
made by any user ID. When the client ID is injected into the authentication data of the Mule event,
Mule generates analytics data for the client application. ProTeams uses this application analytics
to review the team transactions in the application.

To create this player ID and team client ID mapping, the team owners need to develop a new custom
policy that retrieves the user IDs from a header called `userId` on the request. The user IDs can
also be obtained using query parameters. The policy then performs the mapping.

ProTeams uses this example as a starting point and then adds their own mapping logic to it.

## Setting Up the Project

ProTeams develops a custom policy by first creating a
[custom policy archetype project](https://docs.mulesoft.com/mule-gateway/policies-custom-getting-started). Then ProTeams runs the
archetype, replacing the values shown in this example.

Then ProTeams copies the directory to their workspace, and replaces the `groupId` and `artifactId`
values in the `pom.xml` file to match their own:

- Replace `<groupId>_YOUR_GROUP_ID_</groupId>` with the ProTeams Organization ID, which in this case
  is `Group2234`.

- Replace `<artifactId>_set-authentication-policy_<cd/artifactId>` with the required Artifact ID,
  which in this case is `map-to-authentication-policy`.

Additionally, you can add or modify other elements, such as version and dependencies, if required.

## Creating the YAML Configuration File

After ProTeams sets up the project, they start by defining the input parameters of the policy to be
configured in API Manager.

The following code snippet shows an example YAML file for the policy UI:

```YAML
id: Map To Authentication
name: Map To Authentication
description: Maps input user identifier to the associated Client ID, and propagates it via the authentication data
category: Custom
type: custom
resourceLevelSupported: true
encryptionSupported: false
standalone: true
requiredCharacteristics: []
providedCharacteristics: []
configuration:
  - propertyName: userIdExpression
    name: User Identifier Expression
    description: Mule Expression used to extract the user identifier value from API requests
    type: expression
    defaultValue: "#[attributes.headers['fks_user_id']]"
    optional: false
    sensitive: false
    allowMultiple: false
```

In the example, the YAML file contains just one configuration property, which is a DataWeave
expression field, to determine from which request attribute to extract the user ID.

The `name` and `description` parameters are the display title and description of the property,
respectively. The `type` parameter indicates that the field value must be a DataWeave expression,
and the `defaultValue` parameter specifies the suggested field value in API Manager when configuring
the policy. The `optional` parameter is set to `false`, indicating that this field is mandatory.

For more information about how to set up of the YAML file, see
[YAML Configuration File](https://docs.mulesoft.com/mule-gateway/policies-custom-mule-4-reference#yaml-configuration-file).

## Implementing the Policy

After ProTeams has defined the input parameters for their policy, they can start implementing their
policy by:

1.  [Adding a new server in their Maven `settings.xml` file](#add-server_in-settings).

2.  [Adding extra dependencies in the `pom.xml` file.](#add_dependencies_in_pom)

3.  [Adding conditions in the `template.xml` file.](#add_conditions_in_template)

The Event Authentication Extension is available in the Mule EE Nexus repository. The POM file in the
example already holds a reference to the repository, and is configured with a credentials alias
named `releases-ee`. You can rename this alias if required.

### Add a Server in the settings.xml File

To have access to the repository, ProTeams needs to add the corresponding server in their Maven
settings file:

```XML
<servers>
      <server>
         <id>releases-ee</id>
         <username>your_username</username>
         <password>your_password</password>
       </server>
</servers>
```

### Add Dependencies in the pom.xml File

After adding a new server in their Maven `settings.xml` file, ProTeams then adds dependencies such
as the Event Authentication and the HTTP Policy Transform extensions to the `pom.xml` file, for the
policy to perform specific actions:

```XML
    <dependencies>
        <dependency>
            <groupId>com.mulesoft.anypoint</groupId>
            <artifactId>mule-event-authentication-extension</artifactId>
            <version>${authenticationExtensionVersion}</version>
            <classifier>mule-plugin</classifier>
        </dependency>
        <dependency>
            <groupId>com.mulesoft.anypoint</groupId>
            <artifactId>mule-http-policy-transform-extension</artifactId>
            <version>${httpPolicyTransformVersion}</version>
            <classifier>mule-plugin</classifier>
            <exclusions>
                <exclusion>
                    <groupId>org.mule.connectors</groupId>
                    <artifactId>mule-http-connector</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
    </dependencies>
```

For more information about how to create your own connector in Java, see
[Getting Started with the Mule SDK for Java](https://docs.mulesoft.com/mule-sdk/latest/getting-started).

### Add Conditions in the template.xml File

ProTeams now needs to add functionality logic to the `template.xml file` to enable the policy to
perform tasks, such as the ID mapping for ProTeams.

Because ProTeams value mapping is not available in a Mule extension, ProTeams must create and add
their own custom module.

## Uploading to Exchange

To upload the custom policy to Exchange, ProTeams must verify that their `pom.xml` file is correctly
configured for their organization.

### Task Prerequisites

Before uploading their policy to Exchange, ProTeams must verify that:

- A new server is created in their Maven `settings.xml` file, with a unique ID, and username and
  password of the Exchange credentials for their organization.

- The URL matches their region.

  **Warning:** When you perform similar actions to create your own custom policy, note that the
  template uses the URL that corresponds to the US region. If your account does not belong to this
  region, change this value.

- The repository ID matches the one from the Maven settings.

  You can define an alias to that repository using the name tag.

To upload the policy to Exchange:

1.  ProTeams goes to their policy `pom.xml` file\` and locates the `distributionManagement` section:

    ```XML
    <distributionManagement>
        <repository>
            <id>your_server_id</id>
            <name>My Repository</name>
            <url>${exchange.url}</url>
            <layout>default</layout>
        </repository>
    </distributionManagement>
    ```

2.  After ProTeams verifies the server configuration, they begin uploading their policy to Exchange
    using the following command:

```console
> mvn deploy
```

The custom policy that ProTeams developed is now uploaded to Exchange.

## Applying the Policy

ProTeams next applies a custom policy the same way as they apply a default policy. When they go to
API Manager, they can see the new policy available and ready to configure and use.

To view the full custom policy example, see the Github repository
[custom policies examples](https://github.com/mulesoft/api-gateway-custom-policies-examples).