Webinar Recording

Make your Enterprise Applications Ready for Customers and Mobile Users

Posted on Apr 17, 2015

Rapidly growing demand for exposing and consuming APIs, which enables organizations to create new business models and connect with partners and customers, has tipped the industry towards adopting lightweight RESTful APIs to expose their existing enterprise services and corporate data to external consumers. Unfortunately, many organizations tend to underestimate potential security challenges of opening up their APIs without a proper security strategy and infrastructure in place.

Presentation, KuppingerCole

Presentation, Forum Systems

Lead Sponsor

Video Description

Show Transcript

Good afternoon. Good morning, ladies and gentlemen, welcome to another company. Call webinar. The topic for today is make your enterprise applications ready for customers and mobile users open up modernize and secure your interfaces. My name is Alexei Balaganski. I'm a senior Analyst at K Cole. And today I am joined by Jason Macy, who is CTO at forum systems.

Sorry, before we begin just a few words about keeping a call. We are an Analyst company working in the area of information security. We are providing enterprise it research advisory, decision support, and networking for it. We are based in Europe and Germany, but we have a global reach including UK United States and especially APAC region. Speaking about networking. We do a lot of events, more form of free webinars and the real world events as well.

And our flagship event this year is the European identity of client conference 2015, which will take place on in May 5th to eighth in Munich, Germany with over 600. It experts from more than 35 countries around the world, which is definitely when you should not miss. And as its have been traditional for recent years, we are hosting a number of complimentary workshops at the first day of the conference. And one of these workshops this time will be the foundations of IPA security and they pay gateway technology, Which will be attended by myself and chase and Macy as well.

And if you are around MUN on may the fifth, you are welcome to join us. It does not cost anything, just come by. So some guidelines for the webinar. First of all, you are all muted central. You don't have to worry about it. We will record the webinar and make it available on our website. Probably tomorrow. You will all receive an email notification when it's, when it'll be ready, questions and answers section will be at the end, but you are welcome to submit the questions anytime using the special questions tool of the go to webinar control panel.

So we will collect questions and I will read them loud for chase, or maybe for myself to answer it end. There are agenda for today, consist of three parts. First I will provide the general introduction into the very area of API APIs, their role in the modern or connected business and the challenges which your company will definitely be facing when trying to adopt to become the part of this API economy. In the second part, I will handle Jason and he will dive deeper into specific architecture details and technologies for API modernization.

And as I said, there will be a Q and a session at the end. Please start submitting your question as soon as you have them. And I would like to begin with a slide. You probably seen many times, if you have attended any of our webinars listening, the probable computing to is of course, a famous Russian horse carriage drawn by three horses. And these three horses are cloud computing, social computing, and mobile computing. It's just three major it trends, which are driving the innovation in the, in the it area now.

And basically, although they are opening a huge amount of new business models for companies, new possibilities to interact, they are also stretching the scope of information security to the new limits. Basically for information of model. Computer means that your customers can be accessing your services from any time from any platform. Cloud computer means that your data or your business logic will probably be hosted somewhere beyond the parameter of your company network and social computer means that you will have to establish new connections to various new types of partners out there.

And as I said, this, all, all this technological evolution is basically driven by business demand, which mean that it has to keep up. It has to enable new technologies. It has to provide security. It has to basically it has a leading role into, in decisions like which technologies will be adopted by business. So the quote with us, Carol, you see it takes all the running. You can do just to keep it the same place. And if you want to get somewhere else, you have to run at least twice as fast.

Well, basically what we observe now is that everything communicates companies, people, devices, and this new world of smart things, they all have to communicate And how they communicate well. They have communicate. They have to communicate through established interfaces. So basically the term API, we just few years ago meant pure technical meaning known only to software developers has suddenly become a lucrative business opportunity. Businesses want APIs. They want to open up their services to as many new audiences as possible.

And we, the, it, people have to take care about reliable and secure implementation. Just a couple of days ago, I was reading another article describing what here in Germany is called industry 4.0 new industrial revolution, which will totally change the way we work, the way we live, the way we communicate with our partners and customers and leads. It painted a beautiful new world full of capabilities and opportunities.

