Tales from the Front Line: API Access Management in the Real World

Keith Casey:  Anyway, I'm Keith Casey from Okta. API access management is what I live and breathe here. If you were at Oktane with us last year, you heard Todd announce and launch the beta from the big stage. Fast-forward a year, and it's in production. At the same time though, it's scary for some people. It's a new realm. It's a new concept that a lot of people aren't familiar with.

When we were putting this session together, I talked to some of my good friends over here in the front row here about ... Here are some customers, Pitney Bowes and Experian, who last year were some of our first customers in the door with the beta. They saw ... there were some warts at that point, let's be honest. But they were able to help us shape this product and turn it into something really powerful and great. As a result, they've been able to do some great things with their organizations.

We wanted to say, "Look, one year in, how are things different? How are they doing things better, faster, cheaper, easier, whatever, than they were before?" With that, first I'm gonna turn the stage over to Kenn Bryant to talk about this, and then we'll hear from Praveen from Experian. Thank you guys.

Kenn Bryant:  Thank you so much, Keith. Thank you. Good afternoon, all. I'm gonna introduce you to Pitney Bowes. Pitney Bowes is a company that is over 97 years old. We started with the postage meter back in 1920. You think of a postage meter. The postage meter was utilized to allow companies to communicate with their customers, to ship goods to their customers. We, at the base of it, have been enabling commerce since the 1920s.

Fast-forward to 2017. At this point, we are enabling commerce across the world in over 100 countries. We are enabling commerce in 90% of the Fortune 500. We're enabling commerce in over one million S&D companies in 100 countries around the world in various industries from financial services, 30 of the top banks in the United States, telecommunications, insurance. All of these industries are utilizing our capabilities to enable commerce.

Like many companies or many of you today, we've started off in the physical world, delivering software and hardware to our customers. But as we took a very close look at the industry and trends, and we saw this evolution over a decade ago, we saw the way customers are consuming our goods and services were moving from software and hardware to consuming information and data, until finally customers really just want to consume business outcomes. They want to consume capabilities that are gonna solve their problems, not like 10 years ago where you had 10% of a problem, but you had to buy 100% of a solution. Now consumers want to consume products, and they only want to solve that 10%. So you needed a way to deliver capabilities that will allow for customers to consume your capabilities and only utilize that 10%. They don't have to consume 100% of a product.

In Pitney Bowes, like many of us, we're going through digital evolution. We have evolved into the Pitney Bowes Commerce Cloud. The Pitney Bowes Commerce Cloud is based off four foundational technologies. The first one is our business systems technologies. These are technologies that have to be shared no matter what the application, no matter what the solution. You have to create a customer within your organization. You have to create a user. They have to be authenticated. They need a method and a way to pay for their services. All of those foundational services and capabilities, that's needed no matter what your application is.

Second, Tom talked about this a little bit this morning in the keynote. We talked about how consumers want to interact with your applications. They want to interact with it with the way that it's solving their problem. It makes sense. It all looks and feels the same. Our third foundational technology is data. We all have mounds and mounds and data that we're collecting, we're analyzing, and we're turning that data into business outcomes.

Fourth was Cloud enablement. How can we enable rapid development within our organization? We enabled foundational technologies for building your software paths, mobile technologies, and finally APIs and API technologies that's gonna allow our developers to consume those capabilities within their applications.

We offer capabilities in five key areas. One, identify. We help our customers identify their customers and their prospects. Locate. We help our customers locate their customers, employees, assets anywhere in the world through our geolocation services. Third, communicate. We help our customers communicate with their customers and prospects in a variety of ways from engaging with video for your billing and understanding your billing, to communicating via email, communicating via physical mail. Fourth, shipping. We help customers ship anything to anyone anywhere in the world. Finally, pay. We offer services and capabilities that allow customers to pay for shipping, pay for the consumption of our capabilities.

How do we offer these capabilities to our customers? We offer them in five key ways. One, web applications. Many of us are developing web applications. You can consume our capabilities through a variety of web applications. Two, native mobile applications for those customers who are on the go, need to be able to be anywhere anytime and be able to consume capabilities. Three, commercial, our APIs, that allows developers, individual, as well as corporate developers, allow them to integrate our capabilities into their own applications and solutions.

