DEV Community: Laslo Pastor

Azure AD as a federated key manager for the WSO2 API gateway

Laslo Pastor — Fri, 12 Dec 2025 17:43:36 +0000

Intro

The need for an API Management (APIM) layer and a well-structured segmentation architecture within an organization is something most architects agree on. However, having the luxury of building a fully greenfield APIM environment from scratch is rare. In reality, most enterprises already operate legacy web services or APIs built years ago, which makes introducing a modern APIM platform a challenging process.

One of the first hurdles often faced is integration with existing Identity Providers (IdPs). Establishing a secure token exchange mechanism that the API Gateway can trust is essential, but it is not always straightforward.

A modern APIM solution should therefore offer a flexible architecture that supports horizontal scaling, fine-grained access control, and seamless identity integration using the organization’s existing IdP ecosystem.

WSO2 API Manager 4.6 addresses this challenge by natively supporting external identity providers such as Auth0, Azure AD, Keycloak, Okta, Ping Identity, and, of course, WSO2 Identity Server, along with any other IdP that supports OAuth2/OIDC.

This article examines the technical aspects and configuration details for integrating Azure AD as a Key Manager with the WSO2 API Manager Gateway, aiming to make the setup process as seamless as possible.

Requests

My client already had Azure AD B2C in place and wanted to use it as a Key Manager for the WSO2 API Manager Gateway (APIM GW). In addition, they preferred to leverage a preconfigured application instead of creating a new one from scratch.

Solution

WSO2 provides comprehensive documentation to help you get started with this setup Configure AzureAD as Key Manager.

Note 1

You’ll need an application in Azure that acts as a connector between WSO2 API Manager and Azure AD. This application must have the following permissions assigned:

Application.Read.All Application.ReadWrite.All Application.ReadWrite.OwnedBy

Although these permissions are mentioned in the official documentation, it’s worth emphasizing that missing any of them will prevent APIM from creating or locating applications within your Azure environment, causing the configuration to fail.

Note 2

Setting up a new Key Manager in the WSO2 Admin Portal is the first challenge you’ll need to overcome.
From the dropdown list of available Key Manager Types, select Azure AD, and ensure that at least the Direct Token Issuance method is enabled.

You can find the relevant endpoint information under the Endpoints section in your Azure AD application.

However, keep in mind that while many fields in the WSO2 configuration are mandatory, Azure AD does not utilize all of them. As a result, some fields may appear redundant and can remain unused. Your configuration fields should look similar to the following:

Well-known URL , mandatory
(Paste the OpenID Connect metadata document (v2.0) URL collected from the endpoints and click on Import)
In my case :

https://login.microsoftonline.com/{tenantID}/v2.0/.well-known/openid-configuration

