Quantcast
Channel: vordelfeeds
Viewing all 236 articles
Browse latest View live

Speaking at the API Strategy and Practice conference in New York this Thursday

$
0
0



This Thursday (Feb 21) in New York City I'm speaking at the API Strategy and Practice conference. The conference had originally been scheduled for November, but Hurricane Sandy intervened. The conference was rescheduled, stronger than ever, and has a very impressive session lineup.

First up, I am speaking on API Security and Stability at 2.55 pm. Following that, I'm on a panel with the other speakers on the same topic: Paul Madsen of Ping Identity, Andy Thurai of Intel, and Travis Reeder of Iron.io.

Next up, I'm on the API Infrastructure Providers panel at 5.45pm, moderated by Kin Lane, fresh from Dublin. This panel also has Paul Madsen of Ping Identity, this time with Alistair Farquharson of SOA Software, Steve Willmott of 3Scale, Chris Haddad of WSO2, Evgeny Popov of APIphany, and Augusto Marietti of Mashape.

Vordel/Axway is a Gold Sponsor of the API Strategy and Practice conference and we'll be exhibiting on both the Thursday and Friday. Looking forward to seeing you there!


Free Vordel API Workshop in San Francisco next Tuesday

$
0
0
Following on from the very successful API Workshop events in Melbourne and Sydney earlier this month, we're running a Vordel API Workshop in San Francisco next Tuesday (26 February). We have a great location for the workshop, which is the 111 Minna Gallery.

We've be covering:
  • Creating REST APIs in front of legacy SOAP services
  • Cloud Mashups with Salesforce
  • Modernising APIs with XML to JSON conversion
  • "Who's been using my APIs?" - View real-time API usage, and investigate trends over time.
  • Enable secure mobile access to enterprise APIs - OAuth 2.0 in action
  • Usage quotas in order to monetize your APIs - enable the "Freemium" model
And there is Free Stuff :-). You get:
  • A free developer license to Vordel API Server
  • Entry into a prize draw for a Google Nexus 7
  • A limited edition Vordel Immerse T-shirt
  • and... A free lunch from Off the Grid gourmet food trucks at the venue
The workshop is free and you can sign up here. Note that you do not need to be registered for the RSA Conference to attend this workshop.

As you can see from the map below, the 111 Minna Gallert where the API Workshop is taking place is very close to the Moscone Center, just behind the SF MOMA and the W Hotel.


HTTP Path variables with the Axway/Vordel API Server

$
0
0
I've written about this before, but here's a recap and an extra trick which might be useful...

Let's say your API is expecting parameters passed in the URL, like so:

/customer/12345?name=test

Many REST APIs are defined like this, including parameters in their path. Here is how you'd read the value of the second item in the URL path, i.e. "12345" in this case.

Firstly, you'll need the Vordel API Server, which you can download from www.vordel.com . Then, create a new policy in Policy Studio, starting with the "Extract REST Request Attributes" filter. To do this, drag it onto the blank canvas of a new policy, then right-click on it and choose "Set as start". The purpose of this filter is to take the various REST request parameters and place them into variables (or "attributes") for you to use.

Next, join this using a green arrow to a "Trace" filter. The Trace filter serves a very useful purpose by tracing out the values of the variables which were created in the Extract REST Request Attributes filter. Notice that, by default, this filter traces out at the "DEBUG" level. This means that you'll only see the output if you're running the API Server at "DEBUG" level. You can change the trace level using the Vordel Manager interface (over SSL to port 8090, by default) under the "Settings" tab, as shown below:

Now, map this policy to a path called "/customer". The API Server matches on a "longest first" basis, so this means that "/customer/12345?name=test" will be caught by the "/customer" mapping.

Now run it with test traffic from a browser, and take a look at the tracing information in the Traffic view of the Vordel Manager interface (over SSL to port 8090, by default). You should see something like this:


Notice that the path value is clearly visible. ${http.path[2]} is the variable containing our URL parameter, which is "12345".

I can now output this, using a Set Message filter containing the following text:

Customer is ${http.path[2]}

I use a Content-Type of text/html since I'm returning this to a browser.

Then, when I connect to the API Server on the path of /customer/12345?name=test , I see the response "Customer is 12345".

Here is a screenshot of my entire policy. You can see that I placed a "Reflect Message" filter at the end, to return back the response to the client with a 200 HTTP status code:


You may notice above that the third filter is red. This is because Policy Studio does not know in advance about the existence of the ${http.path[2]} variable, so it flags this as a "missing" input variable to the "Return Customer ID" filter.

For more info on the Axway/Vordel API Server, contact info@vordel.com

