Perficient Digital Transformation Blog


Archive for the ‘Technical’ Category

API Security: Common Threats and Considerations


Common API Threats: spoofing, tampering, repudiation, denial of service, unauthorized access, confidentiality violation

API Security Considerations: 

Identification – Know Your Consumer
The common approach to implementing this is using API keys, which are nothing but randomly generated values that will vary for each consumer.

Authentication – is Consumer Authentic

User-Password over SSl/TSL: the API consumer will be providing a user password to ensure their authenticity.

OAuth – Additional Security by providing token-based access, and the token can have attributes like expiration, which means
any user can perform certain activity for certain period of time and then later on they need to renew or get a new token
depending on what strategy is being implemented.

SAML – Another mechanism for Authentication. Security Assertion Markup Language (SAML) is an XML standard for injecting
Assertions. Typically, the identity provider will validate the user’s identity and insert appropriate assertions to describe things like what application, resource users have access, roles etc.

OpenID is another solution that gives funcationality similar to OAuth and SAML

Authorization – Is consumer authorized to perform a certain action?

Apart from these basic things, one might also want to consider following:

Json Attack: Since most of the API accept or return JSON response, the response can be intercepted in middle. We can have API Gateway taking care of this for all request responses.

Data Protection : Depending on the information being sent or received, we might need to encrypt certain data elements or mask data so that it will be difficult to guess or figure out what they are and what they really mean. For example, PHI or PCI information.

Richer, More Personalized Customer Experiences for an API Economy


Open API Economy Source:

At the IBM Digital Experience 2015 Conference, Ajay Kadakia with IBM talked about how the API economy is affecting legacy IT companies versus the newer cloud-based companies. The challenge is how to provide more agile, market reactive content off the legacy systems when competing against seemingly more agile, cloud based systems.

Ajay talked about the digital disruption that is already underway:

  • 90% of data has been created in the last 2 years
  • 4x increase in cloud investment vs 2013 (just 2 years)
  • 100% of LOB apps will be mobile first by 2017
  • 75B internet connected devices by 2020

Customer centricity is the only differentiator in today’s world, so experience really matters. But customer choice has exploded in the ways they can experience our brand.  Previously a website was the key method for customer self service.  Now we have devices such as mobile apps, kiosks, internet TV, connected appliances, connected cars, etc.

The only way to reach out to all these channels is to build robust APIs. To succeed, you must include a strategy for API creation and consumption in your overall business strategy. And this requires support at every level of the organization.

So what is an API in the context of an API economy. An API is like a Lego building block that can be combined with other APIs to build more sophisticated services.  APIs are the fast path to new business opportunities.  At the end of 2014, over 75% of Fortune 1000 had public APIs.  Almost every bank or financial services companies have APIs for their partners.

A successful API initiative requires end-to-end capabilities. APIs need to know who is using the API, you need to figure out how to charge or not charge for use of the API, and of course you need to manage the use of the API, which can require some IT infrastructure.

Entry points into the API Economy include:

  • Build – API Design and Implementation
  • Manage – API Lifecycle Management
  • Secure – Security, Metering and Control
  • Monetize – Analytics and Monetization

So how do you get started?  First accelerate your agility.  If you can’t be agile, you won’t be fast enough to meet customer and market demand.  Second you need a strategy to identify business goals, assets and revenue strategies.  Finally you need to monetize the API.

What can be API’s? Here are some examples of business assets that could be exposed through APIs:

  • Product catalogs
  • Customer records
  • ATM/Retail Locations
  • Payment Services
  • Shipping and fulfillment
  • Job Openings
  • Risk Profiles
  • Transaction data

You need to do a thorough asset inventory to identify the potential assets that you have that can become APIs.  Some APIs could be monetized, while others may be more useful to create brand loyalty. For each API you need to determine the business goals and success criteria.

There are several monetization models to consider:

  • For Free – can drive adoption for typically low valued assets or brand loyalty
  • Developer pays – high value assets (like Amazon Web Services) could get paid by developers
  • Developer gets paid – provides incentives for developers to use your API for things like Ad Placement, etc
  • Indirect – includes other models

For IBM, they were late to the API Economy, but have quickly caught up through various acquisitions over the past few years. IBM Watson and the new IBM/Apple apps are built on the IBM API platforms.

How to Implement Lighter Weight Portals, Part 3: Knockout Portlet

