Identity in an API Economy

Hello, everyone. Welcome to this morning's webinar. Today. We have myself, I'm Craig Burton with temperature co distinguished Analyst, and we have a guest Scott Morrison, the chief technology officer of layer seven. I'm really happy that he could join us and he's prepared some remarks that you'll find enlightening before we start a few quick, housekeeping matters.

First off, everyone is in listen, only mode. You can't speak. You can just hear, and you can send in questions from the panel that you see on your screen, and we'll save those questions until the end and answer as many as we can. And those that don't get answered. I post in a blog post at the KuppingerCole website afterwards and answer all of the questions. So everyone will get an answer one way or another little about, little bit about KuppingerCole we provide, of course, these kinds of webinars and information.

Also a lot of written documents, which what I spend most of my time doing, and also a great conference in Munich this year in may, you can go to the KuppingerCole website and look at the dates and time of register there. So let's go ahead and start.

Yes, Here's the Topics. And I've failed to add as a topic, the Scott's remarks, but they'll be there before the summary. When we do a quick introduction to the API economy and its ecosystem, I'll cover the Cambrian explosion of everything, and I'll cover the five axioms of the API economy from co coal. Then I'm just gonna talk a little bit about how admin based mapping is broken and some of the issues.

Now, this isn't directly related to Scott's remarks, but it helps because it gives you an idea of the gap that exists between dealing with what's happening in the marketplace with the Cambridge explosion of everything in the API economy and the role that this group of vendors of which layer seven is a member of that provides great infrastructure to manage your outbound or what I call the provider side of, of the API economy.

Then I'll talk a little bit about the kinds of technologies that we're looking at that will resolve some of the issues about admin base mapping that's broken and, and a summary. And now in between the, the energy disservice automation section is where Scott will give his remarks. So here are the, the five Coco axioms or, or tenants. One is everything, and everyone will be API enabled. Now this is a real bold statement, but I think it's exactly what's happening in the marketplace right now.

And that, and when you start looking at the numbers of how big that is, which is what I'm gonna show you here in a second, it's a little mind boggling, and it indicates real clearly why companies like layer seven are finding are resonating so well with organizations because the job of managing the number of the sheer number of, of APIs that you're looking at just as an API provider is, is mind boggling. Number two is the API ecosystem is core any cloud strategy.

I think many organizations, well, it's clear that every organization right now is trying to grapple with, with what I call the, the computing Toka, which is cloud computing, mobile computing, and social computing. Those three things together are changing the entire landscape of how an organization deals with identity and personas. And that it's just as important to be thinking about the API ecosystem that you need to manage as it is those, those three components. And that you need to build that into your strategy.

Number three is baking a core comp your core competency into an API set is an economic comparative. This number three statement is just emphasizing how critical it is that providing APIs in your organization to your constituents is, is so important. Now in form five, I make a really strong distinction about the API ecosystem. That is number four, which is enterprise inside out. And you'll see that that's what an API provider is. And number five, which is enterprise outside in, and that's where your constituents can get to your core competency via APIs.

So let me go over the elements of the API ecosystem, so that you're clear about the language and definitions that cup and Cole is using to, to describe the API economy. First off, there are two types of API designs. One is the API provider provider is one that provides API access to internal resources and information. And this isn't just the traditional kind of, you know, brochures and sales literature. This is actually actually where your constituents can get to core competency and real information and interact with it or not just download content, cuz you can do that in the browser.

This is API based stuff and, and understanding that and knowing how to do it is really important. And again, layer seven is in the category of providing infrastructure to support organizations that are doing participating in the API ecosystem as an API provider. Secondly is the API consumer and that's where organizations provide or consume APIs of their constituents internally and, and mash those up with their own internal applications and information resources. Usually for internal use within the organization.

We're not gonna focus so much about the API consumer today or the infrastructure that you use that for, but it's really important to understand the distinction between the provider and the consumer. So drilling down a little deeper, the Avi API provider, which again is enterprise inside out has, is also broken down into two subtypes. One is called open APIs and the other day dark APIs. And let me distinguish between those open in this case does not mean necessarily open source or, or free. That's not what I'm saying when I say open, but that they're published in general.

Not always, but in general for public consumption. Now I'll show some numbers here that that are from an organization called the programmable web.com. And this is probably the premier organization that tracks the number of open APIs.

The, the, the activity that's going on there from resources that provide open API access is, is huge and growing at a hundred percent compound compound annual growth rate right now. So it's, it's, it's significant now dark APIs are unpublished. API is for closed consumption. And what we know about this, although it's hard to track because well they're closed is that it's probably around five times bigger than the open API section. And that's, that's significant just briefly to go over the API consumer.

It's exactly like the, the subtypes for the API consumer, which is the enterprise outside in is the open and dark APIs, which I probably talked about, but there's also the third type and that's internally APIs when that's from legacy applications that has traditional information and resources that are mixed together with those and applications that are either built internally within an organization or externally by a third party or a combination of those.

