Showing posts with label WSO2APImanager. Show all posts
Showing posts with label WSO2APImanager. Show all posts

Tuesday, June 16, 2015

Custom OAuth Grant-Type Support in APIManager


    According to OAuth 2.0 Spec , there are four main grant-types support is available in an OAuth 2.0 authorization server. It supports custom grant type also. WSO2 IS supports OAuth 2.0 spec and it can act as OAuth 2.0 authorization server.

    WSO2 APIManager uses OAuth tokens for API Security. (APIManager uses IS OAuth component to achieve OAuth support). User can write his own gran-type support for API security.

    For this, he has to write; 

  1. GrantTypeHandler : Write the grant type implementation in the handler class. For this implementation user can use AuthorizationGrantHandler  interface or by extending AbstractAuthorizationGrantHandler
  2. GrantTypeValidator: This implementation will validates all the request which are sent to token endpoint. For this implementation, use the "AbstractValidator" class which is available in Amber library from Apache.

Eg: For example, If i want to authorize the requests based on certificates (e.g.;. Grant-type is "cert-auth",) 
OauthHandler:

package org.test.oauth;

import org.wso2.carbon.identity.oauth2.IdentityOAuth2Exception;

import org.wso2.carbon.identity.oauth2.model.RequestParameter;
import org.wso2.carbon.identity.oauth2.token.OAuthTokenReqMessageContext;
import org.wso2.carbon.identity.oauth2.token.handlers.grant.AbstractAuthorizationGrantHandler;
import org.wso2.carbon.identity.oauth2.dto.OAuth2AccessTokenReqDTO;

public class CertificateGrantHandler extends AbstractAuthorizationGrantHandler{
public static final String CERTIFICATE = "sslclientcertb64";

@Override
    public boolean validateGrant(OAuthTokenReqMessageContext tokReqMsgCtx)
            throws IdentityOAuth2Exception {

        boolean authStatus = false;
        
    OAuth2AccessTokenReqDTO oAuth2AccessTokenReqDTO = tokReqMsgCtx.getOauth2AccessTokenReqDTO();
   
    String clientCert = null;
    // extract request parameters
        RequestParameter[] parameters = oAuth2AccessTokenReqDTO.getRequestParameters();

        // find out client certificate
        for(RequestParameter parameter : parameters){
            if(CERTIFICATE.equals(parameter.getKey())){
                if(parameter.getValue() != null && parameter.getValue().length > 0){
                clientCert = parameter.getValue()[0];
                }
            }
        }        
    return authStatus;
    }
}

Validator:


package org.test.oauth;

import org.apache.amber.oauth2.common.validators.AbstractValidator;
import javax.servlet.http.HttpServletRequest;

public class CertificateGrantValidator  extends AbstractValidator {

    public OauthCertificateGrantValidator() {

        // mobile number must be in the request parameter
        requiredParams.add(OauthCertificateGrantHandler.CERTIFICATE);
    }
}

Add the new grant-type in the identity.xml of the APIManager.

eg:


<SupportedGrantType>
<GrantTypeName>cert_auth</GrantTypeName>
<GrantTypeHandlerImplClass>org.test.oauth.CertificateGrantHandler</GrantTypeHandlerImplClass>
<GrantTypeValidatorImplClass>org.test.oauth.CertificateGrantValidator</GrantTypeValidatorImplClass>
</SupportedGrantType>

Generate token using;
curl -k -d "grant_type=cert_auth&sslclientcertb64=" -H "Authorization: Basic , Content-Type: application/x-www-form-urlencoded" http://localhost:8280/token

Tuesday, January 20, 2015

Adding URL parameters in WSO2 APIManager

It is a common use case, where users might want to add URL parameters  which are evaluated dynamically in their endpoints.
We can use same approach what we do in ESB, but it may confuse users on how to implement it in APIManager.
APIManager supports adding custom sequences for the API mediation logic. There are few ways available to add custom mediation plugins.
One, which we can simply use for this requirement is, store the mediation logic in registry as a sequence and select that in the in/out flow of the API invocation when publishing API.