However, as usual, it has forgotten to mention the new challenges and problems and especially security and identity and trust related issues.

Oh, if I dare say that without security, instead of industry 4.0, we can easily end up with Skynet 1.0, if we have a, a look into the past, like safely say that the need to exchange structured data between heterogeneous and separated systems is as old as the networks themself, there were many different approaches to the so-called distributed objects, RPC, decom, CORBA, and so on, but probably the first internet scale, the first attempt to implement it on the internet scale is the so-called soap P single object access protocol, which was the first standardized and formalized set of specifications for to implement the service oriented architecture.

The paradigm of building loosely couple systems based off from the sales contained entities, which belong to different ownership domains. And although they are exposing kind of formalized inputs and outputs, the actual implementation tables are usually hidden though. The first attempt was so it was introduced in 1998. It was extremely well formalized and consist of large number of specifications, defining different protocols, transports, whereas built in security and other technologies for handling encryption, digital signatures and so on.

It was actually pretty successful in a sense, many enterprises still use it a lot for their internal services or for their B2B services. However, it failed miserably when it came to opening the services to the consumer scale internet. One of the biggest problem of course, was complexity. In order to support in order to connect to such a service, you need to develop, you need to do a lot of work. And another problem was pretty slow because the XML ization used for the, to transport the data back and forth is extremely redundant and it doesn't scale well for large implementations.

Therefore the next attempt has been made a few years later. It's so-called rest representation of state transfer is actually not a protocol at all. This is more like a common agreement on how to implement services. It was introduced probably the first noticeable large implementation of rest API was made by Salesforce in 2000, but it really gained momentum in 2006, when many large companies like Facebook, Twitter, and Google came out with their services based on rice APIs. I mentioned it's not a protocol it's just style from web services based on existing HDP methods and your eyes.

It doesn't have any strict requirements regarding the data formats. What most popular ones are chasing or XML. It's very easy to implement, very lightweight where scalable high performance, unfortunately, everything else is optional. So identity security and all the other services are not necessary. They're not built in, and this is why rest essentially one. Now it's a default standard for implementing APIs on the internet because you know, developers are lazy and businesses are inpatient to bring the API from the market as soon as possible.

So the rest, the only problem is it is that although creating a new rest API is very easy, converting new, existing, internal enterprise service to it. Isn't first of all, it, most probably it, it's not based on the rest architecture. It's probably using some legacy or some internal transport messaging protocol, or maybe even soap in any way before making available on the internet. It has to be somehow converted on the fly and it has to be somehow refactored, probably the different parts of different services have to be tailored and combined and merged. Something has to be marked.

And all this has to function on the fly without losing any scalability and security. Now, the next challenge is of course is addressing different types of identity.

Yes, as has been said, many times already, or making your business connected gives you a lot of new business opportunities.

It gives you to adapt to new business models to open up to new audiences, but you have to realize that supporting enterprise identities like your employees or business partners is completely different from supporting consumer identities, be it Facebook or any other social service logins, be it your customers or potential leads, or there are different authentication methods and different strong authentication standards, token smart cards, biometric devices, all this has to be taken care of before you even expose your service as an API.

The problem of course, that rest, as I said earlier, does not have any built in security. Probably the only defactor standard for rest APIs is all, sorry, all 2.0 or it's probably the most popular authorization standard for consumer APIs, which is again, your internal enterprise service is probably based on a different standard.

Most, probably same, which is the most popular authentication and authorization standard for enterprise solutions. Now it means that there has to be some kind of service taking care of accepting different identity, tokens, conversing, different authentication standards, supporting identity Federation standards. So without going into details, which I leave to Jason, I would say that you need some kind of security token service deployed in your network to support identity services for your API.

And then of course, or the access control becomes a completely different story for your internal service. Probably the, the old static role based access control was enough because you only had finite number of employees and few external partners, but to, to manage different types of identities, you really have to make everything dynamic. Each decision, whether to give certain identity access to a certain API method has to be done in real time in run time.