Now switching to just looking at the what's happening in the API economy and in general, these are all API providers and this information is a little old, but, but it's so significant that it's worth looking at because it's just growing. Let's just look at the, a couple of them Twitter in may of 2011. So this is 18 months ago is 13 billion API calls a day. Google's 5 billion salesforce.com has over 50% of all their traffic that goes via an API.

And what I, what I mean by that for both, I think it's evident for Twitter, but for both Google and salesforce.com is that this is, you know, for Google, for example, it's not searches, it's actual applications that call the APIs that Google provides either for Google applications or for the search engine itself or for some other app building component 5 billion a day that's that's significant. And of course salesforce.com has, is more about authorization on authentication, but nonetheless large. So let's take a look at unpacking the Twitter number, just to give some perspective here.

If you take 13 billion API calls a day that's 54 million calls an hour, 900,000, you know, a million a minute, more or less about 15,000 APA calls per second. The, the size and scope of that is just, just mind boggling. So this slide is to try and give some perspective on understanding the API ecosystem a little bit traditionally way over on the left. The website is the way that organizations have traditionally provided data information and access to resources is through a browser.

But the numbers that we're talking about and being an API provider is showing that there is a large spectrum of methodologies from third party to widgets, to social media and mobile and devices that need to go through APIs here. It says open API, but it's also open and dark APIs. Now let's take a look at what's happening with the open API growth.

This, this is from numbers from programmable web I've. I go to programmable web.com and I subscribe to, to get a email every week that shows me the new APIs that come out and invariably they're around a hundred to 150 a week. I get through about half of them before my head starts to, to explode in the interest and curiosity of the types of APIs and kind of information that is being provided there.

It's, it's significant. Now We're At about over 7,000 APIs. You can see that the growth rate here has been, like I said, the compound growth is over a hundred percent and it doesn't look like it's gonna slow down, but rather even speed up.

So, so the number of open APIs that we've hit right now is that just over the 7,000 API mark, we're gonna hit 8,000 by the time, the end of the year, the projections that, that I've done show that will be around 16,000 open APIs by the end of 2015 in just three years. And like I said earlier, the measurements that are being done right now about the dark APIs, which is somewhat subjective, but nonetheless are approximately five plus five times as many.

So like 80,000 APIs by 2015, I think again, these are probably conservative and that the actual number could be significantly more than that as this continues to grow at the rate that it is. So moving past the evaluation of what's happening in the API economy, let's, let's change the topic a little bit and talk about something. I call the Cambrian explosion of everything. And the reason that this is important, you'll see in a second.

And that is a, I love this terminology because there was a point in the time of the growth of this planet, where all of a sudden the, the growth of multi-sale life took off in a way that was unprecedented. And that's kind of what's happening with the API economy and with the number of devices and personas.

And I, and specifically of identities and identity is central to all of this. And that of course is what company co focuses on is identity and security and privacy. So to help give some perspective, I, I really gleaned a lot of information from the iPhone rollout, not about iPhone five, but rather of what's happening in apple. And now this isn't just apple, but the numbers were so collectively interesting about just what's happening at apple, which is a harbinger of what's happening everywhere else that I thought I would go over those.

So here are the numbers, 400 million iOS devices just a few years ago, the category of devices with an operating system that were mobile didn't exist. And now we have 400 million wow, 700,000 apps on the website, on the app store from apple. That's huge.

Now, something I didn't know is that the average person, according to apple uses a hundred plus apps per device. They own that's running iOS.

Now, personally, I know that I'm in that category. So it's, it's not insignificant looking at iPads, 84 million iPads. They have 68% market share in 2012, just in the time period between April and June of 20 2012, they sold 17 million iPads in a category that that what three or four years ago didn't even exist. That's more iPads sold in that time period than any of the other PC vendors sold of their entire product line. During that time period, it shows that clearly we are moving into a post personal computer era into a device era.

And why that's so important is that is impacting organizations in a way that was very similar to how the movement from many computer mainframe was with the PC. What in the eighties? So it's not insignificant.

Finally, 94% of fortune 500 are investing. You know, we're deploying iPads. And I think that the numbers are actually higher than that. Now let's look quickly at Cisco predictions and, and connect that to the cupping or call API tenant. Number one, which is everyone and everything will be API enabled. So if you take what, what Cisco is predicting is that there be, there will be by 20 15, 2 0.8 devices per person on the planet. Now that doesn't mean that every person on the planet will have 2.8 per devices, but that, that there'll be so many that that's how you would look at it.

If you consider, there are 7 billion people on the planet. That's 19.6 billion devices in three years.

Again, I think they're being conservative. So if you take 10 tenant number one, which says everyone and everything is enabled and you add the number of devices and people that's 26 billion APIs.

Look, look that sync in for a second. Okay. So let me Look At quickly.