Issuer , mandatory
(in documentation example is https://login.microsoftonline.com/{tenent-id}/v2.0). If you leave it like that will fail becouse token issuer in reality looks like 'https://sts.windows.net/{tenent-id}/'
In my case,

https://sts.windows.net/{tenent-id}/

Client Registration Endpoint , mandatory
In my case:

https://graph.microsoft.com

Introspection Endpoint, marked as mandatory, but AzureAd does not use it
I put:

https://login.microsoftonline.com/{tenent-id}/oauth2/v2.0/token

Token Endpoint, mandatory
In my case:

https://login.microsoftonline.com/{tenent-id}/oauth2/v2.0/token

Revoke Endpoint, marked as mandatory, but AzureAd does not use it
I put (again):

https://login.microsoftonline.com/{tenent-id}/oauth2/v2.0/token

Userinfo Endpoint, mandatory
In my case:

https://graph.microsoft.com/oidc/userinfo

Authorize Endpoint, not mandatory
In my case:

https://login.microsoftonline.com/{tenent-id}/oauth2/v2.0/authorize

Scope Management Endpoint, in the form, it is marked as mandatory, even though the documentation doesn’t clearly explain its purpose, and in practice, it doesn’t seem to be used. I entered the scope required when requesting a token, but in reality, any value will work without affecting functionality.
In my case:

https://graph.microsoft.com/.default

Also, for clarity: wherever you see {tenantID} in the endpoint URLs mentioned above, make sure to replace it with your actual Azure tenant ID.

The rest of the steps you can follow from the documentation
Fill the Consumer Key Claim URI: appid in the Claim URIs section.
Set the Grant Types: client_credentials (Only use this grant type).

Microsoft Graph API Endpoint:

https://graph.microsoft.com

Microsoft Graph API Endpoint Version, select the checkbox for v1.0
Client ID : Paste the Application (client) ID
Client Secret : Paste the client secret value that is generated

Key Manager Permission: Permission type for role-based Key Manager restriction.
e.g., PUBLIC, ALLOW, DENY

Note 3

After completing these steps, you can navigate to the WSO2 Developer Portal to create an application, generate keys (Client ID and Secret), subscribe to an API, and obtain an access token. Once you invoke the API, the call should return a 200 OK response confirming that everything is working as expected.

Congratulations, you’re on the right track and officially halfway there!

Note 4

To enable the option for out-of-band keys, allowing you to use an existing application previously created in Azure, open the /repository/conf/deployment.toml file in a text editor.
Add the following configuration under the [apim.devportal] section:

[apim.devportal]
enable_key_provisioning = true

After restarting the server, you’ll be able to register applications in the Developer Portal using the Client ID and Client Secret that were previously created in Azure.

Note 5

When you create an application in Azure, the Application ID URI field is empty by default. This causes a problem, tokens generated from such an application will fail, returning an error indicating that the application cannot be found under the specified tenant.

To fix this, make sure to define the Application ID URI in the following format:

api://<Application (client) ID>

Although this step is briefly mentioned in the post-check section of the documentation, it isn’t clearly explained where to find or configure it. So, take a moment to verify this setting before proceeding — it will save you unnecessary troubleshooting later.

Happy coding!

If you run into any issues or discover new challenges along the way, feel free to share them in the comments — I’d love to hear your experiences and help if I can.

Building a Customer Data Nerve Center with Twilio Segment, WSO2, and Asgardeo

Laslo Pastor — Sat, 23 Aug 2025 04:09:57 +0000

In today’s world, data isn’t just an asset but a continuous thread connecting every customer interaction. Whether a customer is browsing your website, chatting with support, or completing a purchase, their journey should feel like one continuous story. The challenge? Ensuring that the story remains consistent, secure, and compliant across every channel.

One powerful approach is to orchestrate Twilio Segment (for customer data collection), WSO2 (for integration and API governance), and Asgardeo (for identity and consent management). Together, they form an identity-first data pipeline, a central nervous system that feeds analytics, personalization engines, and even an AI-driven decision engine.

The Reference Architecture

Think of this setup like the scout battleship that continuously senses, interprets, and routes signals across the enterprise.
• Twilio Segment: Captures events from websites, apps, and backend systems, from page views to purchases. Profiles evolve from anonymous to verified identities once a login happens.
• Asgardeo: Secures that identity with SSO and MFA, while governing consent preferences to ensure privacy.
• WSO2 API Manager: Acts as the deflector shield, validating and securing every inbound request before it touches core systems.
• WSO2 Micro Integrator: Orchestrates data flows, enriching raw events with business context (e.g., CRM details, product metadata) before routing them to downstream consumers (data warehouse, marketing automation, or analytics platform).

Why This Matters

With this approach, customer profiles stay consistent across all channels. Compliance is built into the process, with consent preferences enforced at the identity layer. And each team in your organization can get the data they need in the tools they already use, without fragile point-to-point integrations.
The result: less friction, fewer silos, and more agility.

Current Limitations

As always, there are challenges.

Anonymous activity is hard to connect to a known customer until they log in, which can leave profiles incomplete.
Consent changes in one channel might not appear instantly across all systems.
Without careful governance, there’s a risk of collecting more data than necessary or capturing sensitive information without permission.
Adding routing and enrichment, and orchestration steps can introduce a delay for real-time personalization.

Where AI Can Help

AI has the potential to make this architecture smarter and more proactive.

AI can improve identity discovery, linking anonymous activity to known profiles by recognizing patterns in behavior.
AI can create dynamic customer segments based on predicted data or mitigate the risk, rather than static definitions.
AI can recognize unusual patterns in the data flow, such as a sudden drop in conversions, and create an alert before it becomes a bigger issue.
AI-driven engines with fresh customer data can personalize offers and content in real time.

Future Improvements

Looking ahead, there’s room to make this architecture even more powerful.

Real-time feedback loops could be made even faster, delivering insights in milliseconds instead of minutes. Consent could be managed through a single, unified service that updates instantly across every connected system. AI could play a bigger role in governance, automatically flagging irrelevant or risky data fields before they cause problems. And eventually, the pipelines themselves could adjust automatically, optimizing data flows based on business priorities and performance.

Final Thoughts

The real magic happens when you connect this architecture to an AI-powered future. Right now, Twilio Segment, Asgardeo, and WSO2 ensure that customer data is accurate, secure, and delivered where it needs to be. But when you add Apache Kafka as the real-time backbone, the game changes.

Kafka allows enriched events from WSO2 Micro Integrator to be streamed instantly to any number of systems. That means marketing platforms, analytics dashboards, personalization engines, and AI models can all tap into the same live data without slowing each other down. Adding or replacing a data consumer becomes a matter of configuration, not an integration project.

From there, the Analytics and AI layer, powered by platforms like Snowflake, Databricks, or Google BigQuery, turns this data stream into insight and action. AI models trained on historical and real-time data can predict customer churn, recommend next-best actions, flag anomalies in user behavior, or identify high-value prospects before they’re even on your radar.

The benefits are tangible:
• Marketing campaigns can adjust automatically when engagement patterns shift.
• Support teams can proactively reach out to customers showing early signs of dissatisfaction.
• Product teams can make design or feature decisions backed by live usage data rather than waiting for quarterly reports.

Instead of simply reporting on what happened, the system evolves into an anticipation engine that predicts needs and enables the business to respond in the moment. Kafka ensures that the right data is always in motion, and AI ensures that every piece of it is turned into intelligence that drives results.

Summary

Combining Twilio Segment for data collection, Asgardeo for identity and consent, and WSO2 for secure integration creates a scalable, compliant, and future-ready customer data platform. Add Kafka for real-time event streaming and an AI-powered analytics layer, and the system becomes far more than a pipeline — it becomes a proactive decision-making engine that helps you understand, anticipate, and delight customers at every step of their journey.

Integration thought iteration-The not Bad, the OK, and the Good Enough

Laslo Pastor — Sat, 13 Apr 2024 21:52:02 +0000

In response to a recent request to enhance the pickup system for a transport and storage company, I embarked on a series of iterations to develop viable solutions. This article delves into the evolution of ideas and presents three potential solutions that were considered before identifying the one deemed "good enough" for implementation.

Problem

A storage company operates multiple locations where products are stored. When they receive shipping requirements, they must gather pickup orders from various locations to fulfill the required quantities of each product. The individual responsible for creating the pickup list must determine the closest storage location and verify if there is a sufficient quantity of the required product available. If the required quantity is not available, they need to check the next storage location until the quantity requirement is met. This process must be repeated for every product on the list.

Solution 'not Bad' - The first iteration

Exposing database data as a REST Data Service offers significant benefits, providing a straightforward way to access and manipulate data. Additionally, calling SQL procedures as a REST resource facilitates seamless integration into applications, simplifying the development process and enhancing overall efficiency.
However, ensuring controlled and secure access for external users requires the utilization of API management gateways.

The primary enhancement was implementing an SQL procedure that utilizes ZIP code search to locate the nearest storage facilities and populate the pickup list until a sufficient quantity of the requested product is not found.

CREATE DEFINER=db_753@73.232.207.137PROCEDUREcloud_demo.orderList`(IN productID INT, IN zip CHAR(5), IN qty DECIMAL(5,2))
BEGIN
DECLARE done BOOLEAN DEFAULT FALSE;
DECLARE c_zip VARCHAR(5);
DECLARE c_address VARCHAR(255);
DECLARE c_product_name VARCHAR(255);
DECLARE c_quantity DECIMAL(5, 2);
DECLARE totalQuantity DECIMAL(10, 2) DEFAULT 0.00;

DECLARE orderCursor CURSOR FOR
     select s.Qty, s2.zip, s2.Address,p.Name from 
     Stock s inner join Product p on s.product_id = p.id inner JOIN Storage s2 on s.storage_id = s2.id 
     where p.id = productID and s2.zip like zip
     ORDER by s.Qty DESC, s2.zip;

-- Declare handler for cursor
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

-- Temporary table to store product quantities
CREATE TEMPORARY TABLE IF NOT EXISTS tempProductQuantityPerZip ( 
    t_prod_quantity DECIMAL(5,2),
    t_zip VARCHAR(5),
    t_address VARCHAR(255),
    t_product_name VARCHAR(255)
);  

Delete FROM tempProductQuantityPerZip;
set totalQuantity = 0;

-- Open cursor
OPEN orderCursor;

-- Start iterating over the returned list
read_loop: LOOP
-- Fetch data from cursor into variables
FETCH orderCursor INTO c_quantity,c_zip,c_address,c_product_name;

    -- Check if cursor has reached the end of the result set
    IF done THEN
        LEAVE read_loop;
    END IF;

    IF totalQuantity < qty then
     INSERT into tempProductQuantityPerZip(t_prod_quantity,t_zip,t_address,t_product_name) VALUES (c_quantity,c_zip,c_address,c_product_name);
    END IF;

   SET totalQuantity = totalQuantity + c_quantity;

 END LOOP read_loop;

-- Close cursor
CLOSE orderCursor;

Select * from tempProductQuantityPerZip;

END`

To create RDBMS Datasource, I used WSO2 MI
full db script can be found in the GitRepository

Solution 'the OK' - The second iteration

The primary issue with the initial solution is its limitation to process only one product request at a time. Furthermore, in the event of a database unavailability, requests may be lost. To address this, the new solution introduces an additional API that exposes an integration synapse named 'callDataService', enabling the handling of multiple product requests simultaneously.(with Iteration mediator).
To enhance resilience, the new API exposes a resource that stores requests in the Kafka message queue.(used Kafka connector), using a Kafka inbound endpoint, a specific topic is monitored to direct received message to the 'callDataService' integration.
The final challenge arose from receiving an array of information containing product IDs, quantities, and store details, request was to group this information by storage location and list the products to be picked from each location. For this we used
Script mediator (Big thanks goes to Arunan Sugunakumar).
The final addition was the development of the 'sendEmail' integration synapse, which accepts the payload, iterates through it, and sends an email to each store with information regarding the products and quantities that need to be prepared for pickup.(used Email connector)

Solution 'Good Enough' - The third iteration

Ultimately, to accommodate the final requirement of enabling requests through a JSON file dropped in an FTP location, I implemented an SFTP watcher. This watcher monitors files with a .json extension, parses them, and then sends them to a Kafka message queue.
To achieve I used File inbound endpoint connector

Note: don't forget to URL encode your password when creating a connection string (it took me a while to figure out why my connection wasn't working)