Four, on-premise. We still have on-premise apps, like many of you do. Well, what we've done with those on-premise applications is we've also connected them to the Commerce Cloud to add additional data, capability, and functionality. Finally, our devices. I talked about, we started as a postage meter company. We still have postage meters. However, we have now enhanced our postage meters through the Pitney Bowes Commerce Cloud to add additional capabilities, applications, features, and functionality.

You may ask, "Well, how do you do that? How are you offering all of these capabilities through all of these various channels?" The key and the foundation to all of that is our API economy. Our API economy, you can see it's clearly our gateway, and that's how we're offering all of those capabilities. I'm not gonna hold this up. I'm gonna let you guys get to the meat. But I brought one of my colleagues with me to really get into the nuts and bolts of what we're doing with APIs. With that, I will introduce Srikanth Varadarajan, senior fellow and integration architect at Pitney Bowes.

Srikanth V.:  Thanks, Kenn. All right. If we look at this diagram, there are three key areas here. Up top we have the applications and integration patterns. To talk about that, the applications are essentially SAS applications. It could be devices in some cases, mobile apps, etc. As part of our Commerce Cloud, we provide reusable services like shared UI, things to sign in, sign up, payments, etc. That's one piece. We also offer a developer portal, which is an external-facing developer portal for our customers to log in, sign up, and start using our APIs.

Finally, the third pattern we have here is integration through third-party partner marketplaces. As an example, we have IBM Bluemix marketplace, Amazon, and also Excel in this case. As an example, we have Excel plug-ins as part of the Microsoft store offering, where customers using Excel can download these plug-ins, which are essentially talking to our API gateways to provide services like address validation. You can have an Excel chart with postal addresses, and using this plug-in, you can cleanse these addresses and use them for further processing. That's the top layer, which is apps and integration patterns.

Right in the middle is our API tier. It's the centerpiece that's holding all this together. We use Apigee as our API management and API gateway platform. If you look at it, there are two key pieces to what we have to offer as APIs. The first piece is the commercial APIs. What this is, is essentially making products available as APIs to our customers, so we can monetize, bill usage-based subscriptions and so on.

The way we do this is, we have product teams who turn out these APIs, and we have trained these product teams to onboard APIs onto the gateway and the API management platform. Something that used to take weeks to months, now these teams can do within days to weeks, probably even hours. As an example, we have teams who constantly onboard new APIs every week. We have right now anywhere close to about 200 commercial APIs that are available as part of our developer portal to our customers, spanning all the five or six different areas that Kenn just talked about.

On the other side, we have back office APIs. These are essentially our business systems. What we have here is, for all the applications, SAS applications, devices, etc., there's things like billing subscription, identity using Okta. We have shared services like email services, etc. Using the API gateway, we offer these back office services as APIs for products and SAS applications to consume. These are more focused internally, not so much customer-facing, but internal SAS apps can leverage these APIs to build their applications.

Again, these go through the API gateway. We have about 350 of these internal APIs. Prior to this model, essentially every SAS app wanting to integrate with these back office systems, it was a one-to-one effort. Would take weeks and months. Now we can have product teams integrate with our back office systems in under a week in some cases.

That's the overall view of what our ecosystem looks like. This is something we put together in about, I would say, two years or so. Today we support about 35 SAS applications, and we clock about 40 or so million transactions every month. Obviously, these numbers are growing, the point in time statistic.

When we started this about two-and-a-half years ago, we had a few key objectives as part of our API strategy. I have listed a few. One of the things that we wanted to do was unlock some of our product capabilities to a larger audience. What I mean by that is, a lot of the cool capabilities that Kenn was talking about traditionally were available to our enterprise customers. Now how do we take that and bring it down-market to our small and medium business customers? APIs is a good way to do that. That's the unlocking of all the product capabilities to a larger customer base.

Secondly, we also wanted to improve the overall developer integration experience. One of the goals for us was, a customer should be able to go to a website like a developer portal, play with the APIs, look at it, read the documentation, sign up, and actually start using with keys, production keys or Sandbox, whatever, in minutes. That's one of the key goals that we had as we started putting together our objectives.

Additionally, enable SAS and usage-based subscription model for these APIs and consuming these APIs. There are a couple of different models that we use today. Then finally, also make these APIs available internally across different product teams so they can reuse and put together different offerings based on these product capabilities.