In this series, I’m showing how Portals don’t have to be heavyweight.  In Part 1, I wrote about how to make the infrastructure lighter by using cloud or IBM’s Pure System.  In Part 2, I introduced the concept of using IBM’s Web Content Manager system to build very simple portlets.

Now in this final installment, I am going to extend the concepts introduced in Part 2 to show how we can build more complex portlets, but still keep everything lightweight.  To review quickly, in Part 2, I avoided the build and deploy cycle of building Java portlets by using the built-in content management system – WCM.  In that example, I used WCM to display a Reuter’s news feed from a simple Javascript widget supplied by Reuters.

My Appointments Portlet

Final Appointments Portlet

In this blog, I want to implement a more complex portlet using Knockout, which is a popular Javascript framework.  My example is to display in a portlet a list of my Doctor Appointments pulled from a REST service.  Our goal is still to keep this lightweight, so I shouldn’t see a lot of code.  The first screen shot shows you what the final version looks like in Portal 8.

A typical web page or application consists of several sections:

  • CSS
  • Links to external files
  • HTML body
  • Javascript

In WCM, we can create an authoring template that contains four HTML fields, one for each of the sections described above. The authoring template also has a workflow associated with it so we can control the publishing of our code.
Read the rest of this post »

IBM Digital Experience Conf: Developing Portlets Using JQuery

jQuery is one of the most pervasive scripting libraries in use today. The session “Developing Portlets Using Javascript and JQuery for Engaging Digital Experiences” by Stephan Hesmer, Web 2.0 Architect, IBM and  Jaspreet Singh, Rational Tools Architect, IBM provided good insight as to how to leverage jQuery in IBM WebSphere Portal.

First, a couple of key statistics to indicate why this is important and cannot be ignored:

  • 57.5% of websites use jQuery.
  • jQuery has a 93% marketshare.

WebSphere Portal still includes Dojo but it isn’t required for view mode.  It is required in edit mode however, especially for in place editing.    One key change in portal 8.5 however is when edit mode, the edit panel is now isolated from pages so it will not conflict with the page. Read the rest of this post »

IBM Digital Experience Conf: IBM Web Content Manager Patterns

Eric Morentin and Nick Baldwin spoke about WCM Patterns that should be used in content management development in IBM Digital Experience.  Patterns of course are a “canned” way or even best practice for implementing solutions.  There are four themes of patterns they talked about:

  1. Better content / component model
    • There are different types of content and Content Manager build a content page by pulling various types of content.  Types can include things like slide shows, lists, blocks, highlights, teasers, etc.
    • A good first pattern is the List Content Component. Use a WCM Component to build the list.  The end user only has to select what list to display and perhaps customize the query to define the list.  Within content manager, lists are composed of Navigators and Presentations.  The navigator component is the query tool to select items for the list and the presentation component is how you display the results.
    • In general, then a good content/component model will let you create special purpose components  and then combine them into business level tools that the content authors can easily incorporate onto a page. Special purpose components such as lists, blocks, carousel are higher-level components than what come out of the box with WCM, but are built-up using those out of the box components.
    • A slideshow content component would consist of the same List Content Component pattern, but adds a Javascript plugin component to control the display of the slide show.
  2. More reuse
    • Build a library of standard components that can be reused.  In IBM’s Content Template Catalog, they have many reusable components built on component elements like field design, fragments, inline editing controls, etc.
    • You could have reusable component headers, designs and footers that get referenced by the higher-level components like the Slideshow mentioned above.
    • As an example, in the header, you could have common tools like the inline edit code.  This same header can then be used on all your components so you can manage or change the inline edit code in one place.
    • There are also good patterns and tools available like SASS – Syntactically Awesome Style Sheets to help you with creating reusable CSS.
  3. Better site model
    • Sites connect pages and content.  Pages provide the navigation model in portal.
    • The Page Content Structure pattern shows how you structure a site.  The content site contains just content.  There is a content item created for each “component”.  Teasers live in their site.  All these sites can roll into a common site based on the page.
    • This results in a lot of site areas.
  4. Split content, design, navigation, configuration and code or separation of concerns.
    • The component model pattern helps with this concept.
    • You should split design libraries from content libraries.
    • They suggest a Design library, a Content Library and a Process Library.  The process library and design libraries can be referenced from the various sites.

Other best practices/patterns:

  • Workflows can also benefit from good patterns.  One pattern is to use custom workflow actions to perform dynamic tasks such as picking the appropriate approvers based on an author’s business unit.
  • For Access Control, don’t explicitly define all access rights; instead use inheritance whenever possible. In 8.5, reviewer and draft creator (replacing Approver) can be inherited. Explicit access control also impacts performance.
  • Don’t have content items with 40+ fields.  Look for the ability to use custom fields to merge

