F5 Bot Defense for Salesforce Commerce Cloud – Protect Your E-Commerce Site From Unwanted Bots and Illegitimate Traffic (1 of 2)
This article is the first in a two-part series. Go to Part 2 here. Introduction Effective security matters to every retailer of every size because attacks continue to increase, whether engineered by humans or automated by bots. To help all our e-commerce customers succeed, F5 has made security easy to adopt and offers a wide range of integrations, including with cloud-based commerce platforms like Salesforce Commerce Cloud (SFCC). F5 Bot Defense integrates directly into the SFCC storefront and protects your digital business against unwanted bots and illegitimate traffic. Website owners and developers can gain full visibility, protect against credential stuffing, fraud & abuse attacks, and other advanced attacks that bypass traditional security controls. In this article, you will learn how to configure and customize the F5 Bot Defense solution for your SFCC site. The solution is delivered as a certified cartridge and supports both the legacy Site Genesis Salesforce Commerce Cloud eCommerce sites and the modern Storefront Reference Architecture (SFRA) sites. Note: This article contains a fair number of references to Shape Security-related offerings including Shape Enterprise Defense. Shape Security was acquired by F5 in 2020 and many of the products and offerings are currently undergoing a rebranding effort. During a period of time, you will continue to see the Shape branding reflected in the user interface, some settings, and occasionally in product references. Figure 1: F5 Bot Defense for Salesforce Commerce Cloud Deployment Steps The F5 cartridge can be deployed with either Storefront Reference Architecture (SFRA), a controller-based SiteGenesis site, or a pipeline-based SiteGenesis site. The deployment steps outlined below were tested for Salesforce B2C Version 21.7, Compatibility mode 21.2, and SFRA version 6.0.0. Prerequisites F5 Bot Defense requires an API key and a header prefix string for your e-commerce website to connect to the backend engine. Please contact your F5 account team or F5 customer services for any help in obtaining the API key and the prefix string. Step 1: Install the F5 Cartridge and Import the Metadata Firstly, you will install the F5 Cartridge and set up the business manager, for integrating F5 Bot Defense with SFCC. Download and Install the F5 Bot Defense Cartridge Deploy the F5 Bot Defense cartridge using Salesforce UX Studio for Eclipse. Alternatively, you can use Visual Studio code with the Prophet Debugger extension. Download the F5 cartridge from the SFCC LINK Marketplace by clicking on the Download Integration button. Establish a new digital server connection with your SFCC instance. Import cartridges to the workspace in Salesforce UX Studio. Figure 2: F5 Bot Defense cartridge imported into the workspace within Salesforce UX Studio Add the cartridge to the Project Reference of Server Connection. Figure 3: F5 Bot Defense cartridge added to the Project Reference of Server Connection Wait until the Studio completes the workspace build and uploads source codes to the sandbox. Assign the F5 Bot Defense Cartridge to the Storefront Site In the SFCC Business Manager portal, navigate to Administration > Sites > Manage Sites. On the Storefront Sites webpage, click on your site name. Next, click on the Settings tab on the site webpage. At the beginning of the cartridge path, add the following: int_f5:int_f5_sfra: When done, press the Apply button. Figure 4: F5 Bot Defense cartridge path added to the Storefront site Import the Metadata To add the newly configured setting to the Storefront site, you will need to import the pre-defined metadata: Open the downloaded cartridge package and navigate to the /metadata/f-five folder. Click on the Sites folder and rename the RefArch folder to the ID of your storefront site specified in the Business Manager. Then, zip the f-five folder. Navigate to Administration > Site Development > Site Import & Export. Under the Upload Archive section, upload the f-five.zip file and click on the Import button. Figure 5: Import the pre-defined metadata for the site using the ‘Site Import & Export’ feature Continue reading Part 2 here.F5 Bot Defense for Salesforce Commerce Cloud – Protect Your E-Commerce Site From Unwanted Bots and Illegitimate Traffic (2 of 2)
This article is the second in a two-part series. Go to Part 1 here. Step 2: Setup the Integration You will identify the endpoints and customize several settings in the F5 cartridge. Custom Objects The integration uses custom objects to configure endpoints that should be protected. Custom objects are stored locally (per Site). Navigate to Merchant Tools > Custom Objects > Manage Custom Objects There are three custom object types. BotProtectedEndpoints - describes the protected endpoint behavior SAFEEndpoints - describes the protected endpoint behavior for SAFE mode GETScrapingEndpoints - describes the protected endpoint behavior ISTL BotProtectedEndpoints and GETScrapingEndpoints have the same structure. SAFEEndpoints have only ‘id’ and ‘paths’ fields. The custom object stores a list of all protected endpoints and describes their behavior for different F5 Shape solutions. The example below outlines how to configure the account-login-post object as a protected endpoint. Select the object type based on the subscribed mode and click on the Find button. In the results, click on the account-login-post object id and select a Mitigation Action. Figure 6: Sample configuration to define a protected endpoint Custom Site Preference Groups. Here, you will specify the values of various options to customize the F5 integration. Navigate to Merchant Tools > Custom Site Preferences Groups > Site Preferences > Custom Preferences and click on Shape. Enter the values for Telemetry Header Prefix, F5 Shape API hostname, and API key, obtained from F5. Figure 7: Sample configuration to specify the values for connecting to the F5 Bot Defense back-end engine Scroll down to Specify F5 Shape JS URL or Path. Enter the JS URL. In the Select location for JS tag(s) option, you will choose one of the following, based on your preferred location to insert the JS tag: After head (head) After tail (tail) Before script (script) Figure 8: Sample configuration to specify the values for F5 Shape JS URL and its path In the Insert JS tag(s) in only specific web pages (entry pages) option, select either Yes/ No. The No choice will insert the JS tag to all the webpages The Yes choice will provide an additional option to specify the web pages for which the JS tag needs to be inserted. Figure 9: Sample configuration to assign the JS tag to specific entry pages This completes the F5 cartridge configuration. When done, click on the Save button at the top right-hand cover of the web page. Step 3: Verification To test the F5 Bot Defense integration with SFCC, emulate a malicious request from a client machine to your e-commerce website. From Browser Access and log in to your SFCC site from the browser. Inspect the web page source; you will notice the JS inserted by the SFCC. Figure 10: JS insertion You will also notice the prefix string and the telemetry headers passed in the HTTP POST. Figure 11: Telemetry headers inserted in the HTTP POST Now, disable the JavaScript support in the setting of the client browser and log in to your site. The F5 Bot Defense will identify this HTTP request as malicious web traffic and will block the request ('Block' is the migration action selected for the account-login-post in the custom objects) Figure 12: F5 Bot Defense blocked the request from the JS disabled browser F5 Bot Protection Manager Access your F5 Bot Protection Manager portal to see all the client requests to your e-commerce site. You will notice all the shoppers' traffic to the storefront, the login request from the JavaScript disabled browser that was used to emulate bot traffic will be flagged by F5 Bot Defense in red as malicious. Figure 13: Malicious bot traffic detection by F5 Bot Defense The F5 Bot Defense integration with SFCC using the certified cartridge is an easy-to-deploy solution that seamlessly works with the Storefront Reference Architecture. With this industry-leading MI-driven security, your digital business is safeguarded in real-time with superior accuracy & long-term efficacy. Deploy the cartridge from the SFCC Link Marketplace to minimize the impact of Bots on your business, confidently. Additional Resources F5 Bot Defense integration for SFRA sites: Configuration Guide F5 Bot Defense integration for SiteGenesis sites: Configuration Guide Solution Lightboard: YouTube Video Salesforce partnership: Technology Alliance on F5.com
Cloud Extend: Because One Size Does Not Fit All
Active Endpoints introduces Cloud Extend for Salesforce.com and reminds us that commoditization most benefits providers, customization most benefits customers. In the context of cloud computing we often mention the driving force behind many of its financial benefits is commoditization. Commoditization drives standardization which reduces costs of the product itself as well as the management systems needed to interact with them. Commoditization drives the cost of manufacturing, of creating and/or providing a good or service down for the provider. It is usually the case, expected in fact, that those savings are passed on to the consumer in the form of lower prices. Thus, the commoditization of compute, network storage resources results in a lower cost for cloud computing providers and they have, thus far, seen fit to pass that along to would-be customers. The actual product, while perhaps being highly commoditized itself, however, must still be adaptable to fit the customer’s often unique use case. For many organizations, for example, business applications are a necessary component to managing business. For others, they encapsulate processes that are considered competitive advantages. Applications, even those commoditized, must be able to support both styles of use while maintaining the low cost realized through commoditization. While the core processes many applications encapsulate are the same, there are always tweaks and modifications required that reflect the slight differences in markets, businesses, and even the product being offered. The underlying processes are different from organization to organization and that needs to be reflected in the software, somehow. The general use of some software applications has become generalized. It’s not commoditized, but it’s close. The general process, the data, the purpose of software such as CRM (Customer Relationship Management) and SFA (Sales Force Automation) is generally applicable to all organizations. But the way in which an organization manages customer relationships, sells customers products, and interacts with its customers always comprises some difference that needs to be reflected in the software. Successful SaaS (Software as a Service) providers like Salesforce.com knew that from the beginning. Data was customizable, the GUI was even customizable to reflect the differences in terminology across vertical industries and organizations alike. But it also knew that wasn’t enough, that organizations would find the restrictions on being forced to adhere to a certain codified process would eventually become an impediment to continued adoption. So it built a platform upon which an ecosystem of supporting applications and services could be provided that would enhance, modify, and otherwise allow customers to tailor the core application to better suit their needs. Active Endpoints puts that platform, Force.com, to good use with the introduction of its latest business process management (BPM) offering: Cloud Extend for Salesforce.com. DROP DEAD SIMPLE To set expectations, understand that Cloud Extend™ for Salesforce.com (implying there will be other Cloud Extend solutions, which Active Endpoints confirms) is built on the Force.com platform and targeted at Salesforce.com customers. The reason the overall solution is worth discussing in a broader context is the underlying framework and integration that makes the Salesforce.com solution so elegant can certainly be applied to other software – and potentially infrastructure – solutions. What Cloud Extend offers is an easy to use, guided method of codifying a process within Salesforce.com that simultaneously allows for integration with the growing set of data integration points within Salesforce.com. For example, say a business or sales leader needs to guide customer service in a specific direction regarding a forthcoming upgrade of its software solution. This sales leader can, with no technical training – seriously – lay out the “script” by which customer service folks can engage customers in a discussion regarding the upgrade and properly collect the appropriate data while simultaneously creating any necessary events or e-mail or what-have-you within the Salesforce.com system. After having spent many grueling hours with a variety of interfaces designed to provide drag-n-drop creation of processes, Cloud Extend was the first one that actually delivered on its promise of “drop dead simple.” Now, part of that simplicity is driven by the limitation of what kind of activities can be included in a process and that’s where IT comes in – and the possibilities for other uses in the data center become clear. IT’S ABOUT the SERVICES What makes the integration of Cloud Extend with Salesforce.com seamless is under its hood. When users are creating or invoking activities in the business process it’s really executing service-calls to a cloud-hosted business process management solution called Socrates, based on Active Endpoints’ acticeVOS product. Active Endpoints platform is what provides the services and the integration with Salesforce.com necessary to enable a drop-dead simple interface for customers. When a user needs to specify an action, i.e. invoke a service, in the business process it is accomplished by means of a drop down list of available services, retrieved via standard service-oriented methodologies under the covers. In ancient days, business process codification required the administrator to not only know what a WSDL was, but how to find it, retrieve it, and in some cases, pass parameters to it in order to take advance of services. With Cloud Extend all the minutia that makes such efforts tedious (and requires technical skills) is hidden and presented via a very responsive and intuitive interface. The services and the process automation engine that drives the guidance of users through the process are deployed in Active Endpoints cloud; integrated via a standardized, service-oriented integration model that leverages Salesforce.com APIs to provide the data and object integration necessary to make the experience a seamless one for users. What this solution offers for Salesforce.com customers is customization of not just the solution, but the business processes required by the organization. Cloud computing is primarily about commoditization and SaaS is no exception. The problem with commoditization of business-related functions is that, well, one size does not actually fit all and every organization will have its own set of quirks and customizations to its sales force automation and customer service processes. Virtually all of the more than 90K Salesforce.com customers customize their offering to some degree. But customizing SaaS, in general, aside from the typical naming of columns in the database and some tweaking of the interface is not a trivial task. What Active Endpoints offers in Cloud Extend is exactly what customers need to be more responsive to changes in the business environment and to enable a more consistent sales force and customer service experience for its customers. Scripted, guided processes enable the rapid dissemination of new processes or information that may be required by customers or sales to address new product offerings or other business-related issues. ONE SIZE DOES not FIT ALL The concept of commoditization works well in general. Each of the three core cloud computing models – IaaS, PaaS, and SaaS – commoditize different resources as a means to create an inexpensive and highly scalable environment. But they all recognize the need – if even slightly – to customize the environment, the services, the flow, the application delivery chain, the application. Offering a platform upon which such customizations can be offered, the foundation of an ecosystem, is a requirement but in and of itself the platform does little to enhance the customizability of the resources it supports. For that you need developers and producers of software and services. This is not a concept that is applicable to only software. Custom ring-tones, themes. Hey, there’s an app for that! The ability to customize even the most standardized products like a smartphone assure us that consumers and IT organizations alike not only enjoy but demand the ability to customize, to make their own, every piece of software and hardware that falls under their demesne. You can customize the basic functions, but you also absolutely must provide the means by which the product can be customized to fit the specific needs of the customer. For Salesforce.com that’s Force.com. For Apple it’s an SDK and the AppStore. For others, it’s the inherent programmability of the platform, of the ability to extend its functionality and reach into other areas of the data center using service-enabled SDKs, scripting languages, and toolkits. Where other Business Process Management (BPM ) solutions have often failed in the past to achieve the ease of use required to make good on the promise that business stakeholders can automate, codify and ultimately deploy business process solutions, Active Endpoints appears to have succeeded. Infrastructure automation and orchestration vendors should take note of the progress made in providing simple interfaces to solve complex, service-oriented problems like those associated with automation of deployment and provisioning processes, specifically those requiring the collaboration of network and application delivery network infrastructure components. The service-enablement of components a la infrastructure 2.0 makes them well suited for automation and orchestration via what have traditionally been viewed as software and process automation solutions. There is nothing stopping an organization from taking advantage of a solution like activeVOS and Socrates to create an on-premise solution that leverages the lessons learned from business process automation in a way that positively improves operational process management. Microsoft / F5 Solutions on DevCentral F5 Friday: A War of Ecosystems Aligning IT with the Business by Decreasing Efficiency Tour of Cloud Extend An Aristotlean Approach to Devops and Infrastructure Integration Cloud is the How not the What Standardizing Cloud APIs is Useless Standardized Cloud APIs? Yes. Infrastructure 2.0: Squishy Name for a Squishy Concept Infrastructure Integration: Metadata versus API The API Is the New CLICloud-Tiered Architectural Models are Bad Except When They Aren’t
Database as a service is part of an emerging model that should be evaluated as an architecture, not based on where it might be deployed These days everything is being delivered “as a Service”. Compute, storage, platforms, IT, databases. The concept, of course, is sound and it is generally speaking a good one. If you’re going to offer an environment in which applications can be deployed, you’d best offer the services appropriate to the deployment and delivery of that application. And that includes data services; some kind of database. Shortly after the announcement by Salesforce.com of its database as a platform service – database.com – Phil Wainewright posited that such an offering might “squish” smaller providers. Some vehemently disagreed, and Mr. Wainewright recently published a guest post, written by Matt McAdams, CEO of TrackVia, regarding the offering that disputes that prediction: Rather, Salesforce.com is making the existing database that currently underlies its CRM and Force.com platforms accessible to subscribers who don’t have accounts on one of those two platforms. The target audience is programmers who want to build an application outside of Force.com, but want a hosted database. Unfortunately, web application developers will find the idea of hosting their data outside their application platform severely unappealing. The reason is latency. Database.com: nice name, shame about the platform Mr. McAdams goes into more detail about the architecture of modern web applications and explains the logic behind his belief. He’s right about latency being an issue and is backed up by research conducted by developer-focused Evans Data Corporation. Developers report that performance is the second-most important attribute found in frameworks and platforms. The ability of a framework or a platform to deliver high throughput, minimal latency and efficient use of computing resources is a major factor in decisions regarding which application frameworks to use for development. [emphasis added] -- Evans Data CorporationUsers’ Choice: 2010 Frameworks (April 2010) So performance is definitely a factor, but there’s more going on here than just counting ticks and some of what’s happening completely obviates his concerns. That’s because he ignored the architectural model in favor of narrowing in on a specific deployment model. There are a few critical trends that may ultimately make the Database as a Service (DaaS) architectural model (not necessarily the provider-based deployment model) a success. The CLIENT-DATABASE ARCHITECTURAL MODEL The consumerization of IT is well underway. No one lightly dismisses the impact on application platform development of consumer-oriented gadgets like the iPad and the iPhone. More and more vendors as well as organizations are taking these “toys” seriously and subsequently targeting these environments as clients for what have traditionally been considered enterprise-class applications. But the application architecture of the applications deployed on mobile devices is different from traditional web-based applications. In most cases an “app” for a mobile device employs a modernized version of the client-server model with nearly all client and application logic deployed on the device and only the data store – the database – residing on the “server”. It’s more accurate to call these “client-database” models than “client-server” as often it’s the case that the “server” portion of these applications is little more than a set of services encapsulating database-focused functions. In other words, it’s leveraging data as a service. It’s still a three-tiered application architecture, to be sure, but the tiers involved have slightly different responsibilities than a modern web application. A modern web application generally “hosts” all three tiers – web (interface or ‘presentation’ in developer-speak), application, and data – in one location. For all the reasons cited by Mr. McAdams in his guest post, developers and subsequently organizations are loathe to break apart those tiers and distribute them around the “cloud”. I’d add that reliability and availability as well as security (in terms of access control and the enforcement of roles in a complex, enterprise-class application) play a part in that decision but it’s the latency that really is the deal-breaker especially between the application and the database. But Lori, you say, HTML5 and tablets are going to change all that. Applications will all be HTML5 and even mobile devices will return to the more comfortable three-tiered architecture. Will it? HTML5 has some interesting changes and additions that make it more compatible with a mobile application architecture than earlier versions of the specification. Offline storage, more application logic capabilities, more control. HTML5 is a step toward a fatter robust, more complete application client platform. Couple that with the fact that web applications have been moving toward a more client-centric deployment model for years and you’ve got a trend toward a more client-database application architectural model. Web applications have been getting fatter and fatter with more and more application logic being pushed onto the client. HTML5 appears to support and even encourage that trend. Consider, for a moment, this web application written nearly entirely in JavaScript. Yes, that’s right. Nearly all of the functionality in this application is contained within the client, in 80 lines of JavaScript code. That’s a client-database model. Even on mobile devices, on tablets designed to better support “traditional” web-applications, they are there almost as an after-thought. The browser is used for reading articles and watching video – not interacting with data. It’s the applications, the ones developed specifically for that device, that make or break the platform these days. If that weren’t the case, you wouldn’t need separate “applications” for Facebook, or Twitter, or Salesforce.com. You’d just leverage the existing web application, wouldn’t you? And you certainly wouldn’t need APIs upon which applications could be built, would you? Of course not. So what, you might be asking, does all this have to do with the success or failure of database as a service? The answer is this: developers are lazy, and because we’re lazy we’re masters at architecting solutions that can be reused as much as possible to limit the amount of tedious and mundane coding we have to do. Innovation and change is often driven not by inspiration, but by the inherent laziness of developers looking for an "easier" way to do a thing. And supporting two completely separate application architectures is certainly in the category of “tedious”. WHEN BEING LAZY is a BONUS As more and more organizations decide to support both mobile and web versions of their critical business applications, it’s the development staff that’s going to be called upon to provide them. And developers are - no offense intended as I still self-identify as a developer - lazy. We don’t like the tedious and the mundane; we don’t like to repeat the same code over and over and over. We look for ways to reuse and simplify such that we can concentrate on those pieces of development that are exciting to us – and that doesn’t include anything repetitious. So as developers look at the two models, they’re eventually going to abstract them, especially as they explore HTML5 and find more and more ways to align the two models. They’re going to note the differences and the similarities in architecture and come to the conclusion that it is inefficient and potentially risky to support two completely different versions of the same application, especially when the option exists to simplify them. An architectural model in which the data access portions are shared – hosted as a service – for both mobile and traditional desktop clients makes a lot more sense in terms of cost to develop and maintain than does attempting to support two completely separate architectural models. Given the movement toward more client-centric applications – whether because of platform restrictions (mobile devices) or increasing demand for functionality that only comes from client-deployed application logic (Web 2.0) – it is likely we’ll see a shift in deployment models toward client-database models more and more often in the future. That means data as a service is going to be an integral part of a developers’ lives. That’s really the crux of what Mr. McAdams is arguing against – that a data as a service deployment model is untenable due to the latency. But what he misses is that we’re already half-way there with mobile device applications and we’ve been moving in that direction for several years with web-based applications anyway. APIs for web applications today exist to provide access to what – data. Even when they’re performing what appears to be application “tasks” – say, following a Twitter user – they’re really just manipulating data in the database. There is no real difference between accessing a data service over the Internet that is deployed in the enterprise data center versus in a cloud computing provider’s data center. So the real question is not whether such an architectural model will be employed – it will – it’s where will those data services reside? And the answer to that question doesn’t necessarily require a lot of technical discussion; ultimately that has to be a business decision. The Database Tier is Not Elastic 80-line JavaScript Web Application Does This Application Make My Browser Look Fat? HTTP Now Serving … Everything The New Distribution of The 3-Tiered Architecture Changes Everything The Great Client-Server Architecture Myth Infrastructure Scalability Pattern: Sharding Sessions Infrastructure Scalability Pattern: Partition by Function or Type Applying Scalability Patterns to Infrastructure Architecture Sessions, Sessions EverywhereDespite Good Intentions PaaS Interoperability Still Only Skin Deep
Salesforce and Google have teamed up with VMware to promote cloud portability but like beauty that portability is only skin deep. VMware has been moving of late to form strategic partnerships that enable greater portability of applications across cloud computing providers. The latest is an announcement that Google and VMware have joined forces to allow Java application “portability” with Google’s App Engine. It is important to note that the portability resulting from this latest partnership and VMware’s previous strategic alliance formed with Salesforce.com will be the ability to deploy Java-based applications within Google and Force.com’s “cloud” environments. It is not about mobility, but portability. The former implies the ability to migrate from one environment to another without modification while the latter allows for cross-platform (or in this case, cross-cloud) deployment. Mobility should require no recompilation, no retargeting of the application itself while portability may, in fact, require both. The announcements surrounding these partnerships is about PaaS portability and, even more limiting, targeting Java-based applications. In and of itself that’s a good thing as both afford developers a choice. But it is not mobility in the sense that Intercloud as a concept defines mobility and portability, and the choice afforded developers is only skin deep.Is PaaS Just Outsourced Application Server Platforms?
There’s a growing focus on PaaS (Platform as a Service), particularly as Microsoft has been rolling out Azure and VMware continues to push forward with its SpringSource acquisition. Amazon, though generally labeled as IaaS (Infrastructure as a Service) is also a “player” with its SimpleDB and SQS (Simple Queue Service) and more recently, its SNS (Simple Notification Service). But there’s also Force.com, the SaaS (Software as a Service) giant Salesforce.com’s incarnation of a “platform” as well as Google’s App Engine. As is the case with “cloud” in general, the definition of PaaS is varied and depends entirely on to whom you’re speaking at the moment. What’s interesting about SpringSource and Azure and many other PaaS offerings is that as far as the customer is concerned they’re very much like an application server platform. The biggest difference being, of course, that the customer need not concern themselves with the underlying management and scalability. The application however, is still the customer’s problem. That’s not that dissimilar from what enterprise-class organizations build out in their own data centers using traditional application server platforms like .NET and JavaEE. The application server platform is, well, a platform, in which multiple applications are deployed in their own cozy little isolated containers. You might even recall that JavaEE containers are called, yeah, “virtual machines.” And even though Force.com and Google App Engine are proprietary platforms (and generally unavailable for deployment elsewhere) they still bear many of the characteristic marks of an application server platform.
