Creating a Digital Identity without Borders

Keith Casey:  Internally, I'm actually campaigning for the title "API Problem Solver." So when you do follow up notes to Ryan or Freddy after this, if you could mention that in the email, I'd greatly appreciate that. 

Hi everyone, I'm Keith Casey, I'm here to talk about building a digital experience by removing your borders. The borders that we have right now are kind of poorly defined. I've spent years at Library of Congress, I've been working with APIs for about 17 years. Capital One, Twilio. And the thing that they all have in common is the new phrase of "the API economy." And the thing that ... I don't need a show of hands here, but the thing that scares the crap out of people is that we're letting people into features and functionality and data that used to be ours. We didn't open this up before. We didn't share this with people. And now the concept of the API economy, whether we're talking about partners like Box or Okta, we're opening up features and data that we never even considered before. This used to be ours. This used to be ours to protect. And frankly, it gets a little scary. We're having to share things that we never really expected to share.

So in order to do this well, we sort of have to rethink how we're approaching things. So we introduced the concept of the API. And API, for people who aren't familiar with it so far, in the simplest terms, it's how one piece of software talks to another piece of software. That's it. That's all it is.

Yes, there's plenty of nuance, there's plenty of more complexity we can get into with that, but realistically that doesn't matter. It's how one piece of software talks to another piece of software. Or how Paul Graham of Y Combinator puts it, it's self service biz dev. It's enabling people maybe outside your organization, maybe that team down the hall, to be able to do things that you didn't quite expect. To be able to solve their problems in the way they want to in the timeline that they need to. 

It's about self enablement. And that's a really powerful concept. And it's absolutely necessarily because of the mobile devices we have. They don't have the storage, they don't have the processing power, they don't have the connectivity that we can count on to be a reliable system to work all the times we need it to. APIs allow us to move that functionality off the device back into the cloud, and be able to accomplish big and important things with it.

Sometimes silly things, sometimes useful things. Like that experience across devices. The ability to be able to start watching that movie on your iPhone. When you get home, switch over to your iPad. And when you get back to the couch, to be able to turn on the Xbox and start the movie exactly where you left off is really powerful. That's entirely powered by APIs. From beginning to end, that's APIs.

But the thing is, that the people that are using our APIs are not necessarily the ones we always expected. Yes, there might be the team down the hall, there might be the team in the other building or the partners. But there's also customers, there's also the employees. We have to sort of think how are we opening this up in the right way so that the right people have access to the right things at the right times. And this all revolves around building effective digital experiences. Making sure that we have the right access control on top of that. 

And this doesn't just go with our devices and our applications. This also goes with the systems that we're using, the cloud applications. We've seen the application library a couple different times. But this is all powered by APIs behind the scenes. So whether we realize it or not, we're living and breathing this, just because we have that mobile device. Just because we're using any of these applications. So we have to rethink how this entire approach is handled. 

Because frankly, the way this is handled right now, it comes with a lot of complexity. There's a lot of layers to the system. So on our end, on the Okta side of things, we have an API to power our entire platform. There's the API that we hand to all of you so that you can onboard users, you can trigger MFA, you can manage groups, you can do all of this. And realistically everything you can do through the web interface you can do via an API.

So we want to make sure that the applications and the functionality and the features that we offer to you in one user interface can be embedded directly into your applications. So that really it's up to you where you use them and how you use them. And realistically we're tying this into a ton of applications right now. 

So all the applications on the left, all the Okta application network applications are tying into this in one way or another. So that's how we sort of approach APIs. But if we stop and think about it, we have to think what happened to our borders? Well frankly, they're gone. Sammy talked about data centers surrounded by sharks with laser beams. We still have sharks and laser beams, but those are pets now, they're not our guards. We have to rethink how we're doing this.

And I'm going to say something that might be kind of heretical here. I believe that the way we're designing and building APIs right now is broken. Right now we've got the group, ignore the diagrams for a second. We've got the group on the right, the developers. The developer's job, the only job they have is to build something useful and then go home. Now ideally they want their thing used. By the way, if you ever want to demoralize the development team, have them build something and then shelve it. Let them spend days and weeks and months building something and shelve it. It doesn't matter why you shelved it, but that's the fastest way to demoralize them.

So these people want to build things and they want to go home. Then we have the team on the left, the integration architects. They want to be able to pull these things that developers have built, pull them together and accomplish things. They want to build products, they want to go ahead and ship things. 