And it has to be based on the various types of context information, of course, the good old roles the attributes provided in claims device type geography, time of day, you name it. All of this has to be taken into the decision process and it has to be adaptive, agile and flexible enough to be extended and changed as soon as new standards, as soon as new types of audience appear.

So again, without diving deep into details, there is obviously a need for some kind of a policy management service running into your network, centralized place for creating and enforcing this access control policies. And of course you have to understand that implementing arrest API, you are basically opening a large front door directly into your corporate data, which is your most valuable and most highly protected asset.

And since rest APIs are based on the same HTP protocol, just like the normal website, you have to address all those, the same threats, denial of service attacks, Jackson, malware, you name it. And there are of course new types of attacks, which hack are constantly developing, which are publishing specific protocols or data schemes or, or code injections, which can describe to APIs.

And again, you have to take care of cashing, throttling, and other mechanism to ensure availability of your service. And of course, security is something which people tend to forget the design time and this especially tool for APIs where security is basically optional. And although some workers would say, but we have the transport levels encryption, we have SSL. The problem is that SSL is not enough. It's not secure because if you are, if you're relying on a open source implementation like open FSL, you are basically vulnerable to multiple security holes.

You know, you know, the stories of Hubble or Porwal or other attacks, which have been described recently in the press. And of course another problem is compliance. As soon as your data, as soon as the data you are dealing with is somehow covered by compliance regulations with healthcare data, private information, financial transactions, and on you have to be certified, which means that your API have to be, has to be protected by strong certified encryption. It has to be monitored.

It has to be completely, has to provide a complete audit trail, collect data for forensic analysis and so on and so forth. So basically, although the rest for API is wildly accepted as an easier alternative to hope, it looks like it's not that easy to publish your existing service as a, the rest for API. Luckily you don't have to take care of all these challenges yourself. There are vendors, there are solutions which will support you in that, on that way.

And this is where I would like to handle to Jason, who will provide you a deeper view into the specific principles and technologies for API modernization. Jason, Thank you, Alexei. Yes. So I will share with you the follow on information, bring up my information here. So thank you for that Alexia. It's a great segue into representing the challenges really that are out there to, to modernize and really make your applications ready for consumption, especially in the world of mobile and cloud it's it's, it's, it's certainly a challenge.

And what we're gonna do is we're gonna talk about how to solve that challenge specifically, what kind of technology we can use to do. So first quick introduction is forum systems. We are the provider of the forum century API security gateway, which is the industry's only secure architecture gateway product with fit certified network device protection profile certified, and us department of defense certified technology.

The focus of this technology is gonna line up very nicely with some of the challenges that Alexei just identified because the focus of PS with technology is, is integrated security, identity, access control, single sign on and data mediation. And I'm gonna talk about how all those come together to align with solving many of the challenges of API externalization and how to simplify that effort.

So we were talking about making these enterprise applications ready and Alexei gives some, some very nice introductions to the notion of APIs and the concept of APIs, really API, you know, in terms of looking at an enterprise application, which is usually a mobile app or, or a B2B integration point or Porwal or some data exchange that's happening.

It's often based on some of the modern structured data formats, like HTML, XML, soap, rest, and JS O but the API really represents that access point that intermediary, that interface to that service for data, it's the means by which to communicate often with some additional capabilities, but representing itself as really that, that enterprise application that, that, that interface to that enterprise application.

So if we focus on that as the aspect of getting our enterprise application around, then we can look at the notion of how APIs are truly the center point of integration and innovation across the spectrum of technologies. Today, the innovation curves are all evolved around the ability and necessity to interoperate, to work within different ecosystems, to be able to communicate with different infrastructure components and all of that has very significant aspects of what we're talk about around identity and security.

But it's, it's important to note that that APIs truly are the, the com comprise the, the core of modern day innovation. That's how the evolution of standards and the evolution of many technologies has converged to it enable this explosion of, of, of capability and innovation, which, which we see today in, in the landscape of, of computing.