Common Pitfalls

  • In place edits in non-projects – consider using a plugin to hide in line editing if no project is selected.
  • Multi Language – enable this upfront rather than wait.  Even with just two languages, use the MLS plug-in

Eric and Nick used the IBM Content Template Catalog as examples of patterns that you can implement.  They made the point over and over again that CTC is set of examples, so there are probably more components in there than you may actually every need.  You should take the ideas in CTC and make your own components based on the patterns. You should not really expect to install and use CTC right out of the box.


Google: Reasons Why Nobody Uses Your App, Your Site, Your…

I came across the article Google: Reasons Why Nobody Uses Your App in my favorite iPhone app Zite.  The article is about a presentation given by Tomer Sharon, a user researcher at Google, at Google’s I/O Conference. I embedded the video here for you to view.

Tomer identifies reasons why nobody uses your app.  I want to extend this to your web site, your portal, or whatever because these six reasons apply beyond an app.

I’ll summarize the reasons below, but there were two reasons that really caught my attention because they are spot on with my experience consulting with many, many companies over the past 18 years.

The first reason that caught my eye was “You didn’t test your riskiest assumption.”  Many times clients look to companies like Perficient to reduce risks in their projects.  We have deep expertise in a product they want to implement or build upon.  But we don’t always have expertise in the exact problem that is the riskiest.  When we don’t have that expertise, our value can be in how we approach the problem and how we draw on experience in similar areas.  However too often, clients don’t want to test their riskiest assumptions first, but instead, want to dive headlong into a large project.  Part of the reason is because they they can only get funding one time – so lets ask for the most we can get and then start moving.  Another reason for this is that spending on these kinds of projects – experimentations, proof of concepts (POC), etc – are viewed as wasting money.  But getting a solution to the trickiest part of your project early on is absolutely critical to overall success.

The second reason that caught my attention was “You listened to users instead of watching them.”  Companies have spent boat loads of money gathering requirements by asking users what they want in a system.  Users are more than willing to talk about what they would do with a new system.  But too often what a user says they will do doesn’t match what they really will do.  In the video, Tomar talks about a UK Research Project where the researchers asked people whether they washed their hands after using the restroom.  99% said of course they did.  When the researchers put equipment into the restroom to monitor hand washing, surprise, surprise, less than 80% actually washed their hands.  So when building systems, it is important to get something built quickly – a prototype or POC – and observe how people actually use the system.

Here are the reasons why people don’t use your app, your web site, or whatever. I encourage you to watch the video to get all the details.

  1. You didn’t understand the problem your were solving
  2. You asked your friends (or co-workers) what they thought
  3. You listened to users instead of watching them
  4. You didn’t test your riskiest assumption(s)
  5. You had a “Bob the Builder” mentality

Let me know what you think or if you have other advice.


Upcoming Webinar: Going Mobile with Your Liferay Portal

Next week, on June 12 at 1 pm CDT, I will be presenting a free webinar on Going Mobile with Liferay Portal.  Below is a description of the webinar and a link to register.  If you have Liferay Portal or are considering it, you will want to see what are your options for making sure that your mobile experience is a pleasant one.

Going Mobile with Your Liferay Portal

Mobile technology is expanding, and many marketing and IT organizations are working to catch up with their customers’ mobile demands. Customers expect to download your app, login, submit their order, deposit a check or even schedule their yoga sessions — all while picking their kids up after school or relaxing in the evenings.

The consumer-driven nature of mobile leaves many companies struggling to develop, enhance and provide the functionality needed to compete in today’s environment. Liferay Portal is one of the most aggressive open source portals available.

In this webinar, we will:

  • Review top mobile developments
  • Demonstrate why Liferay is a good open source option for portal development
  • Identify the options available to bring your Liferay portal to life on mobile devices
  • Review best practices for creating, supporting and deploying a full-mobile strategy

Click this link to register: Going Mobile with Your Liferay Portal


WebSphere Portal v8.5 First Look: Install

IBM announced the release of IBM Digital Experience Suite 8.5 on earlier this month. Today, I had the chance to download the software images from and I am writing this as I install WebSphere Portal v8.5 Extend edition on Windows 7 OS. I went ahead with the Extend edition because I wanted to get a hold of all the features that WP has to offer. 

