Demystifying Dedicated Egress IPs in AEM Cloud Services

This post will delve into the specifics of egress IP support for Adobe Experience Manager (AEM) as a Cloud Service. We’ll cover the essential steps to enable and configure the egress IP and the port forwarding rules. While Adobe provides several comprehensive documents on this subject, this post is crafted from my experience and understanding gained while implementing egress IPs and port forwarding rules.

Egress IP:

An “egress IP” refers to an IP address used for outgoing traffic from a network. In the context of network and internet communications, traffic is typically classified as either “ingress” or “egress”:

• Ingress Traffic is incoming traffic, meaning data packets entering a network. For instance, when you access a website, the data packets sent from the website’s server to your device are considered ingress from your network’s perspective.
• Egress Traffic: Conversely, egress traffic is outgoing traffic from a network to another destination. For example, when you upload a file to a cloud server or send an email, the data packets leaving your device and moving through your network to the internet are egress traffic.

Monitoring and controlling egress traffic is crucial for security and bandwidth management in many network setups, particularly in corporate or cloud-based environments. Egress IP addresses are often used in various scenarios:

• Security and Filtering: Egress IPs can be allowlisted in external systems to ensure that only traffic from known, trusted sources is allowed. This is common in business-to-business (B2B) interactions or cloud services.
• Traffic Identification: Organizations can quickly identify and monitor the traffic leaving their network using specific egress IPs. This aids in managing network performance and detecting potential security threats.
• Compliance and Auditing: For compliance reasons, companies may need to log and audit all egress traffic, ensuring that sensitive data isn’t being sent to unauthorized destinations.

In cloud environments, such as Adobe Experience Manager (AEM) as a Cloud Service, an egress IP might define a specific route for outgoing traffic from the AEM service to other systems, like third-party APIs or integrations. This can help configure security rules and ensure seamless connectivity between different services.

In many scenarios, there’s a need to restrict access to critical services exclusively to known IP addresses, a process typically achieved through IP allowlisting. This becomes a challenge in auto-scalable cloud environments like AEM as a Cloud, where the IP addresses of servers can change dynamically. A dedicated egress IP addresses this issue by providing a consistent, identifiable IP address for all outgoing traffic. This means the dedicated egress IP can be allowed at the service level, ensuring uninterrupted access and enhanced security for the necessary services.

AEM as a Cloud currently supports the below Advanced networking options

Flexible port egress: Enable port forwarding rules to support non-HTTP/HTTPS integrations with external services like SQL and Email. When opting out of a dedicated egress IP, most configuration details are akin to those used in a Dedicated Egress IP address setup, including the ability to define port forwarding for integration with non-HTTP/HTTPS services. The primary difference lies in eliminating the nonProxyHosts configuration, as all traffic in this scenario is directed through a shared IP.

Dedicated egress IP address:

The dedicated egress IP address enables AEM as a Cloud Service to use a specific IP, allowing external services to filter incoming requests by this IP. It also supports port forwarding for non-HTTP/HTTPS service integration and lets you configure noProxyHosts to route traffic through default shared IPs instead of the dedicated egress IP.

Virtual Private Network (VPN):

A Virtual Private Network (VPN) enables AEM as a Cloud Service customer to connect their AEM environments within a Cloud Manager Program to an existing, supported VPN. This facilitates secure and controlled connections between AEM as a Cloud Service and services within the customer’s network.

Before proceeding with the configuration, decide the networking type your project requires. Remember that the network configuration type cannot be changed once created, though it can be deleted and recreated with a new kind. This post focuses on the Dedicated Egress IP Address type, but the Flexible Port Egress follows a similar process with some minor differences.

As a first step, create a new project (although an existing project can also be used) in the Developer Console with the Cloud Manager API, and ensure the necessary access rights (Deployment Manager and Business Owner) are granted to enable the network configurations.

Now, you can copy the client ID and generate the access token through the project.

Identify Region:

The AEM as a Cloud enables different regions to host the services; you must identify the region code to execute the API.

To identify the region, click on one of the environments in the cloud manager that will display the hosted region.

Region-to-region code mapping can be looked at here — Creating Programs and Environments — Cloud Manager API (adobe.com)(if you use multi-region, the network configuration needs to be enabled for all the domains)

Step1 — CreateNetworkInfrastructure

Execute the below curl command; the program ID can be identified through the cloud manager. Open the cloud program.