And so we wanna look at these challenges that Alexei just highlighted in many ways around the enterprise application, or really if we focus that on the API challenges in terms of going back to those points that Alexei made around, okay, the authentication in SSO requirements as a component of APIs and, and, and, and enterprise application access, access control, of course, making sure the right decisions are made.

And then of course, the cyber security component of looking at the threat vectors and the, and the, and the characteristic types of security front, that enabling communication to the application, you know, via the API, ultimately poses those challenges. So we're gonna take each of these and focus on how we can solve that, enter the API security gateway concept. So with that notion of API accessibility, the Porwal or the window communicating with that enterprise application is where the API security gateway technology resides.

It effectively wraps and presents that API as a representation of the enterprise application itself. So it's meant to be a seamless intermediary. It effectively is presenting that communication to the consumer exactly as if it's the endpoint communication.

It is the, at that represents that integration point. But then by having control over the communication pattern to wrap that and broker those communications on behalf of the client, we can now start to look at how to centralize and solve many of these challenges that Alexei, just to highlight it very nicely around the, those access identity and security requirements.

And so that's where we focus on the core capabilities that this kind of technology provides that the API security technology has embedded within it policy engines that are capable of doing many things around those specific areas, transport secured, authentication, role based access control, content based access control, attribute based access control, threat mitigation, data privacy, and data mediation. These are all encapsulated within a security container certified so that the gateway itself is a security system by which these features and capabilities can be utilized within.

You have the, the combination of a secure platform that can be deployed on the network with confidence and the capabilities there, and to leverage out of purpose built technology that can do these things. So what does it mean to do these things?

Let's, let's talk about that a little further. Let's break it down to those core components of capability and, and let's map that back to Alex's challenges around what we need to actually achieve in order to facilitate agile APIs to, to, to foster innovation and externalization of information, but have the capabilities around authentication access control in data security. And that lines up very, very nicely with core competencies of API security gateway technology.

In that those are the mantras of that type of a gateway approach, which is unifying and combining identity access control and data security at one technology component, so that you can centralize those decisions. So let's talk about the agility factor that goes into security and identity and how we can achieve that. It goes back to some of the points that Alexei made earlier around the different technologies, the different standards we've talked about rash, we've talked about soap.

So when we talk about unifying capability with regard to API security and identity and access control, we have to focus on the broad spectrum of different technologies in different data formats and different identity formats that, that live on the, on the, on the networks that are a part of existing ecosystems. So when we focus on that one key component of a solution that can, that can provide for the identity management aspect is to be able to understand and consume all kinds of different identity token types.

Now, fortunately, over the evolution of the last 10 or 15 years, a lot of standards have matured and evolved to be, you know, framed within a pretty known set of token types. It's fairly broad still, but still framed within standards. So like in the soap world, you'll usually see username tokens or curb tokens, or X 5 0 9 tokens or SAML tokens or digital signatures within embedded X 5 0 9. So those are very standard ways within sort of soap and, and XML world to deliver identity credentials within the message.

And then you've got your sort of restful and mobile and, and, and web Porwal world of, of protocol identities, like basic authentication digest, a form post authentication cookie off, you know, X 5 0 9, 2 way authentication are all mechanisms of identifying the, the, the consumer or the client that's coming in to make those requests. So we need to unify all of that within a technology component that can consume all of those things. So this is the core capability and competency of gateway technology that can unify and consume all these different formats.

And in fact, translate from one to another. So from an interoperability perspective, from an API exposure perspective, now that same enterprise application can actually be exposed as an API in different ways, potentially in, on different identity, token formats, so that you can extend a much broader landscape of consumers without having to worry about interoperability and other issues.

The having the broadest spectrum of identity consumption capability gives you the highest ability to be agile about that, about that business service, about that enterprise service, because ultimately then you could focus purely on what the service does rather than having to worry about all the different landscape of technologies that are to be consuming. So we want to be able to unify our identity consumption, then provide those access control.

