Exposing Service via API Manager Platform for Kubernetes (APK) with integrating with Asgardeo as an IdP with B2B use case and Scaling
As a start, refer to Quick start guide on how the default IDP works. This article will focus on and how Asgardeo and its organization structure can be used when it is configured as the IDP with the WSO2 APK for B2B scenario.
First of all lets start with the default token issue provided with the APK which will be used to access system APIs (deploy, config, token, etc) and to invoke the organization related APIs (which is deployed for application developers to subscribe and use it in their applications)
There are two main sections in this article where we use the default IDP and WSO2 Asgardeo as Key Manager
The steps will be as follows
- Creating APK configuration file using the OAS file generated
- Deploying the API
- Generating tokens
- Invoking the API (for simplicity, the APK will be deployed on the local machine in Minikube)
Prerequisites
- Install APK using the Quick Start Guide
- Have a service hosted with a Open API Specification (OAS): For this article, I will be using a Ballerina service hosted on the Choreo platform which you can refer in Github repository. Refer to blog on how to host Ballerina service on Choreo. The deployment will be as follows
- Since a Ballerina is used to create a service, it is needed to generate as open API specification (OAS) for the Ballerina service. It is possible to generate the OAS using ballerina it self using the below command.
bal openapi -i service.bal --json- The OAS will be generated in the same folder which the service.bal file resides.
Integrating WSO2 Asgardeo with the APK for Key Management
Configurations and steps in Asgardeo
Follow the steps in Asgardeo integration guide in documentation up to 4th step.
At the end of the 4th step, there will be a super organization and a sub organization.
Then is it needed to add users to use the systems APIs (inorder to deploy and manage APIs from the super organization) and organization APIs (in order to invoke the APIs). Is it possible to do those using navigating to the user management section.
Creating roles in Asgradeo
To invoke the APK system APIs to deploy the organization APIs, the user needs to have the apk:api_create scope. Ir order to do that, it is needed to do the following
- create a API resource add the requested permission
- Attach the API resources that can be accessed to the application
- Map the API resources to roles
- Finally attach the application roles to the user groups
The following is a diagram on the mapping of the above sections to get a better understanding.
Configuring the Asgardeo as the IDP for APK
After that, we need to configure the token issuer for the system APIs and the token issuer for the organizations.
The following is the configs that will be used for the current APK deployment
In the system token issuer (right side config), the claim value for the remoteClaim was configured as the org_id since the token generated by the user in the main organization will contain its organization id in org_id and it will be used to identify the owner organization of the API. Also note the system token issuer value for the organization is given as “apk-system”
As it can be seen, for the org token issuer (left side config), it is given the main organization id as abc077f4-ae13–410a-b510-ccadb5e0dca4 (which is the main organization id) and the claim value for the remoteClaim as org_id which will be received by the main organization’s value in the user token. This will verify when the sub organization user invokes an API using the token and access will be denied if it is not the same. Sample user token from the sub organization will contain the following. The user_organization which is the sub organization id and the org_id as the main organization id.
Find the configs at Github link1 and link2
Then the two tokenIssuers are deployed using the following commands.
kubectl apply -f idp-system-token-issuer.yaml
kubectl apply -f idp-org-token-issuer.yamlAnd using kubectl get tokenIssuer command, it is possible to see the whether the config is applied correctly.
The tokens can be generated using the postman, which provides you the capability to get the access token with authentication code grant type.
Deploying the API
First, the APK-Conf needs to be created. This is where the OAS spec is needed which was mentioned in the prerequisites. The following command is used to generate the conf file with the token received by the Asgardeo token endpoint by the user in the main organization.
curl -k --location 'https://api.am.wso2.com:9095/api/configurator/1.1.0/apis/generate-configuration' \
--header 'Host: api.am.wso2.com' \
--header 'Authorization: bearer eyJ4NXQ-----------lLy6tO8HYw' \
--form 'definition=@"/Users/ramindu/wso2/general_demo/APK/ecom_rest_openapi.json"'Once it the IDP is configured, the API can now be deployed in the APK with the same token received.
curl -k --location 'https://api.am.wso2.com:9095/api/deployer/1.1.0/apis/deploy' \
--header 'Host: api.am.wso2.com' \
--header 'Authorization: bearer eyJ4NXQ-----------lLy6tO8HYw' \
--form 'apkConfiguration=@"/Users/ramindu/wso2/general_demo/APK/ecom-rest-service.apk-conf"' \
--form 'definitionFile=@"/Users/ramindu/wso2/general_demo/APK/ecom_rest_openapi.json"'And with kubectl get apis command, the deployed API can be seen. The token claim value for org_id (eg: “org_id”: “abc077f4-ae13–410a-b510-ccadb5e0dca4”) will be used to imply the API owner organization.
Invoking the API
Once the API is deployed, the API can now be invoked with the token received by the Asgardeo token endpoint by the user in the sub organization.
curl -k --location 'https://abc077f4-ae13–410a-b510-ccadb5e0dca4.gw.wso2.com:9095/RWNvbVJlc3QwLjEuMQ/0.1.1/items?sellerId=-1' \
--header 'Host: abc077f4-ae13–410a-b510-ccadb5e0dca4.gw.wso2.com' \
--header 'Authorization: bearer eyJ4NXQ--------CqsRmf6rGkoU0cuw'In the cURL command, it is needed to notice that the organization (abc077f4-ae13–410a-b510-ccadb5e0dca4) that is available in the API listing in the previous step is used as the prefix of the gateway URL and the host.
Whenever the request comes to the gateway, it will validate the token’s org_id claim and see whether its equal to “abc077f4-ae13–410a-b510-ccadb5e0dca4” and provide access to the API which is added in the idp_ord_token_issuer.yaml as organization.
The response will be received as follows which will be differed with the backend that you are using which is exposed as an API
[{"ID":"7", "Title":"Dog collar", "Description":"abcd", "Includes":"abcd", "IntendedFor":"abcd", "Color":"abcd", "Material":"abcd", "Price":100.0, "sellerId":"clothing"}, {"ID":"9", "Title":"Test", "Description":"Added by Seltron", "Includes":"dfg", "IntendedFor":"dfg", "Color":"dfg", "Material":"dfg", "Price":345.0, "sellerId":"clothing"}]Scaling the dataplane with regards to CPU and Memory
As can be seen, there is only one pod running as the gateway in the deployment. If we need high availability and scaling when the requests comes in, scaling is needed.
To configure high availability with minimum two nodes and which scales up to 5, it is needed to add some configurations. First get the default values which used to create the deployment with the following command so that it is easier to edit.
helm show values wso2apk/apk-helm --version 1.0.0 > default-values.yamlAdd the following configuration in the default-values.yaml file
autoscaling:
enabled: true
minReplicas: 1
maxReplicas: 5
targetMemory: 80
targetCPU: 80The default-values.yaml file will look similar to the following.
Use the following command to apply the new configuration to the deployment
helm upgrade apk wso2apk/apk-helm --version 1.0.0 -f default-values.yamlAnd it will be possible to see the two gateway pods up and running and 3 pods are being ready to be spawned.
With this article, now it is clear how the organization structure works when the Asgardeo is used as the IDP and how the Kubernetes native functionality can be used in APK to scale the data plane with respect to the resource utilization.