Extending the Axway/Vordel API Server with third-party Java classes using scripting

$
0
0
One of the neat features of the Axway/Vordel API Server is the fact that you can extend it using Java. There are a number of ways of doing this, but a really neat way is to run your Java class through a Scripting Filter. Here is a guide to calling your own, or third-pary, Java classes from the Axway/Vordel API Server.

My use case is that I want to use OpenID for single-sign-on using a Google login. I found a nice implementation of OpenID called JOpenID and downloaded it as a jar file. I then placed the JOpenId-1.08.jar file into the /ext/lib folder of my API Server installation. I then placed this new class under /ext/lib on the API Server also, so that it will be picked up by the API Server runtime. Note that, for v7 onward, this must be placed under the /ext/lib instance you want to extend. You can find the correct instance by following the "groups" then "topologylinks" path under the API Server installation. This effectively puts it onto the classpath for that API Server instance.

JOpenID includes a class called OpenIdManager which has a method called getAuthenticationUrl that constructs the URL which directs the user to Google for SSO to a particular endpoint. I want to call that method from the API Server. However, from a Scripting Filter, I can only run a public static method of a class.

So, what I did was to make a class called "OpenIDEngine", and I gave it a public static method called "GetURL". In that method, I create an instance of OpenIdManager and I call OpenIdManager.getAuthenticationUrl to get the URL for me. This is what I will call from my Scripting Filter.

Here's the code I wrote:


package org.expressme.openid;

public class OpenIDEngine {

    public static void main(String[] args) throws Exception {
        System.out.println(GetURL("http://vordelapiserver/openId","http://vordelapiserver", "Google"));
    }
    
    public static String GetURL(String ReturnTo, String Realm, String Endpoint)
    {
        OpenIdManager manager = new OpenIdManager();
        manager.setReturnTo(ReturnTo);
        manager.setRealm(Realm);
        manager.setTimeOut(10000);
        Endpoint endpoint = manager.lookupEndpoint(Endpoint);
        Association association = manager.lookupAssociation(endpoint);
        String url = manager.getAuthenticationUrl(endpoint, association);
        return url;
    }
}

You can see I also added a main method to my class for testing purposes.

After compiling this, I then placed this new class under /ext/lib on the API Server also, so that it will be picked up by the API Server runtime. Note that, for v7 onward, this must be placed under the /ext/lib instance you want to extend. You can find the correct instance by following the "groups" then "topologylinks" path under the API Server installation. Ensure you jar it up, or put it into the correct folder structure so that it gets picked up.

The next step is to use a Scripting Filter to run the GetURL method of my class. Here's a screenshot of my Scripting Filter being used in my policy:


In case you can't see the contents of the script, here it is below. I'm putting in the Java package at the top (note the Rhino syntax) and then running my method. I'm placing the output (i.e. the URL) into an attribute (variable) called "OpenIDUrl". I'm then using a simple Set Message in the following filter to output this variable.

importPackage(Packages.org.expressme.openid);


function invoke(msg)        
 {           

 msg.put("OpenIDUrl",org.expressme.openid.OpenIDEngine.GetURL("http://APIServer/openId","http://APIServer", "Google"));
 return true;        

 }

Here's the Set Message filter which is outputting that URL:



Now, I wire this policy up to a path called "/GetURL", so that when a request comes into "/GetURL", it is run:


Now, when I call "/GetURL" on the API Server, I see my URL is generated for SSO through Google, and when I hover over the link I can take a look at the URL which is generated:



I hope this explains how to extend the Axway/Vordel API Server using your own (or third-party) Java classes, via the Scripting Filter. The advantage of this approach is that it's very simple to do. Also, you can place all your logic in the Java classes, and simply run it through a call from a Scripting Filter as show here. 

Axway&Vordel at the Gartner Identity & Access Management Summit next week in London

$
0
0

If you're at the Gartner Identity & Access Management Summit in London next week, check out the Axway/Vordel booth (number S24). We'll be talking about the Axway and Vordel full solution covering API Management, right down through SOA and B2B. Also, contact us for a conference discount, and when you're there, come to the booth and you could win a Google Nexus 7. The conference takes place at the Park Plaza Westminster Bridge, right across from the Houses of Parliament. See you there :-)

Speaking on BYOD at Computer Sweden Mobility 2013 - 14 March

$
0
0
I'm excited to be speaking at the Computer Sweden Mobility 2013 event this Thursday in Stockholm on BYOD case studies - click below for the details:

 

Excellent series on setting up Kerberos, SAML, and RBAC with the Oracle API Gateway

Job posting: Vordel, RESTful Web Services, TIBCO, SiteMinder skills required in Torrance, CA - with SiteMinder, TIBCO, Informatica