The, the model that we currently have for mapping entities, people, and devices to resources or services, which is very admin intensive. If you take it to say 26.6 billion entities, And You're mapping one entity to a service one by one that would take 640,000 admins, 24 hours a day for the next five years to get that done. In other words, it's not gonna happen the way it is.

And the, the, the reason that I bring this up is to, in relation to the conversation that we're gonna have with, with Scott here in a second, is that the only way for this to get accomplished is through an API ecosystem. We've got to learn and understand how to be able to automate the provisioning and deprovisioning of identities as they relate to the consumption of services.

Now, this is a complicated slide, so I'm not gonna try and go through every element because of the time constraints we have. So please take the time to look at it again, since this will be posted on our website and you can get to it to all the participants here, but basically today, what we see is BA is a one to one mapping between identity providers and service providers. And that's how the relationship between an entity or a person or a persona gets mapped to the consumption of a service and or a resource.

And that means that an admin has to get that done and down at the bottom, you see that it needs to be end to end where there's any number of identity providers being mapped to any number of service providers. The sheer number of that requires Automation. Automation in turn require APIs to get that done, managing the API infrastructure requires technology like what Scott is going to go over. This shows the complexity of a one-to-one mapping, one Entity to one resource, one at a time it's, it's a mesh of, of mappings that are doable around a hundred and we're talking billions.

So that gives you an idea how complicated this problem is now. So what we need in the middle is something that we're calling identity management and service. Now this is a new category of services and is just barely emerging. And there's two major vendors. I expect more, but the two that are doing it are salesforce.com and, and Microsoft. And the distinction between those is that in the middle of this is the ability to manage APIs, not only for organizations, for developers and third parties in a way that is very different than the, in the way that we've seen identities ever managed before.

So the purpose of this presentation is not to go over identity management and service. I bring it up just because it's another key element of infrastructure. That's important to understand in dealing with the C explosion of everything. So we're almost where Scott's gonna start.

So again, what we're trying to look at here is the way to automate this problem. We've got to see a way that applications can be written By the administrator by a third party that does the provisioning and deprovisioning of a entity that wants to access and consume a service or a resource.

Now, there are two really interesting technologies occurring emerging, both of which I think were, it was unclear about how they were going to succeed, but with Salesforce announcing the Salesforce identity technology, both of which are strongly supporting these two technologies, open ID connect and skim. I expect to see both of these gain considerable traction and a boost of reality and support, not only from my both Microsoft and Salesforce, but I expect other large companies to jump in and throw their hat into the ring.

So the summary of my presentation is that Sam, which is the one to one mapping method use today, isn't big enough that we're going to need other standards that are API enabled, and that organization shouldn't rely on the, on the traditional approach of mapping entities to resources. We're gonna have to look at another way, and that means that you need to be considering enterprise inside out technology, which is what Scott's gonna talk about. So now I'm gonna hand this over to Scott, welcome Scott, go ahead and introduce yourself and go through these foils. Hi everybody.

This is Scott Morrison from layer seven technologies. And, and thanks, Craig. I was a really, really interesting discussion of exactly what's going on in this, this fascinating intersection between, between APIs and identity itself.

And, and I think it's something that's gonna have a big impact on, on all of us, you know, literally on a day to day basis. And that's the interesting thing about this technology is for the first time, it's, it's really a, a collision between the things that we've always done within the enterprise and, and really consumer based technology.

And, and that's actually why I think it's gonna have such a massive impact on all of us, because we all use iPhones or Androids or some kind of mobile device like that. Most of us are also using some kind of cloud based technologies. And what's interesting about this, you know, this kind of explosion that we're beginning to see this, this, you know, know literally Cambrian explosion around APIs and identity is that that really is the nexus of, of what's allowing all of this stuff to happen.

And so what I'm gonna go through here is, is talk a little about this evolution of how vendors are beginning to come into this space and provide, you know, solutions that fill that gap that sort of meet that kind of impedance mismatch between these two important technologies, you know, both the enterprise itself, but, but also, you know, the outside world consumerization really of, of enterprise computing. So if we could advance the slide to the first one, let's have a quick look at what I think the, the classic old enterprise looks like.

And, and this is the one that we're all really familiar with. And, and, you know, there's a number of different technologies in here. So if you imagine the enterprises being up there in the upper, right, and, and look at the typical relationships that we see again and again, that the enterprise makes with the, the external world, you could characterize these as very formalized.

So in other words, it's, it's relationships with trading partners and a trading partner relationship doesn't come about, you know, without a lot of ceremony, you know, without a lot of work going into it, you know, usually forms are filled out and triplicate and, you know, signatures go on pieces of paper and things like that. It's, it is a, you know, it's a tight relationship.

And, and so whenever you have that kind of formalized relationship, you can also really extend that same kind of formality and rigor into how you're you are tying together your computer systems. And I think if you look at the technologies that we've used up until now to kind of bind these, this relationship together, you know, from an electronic perspective, I think the technologies themselves kind of echo the formality of that relationship.