The organization ID can be copied from the admin console and logged into the admin console through your organization.

curl -X POST https://cloudmanager.adobe.io/api/program/{programId}/networkInfrastructures \
    -H 'x-gw-ims-org-id: <ORGANIZATION_ID>' \
    -H 'x-api-key: <CLIENT_ID>' \
    -H 'Authorization: Bearer <ACCESS_TOKEN>' \
    -H 'Content-Type: application/json' \
    -d '{ "kind": "flexiblePortEgress", "region": "va7" }'

Note the network infrastructure id (“id”:”12345") returned.

This activity may take 15 minutes. Use the curl command below to check the status.

curl -X GET https://cloudmanager.adobe.io/api/program/{programId}/networkInfrastructure/{networkInfrastructureId} \
    -H 'x-gw-ims-org-id: <ORGANIZATION_ID>' \
    -H 'x-api-key: <CLIENT_ID>' \
    -H 'Authorization: Bearer <ACCESS_TOKEN>' \
    -H 'Content-Type: application/json'

Look for status “status”:” ready.” the network infrastructure configuration is enabled now.

Traffic Routing:

Once the flexiblePortEgress is enabled at a high level, the traffic is routed by the rules below.

AEM as a Cloud Traffic Routing

HTTP/HTTPS on Standard Ports (80/443)

HTTP/HTTPS connections on standard ports (80/443) are automatically proxied out of AEM using the dedicated egress IP address. No additional code or configuration is required to support HTTP/HTTPS connections.

HTTP/HTTPS on Non-Standard Ports (e.g., 8443)

For http or https traffic going to ports other than 80 or 443, a proxy should be configured in the code using the following host and port environment variables to

• for HTTP: AEM_PROXY_HOST / AEM_HTTP_PROXY_PORT
• for HTTPS: AEM_PROXY_HOST / AEM_HTTPS_PROXY_PORT

By default, the above proxy-related variables are enabled by the cloud manager. The same can be used across OSGI, Java Code, and Dispatcher configurations. The traffic is routed through a dedicated egress IP address.

String url = "www.example.com:8443"
String proxyHost = System.getenv().getOrDefault("AEM_PROXY_HOST", "proxy.tunnel");
int proxyPort = Integer.parseInt(System.getenv().getOrDefault("AEM_HTTPS_PROXY_PORT", "3128"));
HttpClient client = HttpClient.newBuilder()
      .proxy(ProxySelector.of(new InetSocketAddress(proxyHost, proxyPort)))
      .build();

HttpRequest request = HttpRequest.newBuilder().uri(URI.create(url)).build();
HttpResponse<String> response = client.send(request, BodyHandlers.ofString());

Non-HTTP/HTTPS connections to external services

When establishing non-HTTP/HTTPS connections (e.g., SQL, SMTP, etc.) from AEM, the connection should be made via a PROXY hostname provided by AEM, and through the port forward mapping (portOrig) configured in the network settings. The traffic is routed through a dedicated egress IP address in these instances.

e.g.

portForwards": [
{
    "name": "mysql.example.com",
    "portDest": 3306,
    "portOrig": 30001
}
....
]

DriverManager.getConnection("jdbc:mysql://" + System.getenv("AEM_PROXY_HOST") + ":30001/test");

The email service should also utilize the PROXY host and the port forwarding configuration(portOrig) for sending emails. Refer to Email service | Adobe Experience Manager for more details.

No Proxy Hots:

Domains included in the nonProxyHosts will be integrated directly through shared IPs, bypassing the dedicated egress IP for routing traffic. The Adobe shared IP is designed to optimize traffic routing.

Configure flexible port egress proxies per environment:

Configure the port forwarding rules and no-proxy settings for each AEM environment. Create a JSON file containing the necessary port forwarding (to support no http/https integrations) and no-proxy configurations (refer to the sample file below).

flexible-port-egress.json

{
    "nonProxyHosts": [
        "example.net",
        "*.example.org",
    ],
    "portForwards": [
        {
            "name": "mysql.example.com",
            "portDest": 3306,
            "portOrig": 30001
        },
        {
            "name": "smtp.sendgrid.net",
            "portDest": 465,
            "portOrig": 30002
        }
    ]
}

Execute the following command to create or update the forwarding rules:

$ curl -X PUT https://cloudmanager.adobe.io/api/program/{programId}/environment/{environmentId}/advancedNetworking \
    -H 'x-gw-ims-org-id: <ORGANIZATION_ID>' \
    -H 'x-api-key: <CLIENT_ID>' \
    -H 'Authorization: Bearer <ACCESS_TOKEN>' \
    -H 'Content-Type: application/json' \
    -d @./flexible-port-egress.json

Choose the specific environment from Cloud Manager to determine its environment ID.

Execute the following curl command to verify the configurations:

curl -X GET https://cloudmanager.adobe.io/api/program/{programId}/environment/{environmentId}/advancedNetworking \
    -H 'x-gw-ims-org-id: <ORGANIZATION_ID>' \
    -H 'Authorization: Bearer <ACCESS_TOKEN>' \
    -H 'x-api-key: <CLIENT_ID>' \
    -H 'Content-Type: application/json'

Acquire the dedicated egress IP address using a DNS Resolver, like DNSChecker.org, on the host: p{programId}.external.adobeaemcloud.com. Alternatively, you can obtain it by running the ‘dig’ command.

$ dig +short p{programId}.external.adobeaemcloud.com

Now that the network configuration using Dedicated Egress IP is complete, you can add the IP address to the allowlist to enable access to restricted services and test your integrations. It’s important to note that AEM as a Cloud Service also supports various other network connectivity options for connecting with external or custom services, such as VPNs.

Note: Some operations conducted via Cloud Manager, such as identifying the environment ID, can also be performed through the Cloud Manager API.

References:

Advanced networking | Adobe Experience Manager

Configuring Advanced Networking for AEM as a Cloud Service | Adobe Experience Manager

AEM as a Cloud: IMS based SSO Authentication for Authors

AEM as a Cloud Service integrates Adobe Identity Management Service (IMS) for user verification. Various other Adobe products, including the Adobe Admin Console, also utilize this IMS authentication method. For AEM Authors in AEM as a cloud service, Adobe IMS authentication is activated, a change from previous AEM versions where identity and access management (IAM) settings had to be implemented individually on each AEM author server. With AEM in the cloud, single sign-on (SSO) configurations for AEM Authors and user and group management are centrally handled through the Adobe Admin Console using Adobe IMS.

The Admin Console enables administrators to oversee all users in the Experience Cloud from a single point. Within this console, users and groups are allocated to product profiles linked to a specific AEM as a Cloud Service instance. This arrangement permits them to access that particular instance.

To manage the Identity configurations, the role of a System Administrator is necessary.

Create a new identity Directory.

Either option is viable for enabling the SSO configuration. If Azure AD is selected, complete the setup by logging in as the admin user.

The “Other SAML providers” option facilitates SSO activation with various SAML providers. Once SAML configurations are enabled, you can obtain the ACS URL and Entity ID or choose to download the Adobe metadata file. Enable the required configurations in IDP using the ACS URL and Entity ID or the Adobe Metadata file. Once the IDP configuration is ready, the IDP metadata file can be uploaded to finalize the configurations, ensuring that SAML claims such as FirstName, LastName, Email, and Country Code are appropriately mapped.

You can test the IDP configurations, ensuring that the SSO configurations and claim mappings work as expected.

The subsequent step involves claiming the SSO domain (such as the email domain, for instance, example.com for [email protected]). If necessary, multiple SSO domains can be claimed.

Three methods are available: logging in directly to Azure Active Directory, adding a domain through Google, and adding domains via DNS proof. After verifying the domain, your SSO configurations become active and ready for use.

However, a potential challenge arises if an organization has already claimed or validated the SSO domain (mainly when a company operates with multiple Adobe Admin Console organizations). In such instances, domain validation may fail, resulting in a notification that “This domain has already been claimed.

An alternative is for the organization that has already claimed the domain to approve its use in a different organization. While user and group management remain distinct in this scenario, it’s important to note that the original organization retains control over the authentication configuration, which the new organization will use. To obtain this approval, you should follow the below-specified process.

Initiating this will send a request email to the organization that has previously claimed the domain. Once they approve, the directory becomes active. As mentioned before, no additional authentication-related configurations are necessary. The settings from the organization that initially configured this will be utilized.

SSO via the company IDP is now active. When logging into AEM Author, other Adobe products, or the Admin Console with an email corresponding to the configured domain, users will be redirected to the company’s SSO page — successful login grants access to the intended services.

If the directory configuration is enabled for an organization with pre-existing users, these users must be transitioned to Federated ID, assuming their default authentication was via Enterprise ID. This transition can be efficiently managed in bulk by downloading the user details as a CSV file, making the necessary updates, and then re-uploading the modified CSV.