Opportunity: Migration from Amberpoint to Vordel policies

Orchestration of a JSON API with a SOAP Web Service using the Axway/Vordel API Server

$
0
0
A frequent question about the Axway/Vordel API Server is "Is it possible to orchestrate multiple calls to different APIs or Web Services?". The answer is "Yes", and in this blog I'll show how. Along the way, we'll see how to configure JSON Path on the API Server.

For my worked example, I'm using a weather-lookup scenario. It's now Spring in Boston, and I'm interested in finding out the temperature using the API Server. Yahoo provides a great Weather API to retrieve weather information using REST and JSON. Unfortunately though, it returns the temperature in Fahrenheit and I'm more familiar with Celsius. So, I want to take the temperature from the Yahoo output, and feed this as input to the W3 Schools Fahrenheit-to-Celsius conversion Web Service. This means that I'm orchestrating to calls, one to a REST JSON API and the other to a SOAP Web Service.

Breaking down the steps, this means:

Step 1) The API Server receives a HTTP GET request containing a zip code as a parameter, like this: http://API-Server/orchestration?zip=02110

Step 2) The API Server first makes an API call for this zipcode's weather to Yahoo's Weather API, which returns the weather info as JSON

Step 3) We then extract the temperature from the Yahoo JSON response, and use this to construct a SOAP request to the W3 Schools Fahrenheit-to-Celsius conversion Web Service.

Step 4) Finally, we return the temperature info, converted to Celsius, to the client.

To achieve this, we use a circuit on the API Server, which I show in its entirety below:


Let's look at the steps in detail. Each of the blocks in the circuit is called a "filter". Let's look at what each filter does

1) Extract REST Request Attributes. This filter takes the items from the HTTP request and converts them to variables (which we call "Attributes"). When I call the API Server with a request in the browser like http://API-Server/orchestration?zip=02110 , the value "02110" is put into the attribute ${http.querystring.zip}

2) Set HTTP Verb to GET. This is a "Set HTTP Verb" filter which sets the HTTP Verb to "GET", as shown below:



I am setting the verb to GET because we need to do a GET request to Yahoo's REST Weather API.

3) Call Yahoo Weather API. This is a "Connect to URL" filter, which is configured to pass the zipcode which we've read from the querystring using the Extract REST Request Attributes filter earlier. Notice the zipcode underlined below in red:


4) Read temperature using JSON Path. After we call the Yahoo API, we have the weather response as JSON. I used the excellent online JSON Path Evaluator to construct the JSON Path to read the temperature from the Yahoo response into an Attribute called "temperature":


5) Create temperature lookup request. The next step is to use a "Set Message" filter to take the temperature from the Yahoo JSON response (which we've just read using JSON Path) and place it into a SOAP request to the Fahrenheit-Celsius conversion Web Service, as shown below:



6) Set HTTP Verb to POST. This is another "Set HTTP Verb" filter, this time setting the verb to "POST" because we are about to POST our new SOAP request to the W3 Schools Web Service.



7) Connect to Temperature Conversion Service. This is a "Connect to URL" filter, which contains the URL we want to POST to.


8) Retrieve Celsius temp from message. This is a "Retrieve from Message" filter which uses XPath to read the Celsius value from the SOAP response. To use the XPath Wizard, click on the little magic wand icon, and open a stored example of the SOAP response. I show the configuration for this below:


9) Return Response. This is a "Set Message" filter, and you can see it takes the ${temperature} attribute from the XPath in Step 8, with the Zipcode we read from the Query-String in Step 1:



I wire up the circuit to a path of "/orchestration", like so:


This means that whenever a request comes in to "/orchestration", my circuit is run.

I can call circuit simply from a browser like so:


You can see it's just over 8C in Boston right now. Balmy, compared to a couple of weeks ago.

Using the Vordel Manager on port 8090 of an API Server instance, I can see each request go through, and click on "Show" buttons to see the actual messages and response.


You can see above that there are three request-response pairs:

1) From the Browser to the API Server
2) From the API Server to the Yahoo REST/JSON Weather API
3) From the API Server to the W3 Schools SOAP Web Service to convert from Fahrenheit to Celsius.

So, what we've seen here is that you can orchestrate two requests, one to a REST API and another to a SOAP Web Service, using the Axway/Vordel API Server. Note that the second request overwrites the initial response (if you want to keep a copy of the first response, use a "Store" filter and then use "Restore" to restore the message later).

For more info about the Axway/Vordel API Server, email info@vordel.com

International Space Station visitors, or not...