You know, we've worked with things like VPNs and, and, and the identities and things like that have been, you know, quite literally, you know, pushed right into our own directories and, and ID and access management systems. The actual protocols that we're using at a low level are, are highly standardized.

You know, whether they're things like EDI or, or even, you know, the next step out, which was, you know, things like soap messaging and classical web services, again, characterized by formality standardization, a lot of work to actually implement these kinds of things. Even if you look at the other kinds of relationships that that might be considered a little, you know, looser between the enterprise itself and the outside world, maybe things like browser clients and such, it's still a pretty formalized relationship.

It's, you know, it's, it's in a lot of cases with the enterprise, a fairly, you know, mediated one way sort of communications. And then finally, when you look at the road warriors, those guys who are out there, you know, representing the company, representing the enterprise, whatever that organization is, again, it can be characterized as a very formal relationship.

Those people come and go with a lot of, you know, sort of internal churn, you know, when somebody's, you know, kicked out of an organization when they're fired or when they leave, you know, it actually impacts the actual identity management within the organization. People have to get up and make changes into that internal directory.

So if I, if I could characterize, you know, this whole slide as anything, it's, it's saying that there's a lot of formality here. There's a lot of big work in creating all these relationships.

Now, if I could have the next slide, let's, let's look at where we're going. And, and I think, you know, Craig has put it very well in that the modern world, the modern, you know, world of computing is much more characterized by, you know, impact of social mobile and cloud computing. So in other words, not just consumerization of, of technologies, but also like an emphasis on very fast, moving agile, outside technologies technologies that don't exist necessarily internally in the enterprise anymore, but really are things that, that come and go very rapidly.

And, and you can really characterize these bio looser relationship. And the interesting thing about this is probably more than anything else. Mobile computing has been the big driver here. This is the modern forcing function for, you know, what we're calling in a lot of ways, the hybrid enterprise, this is this technology that all of us have in our back pocket and all this really demand connectivity into the enterprise.

So if you just look at, you know, the road warriors of before, okay, so the, you know, the people who are again, out there representing the companies and, and I would actually consider myself one of those, cause I, I certainly spend well too much time, too much of my own time actually out there, you know, in airports and moving around, talking to customers and talking to people at conferences, but, but the big, the big important thing here is that, that we're looking at a different way of actually interfacing and communicating with the company.

And in a lot of, you know, respect, there's a shift of burden onto myself, you know, as that, that person, that owner of that device in terms of managing that device. And what's so interesting about what's going on right now, is that the real enabler of all of this.

And, and if I could go to the next slide as well is really the, this convergence of APIs and identity. The thing that's allowing all of this to happen is the fact that all of a sudden we're moving to what I would call a much more agile and, you know, less restrictive approach to integrating different systems together. Whereas before we had these very formalized relationships, whereas before we had very formalized and highly, highly standardized and heavyweight, you know, communications protocols.

Now, I think we're stepping back and saying instead we're embracing relationships that change very, very fast and very, very rapidly. And moreover, we're beginning to, you know, look at our actual protocols and say, rather than putting up barriers, rather than creating friction by forcing people to use, you know, highly complex and highly standardized protocols, shouldn't we be instead sort of looking at the basic problem of, of integration and saying the integration, isn't what it's about. That's just a necessary evil.

In fact, what it's about is creating new opportunities, new apps, new channels to market and things like that. And that's where the focus should be. And in fact, we should instead just be, you know, using the technologies that have worked very well for us in the past for integration. And of course the key thing there, the key insight that I think has been made over the last 10 years or so, is that when we built the web, we did something right.

We actually, for the first time ever build a highly scalable, you know, transactional system, highly distributed system that we can add systems to, you know, virtually indefinitely and it doesn't bring the whole thing down. Well, that's actually really profound because when you think about the history of computing from the, you know, the day we had two computers instead of just one, and we wanted to make those computers talk and we put a wire between them, we had this terrible problem of, of, of how to create that lingo Franco between different systems.

How do we actually make them talk effectively? And we've had so many different attempts to try to make that happen. And we finally got it right with the web. We finally built something that actually scales pretty indefinitely, where we don't actually have any kind of, you know, central repositories that have to register everything that are always, always, you know, the point that make things fail. We didn't have to suddenly, you know, over define our protocols.

We could instead rely on something very lightweight and simple, like HTTP to really be able to do some pretty amazing and magical things with it. And so the, you know, the real genius of the API movement these days is it sort of steps back and says, let's embrace that.

Let's, you know, take all of the principles of, of the web architecture as, you know, as, as really articulated in, in, in the restful paradigm. And then let's add some, you know, simple content models and simple ways of describing data with things like JS O which bind naturally, and obviously into languages like JavaScript, but also very simply into pretty much any language. And let's just use that because you know what, the thing isn't the protocol, the protocol should just kind of go away and make it easy for us. It should not throw up barriers. It should not throw up friction.