Eg:
If we want to invoke the API with something like(note: we pass PhoneNumber parameter)
http://localhost:8280/dimtry/1.0?PhoneNumber=+16506697051 and send to the backend: http://ws.cdyne.com/phoneverify/phoneverify.asmx/CheckPhoneNumber? PhoneNumber=+16506697051&LicenseKey=0"

In the above example, backend service expects two URL parameters for the GET call to return proper response. But user will pass only one parameter(i.e.: phone number). We need to extract that user parameter and within api mediation logic we need to add another license key parameter too.

To achieve this, When publish an API define HTTP endpoint with parameters and assign values to those parameters in the custom sequence.

Eg: <http uri-template=" http://ws.cdyne.com/phoneverify/phoneverify.asmx/CheckPhoneNumber?Phonenumber={uri.var.PhoneNumber}&LicenseKey={uri.var.LicenseKey}"/>


Here, you need to pass two parameters, which can be passed through the custom sequence. Edit the existing log-in message sequence like below and save;(you can create new sequence and save it)

<sequence xmlns="http://ws.apache.org/ns/synapse" name="log_in_message">

                <property name="uri.var.LicenseKey" value="0" scope="default" type="STRING"/>
                <property name="uri.var.PhoneNumber" expression="substring-after(get-property('To'),'/dimtry/1.0?PhoneNumber=')" scope="default" type="STRING"/>
</sequence>

If you check above sequence,  phonumber is extracted from incoming request using an xpath and hardcoded a value for licensekey, which user can modify according to his requirement.
Now when  we create and publish the api, select above insequence.

APIConfiguration:


Send a GET request for the API like;


You will get response;


Monday, December 22, 2014

axiom.soap.SOAPProcessingException: Transport level information does not match with SOAP Message namespace URI

This is a common exception [1]we see when invoke services hosted in axis2 based servers.
It occurs due to the namespace mismatch in the request. Check the service'e version and the request's version.
eg: SOAP 1.2 message with content type text/xml, we get this error. Correct the namespace in the request.

[1]

ERROR - RelayUtils Error while building Passthrough stream
org.apache.axiom.soap.SOAPProcessingException: Transport level information does not match with SOAP Message namespace URI
at org.apache.axis2.builder.BuilderUtil.validateSOAPVersion(BuilderUtil.java:745)
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:58)
at org.apache.synapse.transport.passthru.util.DeferredMessageBuilder.getDocument(DeferredMessageBuilder.java:118)
at org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:107)
at org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:82)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:68)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:131)
at org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive(ProxyServiceMessageReceiver.java:166)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
at org.apache.synapse.transport.passthru.ServerWorker.processEntityEnclosingRequest(ServerWorker.java:411)
at org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:183)
at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
[2014-12-22 00:53:36,500] ERROR - SequenceMediator Error while building message
org.apache.axis2.AxisFault: Error while building Passthrough stream
at org.apache.synapse.transport.passthru.util.RelayUtils.handleException(RelayUtils.java:236)
at org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:111)
at org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:82)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:68)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:131)
at org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive(ProxyServiceMessageReceiver.java:166)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
at org.apache.synapse.transport.passthru.ServerWorker.processEntityEnclosingRequest(ServerWorker.java:411)
at org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:183)
at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
Caused by: org.apache.axiom.soap.SOAPProcessingException: Transport level information does not match with SOAP Message namespace URI
at org.apache.axis2.builder.BuilderUtil.validateSOAPVersion(BuilderUtil.java:745)
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:58)
at org.apache.synapse.transport.passthru.util.DeferredMessageBuilder.getDocument(DeferredMessageBuilder.java:118)
at org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:107)

Saturday, November 29, 2014

Synapse Handler