And then we have this group in the middle, security architects. Security architects are our bad guys, right? They're the ones that say no. Has anyone ever gotten good news from a security architect? Exactly. I'm sorry for my security architects in the audience. I feel for you. Because you're put in this awful position to be the bad guy, and you shouldn't have to be. The reason this is happening, because how we're building APIs is wrong. We're asking developers who want to build things and go home, to build things, oh yeah, and force security policies and procedures and password resets and all the stuff, and then go home. And frankly that's not what they're good at. That's not what they know. They don't know the rules and compliance issues. They don't know the requirements that your organization has. It's not their job.

So when we approach it the way we have been, we end up with all this angst. We end up with situations where development teams launch products and they forget to cc the security team on it. Has anyone done that? No, no show of hands there. No show of hands there, because I suspect there's a lot of hands on that one.

We run into these problems where the developers are launching things not telling security. And security finds out days, weeks, months, in some cases years later. And now we have a problem. Now we have those vulnerabilities that no one ever really expected. We have those back doors into our system that we didn't expect. 

So we have all these problems. And so our approach at Okta is to separate this. Separate concerns. Software development 101. Separate concerns where the people who have to worry about development can worry about development. And the people who should worry about security and compliance can worry about security and compliance.

So that was kind of the approach behind API Access Management. We wanted to be able to take the system of record, our universal directory, and open that up, through OAuth so that people can authenticate against it. Get the access management aspects, all the MFA aspects, all those things that come together with Okta, and apply it to APIs. So now the developers can build things, and security compliance can secure and make sure everything is compliant. And there's no way around it. There's no way to grant additional access because it's all centrally managed, it's centrally controlled.

I was at a conference a few weeks ago and I asked ... There was a team I was talking about how they're launching new APIs, I said, "Oh great, how are you managing users right now?" And they're like, "Oh, we just create the users in the system, it's a database, it's not a big deal." And I said, "Well when somebody leaves your company, what do you do?" They said, "Oh, well HR emails us." Really? Every time? He's like, "Oh, well we do an audit every quarter." Oh, so people might just have unauthorized access for 89 days. That's not a big problem, is it?

By separating these things and having everything plugged directly into Okta, that 89 days becomes 8.9 seconds. I mean that's the kind of timeline that we're talking about here. The vulnerability window shrinks to nothing. That's powerful.

And the way we have approached this is through our API Access Management product. And we separated, just like we separated concerns, we separated the problem in two halves. And by separating this problem in two halves, each half becomes a lot easier. 

So there's the external half. This is the part the developers need to worry about. This is OAuth. I don't mean OAuth like or OAuth friendly, I mean OAuth. So if anyone's already using OAuth, all the training all the libraries, all the tools that you've already used and you've already invested in to be able to use OAuth, you can use here. We're an OpenID Certified Provider, we've met all the check boxes there. So that's taken care of.

On the internal half, we went ahead and we've plugged into our universal directory. So all the systems, all the HRs and master, all that functionality that you already have applies directly. Because it's all backed by our API behind the scenes.

So by separating into two different problems, and separating into two different concerns, we're able to manage each a lot more easily. And we're able to let the developers to build things, plug into the compliance piece, and then go home. Our integration architects can go ahead and authenticate the way they're expecting, build stuff, build useful things, and go home. And the security people are no longer the bad guys.

A couple of things I want to throw out, if you're not familiar with OAuth, don't worry, it's actually relatively easy. Sandeep from Teach for America touched on this earlier. We think of it as a hotel key card. When you check into your hotel you provide identity through a driver's license and you provide billing information through a credit card. And by providing those two, then they issue you a token, also known as a hotel key card, that expires after a certain amount of time. Usually your checkout date. Sooner than that we have a problem. But it expires on your checkout date, and that grants you access to certain things. You can get into your room, you might be able to get into the exercise room, the executive lounge, whatever. And then if you need a new key card because you've extended your stay, you go back and you refresh that to get a new one. That's how OAuth works. 

The main benefit is you never have to present your credentials or your billing information again. So that information's not replicated or stored anywhere else. That's powerful.