It should not say you gotta load a whole bunch of different libraries to make this happen. Instead, the protocol should just go away and be an enabler. And that's the genius really of the whole API movement. Now what's interesting. And what I think Craig and KuppingerCole have, have really done a very, very good job of articulating is actually on the next slide.

And so if we could advance that one, is that what we're seeing now is this really interesting shift between, and, and that APIs are allowing between this sort of old model of centralized identity and moving out into this new new model where identity is really being delegated outwards. So in other words, identity isn't necessarily about, you know, that, that kind of internal model anymore of, of centralized authority. And in fact, it's about distributed authority and distributed ownership.

So in other words, me as a road warrior going out there on, you know, on too many planes and things like that can actually manage my own identity can actually manage the life cycle of my identity, but moreover can actually start to begin to build up the Federation relationships and, and ladies and gentlemen, that is the true secret to, to scalability and APIs and identity. And in fact, the next, I think missing ingredient in this whole idea of, of how we actually scale a modern enterprise.

Now we move away from that central authority, you know, just as we moved away from the central authority of registries and repositories, the secret of the web was again to not have that centralization.

Now the secret of identity is the same ideas to move away, break down the castle walls and to instead say there's a lot of different ways of doing things, and we're gonna scale by delegating out delegating the responsibility of identity out to, well, the people who own that identity and the beauty of that is the beauty of it really is that it follows the, you know, the great model I think, of, of modern agile, restful development. It follows the lead of APIs. In that it's saying it's not about complexity, it's about getting things done. It's about agility.

It's about making things come together fast. And, and that's the real beauty I think, of modern development.

I, you know, I look at the current scene in development now and I get really excited as an old developer because I think the kids today are, are pretty brave, you know, because they don't get constrained by complexity. They don't have to impress anybody with complexity.

In my era, we used to think that, you know, being a part of the priesthood and knowing all of this arcane stuff was cool. That's not cool today.

In fact, that's actually really uncool today and it takes courage though, to step away from that.

And that's why I think the kids are all right right now, cuz you know, if you're 23 and you're right outta school and you're building some kind of startup based on web APIs and, and, and it's all about integrating identity and you know, building services like identity as a service like Craig is, you know, so well pointed out earlier, you don't really care about impressing people with your knowledge, as much as you care about impressing people with doing something different than nobody's done before. And that takes courage.

And I think, you know, hats off to the current generation, cuz I think they're breaking down those barriers and they're making things accessible and, and that's a very, very cool thing. So on the next slide, let's, let's, let's talk about the problem we're facing.

So, so how do we get there? Like what is the technology that we really need to come in and, and sort of bring all this together? Like what is the fundamental, you know, thing that a vendor like myself at layer seven can do to sort of bridge this gap between, you know, an obvious need is Craig is so well articulated and, and real concrete implementation cuz you know, as a vendor, of course that's the kind of thing that, you know, that really interests me. What can I do for the kids today? What can I do to actually make this idea of agile identity and APIs really come together?

And I think if you look at the issues, they're, you know, the perennial issues of any kind of large enterprise, which is how do we more be more agile? How do we scale effectively? But more over in the, the really interesting thing now that I think is really hard is how do we distribute effectively? And this is again, one of the things that the web did very well. Sam was interesting in that we had clues in SAML about how to distribute.

I mean, I think the genius in a lot of ways of SAML was that in many ways it distributed effectively.

It, it, it sort of socialized this idea that you didn't have to necessarily centralize too much, that you could have local points of authority that could look at a SAML token, inspect it and make decisions based on trust relationships, where the whole thing fell apart, where it became very, very difficult and unwieldy and unscalable was keeping those trust relationships straight as they got, you know, very complex and, and Craig slide, I think showed that very, very well is that you got all these crossing lines of authority and, and this is where we need to sort of look at newer approaches, newer ideas, which again, push authority out to the individuals, let the individuals sort of decide as to what their entitlements are and, and you know, when something can do something on their behalf.

And, and I think the foundation is starting to come up from the grassroots. And again, it's something that really excites me it's different than before. Whereas in the past, in the world of Ws star, in the world of soap in the world of big heavyweight web services, you know, we had vendor driven, you know, complex standards where we all sat down there in the Ramada, in around a, a table and hammered our fists on the ground on the desk and said, oh no, we have to have it this way. We have to do it that way.

You know, today I think it's much more inclusive. You know, I think standards come from the grassroots trying to solve problems first and foremost. And then once the core is there, then the standardization sort of smooths off some of the rough edges and things like that.

And, and I think these, we're starting to see these in a few of the core standards, which I show in the next slide here, which, you know, are, are number one O off for, you know, getting access to APIs about authorization and, and even authentication arguably. But it's about creating those relationships. It's about me as an individual, you know, being able to say, I am going to give access to a certain client, a certain application, a certain program access to, you know, my resources on another system.

And, and, and the neat thing about this is when I first saw it coming out, my first reaction was, oh, you could do that with Sam. You could do that with Sam and you know what, I was totally wrong. I was absolutely missed the point of it. And it took a little while to sort of rock what it was really about and the real problem that, that it was trying to solve, but it was in fact solving a really good problem. And at OAuth I would argue now has actually become quite mature.