$
0
0
I was checking out the Google Analytics for the Vordel website right now, and I see 41 current visitors on the website from the International Space Station. Normally I see some visitors from the US, some maybe from India and Europe, or Australia, depending on the time of day. But the International Space Station???


But, when I click over on "Traffic Sources" to see how they got to the Vordel site, I see what it is - April Fools :-) . Nice one Google, I should have guessed it based on the "41".


The power of full API engagement

$
0
0
On April 18th I'm co-presenting a webinar with Forrester's Jeffrey Hammon on "APIs - A Key Part Of Your Enterprise Engagement Strategy".

We'll be talking about how APIs enable your business to become a platform, enabling innovation by an ecosystem of developers. We'll also talk about the API Management which makes this possible.

 To join us, sign up here


Simplifying the app delivery stack

$
0
0
Gunnar Peterson and Ken van Wyk are running a Mobile Application Security Triathlon in NYC for three days (hence "Triathlon") starting on 29 April. As part of this, they're running a joint blog. The posting today is a great examination of the different sessions which are in play when a mobile app is used:
First off the user likely authenticates locally to the mobile app itself, let's call this session #1. Then any time the app needs to do something on the network (like synchronize data or replicate) it authenticates from the mobile app to the server, let's call this session #2. Next the server is very likely an API Gateway with no data or business logic, that is on the backend app servers, so the Mobile API Gateway has authenticate to the backend servers, let's call this session #3.
Now just logging into each of these sessions is a decent bit of work in and of itself. Add onto that the fact that very likely these are three fundamentally different protocols - maybe username/password for #1, OAuth for #2 and SAML for #3. Logging in is where it begins, but that's not where it ends.
 
http://mobappsectriathlon.blogspot.com/2013/04/mobile-session-management-which-session.html
Counting the different session contexts is a useful way to examine the traditional architecture used to deliver mobile applications. I'd add that there is usually a data services layer behind the app server, and that has a security context of its own, which is often overlooked.

Drawing it out, we see the the diagram below:

But, let's examine what the app server is doing. Usually, it is housing Java code, and providing session management services. But wait, we've see that an API Server can be used as a container for scripts and Java classes. It also can be used to manage sessions, and to connect to data services. So it makes sense to simplify the architecture, introducing the API Server like so:



The API Server acts as more than just a Gateway, because it houses the API itself. It also means that there are fewer security sessions in the architecture to worry about. It means fewer moving parts, less to manage, and less expense. That connection between the API Gateway and App Server is gone, because they are now one and the same: the API Server.

Here at Axway we see the API Server enabling the Next Generation application "stack": consisting of apps at the front end, connecting to the API layer, with data services behind. An API Server simplifies the API layer by combining the API exposure with the API delivery itself, meaning fewer moving parts, less expense, and, as we see here, fewer security sessions to deal with. 

Job posting: Application engineer with Vordel experience required by CGI for US Dept Homeland Security (Coast Guard)

$
0
0
CGI has posted is an Application Engineer position with the US Coast Guard's REST-based SOA team. It's a great opportunity to get involved in an innovative team which has been to the fore in designing REST-based application infrastructure. The job involves using technology from Vordel and Fiorano, along with other technologies such as Amazon and Rackspace Cloud, and JavaScript/JSON/Groovy. The location is Kearneysville WV, in the greater DC area. Kearneysville is in a beautiful rural part of the world, not far from Harper's Ferry where the Potomac and Shenandoah rivers meet.

Responsibilities include:
  • Work with customers, senior architects, administrators, engineers and developers on the SOA team and various other Coast Guard technical teams to help architect, design, develop, implement and maintain mission-critical REST-based Service Oriented Architecture solutions and software applications for multiple Coast Guard business units. 
  • Operate, maintain and implement continuous improvements to the SOA infrastructure to meet or exceed all SOA Service and Operating Level requirements. Responsibilities include but are not limited to: Configuration management/administration for SOA, evaluating, installing, upgrading, configuring, monitoring, testing and tuning SOA software and related products, backup and recovery policies and procedures, XML security appliance configuration & maintenance (creating and maintaining policies, users, roles, and privileges), ESB tuning and performance monitoring, application/message flow tuning and performance monitoring. 
  • Develop, validate, coordinate, lead and execute complex maintenance, failover and disaster recovery activities in a 7x24 mission-critical production environment.
  • Work in conjunction with senior architects to implement continuous improvements and updates to the Coast Guard's SPEAR architecture.
Vordel skills are desired:

  • Experience with security technologies such as single sign on, AD, Kerberos, SSL, SAML a plus – (direct experience with Vordel XML Gateway technologies strongly preferred).

Many readers of this blog already have these skills, so if sounds like a job for you, here is more info on the CGI site. 

