How To Get API request originator IP address in ESB

Scenario

Retrieve the IP address of the actual originator of the API request in below mentioned scenario.

In the above deployment scenario, I had a requirement to the get IP address of the client from ESB.

Prerequisite

• WSO2 API Manager 1.7.0 
• WSO2 ESB 4.8.1

Solution

 'X-Forwarded-For' header property is a transport level header property. This property is normally used by Load Balancer to stamp the IP address of the client which is requesting a service from back-end server. 

This property can be used append Client-IP address in the WSO2 API Manager. Later on by accessing this property, relevant Client-IP address can be fetched from ESB side. I included following filter configuration in WSO2 API Manager to append  Client-IP address to  'X-Forwarded-For' header property.

	<filter source="get-property('transport','X-Forwarded-For')" regex=".*">
	<then>
	<property name="coming-X-Forwarded-For" expression="fn:concat(get-property('transport','X-Forwarded-For'), ', ')" scope="axis2" type="STRING"/>
	<property name="clientIP" expression="get-property('axis2','REMOTE_ADDR')"/>
	<property name="X-Forwarded-For" expression="fn:concat(get-property('axis2','coming-X-Forwarded-For'), get-property('clientIP'))" scope="transport" type="STRING"/>
	</then>
	<else>
	<property name="X-Forwarded-For" expression="get-property('axis2','REMOTE_ADDR')" scope="transport" type="STRING"/>
	</else>
	</filter>

view raw mediation-extension hosted with ❤ by GitHub

In API manager, each API definitions are stored in separate synapse config files. Therefore you have to add the above mentioned configuration in each and every files. Since this is a cumbersome task, you can use mediation extension. By doing so, the filter configuration will be included in each and every synapse API definitions.

Now from the ESB side, you can obtain the Client-IP address from  'X-Forwarded-For' header property by having following synapse configuration.

<property name="coming-X-Forwarded-For" expression="get-property('transport','X-Forwarded-For')"/>

view raw X-Forwarded-For hosted with ❤ by GitHub

How to get a session cookie from a webapp which uses SAML SSO

Scenario

1. WSO2 IS is configured for SSO and acts as IDP.
2. Web app is placed in Tomcat 7.x
3. Web app contains the SAML Assertion Response from IDP.
4. By using the SAML Assertion Response from web app, we should obtain the cookie to access admin services like updating password, retrieving tenants etc ....

You can learn more about enabling SSO in WSO2 IS 5.0 by going through this references. In order to demo this scenario, I have modified the code provided in this article.
Source code for above mentioned article can be found here.

I have written a sample web app to update the password by invoking the admin service.
In this sample app, cookie is obtained by logging in to the admin service  "SAML2SSOAuthenticationService" by passing the the SAML response.

In the event of successful login to the admin service, it returns a cookie string. This cookie can be lately used to access the admin service method "changePasswordByUser".


The diagram flow can be displayed below.

[1] SAML Request to the IDP.
[2] SAML Assertion Response to the Web app
[3] Login in to the admin services by using SAML Assertion response
[3] Cookie will be returned to valid login


Prerequisite

• WSO2 IS server 5.0 - PORT 9443 ( PortOffset 0 ) . You can download it from here.
• TOMCAT 7 - PORT 8080 

Steps

• Check out and build the code from here (In order to test this sample you have to build the POM file using "mvn clean install").  The war file "saml2.sso.demo.war" can be found in target folder. 
• Configure WSO2 IS 5.0 for SSO by using following link.  While configuring the SP please make sure to have following configuration values when configuring SP.
  1. Issuer - "saml2.sso.demo"
  2. Assertion Consumer URL - "http://localhost:8080/saml2.sso.demo/consumer"
  3. Check the options in Enale Response Signing and Enable Response Signing   in SP.                                                                                                                     

• Navigate to repository/conf/security/authenticators.xml and update the "ServiceProviderID" value same as Issuer's value.
  

  	<Authenticator name="SAML2SSOAuthenticator" disabled="true">
  	<Priority>10</Priority>
  	<Config>
  	<Parameter name="LoginPage">/carbon/admin/login.jsp</Parameter>
  	<Parameter name="ServiceProviderID">saml2.sso.demo</Parameter> ( Place to be changed )
  	<Parameter name="IdentityProviderSSOServiceURL">https://localhost:9443/samlsso&lt;/Parameter>
  	<Parameter name="NameIDPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</Parameter>
  	<!-- <Parameter name="IdPCertAlias">wso2carbon</Parameter> -->
  	<!-- <Parameter name="ResponseSignatureValidationEnabled">false</Parameter> -->
  	<!-- <Parameter name="LoginAttributeName"></Parameter> -->
  	<!-- <Parameter name="RoleClaimAttribute"></Parameter> -->
  	<!-- <Parameter name="AttributeValueSeparator">,</Parameter> -->
  	<!-- <Parameter name="JITUserProvisioning">true</Parameter> -->
  	<!-- <Parameter name="ProvisioningDefaultUserstore">PRIMARY</Parameter> -->
  	<!-- <Parameter name="ProvisioningDefaultRole">admin</Parameter> -->
  	<!-- <Parameter name="IsSuperAdminRoleRequired">true</Parameter> -->
  	</Config>
  	<!-- -->
  	</Authenticator>

  view raw Authenticator hosted with ❤ by GitHub