Summary:
All connectors used in the solution and much more can be found on th WSO2 store.
The whole MI solution can be found on GitRepository.
The journey of refining and enhancing your solution knows no bounds, and it all begins with that very first step. And as Gandalf the Gray said: "..It's a dangerous business, going out your door. You step onto the road, and if you don't keep your feet, there's no knowing where you might be swept off to..."

Identity events and conditional authentication

Laslo Pastor — Wed, 10 Apr 2024 02:03:15 +0000

In today's fast-paced digital landscape, application developers face a hard job: meeting high business demands while ensuring a seamless and secure login experience. The task becomes even more challenging when considering the need for resilience, ease of implementation, scalability, and adherence to tight timeframes.
Modern Identity and Access Management (IAM) solutions are designed to accommodate evolving business needs while remaining developer-friendly.In essence, the quest for an ideal login experience is neverending, but with the right IAM solution, developers can perform modern application development with confidence and ease.

Recently, I had a task to implement a solution supporting a self-sign-up process and providing users with limited-time access to applications until they've subscribed for full access.

Solution proposed

The application redirects users to the Identity Provider (IDP) during the login process (configuration needs to be provided). The IDP will facilitate self-registration, creating a user profile in an external persistent store, such as a MySQL database, with a trial period. Subsequently, an external payment system will alter the user's status in the database upon successful payment confirmation.