And on the inside, we have our universal directory. Sammy talked about this already. We've got the group membership, the IP address, client based configuration, so we can say, when somebody connects with this type of client, when somebody connects with a mobile client, here are the permissions that they're allowed to request. When they connect with a web client, they can request different permissions. Maybe a more advanced set of options. So the next time you have a mobile app on your phone for your bank and it allows you to check your balance but not do wire transfers, that's really powerful because now when you sit down in a desktop environment you can do those sorts of things. The next time you lose your phone, that would be really handy.

And this ties into all kinds of clients and applications, whether we're talking mobile, we really don't make a distinction between those. So with that let me actually jump into the demo and show you how this works.

Alright. So I'm going to show you a couple quick things. 

This is the management console that you've seen before.

So just like I said, we've split this into two halves, this is what we do here. So on the external half we have an OAuth provider. So we set up our OpenID Connect connection here, our application. 

We say where it's redirecting to after authentication. And so now we can support single sign on, we can do all those sorts of things to medially enable applications out of the box. But let me make sure that people are actually assigned to it.

So that's the external half. That's the OAuth piece that the developers actually build against. And then on the internal half, we have authorization servers. Our authorization servers are where the rules get applied. Based on groups, based on the client they connect with, based on those sorts of things. 

So we can save this into the auth server. 

We can say what API it's actually protecting. 

It's expecting a resource URI there. 

And then we can go ahead and we can configure things about that. We can set additional scopes, which are simply permissions that the API user can request. So we can say this is API read. 

We can add additional claims. Additional claims are just additional information that comes back about the user. It could be anything from a phone number to a member ID, anything along those lines. And then we set a series of access policies. And the policies are relatively simple at the first blush, but we can get pretty advanced with it.

Each policy has a set of rules. So we can say rule number one. And we can say depending on how the user connects, what type of client they're using, what we can do from here. So we can say, well let's worry about a client credential flow like a microservices architecture, any users assigned the app, any scope that they ask. Let's go ahead and grant them access.

So now we've gone ahead and we've set up both halves of the problem. So now we've got users can go ahead and request a token, request access to things, and we've got rules set up to actually be able to grant it.

Now this only gets really powerful when we actually apply it to an API. So here I have an API set up through AWS, their API gateway, which has a plugable extension where we can go directly into it. So if you're already using an API gateway, Mulesoft, Apigee, any of those, we can plug into it directly right out of the box. So there's not a lot of additional customization required.

In this case we're taking all the incoming requests, we're sending it to my API behind the scenes, and now we're going to enable authorization. So if all goes well, when I make a request to this API, it's going to go ahead and, if I have a valid token, it's going to validate the token with us, come back, and actually give the results of the API request.

So with that, let me go ahead and get a new token. 

And any of my developers in the audience, this is just Postman. So we can add a bearer token here. And if this all works, there we go. We actually made a request of the API. So this went out to AWS, validated the token there, and came back and made the request to the API. This is all it takes. It's a really powerful thing.

So now you know how to plug into Okta to be able to protect your APIs and protect any of the rebels in your organization from being able to make sure your APIs are working.

So with that, I'd like to go ahead and ask Kenn Bryant to the stage. Kenn is one of our customers with Pitney Bowes and is doing amazing work with APIs, and I'd love to hear what they have to share with us. Thank you.

Kenn Bryant:  Well good afternoon. Unfortunately I stand between you guys and break. So I'll move as quickly as I can.

Like Keith said, my name is Kenn Bryant. I'm a director of architecture and SaaS services at Pitney Bowes, and I'm responsible for the infrastructure that supports all of our APIs, our SaaS products, and all of our developers building against those APIs. But I'll talk a little bit about our journey, because I think that's important because many companies are going through digital transformation. But the reality is I can't think of a better term, to me that's still what it is.

Pitney Bowes is a global company that's been around for 97 years enabling commerce. Most of you know Pitney Bowes as a company who products postal meters if you've seen us before. So in the 1920s we produced our first postal meter, and we were enabling commerce back in the 1920s. As of today, we are 90% of the Fortune 500, we have 1.5 million SMB customers. And in various industries as you can clearly see. Telecom, financial, all of the major industries. We're a global company doing business in over 100 countries around the world.

So when we looked at our capabilities, we wanted to identify how do we take all of this knowledge, information, and share it with a broader audience. Get it out of delivering software and really get into a way of delivering value and capabilities. And the way to do that is via APIs. So we embarked on building the Pitney Bowes Commerce Cloud.

