Skip to main content

Posts

Openwhisk Web actions with path parameters

What are web actions? Web actions can be explained as OpenWhisk actions annotated to quickly enable you to build web based applications as defined in the official documentation. If we compare an Openwhisk action and a web action, an OpenWhisk action that is not a web action requires both authentication and must respond with a JSON object. In contrast a web action can be invoked even without authentication and is capable of also passing additional data such as HTTP header, Status codes and returning body content of different types. What can we retrieve inside a web action? When invoking web actions they are capable of receiving additional HTTP request details as they are designed to facilitate features of HTTP invocations. __ow_method : The HTTP method of the request. __ow_headers : The request headers. __ow_user: The namespace identifying the OpenWhisk authenticated subject who created this web action. __ow_path:The attributes which are passed as path parameters into the ac
Recent posts

Configure WSO2 Identity Server for single sign on with Moodle - Part II

User provisioning and attribute profile mapping with Moodle and WSO2 Identity Server  This is the continuation of how to configure SAML2 Web SSO with WSO2 Identity Server and Moodle. I will guide you on how the attribute mappings and user provisioning can be done using WSO2 Identity Server and Moodle. In order to do this we need to make sure that the attributes on the WSO2 Identity Server maps with the corresponding attributes in Moodle. This plugin provides the capability to auto provision users in Moodle. If a new user who is not registered in Moodle but is registered in the WSO2 Identity Server needs to be created in Moodle we can make use of these mappings. Let's get started on the configurations. First let's carry out the configs on the moodle end. 1) Same way as we did in the post [1]. Navigate to the Moodle's authentication plugins section and select the Settings of the OneLogin SAML SSO Authentication plugin. 2) Check the following two options.

Configure WSO2 Identity Server for single sign on with Moodle - Part I

Introduction Moodle is a learning platform designed to provide educators, administrators and learners with a single robust, secure and integrated system to create personalized learning environments.[1]. This is commonly used in the education sector and there might be occurrences where it would require to use SAML to login to Moodle instead of the default basic authentication. For this we would need to have an Identity Provider capable of issuing such SAML tokens and Moodle configured to accept the tokens in order to do the authentication I will be discussing this in two parts. Part I - How to configure moodle for SSO with WSO2 Identity Server Part II - How to carry our user provisioning and attribute profile mapping with Moodle and WSO2 Identity Server Let's see how this can be achieved using a SAML authentication plugin provided by one login. Prerequisite  You need to have a working version of Moodle installed. If you want to try this tutorial from scratch you can

Change NameID format in SAML Response in WSO2 Identity Server

By default the SAML response of the WSO2 Identity Server will contain the tenant domain in the response. See the below response block which containts the tenant domain appended to the NAMEID element. <saml2:NameIDFormat ="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> admin@carbon.super </saml2:NameID> If you want to get rid of the tenant domain being appended you can follow one of the below methods to accomplish this Method 1 - Disabling this option from the management console. Log into the management console of the Identity Server Expand your service provider configuration and select the 'Local & Outbound Authentication Configuration' option Untick the option 'Use tenant domain in local subject identifier'               Now the tenant domain would not be displayed in your SAML response. Method 2 - Setting this value for the file based Service Provider configurations Given that you have configured the serv

Getting rid of request parameters from the request

In most service chaining and API invocations we might come across situations where we will require to remove the initial request URI from the request. If we take for an example the following scenario. 1. We need to obtain some parameters from the users of our API. Therefore we define a resource as below which takes the name and age What we really need to do is get the name of the student and return the exam grades information. For that we need to invoke a URL in the following format. http://www.mocky.io/v2/59a3e86f130000b013ce056d /getGrades/{query.param.name} But with the request URI already been defined in step (1) the request which will be sent is the one below http://www.mocky.io/v2/59a3e86f130000b013ce056d /getGrades/{query.param.name}?name=Jessie&age=20 Since the backend does not identity a request with such trailing parameters it will fail. How can we get rid of the trailing query parameters from the request (1)?? It's pretty simple. We have a property

Adding error sequence to a custom sequence

In my previous posi i explained how to call an endpoint using the call mediator. Usually when errors are thrown from the call mediator we can handle them using a custom sequence. When call mediators fails the execution stops hence handling errors is very essential. For this post I will be modifying the same sequence which i created in the blog post [1] The change which we need to do is we need to modify the sequence definition to map with the error sequence as shown below. You can find the modified sequence here . <sequence xmlns="http://ws.apache.org/ns/synapse" name="countrySequenceWithError" onError="countryErrorSequence"> <property name="uri.var.countryCode" expression="$url:countryCode"/> <property name="REST_URL_POSTFIX" scope="axis2" action="remove"/>     <call blocking="true">         <endpoint>             <http method="get" uri-temp

Service Chaining with WSO2 API Manager/API Cloud

Introduction In the real world we require to create use cases where we need to invoke more than one endpoint to get the response we need for the API. We may require to get the response from one endpoint and manipulate that response and send it to another. In order to demonstrate this sample let's consider the following flow. We need to design an API which returns details about a country when a country code is entered by a user. One limitation we have is the endpoint which returns the country details expects a country name to be passed. Therefore to accomplish this task we need an intermediate service which gives us the country for the given country code (Service A). After we get the country name then we can pass it to our actual backend service. (Service B) Flow of events.  User needs to input a country code  We need to pass that entered value to the service A which returns the corresponding name of the country back to us. This is the format it will return. {"country