Along the way, we had a few challenges. One of the things that we noticed was, a lot of these commercial APIs, they came from different teams, and different teams had different business models, different ways of presenting the information to our customers and so on. That really does not ... When a customer logs into our developer portal, it's really good to have a unified experience. In order to address that, we brought together the project managers, explained to them visually how we could harmonize the overall look and feel, try and see where we can align the different models for business models, so we can present a unified view to our customers.

The next one was driving API standards across the organization. This can be a challenge, especially when the teams operate pretty independently and they're geographically diverse. One of the ways we tried to do this was not to be overly prescriptive. We have a team that helps different product teams who want to onboard their APIs to our API platform. We work with them. We look at their APIs, provide guidance, show them some example. There's some standards documents we have put together. How to do error capture, error reporting, and so on and so forth. These are guidelines we provide them and work with them to fine-tune their APIs and provide a more unified look and feel. That's with regards to the standards.

The next piece is, how do products componentize their APIs such that it can be used across within the organization? It so happens, a lot of the products, as they are building their SAS products, they do build behind-the-scenes APIs. However, they don't think of it as something that can be used across the organization. They are focused on their app and their APIs. That's where we step in and work with them and say, "There are ways we can tweak this, so this not only is useful to your product, but it can be used widely across within the organization to put together more products and features."

Finally, we have API security. One of the challenges we had here was, the way we make APIs available internally is either through the API management platform, or some teams do their own APIs. It's not part of the API platform. This results in a challenge, wherein when an app needs to communicate with these two different types of APIs, there's different authentication mechanisms, different tokens, and so on. One of the things that we talked about was, how do we bring on board these other external APIs that are not part of the API management system and make them a part of the API gateway, such that we have a unified security mechanism for that?

This slide talks about how we've used Okta and Apigee, our API platform, how we've brought those two platforms together about a year ago to provide some of these API security capabilities. If you look at this, on the left hand side, there's this thing with big IP and the diverse proxy piece. That's a piece my colleague will cover tomorrow as part of a separate session. It's at 11:45, pinion one and two. Those of who are interested in that piece can definitely go to that session. I will focus on the parts that are highlighted here.

Essentially, for any app within our ecosystem, there are a couple of integration patterns that we offer. One is the SAML federation SSO. This is where the end user logs into the app, and then we SAML federate SSO to the application. Now, at this point, any API access is done through traditional client credentials, secret and key, so there's no user context that goes as part of that. That was the old model. Now, fast-forward over the last year. We've been migrating to the more OIDC-based mechanism, where we have the end user log into an application, and we use the access token that we get as part of authenticating the user against Okta, and it is that same token that gets carried over to Apigee to provide the context and security for authenticating into the APIs.

There are a couple of benefits to this. One is, it's a unified token, just one token that can traverse the entire chain. Then more importantly, we also have the user context that's available as part of this token without any impersonation or without the app telling us who the user is. As a result of that, we can, with a greater level of confidence, authorize what the user can and cannot do based on that token. That really nicely blends with some of the authorization capabilities.

The other good use case we have with this has to do with how mobile apps, native mobile apps, and desktop apps ... yes, we do have some of those. How desktop apps can exist within this ecosystem. Because there's no browser-based ... these are desktop and mobile, so we cannot embed stuff within the apps. This model also works nicely with that. That's in how we've implemented API management security, and that has helped us as part of our larger Commerce Cloud strategy. I think I'm almost out of time. Next I'll introduce Praveen from Experian, who's gonna continue this with his piece.

Praveen Kumar:  Thank you. Hey, my name is Praveen, and I'm from Experian. Little bit about Experian. We are a bureau. Many of you have heard of Experian. Your credit reports are pulled from Experian. We are actually a data company. We run decisions on data. We provide analytics solutions to our customers on the data that we receive. We are helping users, businesses, and organizations across the globe make decisions using the data that we have curated and the services that we provide.

We use our data in many channels. Our products are really web apps, there are mobile apps, and definitely there are APIs. Since we have been in business for a long time, we have been doing APIs, but we were doing more SOAP-based integrations in the past. That is how a lot of our data has been exchanged with our clients and partners.

Like I said, we have, over a period of time, grown by buying smaller bureaus or organizations. That has led to an ecosystem which is pretty complex, and there are challenges with the existing ecosystem within our organization. We traditionally acquire businesses. We do a good job of doing the legal stuff, the marketing stuff, but the IT piece is just put on the side. If somebody was using one set of source control, they continue to do that. There is all sorts of diversities. The way they were doing their SDLC means that they way they were doing stuff.