The logical next step of identifying user or, or, or a device or a system is to then provide those dynamic mechanisms that actually noted around access control. That includes often talking to some kind of IBM infrastructure system that contains, you know, password credentials, you role information. This could be app, an active directory, a site mindly all the standard IBM systems out there database, which the, ultimately when those credentials are extracted, then communicate with one of those IBM systems for validating those credentials and then doing additional checks around roles.

And here's the key, the gateway capability of combining data security with identity allows you to also look at the messages that felt the information itself that's being presented to the API coming in, as well as going back so that we can focus access control, not only just on trusted users and entrusted roles, but rather more dynamically about the information also that's coming with that user and that's leaving the back out the API to that use.

That's really a key aspect of access control is also focusing on the data and the content affiliated with that user as a part of the, the access control dynamic analysis. And then obviously attributes in terms of the time of day geo geolocations, where you're coming in from all kinds of different conditions that are in fact dynamic in nature.

And, and, and the philosophy of, of a gateway approach to this is that now you can unify that, such that all those types of accesses to different APIs to make these decisions dynamically through policy design and policy implementation. And ultimately our next step in that is we do certainly want the identity concepts. So for sure we know who's coming in and accessing these APIs control that and through various access control, but ultimately when these are cases of valid users and valid transactions, we want that experience to be seamless and unified across our APIs.

And that's where the concept of Federation comes in, where you'll see standards like Sam and oof, as, as quite the, the two primary adopted solutions out there around delegated authentication and the ability by which to take those identity authentication and access control decisions and extend them to different parts of the, of the transaction pattern to different systems and different APIs, either within your own infrastructure or through shared relationships out in the cloud or other trading partners where those strong authentication access control decisions that were made can be extended and delegated.

So we can key what we call single sign-on, which is the ability to vet user in a validated user, and then determine what that user can do across a bigger set of services and, and data rather than just point services and, and, and forcing credential authentication for every single access to every single different service. The, the goal is a more seamless unified experience, especially in the mobile world and a web Porwal you log into, you know, an online banking application.

You want to go through all your various parts of that interface without having to reauthenticate every time those are things under the foot that gateway technology facilitate by extending those base capabilities and credential of access control and, and, and those checks to single signon capabilities. And again, primarily using scheme like, like cookies and Sam and OA are very, very popular means to achieve it in very simplified means when you're using purposeful technology, that you don't have to write any code to achieve any of that.

So we get to the point of identity Federation, but we have to focus clearly on as Alexei noted the data security component of that. It's not enough to have a trusted user and access control checks without being concerned with the exposure of an API and the information threats that API externalization and, and application externalization ultimately lend itself to, from a threat profile. So we look at security across really four primary areas. When we're talking about enterprise applications and, and, and consuming at first, we want to focus on allowing the appropriate kinds of content.

So if we've got restful service for a mobile app, we know it's gonna be framed within some realm of expectation around, okay, maybe it's XL, maybe it's JSUN, or, or that are expected, but those are defined aspects of what the service infrastructure expect. We should be checking and validating that that information is aligned with what the infrastructure expects.

Similarly, looking at information, coming back out of that API from a request response perspective, is that data aligned with what that API was expected to be sending back, or do we have a breach situation where we've got data leakage, a, a table dump or something that's not in line with expectations can be enforced and, and should be enforced from a threat perspective. So you're not just allowing trusted users or validated users to have any accessibility characteristic whatsoever of any kind of data exchange. It should still align with what the actual application expects it should look like.

And then of course, there's the aspect of rates and sizes. There's certainly characteristics of users that should only have certain SLAs there's certain characteristics of what your application service can do. If you expose that application service and have 10,000 consumers in the next week, can it sustain that, is that a situation where you get oversaturated in the service cannot reliably perform well, those are rates that can be enforced at a gateway layer and, and preventing this.

Oversaturation either by size heuristics or rates of access, looking at things like antivirus and data and, and pattern recognition with SQL injection. These are all mechanisms to validate and conformance and, and validity of, of information of the data at the same time, we're validating identity and access control. So we can have a much more unified approach to that without having to, to be worry about how to combine them in different ways that with different architecture components that don't know about each of those capabilities.