The Pitney Bowes Commerce Cloud has four foundational technologies to drive the overall experience. Design, all the technologies under design across the organization to help developers build a constant experience for all customers no matter what the application, the API or whatever we're delivering. 

Cloud enablement, as we talked about our integration pattern was APIs, so we looked for tools that would allow us to help do that. So APIs were foundational. How were we going to build software, so we were looking for who was going to be our cloud vendors. 

The third one was data. As we talked about, we had kept everything amongst ourselves and in our walls, but data is power. That's what our customers are looking for, that's what we're trying to give them. So we created an entire big data platform which we fronted with APIs for our customers. 

And finally business systems, which is probably one of the most complex systems in the overall ecosystems. What business systems is, is how do you create new users, new customers, new enterprises, within your organization, knowing that you have a series of systems that you've had for a long time, if you have a 97 year old company.

So we chose to partner with some of the best vendors in the industry to really build out these four foundational pillars. And as you can see, one company we partnered with was Okta. We did extensive research in the industry and found that our external use case, which is maybe different from many of you in here, our use case was completely external. And partnering with Okta we began to drive that external use case. 

we looked at identity and three distinct phases. One, was for users. We talked about that, how do we authenticate a user, how do we ensure that that user belongs in our ecosystem. Two, were services. That's really what we're talk about when we're talking about APIs, where one computer is talking to another, or one system is talking to another. That communication, how do we secure our services now that we're exposing them externally, and we're exposing them to our developers. 

And finally, things. That will be our next wave. As I talked about Pitney Bowes has a lot of physical equipment that we are now connecting to the cloud to provide our customers with more value through data. More information. And we have to secure all of those from a single identity store.

So our journey was a little bit shorter than some of the others we talked about. We actually enabled Okta in our ecosystem in about eight months. One of our key tenets for enabling Okta, because it was external, is we could not break our customer experience. They had to always be able to log in, we couldn't have any down time. So we actually ended up running multiple IDPs concurrently for six to eight months, to allow all of our applications to migrate from our former identity provider to our new identity provider. We migrated over 35 applications in that period of time. And the bigger things is we actually migrated about 2.8 million users in that eight month period without interrupting their experiences at all.

You can see by the couple of graphics we have there, how global our footprint is. And also how you continually see that our usage and users in Okta's continually growing. 

So just talk a little bit about how we enable our users. Like we said, we have multiple ... You saw vendors that we work with. We talked about the SAML protocol, everyone's used to that and it's great for web applications. But when you start looking at, like Keith said, mobile devices, and other type of devices, browsers based XML protocol is a little bit too large for that. So we employed the OIDC protocol, the OAuth protocol within our ecosystem. All new applications, all new services, all new integrations with devices utilize that protocol that Keith was talking about with the API Access Management platform.

What that gives us is in the past, when you had to talk from a service to an API, it was really a trust between the service and the backend service. What we've done in our ecosystem now is add user context into those specific calls. So now, when a user logs in, that user context goes to the application. When the application makes that next API call, the user's context within that call, and the user is validated with Okta in order to ensure that they should have access to that resource.

We actually took it the next step further. Keith had talked about the vendors the had been working with Apigee, Mulesoft and some others. We utilize Apigee at Pitney Bowes. We have an excess of 500 APIs that we use to expose our capabilities today. 150 of those APIs are exposed externally to our customers. We have shipping APIs, locate APIs, identify APIs. And a funny thing about it is some of those APIs you guys probably use every day and you don't know about it. They're integrated into the back end of various enterprise systems. If you have certain desktop applications and you're validating an address, a lot of those actually are calling some of our address validation APIs on the backend. 

So the partnership with Okta and Apigee on the integration that we use allows a trust between Okta and Apigee using that OAuth protocol where Apigee can validate the user's credentials against Okta before they give them access to our backend APIs. And like Keith said, that's a huge, huge thing. Because now the trust doesn't live between the application and the backend system, with the user context sitting off the side. All of these things are clearly connected, and you have one strong security resource that validates those users and their ability to call your backend systems. 

Thank you. Any questions? Keith, please, come up and join me.

Keith Casey:  I believe we have time for a couple questions, so anybody. None, I think we did a perfect job. Let's get out of here.

Kenn Bryant:  We're standing between people and food.

Keith Casey:  Oh yeah, good point, good point.

Kenn Bryant:  That's what that is.

Keith Casey:  Alright, thank you.