It, you know, I it's gone through the ITF process, you know, back in June or something, it got ratified. And only what is it last, last week? I think the RFCs, you know, officially got published and, and what's interesting is people are saying, oh, well talking about O two is so last week.

And, and that's actually a really good thing cuz it means we've embraced it. It means we've actually started to take it on and just said, of course we're gonna use things like, oof, that's just, that's a necessary and, and done part of the solution. The more interesting stuff that's, that's coming out of the bleeding edge now is, is much more around things like open ID connect, which really bring, you know, you know, this idea of, of how to share information.

So it's not just about authorization authentication, but open ID connect is the next piece which actually says, how do I share information about my name, address, serial number, what floor I'm on on the building? You know what my favorite color is those kinds of attributes, which are a necessary part of, of, of identity.

They're, they're part of how we declare who we are and what we are and everything like that. How do I communicate that effectively? And there needs to be a pretty standardized way of doing that because more and more, the secret of scale and identity is looking at things like not just an individual's identity, but looking at things like attributes because attributes don't change a lot or if they change, maybe the set of attributes that are necessary, you know, don't necessarily change in terms of who gets access to what you know.

And a great example of that might be, you know, what happens in the military and, and, you know, concepts like attribute based authentication are huge there because people come, people go, there's large organizations, which you can't necessarily pin access on individuals simply because there's too much churn in individuals. But what you can do is begin to pin access on attributes, begin to pin access on things like pay grade rank, you know, things that are much more constant in that yes, they change on an individual basis, but in terms of access control, these things are much more constant.

And so again, one of the secrets to beginning to scale effectively is not pin yourself necessarily on individuals, but pin yourself on concepts that maybe, you know, move between individuals. So any one individual may only have one rank for a little while, but the fact is is that they, you know, they move on, they get different ranks, they go to different roles and things like that. And you're not constantly updating access control approaches, you know, based on individuals, you're more building it up on, on a set of attributes, a set of ideas.

And of course, the way we're gonna pin, how to do that kind of thing is bringing together open ID connect, which gives us access to that kind of information, which allows us to, you know, on one system, get access to an individual current, most authoritative instantaneous set of attributes and, and points of interest and, and make decisions based on that. And of course the whole thing is built on OAuth, open ID connect couldn't exist without OAuth simply because it's, it's built on that fundamental foundation.

And, and again, going back to, you know, some important points that Craig mate, the other important piece of this three-legged stool and, and if we didn't have three legs, remember the whole thing would be pretty damn wobbly is skim. Is this idea that we also need a way of, of essentially, you know, managing things like identity provisioning, creating new identities on different systems, whether it's in the cloud, but also potentially whether it's in the enterprise and then actually managing that effectively through its life cycle.

So three very important, you know, emerging standards, which I think right now can be characterized, you know, with this idea that all of them grow to the grassroots, but go through a, you know, a more formal standardization process as they come out. So let's talk about this in terms of priorities. And if I could have the next slide, the first priority of course is gonna be oof, because as I mentioned, oof is mature. Oof is done. OAuth is baked, put a fork in it as Tim Brady, I think famously said a few months ago.

You know, when there's some controversy around the whole thing, this is something that we're all taking for granted now. So the important questions in oof is, is how do we make it really easy? Number one, and then how do we make it scale? Cause the thing about oof is it, isn't incredible easy.

Like if you start to just jump and read the specs, your eyes are gonna glaze over and you're gonna probably put yourself to sleep pretty quickly, cuz there's a lot of complexity in there and that, and, and you know, but when you really step out, when you really step out from saying, you know, let's not worry about the signatures necessarily or, you know, in oof 1 0 8 or let's not necessarily worry about every different kind of grant type as much as look at the fabric of what oof is really about.

What you really get down to is is, is a few very simple concepts about authorization, you know, that is by consent. And then, you know, finally being able to, to distribute that effectively amongst a lot of different resources.

So, so the question is, you know, if you just get that little part of it, how can you, how can you implement oof quickly and easily in such a way that you don't have to worry necessarily about all of these myriad of little details. Somebody's always gonna have to do that at one point or another, but, but from an architectural point of view, it's really nice. If you can just sort of step back from the 10,000 foot level and say, boom, we can drop in a lot solutions here, here, here, here. And it just goes away. Scalability of course, is the other thing that's really, really important.

You know, if you just look at the standard and you've, you've, you know, you've been around the SAML wars and things like that and you know, where the problems are, you'll immediately start to think about scalability because this is a hard problem in a lot of ways. And so scaling a lot is something to, you know, to consider pretty, pretty significantly.

So let's, let's take the first one of, of these on, and it's on the next slide. Let's, let's look at how to make O easy number one.

And, and I think the best thing you can possibly do is, is really begin to number one, separate out, you know, the idea of enforcement from your actual applications themselves.