Basically, it is a huge amount of complexity and diversity in the ecosystem that we live in. We have siloed processes. We have barriers to how we innovate and we expose our data across our products. We have very low-level API exposure due to this situation within the organization. At the end, our clients who integrate with us go through that pain, and the situation is such that sometimes we are sending them PDFs which are 500 pages long to integrate with some of our products. It makes the whole system very unusable, I would say, and there's a huge amount of friction when it comes to client onboarding and the way we would integrating and doing business.

When last year, I think, we really looked at our APIs and how we were doing business, we realized that there is definitely a need of a solid API management layer and a secure layer. Again, like I said, we are mainly exchanging data, so we do have gateways. We have DataPower. We have Axway deployed on-prem. Axway more for batch data ingestion, and DataPower was more for APIs in the past. But due to the history that we were integrating with, we were not able to go to the next generation securities model for our API, so we continued with basic auth. Most of our traditional products integrate on basic auth through DataPower for APIs and through Axway, which is our batch gateway. We do traditional SFDP and SSHT, etc.

We realized that there is a need to transform, and we need to change the model to help the situation, improve the customer experience, etc. Then we also felt that, I think, there was a need to put this layer to improve the developer experience, because it was taking, I think, close to six months sometimes to onboard an API into production. We wanted to lower all of that and innovate, innovate where our product teams could expose data and generate more revenues with these channels. We realized that we will have to have a solid API management tool, and we will have to improve on our API security.

We pinned down on Apigee as our API gateway, and we did put some standards together. I think we are marching on the lines of having the Auth 2.0 for all our partner APIs and external-facing APIs, and having basic auth for all our internal APIs. At this moment that's, at the high level, how we are moving forward with our API strategy. Most of our portals, the dev portals or some of the other product portals, are leveraging SAML to authenticate the user.

Real quick, a glimpse of our journey. We founded Center of Excellence team last year in February of 2016. That's when I started leading that team. We evaluated several API management tools: IBM, Mashery, MuleSoft, Apigee. Then we realized that Apigee did the most justice to our situation and ranked the highest, and we went ahead and signed the contract sometime in August, post which, we started deploying Apigee and knowing our company's setup.

We are present in US, UK, and Brazil, which are three of our largest market. Due to data residency challenges, we have to have three different instances of Apigee running in these three regions. Each of these three Apigee instances demand we have three different developer portal instances. Also on Okta's site, we have different instances for US and for EMEA region due to all the data residency laws and regulation.

We rented an NVP for US in the month of November last year. We onboarded one product into Apigee as an API. In the month of February, we had our first live traffic through Apigee. Took us a while to set up the whole auths and the integreation with Okta. I talk about how we integrated Apigee and Okta at that point in time, because that was, I think, a time when the API access manager was just announced, and it wasn't really ready for prime time. So we did some workarounds, and we used Okta, but then not the API access manager feature of it.

Continuing further, we recently released our UK instances. That was in the month of May. Now we are all set up in Brazil as well. Today we have the API gateway set up, deployed, running for production prime time in these three regions. We have the dev portals up and running, integrated with Okta. We have the meat of the whole solution in place. We have the flows happening. We do have the integration working.

Some numbers here. A lot of our traffic increased due to the new age APIs. They're more REST-ful. They're JSON. They're no more XMLs. The onboarding time for some of our products have reduced from, I think, couple of months to few minutes today. The devleopers are able to log onto our dev portal, send stuff, get a token, and make an API call, which sometime back was at least a three-month long process. You send an email. Then our customer service would review that. Then they should create a test account in our mainframes, which actually goes out, and then they would try to use that to make a call. You heard the word "mainframe," so you know how long it would take, right? All of that has gone away now, and we are seeing traffic increasing.

At Experian, we do not have a small number of products. We are talking about a few hundred products in each region. We have a lot of API products. In my knowledge, I think that number is around seven, eight hundred API products. It gets complicated to host all of them into Apigee and showing them on the dev portal. That is another challenge that we have to solve for. But again, I think we have been doing pretty well on our API management journey. The tool is there, and Okta played a key role in that.

This is how we are set up today. I'm sorry. The synchronization of the numbers is a little weird. As of today, what we have is, Apigee is acting as our auth server, and Okta acts as a true identity provider. We onboard the clients. The users' or the machines' credentials are stored in Okta. We recall all the necessary details. We have pretty strict security guidelines. We have IP restrictions, time of the day checks, and things like that, that we have to execute before we allow someone to make a call.