Similarly, when Alexei, he said, SSL is not enough, clearly we know basically based on heart lead and other things that any C based library is inherent vulnerabilities, so that the, the notion of, of open SSL has as many problems as we've seen, but even philosophically the notion of SSL, it's just a peer-to-peer encryption mechanism. It does not apply for many aspects of modern day applications because that data itself XML and soap and JSON is, is where all the data and information resides inside the message.

So we gotta look at message security in motion, as well as what we call at arrest, or as that message moves around to different components through its life cycle. We want to consider encryption schemes and data level encryption to make sure the privacy of that information is always maintained throughout its life cycle and, and, and transaction privacy is a big part of the data security model, depending on the kind of application and API exposure that we want to achieve.

Similarly, we look at integrity. This is, did signing of information and, you know, in the so world and the XML world, Lexi noted, there's definitely many standards that have evolved as Oasis and W3C around DSIG and signature verification.

We're starting to see some cases in the restful world as well with, you know, places like Amazon S three C two, and, and, and eucalyptus, where there's, where they have some, some concepts of signing of information using some hashing algorithms, other things that we we often see, but ultimately the goal is to define some mechanism of validation so that you can ensure integrity with information, meaning that when information leaves one point, it can be validated that it at the consuming point that it hasn't been altered or tampered with.

And so enforcing things like the protocols, the methods, schema information, and having signatures concepts are always in which to help ensure a high level of information, insurance and integrity, which is an important part of business agility. You wanna be able to do this business with all these different people, but you want to have the notion that the data has maintained its integrity and hasn't been compromised. And the accountability side of it goes back to some of what Alexei was discussing. You have to have, you know, real time capabilities of, of monitoring.

You have to have historical ability from, from a, from a reporting and auditing perspective. And so the notion of externalizing enterprise applications, isn't the concept of just each individual. It's rather aggregating that conceptually and, and logically at one architecture tier such that you can see and have visible all the kind of API calls, all the data communication, all of the information exchange that's going on, centralized in your architecture.

If you don't go with a philosophy, then you're looking at end end mile logging mechanisms on end mile servers that have to aggregate in various different. It's very difficult to achieve a unified accountable transaction philosophy without the design principle of a gateway approach. The gateway inherently gives you that through that approach of, of API brokering and thus centralization of the information that can be logged and audited, which is a very important part of, of a security model.

And then of course, there's the data mediation capabilities, both at the protocol layer, as well as the message layer in order to have agile business practices. You don't want to have to go back to the enterprise application and try to rewrite adapters for every single kind of different client, every kind of different technology that you may want to integrate it with.

That's not agile it's and in many cases, it, it can't happen either through the fact that these are legacy applications, simply haven't thought the capability, or you just, it's not practical from a business perspective to try to do that. And this goes back to the philosophy of a gateway architecture approach.

Those APIs can be presented as in different formats, even on different protocols to the same exact enterprise service, so that the notion of APIs, as we discussed earlier, being that window into the service also gives you that logical abstraction to now make a couple of different windows, or this one maybe is an XML API to this service, and maybe this other, one's a JS API to this service. Maybe we've got one over here. That's an SSTP API. And another one, that's an HC API.

So the concept is that you can now present the consumption ability to those enterprise applications, because we're considering the abstraction point of a gateway philosophy. We can also accomplish a lot of the mediation and a lot of the interoperability without having to go back to that actual application and change anything. All of this can be done without writing a single line of code. And so by unifying all of these concepts, we achieve what we want to achieve, which is business agility with integrated security capabilities across each of these different areas that I've just discussed.

These all go together and, and fold back into that notion that we talked about earlier around all the capabilities that reside inside of the gateway to offload and centralize those key functions that we've, we've noted as necessary components and, and, and ultimately some of the challenges that businesses face.