During the login flow, upon successful user identification, the application will verify the user's status in the external database. If the user attempts to log in during the trial period, access will be granted. However, if the user tries to log in after the trial period and payment confirmation is pending, access will be denied.

The WSO2 Asgardeo is used as IDP and Choreo as an Integration platform.

Database setup

I have used the publicly available MySQL database and created a simple table with the following DDL.

CREATE DATABASEcloud_demo; CREATE TABLEUsers(idint NOT NULL AUTO_INCREMENT,userNamevarchar(55) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL,allowAccessint NOT NULL,endSubdate NOT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB AUTO_INCREMENT=56 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

IDP setup

In Asgardeo created an organization YDNC.
In Login&Registation, click on Self Registration and enable it.

In the Event section check the Registration events.

From here if you can click on 'Go to Choreo', note that you need to have a valid subscription and organization with the same name.

Choreo setup

Create a CRUD service and expose it as an API

Click on the 'Create' button above Component Listing and choose Service.

Note that you will need a GitHub repository with your code. I have used Ballerina, a cloud-native language optimized for integration.
Creating the REST API service to connect with DB to support the CRUD command is straightforward.

`service /company on new http:Listener(8090) {

isolated resource function post user(@http:Payload User payload) returns error? {
    sql:ParameterizedQuery insertQuery = `INSERT INTO Users (userName,allowAccess,endSub) VALUES (${payload.userName}, ${payload.allowAccess}, DATE_ADD(now(),interval 5 day))`;
    sql:ExecutionResult _ = check mysqlClient->execute(insertQuery);
}

isolated resource function put user(@http:Payload User payload) returns error? {
    sql:ParameterizedQuery updateQuery = `UPDATE  Users SET allowAccess=${payload.allowAccess},
                                         endSub=${payload?.endSub} where
                                         userName= ${payload.userName}`;
    sql:ExecutionResult _ = check mysqlClient->execute(updateQuery);
}

isolated resource function get users(string userName) returns json|error {
    sql:ParameterizedQuery selectQuery = `select userName,allowAccess,endSub from Users where userName=${userName}`;
    stream <User, sql:Error?> resultStream = mysqlClient->query(selectQuery);
    User[] users = [];

    check from User item in resultStream
        do {
            users.push(item);
        };
    return users;
}

isolated resource function post risk(@http:Payload RiskRequest payload) returns User|error? {

    sql:ParameterizedQuery selectQuery = `select userName,allowAccess,endSub from Users where userName=${payload.userName}`;

    stream <User, sql:Error?> resultStream =  mysqlClient->query(selectQuery);
    User[] users = [];

    check from User item in resultStream
        do {
            users.push(item);
        };
    return users[0];
}

isolated resource function delete user(string userName) returns error? {
    sql:ParameterizedQuery deleteQuery = `DELETE FROM Users WHERE userName = ${userName}`;
    sql:ExecutionResult _ = check mysqlClient->execute(deleteQuery);
}

Git-hub repository https://github.com/lpastor74/db_crud

Once your component is created you can publish it and set up a configuration per environment.

API Service is public and it will be visible in the developer portal.

Create an application and subscribe to API. In the credential section note the ClientID, Secret, Token Endpoint, and API service URL because you will need it to finish the setup of the webhook component.

Create a webhook

Click on the 'Create' button above Component Listing and choose Webhook. The code to handle the 'add user' event checks if the method is 'SELF_SIGNUP' and connects to API service and in DB creates the record with the user name and sets up the allowAccess value to 0 as forbidden.

`remote function onAddUser(asgardeo:AddUserEvent event ) returns error? {
log:printInfo(event.toJsonString());

  json __user = event.toJson();

  string method  = check __user.eventData.userOnboardMethod;
  if(method=="SELF_SIGNUP")
  { 
       string userNameStr  = check __user.eventData.userName;
       log:printInfo(userNameStr);
       http:Client http_Client = check new (_endUrl, 
         auth = {
                 tokenUrl: _tokenUrl,
                 clientId: _clientId,
                 clientSecret: _clientSecret
         });
         log:printInfo("...sending...");
         anydata|http:ClientError unionResult = check http_Client->/user.post({
             userName: userNameStr,
             allowAccess: 0
         });
  }    
}`

Git-hub repository https://github.com/lpastor74/asgrd-hook
Once your component is created you can publish them and set a configuration per environment.

Note that the configuration of the webhook is populated automatically and you are only responsible for filling up the configuration to allow connecting to your REST API created in the previous section

Create an application in IDP

I chose a single-page application and the Sample React application provided in the QuickStart tab to run it locally, to simulate the login flow.
Don't forget to update the app with your configuration (ClientID, Base URL, Redirect URL, and Scope). All details are in the Quickstart section.

in Login Flow enable Conditional Authentication and put the following code

`var errorPageParameters = {
'status': 'Unauthorized',
'statusMsg': 'You need have valid subsription.'
};

var errorPage = '';

var onLoginRequest = function(context) {
executeStep(1, {
onSuccess: function(context) {
var today = new Date();
var user = context.currentKnownSubject;
Log.debug('UserName of ' + context.currentKnownSubject.uniqueId + ' is : ' + user.username);

        var connectionMetadata = {
            "url": "https://URLtoPublicAPIservice/risk",
            "consumerKey": "xxxxxx",
            "consumerSecret": "xxxxx",
            "asgardeoTokenEndpoint": "https://api.asgardeo.io/t/ydnc/oauth2/token"
        };

        var requestPayload = {
            "userName": user.username
        };

        callChoreo(connectionMetadata, requestPayload, {
            onSuccess: function(context, data) {
                Log.info("Successfully invoked the Choreo API.");
                Log.info(data.userName);
                Log.info(data.allowAccess);

                if (data.allowAccess == 0) and (today > data.endSub){
                    Log.debug('User ' + context.currentKnownSubject.uniqueId + ' dont have valid subscription.');
                    sendError(errorPage, errorPageParameters);
                }

            },
            onFail: function(context, data) {
                Log.info("Error occurred while invoking the Choreo API.");
                Log.info(data);
            },
            onTimeout: function(context, data) {
                Log.info("Invoking Choreo API timed out.");
                Log.info(data);
            }
        });
    }
});

};`

Test everything

Locally, start the React application on https://localhost:3000

On login, the user will be redirected to Asgardeo and SignIn form (please, observe I branded the form ;)) will have the option to Register.

The user will populate the required field, and if he wants, some of the optional ones.

Upon successful account creation, we can observe runtime logs in Choreo indicating that the event was triggered.

And in DB we have a new record with the user email, status 0, and endSub date set 5 days in the future.

If the user tries to access during these 5 days login will be successful but after that (if the status is not set to 1) he will get the following message.

Note that I have not covered the part where, after valid payment, the user status is changed in DB from 0 to 1.
Integrating with the publicly exposed API will be straightforward. You just need to make a PUT call to the /user method and include the following payload.
{ "userName": correctUserName, "allowAccess": 1 }

Final note
All functionality presented here is available out of the box and with a free subscription.
Good luck and happy coding

IDP init SAML SSO login flow

Laslo Pastor — Tue, 07 Nov 2023 03:40:43 +0000

This article covers the initiation of the Identity Provider (IDP) over Security Assertion Markup Language (SAML) Single-Sign-On (SSO) login flow, serving as a quick setup guide. If you have any comments or suggestions, please feel free to reach out to me.

Use case:
Is IDP init right for my organization?

Simplifies experience by requiring an identification process before accessing any Service Providers (SPs).
Ensures a consistent user experience across various channels and services.
Establishes a centralized hub for maintaining a consistent level of security across all resources, incorporating Multi-Factor Authentication (MFA), biometric verification, or adaptive login.

I will try to explain possible scenarios with Azure Microsoft Entra ID (AEID) and WSO2 IS platform.
Both can be used for free. Microsoft Entra ID has a free tier and WSO2 is open source and the version downloaded from the site can be used free for preproduction env.

Setup WSO2 IS

Download it, unzip it, setup JAVA_HOME, run it. (a good place to start is WSO2 IS documentation

Note: WSO2 IS version 7 will be released by the end of Nov 2023. The full B2B concept will be implemented as a first-class citizen functionality. This concept started first in the WSO2 SaaS platform [Asgardeo].(https://wso2.com/asgardeo/)

After logging in to IS, you will be at the root organization level.

go to https://localhost:9443/console (if you haven't changed anything in /repository/conf/deployment.toml file the platform should run on the default 9443 port) and log in with admin/admin (username/password)

Create the organizational structure (ORG_A, ORG_B,ORG_C,ORG_D)

Create an application at the root level in my case with the following settings

name : Simple SAML app

Issuer: simple_saml_app

Assertion consumer service URLs:
http://localhost.com:8080/saml2-web-app-pickup-manager.com/home.jsp

Note: Issuer is used to uniquely identify your service/application, while Assertion consumer service URLs is URL where your application will receive SAML assertion from IDP. In my case, I'm using the demo application found on WSO2 Samples page.

Finally, shared the application with ORG_D.

Note: You need to check it the 'Enable IdP initiated SSO' in the Protocol tab.

Setup Azure

Go to Azure/MS Entra ID/Enterprise application/ and create a new one by clicking on the 'Create your own application' button. In my case, I named it IDPInit. Choose 'Single sign-on from the left menu and choose SAML application.

Edit Basic SAML Configuration with the following:

Identifier: IDPInit

Reply URL (Assertion Consumer Service URL):
https://localhost:9443/samlsso?spEntityID=simple_saml_app&fidp=OrganizationSSO&org=ORG_D

Note: If you want to change from the SAML application and redirect login flow to the OIDC application the Reply URL should look like this:
Reply URL (Assertion Consumer Service URL):
https://localhost:9443/oauth2/authorize?client_id=[oidc_app_client_id]&fidp=OrganizationSSO&org=ORG_C&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fpickup-manager%2Foauth2client&response_type=id_token&scope=openid

Download the Certificate (Base64) and Federation MetadataXML and save it (you will need later)

Go back to WSO2 IS

Switch to sub-Organization D and create a new Standard based connection with SAML protocol.
name: IDPInit (same as we defined in Azure)

Service provider entity ID: IDPInit
Upload the XML metadata we downloaded from Azure.

Upload the downloaded certificate.

Go to the application, and choose the Simple SAML app.
In Sign-in Method and in Classic Editor choose 'Start with Default configuration'.

Remove 'Username and password; and add 'IDPInit' Authentication connector

Back to Azure Again

Assign a user(s) that should have the right to log in with the IDPInit application.

while you are there note the attributes and claims that will be passed in SAML accertion.

In the Properties section, you will find the User access URL link that can be used to initiate the flow. This is the link that your application will redirect the user to start the login flow.

Claims mapping

When you finish the login flow, the following popup will indicate that the required claim received from SAML assertion is not mapped to the application.

Fill out the claim mapping in the WSO2 'IDPInit' Authentication connector

The correct values for External IdP Attribute can be found on Azure in Attributes & Claims section.

Good luck!