In today's architecture, the client hits Apigee using the Apigee-minted client ID and client secret. We then make API calls into Okta to pull all the user's details. Then Apigee is issuing the JWT tokens, which is then used by the client to access the resource. Apigee is truly the auth server in our case as of our today, and we have retained custom code on top of the auth that is provided out of the box by Apigee, because some of our back end APIs needed more than the JWT. They wanted additional information and things like that. So we had to override the out of the box functionality that came with Apigee. Today, this is the architecture. It's a simple auth server, and Apigee takes the ownership.

Now, the challenges with this is, I have 700 products, and I'm talking about just the US region. Each product team comes to me with a requested, "I want that field in the JWT token. Oh, I don't want that field. Oh, that field is highly secure. Can you encrypt that?" It becomes very difficult to manage 700 products with a single auth server in the middle catering to all their needs. That's one challenge. Secondly, I think truly, Apigee is an API management tool. So we want to leverage those functionality of API and Apigee as a tool, rather than using that for all our security. We want to use the right tool for the right thing.

What do we want in future? I think we do want to start using the API access manager feature of Okta. We would like our clients to go hit Okta, get a token, and the client IDs will be synchronized between Okta and Apigee. Okta team is helping us come up with a plug-in, which is actually a code which will run within Apigee. The developer apps will be created in Okta, and the client ID and client secret would get synced with Apigee. The clients will make a call to Okta, will get a token. There is a provision in Apigee to register a third-party token. We will do that. Then when the client makes a call to access the resource, we would validate that token on Apigee and allow the call to go through.

At a high level, I think we are at a stage where we started getting the plug-in code from Okta team, only some time back. Because they were, I think, working on it, and there are certain nitty-gritties and challenges from the adminsitration side of Apigee when you use those plug-ins. When you log in as an admin into Apigee, managing the developer app becomes a challenge. We are working on those use cases now with the Okta team.

Again, like I said, we also have DataPower and Axway, so we will continue to see how we can leverage plug-ins on those two gateways as well, not just Apigee. In our road map, we want to do Apigee first, continue to do DataPower, followed by Axway, in that order, and try to leverage as much as we can from Okta API access management, rather than build these features on Apigee. That's pretty much what we have been doing and how we are set up at Experian. Open to questions.

Keith Casey:  Hey, from here we want to open it up for questions, so let me come at you. Don't forget, this is being recorded.

Audience: Yep. Hi, Praveen. I have one question. Have you guys transformed from Axway to Apigee, or does this Apigee was [inaudible 00:34:38]?

Praveen Kumar:  No, we have not done that. Our architecture is, Apigee's on the Cloud, Data Power on-prem, and Axway sits on-prem too, and we divide by use case. All our batch transfers have to happen through Axway, because we are dealing with some huge file sizes. I'm talking over 200 gigs here. These are massive files. Apigee will not be able to stream that through the Cloud.

Audience:  Okay. Any challenges on Apigee side due to the standardization over the virtual things and making the standard formats?

Praveen Kumar:  On Apigee, again, as a tool, it comes out of the box with those transformations. The challenge ... and I think Srikanth also, he does jump on it. The biggest challenge in this organization is the education piece and making sure that the product development teams are adhering to the standards that somebody wrote. I run the COE, so my job of my team is to come up with those standards. We will look what kind of standards are out there, what makes sense for our business. Shall we use opaque tokens? Shall we use JWT tokens? And all of that.

But then, trickling it down from the COE to the product teams is, I think, our biggest challenge, because the tools, I think, are pretty good. They do have out of the box features to transform. Doing XML to JSON, all of that is fairly straightforward, but yeah, you do need to extend sometimes based on your used case.

Keith Casey:  All right. Any other questions? None. You guys nailed it, apparently. Nice job. I did want to give one quick announcement. Tomorrow at 1:30, Tom Smith, who's hiding in the back corner over there, is giving a presentation on Intro to API Access Management using AWS and their API gateway. If you're interested in that side of things, as opposed to Apigee, great. We've got a session for that too. I believe he digs into Lambda and integrations and all kinds of fun stuff, right?

Tom Smith:  That's right.

Keith Casey:  All right, fantastic. Thank you, everybody, for coming. Thank you again to our speakers. Appreciate it. Thank you.