But when we look at the ability by which to then leverage technology that integrates all of these capabilities directly and purposely as a technology component, that's been designed and purpose built to achieve area of functionality that alleviates the necessity of, of having to consider all the complexities of these parts of identity, access control, and data security, and rather just focus on the design principles and the rules of ex externalizing applications and let the technology due to heavy lifting and the work for you.

And so that's really the concept and the premise of how we approach this, this area of, of application externalization and achieve the notions of, of centralizing identity, access control, and data security. It really lives at the, the border of information exchange. If you consider legacy security architecture of sort of traditional firewalls labs IDSS and, and event monitoring systems, your API security layer is effectively.

Your API exposure point is something that you also centralize at the information border, and that allows you to unify many of these aspects that we've discussed today, where we bring together the concepts of identity, access control, SSO, full capabilities for SAML and oof schemes directly provided for by the technology without having to write any custom adapters or custom code, but rather present that to the external parties and the external consumers, and simply broker those information exchanges on behalf of the client while still maintaining those very key modern concepts of data security, a protocol break, deep content inspection validation, spread analytics, AB scanning, and certainly performance acceleration so that the purpose-built technology can do these things at very, very high speeds, rather than trying to build these components yourself, which is very difficult and obviously often not performing and certainly not scalable for a long term strategy.

And so that's really the concept that we come at from a design philosophy, as well as a technology perspective, to aligning with various of those things that Alexei noted as challenges. We really face those head on and look at utilizing the concept both from a, from a, from an architecture philosophy of the gateway, as well as clearly, the necessity to have the embedded technology to achieve that is, is, is how we then accomplish the goal of enterprise application readiness. Thank you for your time.

And I will open the floor and turn it back to Alexei for any, any questions or any comments from, from the attendees. You can submit your questions. Anytime you have the questions tool, please keep them coming. And the first question is, so basically the one concept of a gateway introduces a single bottleneck into your infrastructure, right? Or it's potentially, first of all, it it's a single point where enormous amount of processing various kinds occurs. So what about performance penalties, right? Like that.

And the second part course, what happens if the gateway itself breaks or if, what happens when the gateway itself is hacked? So how do you ensure that nothing of that kind happens? Great questions. Both of them I'll take each one, one at a time, let's look at the performance profile. So first of all, the, the performance is a very essential part of this. And there's various aspects that go into the performance profile. One is cryptography.

Anytime you have PKI symmetric cryptography around either SSL capabilities, digital signatures, encryption, decryption, those are very traditionally heavy lifting aspects. The gateways built, you know, from the ground up with these capabilities to achieve cryptographic acceleration and, and performance processing around all of these different capabilities.

So the, the gateway technology is a, a closed system built with policies that have been designed to, to feed into what we call the, the data funnel flow for, for request, for response, transaction processing, designed by intent to achieve much higher transaction fees. You achieve those fees because you're actually reducing the burden on many of your other existing components by centralizing these roles at the gateway, I'll give you great examples. Identity, most traditional approaches to identity are agent based approaches that you have agents sprinkled about on N mile services.

They have to communicate back and forth to an IBM policy server. One service knows nothing of the other. You get huge IO latency implications in a glass ceiling on the ability to achieve a true scalable architecture. A gateway approach is centralizing that decision point, knowing the APIs that are all related to those identity credentials, intelligent cashing to significantly reduced by often an order of magnitude, the IO agency imposed by continual communications back and forth to identity policy service.

So through many aspects, the gateway, and we have lots and lots of deployments globally that can speak to this, that, that, that facilitate a much actually faster transaction path, because you are leveraging technology designed to optimize those processing aspects to the second point, a very key point. How could you possibly adopt a gateway if you are concerned that the gateway could be the point of being compromised?

I can't tell you how great it is to hear that question, because it's the foundation of us as a company and organization over 14 years in the industry, we've achieved these certifications of fits in NDPP and us department of defense through our rigid adherence to the assurance of the architecture capabilities of this gateway are designed such that it can, can't be compromised. And it's gone through some of the most rigid, independent certification and penetration tests. As you can imagine, military grade tests, years and years of, of, of, of, of penetration testing.