Synapse handler is similar to axis2 handler , that can be used in RESTAPIs to handle incoming request and the responses.

Sample handler ;


package test;

import org.apache.synapse.MessageContext;
import org.apache.synapse.rest.AbstractHandler;

public class TestSynapseHandler extends AbstractHandler {
@Override
public boolean handleRequest(MessageContext messageContext) {
String idKey = "idKey";
String idValue = "abc";
messageContext.setProperty(idKey, idValue);
return true;
}

@Override
public boolean handleResponse(MessageContext messageContext) {
// TODO Response handling
return true;
}

}

Handler has to be registered in the RESTAPI configuration.

Sample configuration;

<api xmlns="http://ws.apache.org/ns/synapse" name="calAPI" context="/cal">
   <resource methods="GET">
      <nSequence>
         <send>
            <endpoint>
               <address uri="http://localhost:9763/services/calservice"/>
            </endpoint>
         </send>
      </inSequence>
      <outSequence>
         <send>
            <endpoint>
               <default/>
            </endpoint>
         </send>
      </outSequence>
   </resource>
<handlers>
        < handler class="test.TestSynapseHandler"/>
   </handlers>
</api>












Sunday, August 31, 2014

Invoking SOAP service via an API in WSO2 APIManager

WSO2 APIManager provides  comprehensive features to support API management capabilities. Users can  publish APIs for REST and SOAP services. To test REST service, REST testing tools are available in API store. But for SOAP services there is no inbuilt tool to test the API. Users can use  any SOAP client to test the API. A simple easy to use tool is SOAPUI.
To test SOAP service api, user needs to set a http auth header to invoke api successfully.
There is no any difference  between REST service api and SOAP service api when creating,  publishing or subscribing to API. After generating an accesstoken, user can  use REST client to invoke API by setting "Authorization" header. 

Eg: Authorization: Bearer ozVF2bhIBnd6rgziVJNr1Vu0J54a

Same header has to be set as HTTP header in soap-ui too. Note that, this is not ws-security header.


Saturday, August 2, 2014

Configuring WSO2 APIManager with Apache HTTP server for reverse proxy

Applies to : AM -  1.8.0

APIManager which has two web apps deployed by default which are api_publisher and api_store. When user needs to route the requests through a proxy server for publisher and store, he can do that by editing  site.json file which is available in AM_HOME/repository/deployment/server/jaggeryapps/store(/publisher)/site/conf folder.

Apache HTTP server
  • Download and install HTTP server
  • Check the default installation works fine for HTTP.
    • Try like "http://localhost" you will see the default index page.
  • To set SSL settings, edit the default http_ssl config file with the following settings. User has to create a new ssl cert/key for ssl communication. 
<VirtualHost _default_:443>
SSLEngine on
SSLCertificateFile /Users/ratha/WSO2/apachehttp/server.crt
SSLCertificateKeyFile /Users/ratha/WSO2/apachehttp/server.key

ProxyPreserveHost On
SSLProxyEngine on

# Proxy path which user wants to map with actual backend
ProxyPass /publicstore https://localhost:9443/store/
ProxyPassReverse /publicstore https://localhost:9443/store/
ProxyPassReverseCookiePath /store /publicstore

ProxyPass /publicpublisher https://localhost:9443/publisher/
ProxyPassReverse /publicpublisher  https://localhost:9443/publisher/
ProxyPassReverseCookiePath /publisher /publicpublisher

</VirtualHost>


  • After editing the ssl configuration restart the http server. Try accessing "https://localhost", if settings are fine, user should be able to see the default index page.
site. json configuration

Edit the context and request-url parameters.
context- The url context
request_url- The original request url which hits the proxy server.

"context" : "/publicstore ",
"request_url":"https://localhost/publicstore ",

Now access the store page(/publisher ) using 'https://localhost/publicstore' and  the request  will be routed internally to 'https://localhost/store'