Download CSV template

Choose the specified directory to download only those users associated with it who require ID-type migration.

Modify the New Identity type to “Federated ID,” update the New Email, and set the New Username to the existing email ID. For the Country code, specify the appropriate code, or use ‘UD’ (Undefined) if specifying a country code is not necessary.

After incorporating the new values for all users, upload the files. The processing might take a while, but you can monitor its progress via the “bulk operation results” section. This change in Identity Type will not affect the existing user permissions.

The SSO configuration is now complete, allowing users to utilize the company SSO to log in to the Adobe Admin Console and AEM Authors.

Select ‘Company or School Account’ on the next screen. This action directs the user to the company IDP. Upon successful login, the user will be redirected to the Admin Console or AEM Authors, depending on the initial request.

Next, follow these high-level steps to enable the necessary permissions for AEM Authors.

Create IMS Groups:

In the Adobe Admin Console, establish IMS Groups to streamline the management of users who need the same level of access. Additionally, appoint Admins to oversee each of these individual groups. Create groups specific to each environment to manage user access.

Place the users into the appropriate groups as needed.

Assign Product Profiles to the Groups:

Assign the Product Profiles to their respective groups. By default, AEM as a Cloud Service creates AEM Admin and AEM User profiles for each environment. Assign the environment specific Admin profile, or user profile, to the corresponding environment-specific groups. The admin profile grants full control over the environment, while the User profile provides basic read-only access to the specific environment. If necessary, additional product profiles can be defined. These product profiles are then synchronized with the AEM servers.

• AEM Administrators: An AEM administrator is typically assigned to developers, in particular developers who need access to, for example, the development environments. The AEM administrator’s product profile is used to grant administrator privileges in the associated AEM instance.
• AEM Users: AEM users are the users in your organization who use AEM as a Cloud Service generally to create content. These users need to access AEM to do their tasks. The AEM user's product profile is typically assigned to an AEM content author who creates and reviews the content. This content can be of many types such as pages, assets, publications, and so on. The AEM user's product profile shown below is assigned to these members.

Assign groups that require full administrator access to the corresponding environment-specific Administrator profile. The rest of the users can be added to the environment-specific AEM Users profile.

IMS groups and Members to AEM:

The IMS groups and their associated members are synchronized with the corresponding AEM environment. This membership synchronization occurs whenever a user logs into the system. This process ensures that users are accurately linked to their specific AEM access levels.

Create Corresponding Local Groups in AEM:

In AEM, create local User Groups that correspond to the IMS groups. Clearly define the specific permissions for each of these local groups within the AEM environments.

Assign Local Groups to the Corresponding IMS Groups:

Link the local groups in AEM to the relevant IMS groups. These IMS groups are automatically created and synced in AEM, along with the details of their members from IMS. Utilizing local groups in AEM for permission management, instead of adding users directly to the IMS groups, helps maintain a clear separation between IMS-managed groups and AEM local groups. This approach ensures that the IMS groups handle user membership while the local AEM groups manage the necessary permissions.

Users assigned to a IMS group in the Adobe Admin Console are typically automatically linked to the corresponding local User Group in AEM. This means that when users log into AEM, they acquire the permissions associated with the local User Group that align with their Product Profile. Consequently, when users log in through the SSO, they gain the appropriate access within the AEM system.

User Management Flow — AEM as a Cloud

If needed, you can activate automatic synchronization of IDs between Active Directory or LDAP servers and the identities created within the Adobe Console through the User Sync tool. This tool enables system administrators to align user groups from the customer’s directory with product configurations and user groups in the Admin Console. The User Sync Tool can adaptively map new LDAP groups for user membership, facilitating dynamic user group creation within the Admin Console.

The User Sync Tool is available via the Adobe GitHub repository. As an open-source tool, it offers customization options, allowing customers to tailor it to their needs. This synchronization feature includes dynamically mapping new LDAP groups for user membership in the Admin Console and creating new user groups dynamically.

References:

IMS Support for Adobe Experience Manager as a Cloud Service | Adobe Experience Manager (mktossl.com)

Create a directory for SAML-based identity providers (adobe.com)

Authenticate your users with Microsoft Azure (adobe.com)

Google SSO federation (adobe.com)

Originally published at https://www.albinsblog.com.

Follow me for upcoming blogs follow.