We are in the critical path of about 80% of the United States credit card transaction processing about 45% of Western Europe. We view all the United States tax returns. We're in about eight UK agencies with very, very high performance requirements. So these are systems that have been adopted and run today in some of the most mission critical environments that you can imagine they're designed and, and by intent and architected by intent to be able to be deployed as a centralized component without having the exposure compromise.

And this is a difference that you'll see, this is why we call our solution in API security gateway. Others will call their solutions in API gateway. The difference is how secure is your gateway? If your Gateway's not secure, you can't do the things that I have discussed today because it itself then becomes a point compromised and you can't deploy it at the information order. You have to deploy it deeper in the enterprise with lots of layers of protection above it, which, which, you know, removes those concepts of agility that we've discussed today.

So that's a core difference between an API security gateway and an API gateway. Well, I can just say that I cannot really agree more with that because way too many companies start thinking about security too late and not building the security into your, the whole life cycle of your product, I want to say is essentially a big mistake. Cause a gateway has to be the most secure part of your whole infrastructure. Okay. Let me remind you again. Please send your question to the question tool. And here is one, can you please provide some examples of content based access controlled use cases?

Absolutely. I'll I'll provide a couple good ones. Probably a good one to talk about is so every, so the United States, the entire revenue stream of the us government facilitated through electronic tax filing. The form century devices have been at the perimeter of the United States treasury since inception of that program. That is an electronic means by which every citizen of the United States files taxes and tax return information.

That data actually gets transposed into a soap document with attachments that soap document with attachments contains very specific information about each tax filer and has to be correlated across many different characteristics of validation, who the authenticating multifactor authentication to designate the user source of transaction, and then taking that and correlating it to the information inside of the request pattern, which is effectively the tax turn information such that the data itself has to conform not only to the requirements of the service, but also conform to those capabilities that have been associated in those roles that have been associated with the users.

So that's one example. Another good example is the oldest relevant system in the world is in, in the, in the UK, it's now managed by network rail. If any of you've ever traveled to the UK and rode the rail system, that infrastructure is actually protected by form century technology. And all of the integrity rail checks that are done across 30,000 miles track are actually facilitated and brokered through century technology.

We did this about two years ago as a result of the government mandate that required integrity checks on the rail system, but they had an old legacy system that couldn't facilitate that used to do it by paper and pen. And they were not gonna be able to achieve that government mandate of, of having those integrity checks each year.

So we worked with network where else to provide a, a rest mobile application iPhone application called basically that provided role based capabilities to field personnel, to upload integrity information and checks based on their designated levels of, of field personnel that validated various things at the gateway. You've got to now look at the data payload. If you're sending in a report about a, either a good track or a bad track, you have to have, you have to be the right kind of person, first of all, field personnel that can do that.

So you've gotta identify that user in that phone as an eligible mechanism. And then you have to make sure that the data being submitted first of all, is conformant. And second of all, aligns and, and, and matches up to the role of the user that's allowed to. You certainly don't want a rogue user talking about a track or, or, or providing bogus data about an integrity check of a rail system. So those are a couple just simple off the top of my head. Examples.

I got lots of others, but those are all the characteristics of wanting to combine the notion of who you are, where you're coming from and what you're bringing with. It's probably best correlated with airport security. When you go to airport security, you've gotta identify yourself and check your bags, check the ticket, same concept with gateway and APIs. You want to check all those things at the same point of communication rather than at different points in the transaction path. Okay.

Well, thank you very much. And since we are almost at the top of the hour and looks like there will be no further questions. Let me just quickly draw your attention to our related research documents, which you can find on our website.com. Especially we have one multi vendor report in the box. It'll be published pretty soon concerning the topic of API security management. And I show you that will be some pretty interesting findings in that document. And with that, I can only thank you very much, Jason, for even such an interesting presentation, thanks for the audience.

And I hope to see you again in one of our future webinars, or maybe it's our API workshop in Munich. Thank you. And goodbye.

Like this?

Don't like this?

Why don't you like this?

Make your Enterprise Applications Ready for Customers and Mobile Users