Webinar with Sreedhar Kajeepeta from Adunik this Thursday

On Thursday at 11am Eastern I am presenting a webinar with Sreedhar Kajeepeta about APIs and SOA. As Sreedhar puts it, it's "The journey from SOA to $OA". The new lightweight Web API model allows organizations to extract business value from SOA in a way which was not possible below.

Here is the link to sign up for the webinar - I look forward to a great discussion and great questions.

Identity is the New Perimeter

It was Bill Gates who said that security should be based on "policy, not topology". It's a phrase which always stuck with me. Rather than basing security on where something is, you use a policy which is independent of the network.

Identity is a key part of security policies. We make decisions on who the user is, where they have logged in (their identity provider), and their attributes.

I've put this into a diagram below. On the left, you see the old security perimeter, with "good guys inside, bad guys outside". On the right, you see the the new architecture, where an organization has mobile workers, and employees who expect to use Cloud-based services like SalesForce.com just the same on-premises apps.

In the architecture on the right, security is based on identity, not on the perimeter.

APIs are key, both for the mobile and Cloud cases.

For mobile apps, it's important to provide the mobile backend which is the API layer that links mobile apps back into internal systems. A mobile backend exposes APIs which are consumed by mobile apps. It is at the mobile backend that rules based on identity and data validation are applied, as well as where the audit trail is written. Identity standards such as OAuth allow identity to be brought to bear for mobile users. 

Employees expect to use Cloud-based services such as SalesForce.com side-by-side with internal systems. The old perimeter model simply does not apply here. SalesForce is outside “the perimeter” but users must still be able to use it. Again, the solution lies with Web APIs. An API layer allows organizations to apply identity-based controls to SalesForce usage, plus data validation, and an audit trail.

Identity standards are key to the new perimeter. By using standards such as OAuth, you can based security on "policy not topology" where the policy is dependent on the client identity. This goes for connections "going out" (on-premises to Cloud) as well as connections "coming in" (mobile to on-premises).

Adding a SalesForce Connector to a "SaaS" group on the Axway/Vordel API Server

A frequent question about the Axway/Vordel API Server is "Can I add a new filter to the filters on the right of Policy Studio?". The answer is "Yes", and there are two broad ways to do this. The first way is to use the Filter SDK, which is a Java SDK for writing filters. The second way, requiring no programming, is to take an existing policy and convert it into a filter, by making it into a "Policy Package".

Here I am using the example of SalesForce.com. I have imported a SalesForce policy [which you can see in action for a SalesForce mashup here]. Once it is imported, it is visible on the left-hand-side in Policy Studio.

So I can I take this policy and make it into a filter on the right-hand-side of Policy Studio?

The answer is to right-click on it and make it into a "Policy Package". This is what I am doing below:

I am choosing a new category called "SaaS" for my new filter. Once I create the Policy Package, now notice the new "SalesForce" filter in the "SaaS" group below:

It is as easy as this to create a new filter from an existing policy. 

Plugging Cloud Identity Leaks - speaking May 15 at the European Identity & Cloud Conference

This Wednesday in Munich I'm speaking on "Plugging Cloud Identity Leaks - Should your Business become an Identity Provider?" at the Kuppinger-Cole European Identity and Cloud Conference.  

So what does it mean to "plug a Cloud Identity leak"? If employees at your business find it easier to "login with Google" or "login with Facebook" to cloud-based apps which they use for business, then that means that your employees are using a Cloud-based identity over their corporate login. This means that your employees credentials are being managed by a third-party. You're losing control, effectively leaking identity.

What is the alternative? The technical answer comes from standards such as OAuth 2.0 and OpenID Connect. These allow your employees to use their corporate login as a springboard to Cloud-based services, providing the same convenience of single sign-on, but with identity anchored at the corporate level.

I look forward to talking about this, and other cloud and identity topics, at EIC13. It's always a great conference with animated discussion (and German beer :-) ). 

How to change the listening port for the Axway/Vordel API Server

A common question about the Axway/Vordel API Server is "How do you change its listening port?". The key to answering this question is to understand what are the "Services" groups under Policy Studio for the API Server:

What are the "Services" groups?

If you look under "Listeners" in Policy Studio, you will see the various "Services" groups. In the screenshot below we see "Default Services", "OAuth 2.0 Services" and "Sample Services". These are a way to group different paths under different ports. So, for example, the sample services are only available under the port which is defined under "Sample Services". And, the sample services can be disabled en masse, without affecting other listeners. You could also setup a new Services group, call it "SSL Only", then put an SSL listener in that group. Then, paths exposed under "SSL Only" could only be accessed using SSL.

Parameterized Ports