I think one of the problems that people face these days is that, you know, when they start to implement, oof, they immediately start to think, okay, what am I gonna do in terms of coding, some kind of access control, you know, into my resources, into my services, into my APIs and really what we should be thinking about instead is making that as declared of as possible, because we're gonna be faced with the same problem over all of our APIs.

And as programmable web is shown us, you know, every day there are hundreds and thousands potentially of new APIs appearing in that, not just the public ones, but, but lots and lots and lots of, of private ones as well. And so to scale that effectively, we can't be trying to implement this on every single, you know, API. We've gotta start thinking about consolidating the enforcement of things like a loss, maybe outside of the API itself into, you know, a much more declarative layer and that's what different vendors are, are doing.

And, and I'll show you the layer seven solutions just as, as, as an example of, of how you can do this easily. And in our case, you know, we're a gateway vendor.

We, we have this idea of either a hardware or virtual appliance that you drop in, in front of your APIs and it takes over the security processing, whether it's access control using oof or also the processing of things like SSL and, you know, for confidentiality integrity or threat detection or audit, you know, all of these aspects of security and management consolidated in one place. So you can do it the same way for all of your different APIs and resources in the back end. And of course, you know, the best way to make it easy really is to try to make it as, as declar as possible.

And, and on the next slide, let me show you, you know, a, a real quick example of that, where, you know, this is an, you know, just what we do with our API enforcement solution. And, and this is our management console where we take a, a very simple resource.

And, and in this case, that's kind of articulated on the, the, the right side of this, where you see the, the, the resource called protective API. So this could be anything, this could be the, the, you know, buy or sell stock API. It could be access to, you know, a, some kind of Dropbox like system. It could be access to, you know, a database or something like that. Doesn't really matter what the API is.

You know, this is essentially where we define the access control. And so what I'm defining right here, this little, what we call a routing assertion, that's that, that thing says route by HGTP to this, this internal resource, this basically says any, anything coming into, you know, one of these access control gateways will immediately be routed internally to that particular API. So right now it's just a simple, reverse proxy, nothing special there it's, it's all it's doing really is masking the internal address from the outside world.

So no real security there, other than obscurity, as we all know, that's, that's no security whatsoever, so let's, let's drop some O off onto it. So the next slide shows, you know, an example of just quite literally dragging and dropping requirement for an O two token right into this policy.

And, and so now the policy on the next slide is really composed of two different components. You know, the first part of it is the, the oof requirement. And the second part is the routing. So now what I've done, you know, quite literally by dragging and dropping something in is oof, enabled this proxy. So now just to be able to get in there, you have to go through the oof dance.

And, and of course this resource server is also bound to a particular authorization server, which of course is, you know, when you think about it is, is almost like a facade on top of a directory that knows how to speak. Oof. So all of a sudden you can do it here. You can do it for, you know, a hundred different APIs the same way. And so you get that consistency. You make it very, very simple. So the next question we've gotta ask is we've made it simple now, how do we scale it?

So the next slide tells me a little about scaling and, and in this really, this is the piece that I think a lot of people don't get, because if they're implementing oof, they'll immediately go off and start pulling down oof libraries and, and, you know, throwing that in front of their APIs. And, and, and pretty soon they find that they have a huge problem because that doesn't scale very well, because in, in one respect you, every time you check, 'em an ooff resource server, every time you wanna look at an ooff access token, you've gotta validate it centrally.

And that can be a huge, huge problem. And, and so you need to be able to come up with a, a solution that effectively, you know, deals with things like Cing, that effectively breaks out the tiers between the authorization server and the, the, the protection of the resource, excuse me, server. And you've also gotta be able to scale those individually because the, you know, the performance requirements on each of those different operations is, is actually quite radically different.

You don't hit an authorization server nearly as is hard as you're gonna be hitting, you know, let's say high performance APIs that need to, you know, transact, I don't know, 10,000 transactions a second. And somewhere in that whole mix, you've gotta be able to, you know, essentially take an access token that you are handed by a client and be able to validate that.

And well, maybe 10,000 transactions a second, and that's a non-trivial problem. And so really you've gotta start to break out these tiers. And furthermore, you've gotta think about where this stuff is residing, cuz things like access, tokens are keys to the kingdom.

I mean, those are very, very short lived, but nevertheless valuable there tokens which really give, you know, know a particular client access to a particular resource for a particular amount of time. And if they're hijacked in some way, you've gotta be able to shut that whole thing down. And of course, if you're holding onto tokens like that in some kind of central repository that better damn well be secure, which means it better not be in something like your DMZ, it's a terrible place to put that kind of stuff. These are the keys to the kingdom folks.

You don't want to be treating these things like they were, you know, just some kind of short-lived token that doesn't really matter. Cuz if for some reason that authorization server is cracked. If there some reason that that, you know, token store is accessed, all of a sudden you can potentially lose all the access tokens and maybe they they're gonna time out fast, but in that short period of time, disaster could Sue. So really you've gotta start to, you know, apply some good security best practices to this and, and separating out token stores out of the DMZ, absolutely essential.