WebSphere Portal v8.5 First Look: InstallDownloading the Installables
IBM made it easy for me to search for WebSphere Portal v8.5 installables and find all relevant e-Assemblies. The only thing that I find slightly irritating is that the relevant WebSphere Portal v8.5 e-Assembly was right at the bottom of the page. No worries – a quick browser text search for got me to the right e-Assembly.
Expanding the eAssembly – you can immediately see that IBM has change the packaging a little bit. The e-Assembly only has WebSphere Portal images.In the past, you would have to wade down through a whole list of other supporting software components (TDS, DB2, etc.). This has confused users (both new and old) in the past. No longer the case this time.  The right step towards a simpler “Digital Experience” perhaps? Excellent!


  1. You will have to download the image for WebSphere SDK JAVA edition v7.0.6.1. I don’t think I have downloadedthis in the past but this time around I had to download it (even though it says “optional” during the installation).
  2. No support for 32-bit Windows architecture (I found this out the hard way)
  3. The remote search server is truly optional (and is not required especially for a local install)
As from past installations of WP, I unzipped the downloaded zip files – taking care to ensure that I unzip all the files into a single folder. Total size of the downloaded zip files and the unzipped images together is about 19GB. Simple enough so far.

Read the rest of this post »

SharePoint migrations may cause consternation

When migrating to SharePoint 2013 older assets may need serious modification to gain from the benefits of the new, lightweight, fast, and fluid user interface. These benefits come from new CSS styles, themes, and master pages.

Thus, you must re-create your custom branding by using the new styles, themes, or master pages available in SharePoint 2013, and then apply the newly re-created design to the upgraded site collection.

SharePoint2013You can read more about the details from a Microsoft support article which outlines the approach for migrating custom UI artifacts to SP2013.

Some of the common approaches suggest creating an evaluation site collection and then, making specific modifications depending on the artifact:

  • Custom CSS – use that site as the environment where you can identify the new SharePoint 2013 styles that you need to override. Create a new CSS file for these styles, and then apply that CSS to your upgraded site.
  • Custom theme – re-create the theme by using the new theming features in SharePoint 2013.
  • Master pages – re-create the master page in the SharePoint 2013 site. After you verify that the new master page works as expected, move the master page to the new site collection and apply it to the site.
  • Custom content placeholders on a custom master page – create an evaluation site collection that is also a publishing site, and then set the master page to the out-of-the-box SharePoint 2013 master page. If the site still renders, you don’t have this issue.

Microsoft recommends that you do not add custom content placeholders to your custom master page or page layouts.

In conclusion, I hope this helps with your planning when considering either new initiatives on older releases of SharePoint (i.e. SP 2010), or when migrating to SP 2013.

Multifaceted Search using IBM Web Content Manager

Maria Rauba from Asponte presented how she implemented a multifaceted search using IBM Web Content Manager in Portal.  Faceted search is an often requested feature and is not something that comes out of the box in WCM.  Components used:

  • Custom JSPMultifaceted Search Using IBM Web Content Manager
  • Custom Search Seedlist
  • WCM Search component
  • Custom Javascript

The HTML Form contains the custom JSP used to render the checkboxes for the faceted search.  The search component is placed on the HTML form to show the results of the search.  When the search is submitted, custom javascript executes the search against the seedlist.

JSP component was used instead of Taxonomy fields because the taxonomy field is sortable only one way – alphbetical.

Search Component & Search Collection.  They used one search component for each language.  In the search component you can specify the sort order.  Out of the box you can select sort by relevance, date and none.  The search collection was scheduled to run every night, but you can schedule the crawler as often as you want.

Custom Seedlist was necessary to support the many levels in the taxonomy. Out of the box seedlist only looks at the last level for the search and does not include the full taxonomy hierarchy.  Also many times category names are repeated under different taxonomies, so you have to use a unique identifier (UUID) to make sure the search finds the right categories.

Some issues that were faced:

  • Dojo performance for sorting wasn’t as good as it could be, so they reduced the number of items in the list.  In the end, the sort time was unacceptable, so they went back to the default sort provided by WCM instead of using the custom sort.
  • Caching was an issue when the advanced cache was turned on.  They ended up turning cache off for this feature.
  • When there were a lot of check boxes, the ran into url length issues.

As a summary, Maria’s solution was

  • Dynamic
  • Fully multifaceted
  • Used only WCM
  • Provided a custom sort
  • Allowed content authors to manage the content and feed the search appropriately

Overall Maria’s solution was a good way to use out of the box features with some simple customizations.