• Now you can deploy the "saml2.sso.demo.war" in to tomcat's webapps folder.
• Start the both IS and tomcat.
• you can use the http://localhost:8080/saml2.sso.demo/ to test the web app .

Source Code can be found here   

How to retrieve all APIs docs published on WSO2 API Manager 1.7 environment

WSO2 API manager provides the necessary platform for creating, publishing and managing all aspects of an API and its life cycle. API Manager uses Swagger framework to provide interactive documentation support to help users to clearly understand and experience the APIs.

Hence, WSO2 API Manager stores the API definitions in registry.

       

These API definitions are compatible with Swagger version 1.2. In order to further learn about WSO2 API Manager, you can refer the documentation.

You can view the API documentation definition by logging in to API Store. You have to follow the following steps to achieve this.

• Log in to API Store.  ( https://[HOST_NAME]:[PORT]/store )
• It will display all the available APIs. 
• You can click and visit to an API.
• Navigate to "API Console".
• Click on the "Download" link.
• It will display the api-doc.json ( This compliance with swagger 1.1 ).
• In order to navigate to API doc definition which compliance with Swagger 1.2, you have to replace the "api-doc.json" part of the URL (final part) with "1.2/default" part.

But in general, users might want to view the API docs by using private Swagger UI for various reasons. 

I have written a sample code on how to get all the API documentations get downloaded for both tenants and super-tenant.

All the API definitions are stored in registry. Only thing you have to do is to log in API Manager first and then next login to store by using admin services provided by WSO2 Carbon.

Next, you have to follow a REST URL provided to access the API definitions stored in registry.

URL formats used to access the API definitions differ based on either tenants or super-tenants.

1. Super-tenants as API providers. 

             https://[HOST_NAME]:[PORT]/registry/resource/_system/governance/apimgt/

             applicationdata/api-docs/[NAME]-[VERSI0N]-[PROVIDER]/1.2/default 

      2.  Tenants as API providers.

            https://[HOST_NAME]:PORT]/t//registry/resource/_system/

            governance/apimgt/applicationdata/api-docs/[NAME]-[VERSI0N]-                                                 [PROVIDER]/1.2/default

      In abstract what we are  going to do vi program is
   
      [1] Log in to API Manager carbon home
      [2] Retrieve all the tenants.
      [3] Log in to API Store
      [4] Dynamically generate the URLs by using program.
      [5] Retrieve them by simple GET call.

       Source code can be downloaded from here.

How to invoke Admin Services on WSO2 Carbon Products.

This blog post explains on how to invoke admin services provided by WSO2 Carbon Products. I have implemented a sample code tested with WSO2 Identity Server.

In this blog post I will briefly explain on how to update the password via admin service.
I will use both AuthenticationAdmin and UserAdmin services to update the password.

 - AuthenticationAdmin will be letting users to log in to the system.
 - UserAdmin provides the API "changePasswordByUser" to update the logged in user's password.

WSDL files of Admin Services can be viewed by following steps.

• Update the value of "HideAdminServiceWSDLs" element to false in carbon.xml.                 Located inside
• WSDL file to a corresponding admin service can be viewed by browsing to to the URL.
  https://[CARBON_HOME]:[PORT]/services/[ADMIN_SERVICE]?wsdl                                                                                                                                           

Next we have to generate the stub. Stub will wrapping up the underlyaing RMI operations that occur when invoking the admin services.assist you to perform RMI operations on Admin services exposed via corresponding WSDL. Stub can be generated by various means. But in this sample I have used the  maven-antrun-plugin to generate the stub dynamically during compile time.

	<configuration>
	<tasks>
	<java classname="org.apache.axis2.wsdl.WSDL2Java" fork="true">
	<arg line="-uri src/main/resources/UserAdmin.wsdl -u -uw
	-o target/generated-code -p org.wso2.feature.password.verification"/>
	<classpath refid="maven.dependency.classpath"/>
	<classpath refid="maven.compile.classpath"/>
	<classpath refid="maven.runtime.classpath"/>
	</java>
	<java classname="org.apache.axis2.wsdl.WSDL2Java" fork="true">
	<arg line="-uri src/main/resources/AuthenticationAdmin.wsdl -u -uw
	-o target/generated-code -p org.wso2.feature.frontend.authentication"/>
	<classpath refid="maven.dependency.classpath"/>
	<classpath refid="maven.compile.classpath"/>
	<classpath refid="maven.runtime.classpath"/>
	</java>
	</tasks>
	</configuration>

view raw stub hosted with ❤ by GitHub

Once done with the stub generation, Only thing left now is to invoke the relevant stubs to perform necessary operations. First thing you should do is to login by using the AuthenticationAdminStub. During the logging in process, the stub returns the cookie. By using that cookie, you can proceed with your subsequent operations.

The complete code can be downloaded from here.