And that, and we've got, you know, people doing this right now in, you know, quite literally mission critical applications where lots and lots of money is trading hands on transactions. And oof is a part of that. And of course those tokens cannot, cannot be in any place that, you know, could potentially be compromised. And so the separation of tiers, isn't just, you know, for scalability, it's also for security reasons. And of course, to do that effectively, you need to start to think about the protocols between each one of those. So that was priority two. We've got the scalability.

So now let's think about what's the next piece of the puzzle and let's, let's try to wrap this up cuz I know we're coming up on the hour really fast. So the next thing we've gotta worry about are our, our, you know, breaking up the different components and also breaking up things like open ID connect. So let me, let me jump to the next slide cuz I know we're, we're a bit pressed for time here.

The next thing to bring in is open ID connect and open ID connect of course allows us to begin to create that facade where we can over over directory so that we can effectively query for, you know, for different attributes and things like that. Very important piece.

And it, it really articulates a couple of simple restful end points, which again, built on, oh wow. So they need to be authorized by an individual.

So again, we're getting to that idea of distributing out the control to the individuals scale through distribution, out to the people who own the identities, but making that available on a, on a case by case basis between different tiers. So this is an important piece of it and the same way that attribute assertions were important at SAML. I think open ID connect sort of opens up that, that avenue for different systems to begin to exchange information. And it could be as simple as two different websites.

You know, one of which has AC has, let's say my name and address, like imagine two commerce websites. One already has my, my, my home shipping address in it.

And I, you know, I, I get an account on another website that I'm also doing commerce with. Wouldn't it be great if I didn't have to put in my name and address on shipping address and all that stuff again, instead I could just say, oh, just go get it over here. It's already over here. I'll authorize you to, you know, get it on this first site. Very powerful idea. Open ID connect allows that.

And, and the next piece of course is skim, which is, is this idea that, that if you're gonna distribute this stuff out, you need to be able to remotely manage it effectively. And, and skim just really brings a number of crud methods again, using, you know, the whole restful API idea to be able to manage groups and identities themselves. So in other words, this is this, this piece that I can use to begin to provision myself onto new, you know, new websites, cloud sites, whatever.

So again, it's giving me power as an individual. I can begin to, you know, take my identity and, and effectively manage it wherever it is. Or if you're the enterprise you can begin to on mass do like bulk relationships with different systems. Consider this example. Let's say you, you know, you're a large enterprise of thousands and thousands of people and all of a sudden you decide we're gonna do salesforce.com and we want to enable it for everybody in our directory.

Who's, you know, on, you know, as, as a, as a field, you know, salesperson and that, and that might be, you know, 500 different people. Well, how are you gonna create accounts up on Salesforce for all those people? You know?

Yes, you could go do it and, and hire somebody that type, all that stuff in, but wouldn't be better if you could just, you know, write a little script that basically went through your directory and said, oh yeah, this person, Scott Morrison, Craig Burton, cetera, etcetera, cetera. These are all, you know, field sales people.

So, you know, for every one of those people go out there and automate the creation of an account out on Salesforce, that's the kind of thing that skim does skim was invented to solve that problem. And of course, as it solves that problem, people also recognize that the problem has even more scope than that. So they created, you know, I, I think a broader scope, but which still fundamentally is about that idea of remotely using APIs, being able to, you know, deal with, with that kind of management.

So final slide, the summary is, you know, the things that I wanna leave you with is really, we should be dealing with oof. Now, you know, OAuth is mature. Now don't let people tell you it's not ready for prime time. Don't get caught up in, you know, religious wars about, you know, people who like OAuth people who don't like OAuth OAuth is here to stay solves a very, very important problem.

It, it is a done deal. And, and it's something that we should be thinking about implementing, you know, all over. The next thing is open ID connect. This one is still quite frankly evolving on a day to day basis, but it's settled down enough that solutions are available now that can be dropped in that create, you know, those key endpoints, those critical endpoints that are necessary over existing directory infrastructure. And then finally planned for skim, skim is something that is being used on a day to day basis on a lot of big websites, you know, today.

And, and you've gotta be looking at how you can implement that, you know, within your own identity infrastructure. So with that, I'd like to, you know, potentially open it up for questions in, in what time we've got I'd, you know, I appreciate your time and, and Craig, I really appreciate the opportunity to, to, you know, share the stage with you. Thanks a lot, Scott, our time's up. So we really don't have time for questions, but please I answered some of the questions.

I will go through all of them and make sure they get posted on my blog and any questions that you have be feel free to email to me at CB KuppingerCole dot com. And if there's something about layer seven, that needs to be done, I'll be in touch with Scott and we'll get it answered. Thanks everyone for attending. And we had good part attendance and listening with low drop off.

And I, I really enjoy these webinars. And thanks again for Scott and talk to you next time. Bye.