How to read username and password from the Authorization HTTP header using the Vordel API Server

$
0
0
Here is a handy script I've written, for use in the Vordel API Server's Scripting Filter, which takes the Base64-encoded username and password from the HTTP Authorization header and places it into two attributes (variables) called "userchopped" and "passchopped".

Note that this must be preceded by a "Retrieve from HTTP Header" filter which reads in the "AuthorizationHeader" value like so:


Here's the script:


importPackage(Packages.com.vordel.common.base64);

function invoke(msg)        
 {            

var AuthZHeader = msg.get("AuthorizationHeader");
AuthZHeader = AuthZHeader.substring(6);
msg.put("ChoppedAuthZHeader", AuthZHeader);

var dataDecoded = Decoder.decodeToString(AuthZHeader);
msg.put("data.decoded", dataDecoded );
 
var userchopped = dataDecoded.substring(0, dataDecoded.indexOf(":"));
var passchopped = dataDecoded.substring(dataDecoded.indexOf(":")+1);

msg.put("userchopped",userchopped);
msg.put("passchopped",passchopped);

return true;         
}

You run this in a "Scripting Filter".

Once you have the variables userchopped and passchopped populated, you can use an "Attribute Authentication" filter to authenticate them like so:


In the case above, I'm checking the values against Active Directory. I could also check them against CA SiteMinder, Oracle Access Manager, IBM Tivoli Access Manager, etc.


Senior Oracle SOA Services Developer with Vordel experience required by CSC in Dallas

Cloud APIs – the Next Battleground for Denial-of-Service Attacks

$
0
0


Denial of Service attacks have been in the newsrecently. Most of the coverage focuses on Website outages caused by the attacks. However, Web APIs represent a soft underbelly for Denial of Service, and don't get the same level of coverage. To help address this, I've written a piece on the Cloud Security Alliance blog about "Cloud APIs - the Next Battleground for Denial-of-Service attacks.


The piece talks about strategies for protecting Web APIs, such as the usage of API Keys to throttle usage, and separation of Web API and regular Website traffic.

Webinar with Jeff Hammond of Forrester - The API wave, the Internet of Things, and the hidden world of Dark APIs

$
0
0
APIs are hot. Today on 18 April at 11am Eastern, 8am Pacific, and 5pm CET, I'm speaking on a webinar with Jeffrey Hammond from Forrester on enterprise APIs. Topics we'll be covering include:

- Catching the API wave. Jeff has a great analogy for this, which I'll leave as a surprise until the webinar...
- APIs and the "Internet of things". Cars, smart meters, and other sensors will soon outnumber mobile apps as API consumers. Is your API ready?
- The hidden world of "Dark APIs". Public APIs get all the publicity. What about the APIs used for sensitive data such as health records?

Register for free below:


Forcing HTTP 1.0 or 1.1 for incoming calls to the Axway/Vordel API Server

$
0
0
In a previous post, I wrote about how you'd configure the Axway/Vordel API Server to connect out to APIs using either HTTP 1.0 or 1.1. But, what if you wanted to force the API Server to receive API calls using either HTTP 1.0 or 1.1? This can be done using a simple trick. What you do is to create an "incoming" Remote Host, as shown below. In the example below, I've checked the box for "Force HTTP 1.0". This forces incoming connections to use HTTP 1.0

How to check for certificates about to expire, using the Axway/Vordel API Server

$
0
0
Did you know that the Axway/Vordel API Server can automatically check its certificate store (or Java keystore) for X.509 Certificates which are about to expire? This can be a very useful feature, to alert you to certs which are about to expire, before they actually expire.

Here's how to set this up. Firstly, I make a simple policy containing two filters. The first filter checks the certs, the second raises an alert (e.g. to an email address) with details of any soon-to-expire certs.

Here is the policy:


Note the first filter in the cert is checking for certs which will expire within 7 days. You can find this filter in the "Certificate" group in Policy Studio. Be sure to right-click on it and select "Set as start".

The second filter is the one which raises the alert. It's just an "Alert" filter. Note that it's joined to the top filter with a green arrow. Here is how I configure the text of the email to be sent:



So how do we make this certificate-checking policy run automatically? To do this, we use a Policy Execution Scheduler. Here I am selecting this:


I click on "Add Policy Execution Scheduler" and I configure it as shown:


If you want to add a different schedule (e.g. to run it once a week, or once a month) then add a new schedule under "Libraries -> Schedules" in Policy Studio.

So that is how easy it is to add a policy which checks through the certificate store to find certs which are about to expire. 
Viewing all 236 articles
Browse latest View live


Latest Images