If you look at the circled item in the screenshot above, you see that the port number is not visible. Instead, we see an environmentalized parameter. So where is the port number? Notice that the variable starts with "env". This is a clue. It is in the Environmental Properties file.

So, if you look under /conf for the particular API Server instance, you can find the envSettings.props file, which is where this variable is defined. Here we see it below:

Notice the highlighted text. This is where the port is defined, and it's port 8080 at the moment. You can change this value here. And, in fact, you can add other variables here and then reference them in policies, providing environmental customization of the API Server [e.g. on another machine, we may use 8888 instead].

How to read in a SAML Assertion from a REST STS and insert it into a HTTP header, using the Axway/Vordel API Server

It is a common scenario that an API Server must call out to a Security Token Service (STS) "off to the side" in order to get a SAML assertion issued for a user. This SAML Assertion then then usually inserted into the request, often as a HTTP header. Let's see how this is done with the Axway/Vordel API Server...

Firstly, I've setup an STS policy which is a "REST STS" (or "RESTS" for short). It takes in a UserID as a REST parameter and issues a SAML Assertion for that user. Here is the RESTS policy for this, below. Note that it's being served from the same API Server instance, but it could be served from another instance, or another product altogether could be issuing the SAML Assertion:

Looking at the policy above, we see the steps are:

1) Use the "Extract REST Request Attributes" filter to extract the attributes from the REST request. These attributes are the parameters being passed as part of the REST request.

2) We copy the "userid" parameter from the REST request into the "authentication.subject.id" parameter, and also populate the other two parameters which are needed for the "Insert SAML Authentication Assertion" filter we will be using later in the policy. The filter now looks like this:

3) We use a simple "Set Message" filter to create a SOAP wrapper into which we will put our SAML Assertion. This looks like this:

4) We then insert out SAML Assertion, and I put "REST STS" as the issuer name. I also choose "Sender Vouches" as the Subject Confirmation Method. 

5) Finally I round out the policy with a "Reflect Message" to return the SAML Assertion back to the client.

This policy allows me to get a freshly-minted SAML Assertion for a request containing a UserID passed as a QueryString parameter. Here is a screenshot of me running it below:

So next, let's look at the policy which calls this REST STS. Here's a screenshot of it in Policy Studio:

At a high level, this policy is firstly authenticating the client, then it is calling out to an STS to get a SAML Assertion for the client, then it is inserting that SAML Assertion into a HTTP Header. Note the Store and Restore filters which are used. These are used if you want to store the incoming message before calling out to the STS, because the message will be overwritten by the response from the STS. Note that if you're receiving a HTTP GET request initially, you don't need to use Store and Restore, simply because there is no message to store and restore.

Let's look at some of the filters which are used in this policy:

1) HTTP Digest Authentication. This is just standard usage of this filter, in this case against the Local User Store.

2) Store Message. Again, nothing special here. I'm using this filter with the default values.

3) Call REST STS. This is where it gets interesting. Notice I am passing the ${authentication.subject.id} parameter as a parameter to my REST STS:

If we had been calling a more traditional WS-Trust STS, I would have used a "Set Message" to create the RequestSecurityToken message, then used a "Set HTTP Verb" filter to set the verb to "POST", then a "Connect to URL" filter to connect to the STS.

4) "Retrieve SAML Assertion from message". This is a "Retrieve from message" filter which is reading the SAML Assertion which is returned from the STS. I am using XPath to do this. Notice that I am using the XPath Wizard (the little magic wand icon) and a sample message, to test my XPath. I am also using the "Serialize all nodes in the nodelist" option, because I want to retrieve the entire SAML Assertion into a nodelist:

5) Restore Message. This is restoring the original message (which was over-written by the response from the STS, when we called out to the STS "off to the side").

6) "Add SAML Assertion". This is where we add the SAML Assertion, Base64-encoded, as a HTTP Header (note that if we wanted to place the SAML Assertion into an XML message, we'd use "Add XML Node")

So that is how we call out to a REST STS "Off to the side", retrieve a SAML Assertion, and then place the SAML Assertion into a HTTP Header, using the Axway/Vordel API Server. 

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

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. 

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

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

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

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:

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

Denial of Service attacks have been in the news recently. 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.

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

CSC requires an Oracle SOA Services Developer with the following hands-on experience:

• Hands on development experience with:
• Vordel API Gateway 7.1.1
• Monk Scripting
• SOAP/MI ME messaging
• Java
• XML
• HTML
• SQL
• Test Scripts
• Unit Testing

The position is in Dallas with a lot of travel. Fittingly, for an Oracle centered requirement, it's listed on Taleo here: https://csc.taleo.net/careersection/jobdetail.ftl?job=1339480

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

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.