KuppingerCole's Advisory stands out due to our regular communication with vendors and key clients, providing us with in-depth insight into the issues and knowledge required to address real-world challenges.
Unlock the power of industry-leading insights and expertise. Gain access to our extensive knowledge base, vibrant community, and tailored analyst sessions—all designed to keep you at the forefront of identity security.
Get instant access to our complete research library.
Access essential knowledge at your fingertips with KuppingerCole's extensive resources. From in-depth reports to concise one-pagers, leverage our complete security library to inform strategy and drive innovation.
Get instant access to our complete research library.
Gain access to comprehensive resources, personalized analyst consultations, and exclusive events – all designed to enhance your decision-making capabilities and industry connections.
Get instant access to our complete research library.
Gain a true partner to drive transformative initiatives. Access comprehensive resources, tailored expert guidance, and networking opportunities.
Get instant access to our complete research library.
Optimize your decision-making process with the most comprehensive and up-to-date market data available.
Compare solution offerings and follow predefined best practices or adapt them to the individual requirements of your company.
Configure your individual requirements to discover the ideal solution for your business.
Meet our team of analysts and advisors who are highly skilled and experienced professionals dedicated to helping you make informed decisions and achieve your goals.
Meet our business team committed to helping you achieve success. We understand that running a business can be challenging, but with the right team in your corner, anything is possible.
Well, good morning. Good afternoon. Good evening, ladies and gentlemen, depending on your location around the world, I'm Dave Kerns, senior Analyst for KuppingerCole, and I'd like to welcome you to today's webinar, borderless identity, managing identity in a complex world. We'll be talking about security and the internet of everything and everyone from industrial control systems through wearable tech, to smart devices for the home, the office and the car.
You know, I was thinking that 25 years ago, we were amazed those of us who were in it by the million object directory. And yet today we could conceivably add that many objects every month. Today I'll be joined by pro cDNA, the director of security architecture at Ws O two incorporated. Welcome PBA. And thanks for being with us today. Thanks and thanks for, for joining. Yeah. And I guess this is our various webinar with cap. I'm very much looking forward to it.
Well, thanks as I say, thanks for being with us now, for those of you not familiar with my company, KuppingerCole, it's a global Analyst company headquartered in Europe, focusing on information security and identity and access management. We further specialize in governance, risk management and compliance.
Our analysts are experienced in deriving corporate value from securing and maintaining information, security, security, and privacy across cloud mobile and social computing platforms go Cole, organizes conferences, workshops, and webcasts in the fields of information, security, IAM, and cloud, the European identity and cloud conference, which is coming up next week. And which Perth will also be speaking at is Europe's leading event for thought leadership and best practice in identity and access cloud and digital risk.
Before we get started a few guidelines for today's webinar, you are muted centrally. You don't have to worry about turning on and off your speaking devices. We control that feature. The webinar will be recorded and the podcast recording will be available tomorrow. And you'll also be notified by email. When it's available, you can ask questions at any time using the question and answer tool in the control panel of go to webinar.
Generally, we'll pick up those questions at the end of the session, but if they're appropriate, we will stop and, and take questions during the session too. Especially if it's for a point of clarification or something like that, today's agenda is going to be in two parts.
First, I'll start by looking at how we got to this massive and growing exponentially internet of everyone and everything. What dangers lurk in that dark forest, or more likely that dark cloud and I'll offer some recommendations on how to mitigate the problems. Following that we'll discuss the risks of challenges associated with building a common identity platform, which expands across multiple heterogeneous Federation protocols and environments, and how to mitigate those risks and challenges.
So let's get going over the past few years, the internet of things has become a hot news phrase used to identify a myriad of devices from thermostats to light bulbs, to automobile parts, which came monitored or controlled by means of an internet connection. But the reality is that the internet was always about things. And in the beginning, really only about things when it was first invented, 50 years ago, those things were hosts servers, mainframes, terminals, and other computing devices.
It's true, but it wasn't long before other non-computer devices were added. It was in the mid 1970s, 40 years ago that a group of computer science grad students at Carnegie Mellon university, my Alma mater and Pittsburgh grew weary of trudging up a couple of flights of stairs. Only find that the Coke machine was empty or worse that the Cokes were warm. So they decided to do something about it.
As explained at the machine's own website, they installed micro switches in the Koch machines to sense how many bottles were present in each of the six columns, the switches were hooked to CMU a, the PDP 10 computer that was then the main departmental computer. A server program was written to keep tabs on the code machine state, including how long each bottle had been in the machine. When you ran the companion status inquiry program, you get a display that might look like this, just let you know that cold Coke could be had by pressing the lower left or lower center button.
While the bottom bottles in the two right hand columns had been loaded an hour or so beforehand. And so they were still warm. That display changed to just cold. After the bottle had been there for three hours. Now the software, the hardware and even code machine itself have been updated over the years, but it's still there and it's still operating most likely the longest running thing on the internet of things By the mid 1980s, we realized that while identifying the nodes on the network was good, it was how we routed data back and forth and still is.
We really needed to identify the people who were using these nodes and restrict which resources they could use on the network. Thus was worn authentication and authorization.
Of course, this made it necessary to identify all of the resources that people might want to use. Things like printers or fax servers or telephone switches, or even Coke machines. Gradually over time, people use their own ingenuity parts available at the ever present radio shack in its ill, and eventually even home brew kits, like the raspberry pie connect devices in their life to first their wireless home network and later the worldwide internet. Now it was possible for me to stand on a stage in Munich and turn off and on the lights in my home in a suburb of Washington, DC.
This wasn't half as funny to my wife who was home at the time and trying to sleep since it was four o'clock in the morning. Some of the people creating these controllable things were software and hardware, engineers, And word of what they were doing as a hobby made its way to the marketing folks in their organizations and voila. The era of smart devices was boring.
Kristen, by marketing, of course, as the internet of things at the turn of the 21st century, this conglomeration of devices was thought by many to be a different internet from the one that allows people to connect with each other via social networks. For example, unfortunately, each of these devices had an associated app, which typically ran on a smart mobile device.
Well, what would be the point of having an app on your desktop to turn your office lights on and off the idea of a smartphone dashboard to display all of the, to display all of these apps functions seems to have never occurred. Each app must be clicked individually to bring up the functional interface. And this can only happen one at a time.
Of course, there wasn't any, or very little built in security with these apps. It was simply assumed that if you could get to the screen showing the app, then you had permission to run it. So we added on security, one app at a typically this was a username password combination, or perhaps an email address and a pin Different for each app.
Of course, some more advanced apps would also check the hardware footprint of the smart device as an added authentication method, a number of apps, proliferated lights, thermostat, TV, coffee maker, refrigerator, Whirlpool, bath Coke machine. What have you, the old ugly problem of proliferating passwords raised its ugly hydro like head once again. So what should we do?
Well, we could carry a list of all of our passwords, perhaps in our wallet, perhaps a sticky note on the back of our phone, we could keep them documented and stored on our phone in a spreadsheet. We might even have an app or a basic tool on the phone, which kept track of them. All of course that meant that anyone getting possession of the phone also had access to all the apps, not the increase in security we were thinking of. Was it without security built in from the start?
We can sometimes make it worse when we T on later, the other security problem is that the internet of things isn't really excuse me, a separate network. It's all one big net, the internet of everything, and everyone it's subject to all the security problems we've associated with the internet. When we were just considering people in resources, Some of those security problems include man in the middle attacks, key lagging fishing and all the rest. And these security problems occur on every platform.
While we talked about for years with our desktops and laptops, that certain operating systems were more secure than others. When we get to man of the middle attacks and fishing, we're out of the realm of what the operating system can protect. So it doesn't matter what platform you're on. These things can still affect you.
And remember it, isn't just whether there's a cold Coke in the machine, that's being controlled, but your automobile, the airplane you're flying on, or even a steel mill, according to a BBC report, a blast furnace that a German steel mill suffered massive damage following a cyber attack on plants, network attackers use Ruby trapped emails to steel logins. That is to say fishing that gave them access to the mills control systems. This led to parts of the plant failing and meant a blast furnace could not be shut down as normal. The unscheduled shut down on the furnace caused the damage.
In this case, the industrial control system was a desktop app, not a mobile one, but mobile ones are coming. And for one would hate to think that a username and pin was all that was keeping hacker from destroying my plant. So what can we do security by design security built in from the beginning as needed security.
That's an integral part of the apps and OSS and platforms that we're using hardened secured simplified sign on to overcome password proliferation is needed, no more password lists, password reminders, password notes is the heartened system to handle it all for us, secure encrypted transports to protect communications, to keep out those men in the middle attacks or anybody else who might try to listen in and privilege management for the users and services, the privileged users and the privileged services that have access to so many things.
And maybe not just those people, but apply the principles of privileged user management to everybody on the network. Certainly something to think about. And it's something that can protect those in the long run in the end, the internet of things, just like the internet of people. And as I say, it's all really the internet of everyone and everything needs adaptive policy based access management Policy based so that decisions can be made at runtime adaptive so that changes can be made at runtime access management so that the right people get the right access to the right things.
At the right time. You can find out more about this at EIC.
Next week, when my boss Martin Kuppinger will be giving a presentation on adaptive policy based access management beyond a back and our back. And if you go to this website, you can see the blog entry that he wrote about it a couple of weeks ago, as sort of a preview to what his talk is going to be about next week. This is something that we at KuppingerCole believe is necessary for the future of the internet of everything. And everyone.
Now this time, I'd like to turn over to pro for his presentation, but first again, let me remind you that you can type in your questions at any time using the question module on the control panel for go to webinar. So pro take it away. Okay. So as they mentioned before, I'm from, and I'm the director of security architecture at w O two and little bit about me. So this is first time I'm doing a webinar with KA inal. I've been with w O two for seven plus years now.
So basically since I joined w so two in 2007, I was directly working with the w O two's main IMT management and access product w server. And also now I'm leading the complete, the platform. This I'm looking over, or the secret to W2 platform.
And also, I, I have written a few books and look at com, I'll be doing a keynote at the EIC this year. So be next week on sixth may, If you are new to w so two. So w so two was founded in 2005 by acknowledged leaders, INL web services, technologies standards. So we produce a set of middle layer, all opensource, PO opensource hundred percent opensource release under attach to license. So a is the most business friendly opensource license. So basically you can do anything like you can get the code, modified the code, and even you can ship the modified code with your own product.
So it's very business friendly. And also we don't have like two additions of our products. Everything is pure open source. We don't maintain a community edition and a different enterprise decision. It's not just our core open. We also make all our architectural technical decisions openly. So if you're interested, you can join architecture at w or list for architectural discussions and any discussions related the development of the products, then you can to deal with w or so. We are a very fast growing company at the moment.
We have 500 plus employees, and we have offices in USA, Europe, and Sri Lanka. And the main RD center is in Sri Lanka Colombo. And we are planning to grow by a hundred plus, maybe more than that will by the end of this year. Yeah. W so two produces like 20 plus products to address different aspects in your enterprise. So basically you can use w so two platform to power, the connected business, the w two, it server is a product which take yeah, yeah. API security and int management aspects of your enterprise.
And we have w so two enterprise service bus message broker, then business processor, which is a workflow engine, which takes care of the integration aspects. Then we have a data server which can create services or expose services from your data. Then again, we have an API management solution. We security monitor for managing. So basically we have WSO two analytics platform that includes bam, complexity processor, and also a machine. And the presentation there, we have an application server where you can host your applications and also use engagement server where you can build your own gadgets.
Okay. So going back to the main topic, consumerization post about reorientation of product and service designs around the individual end user it consumerization is an emerging topic or trend for last S this quite important trend, not just about new devices, it's about the entire relationship between it. And it's use population. This trend also introduces significant security issues because critical it assets needs to be available and most important securely and increasingly distributed and diverse use user base that is using consumer devices of their own choice.
While the initial consumerization high was focused on bringing your own device spread, we are now seeing the emergence of bring your own identity concept. The, the rise of I, or bring your own identity is being driven by users. Identity fabric users have too many accounts, too many usernames and too many passwords. When the competition is literally click away, organizations must enable the easiest user experience possible for users might create sites that offer the simplest registration or developing process.
If you look at like many websites, how more quickly to accept entities from popular online ID providers like Facebook, Google lending, and even project the research done by the Alexei firm calls confirms that many businesses now have more than external users than internal users in Europe, 58% trans directly with users from other businesses or consumers for UK alone. That figure is around 65%.
If you look at the history, most enterprises grow to the acquisitions, mergers or partnerships in us only merges and acquisitions volume total to 8 65 0.1 billion in the first nine months of 2030, according to a company called the logic. So that is like 39% increase over the same period a year ago, 2012, and the highest nine months total since 2008. So we can clearly see there's upward rate. So this is the most important question. What does this mean to enterprise management?
You would have to work with multiple heterogeneous force authorization protocols, letter systems, and many more bringing own identity is not just about bridging social identity with your enterprise identity. It's also about bridging different heterogeneous identities between different corporates or enterprises, some open ID, open connect, doubles Federation, all support Federation and cost domain authentication, but can we always expect all the parties in the Federation use case to support semi open or open connect? Most of the Federation systems we use today are in silos.
It can be a silo semi Federation, a silo open dependent Federation, a silo of open Federation. So basically in a silo, all service providers and ID providers took the same language or of the same protocol. You are not able to talk between silos. Someone was mostly used to facilitate in the, it can be just within the same domain or between do domains, Samuel version two, which is the, the, the latest and the popular version. It came in 2005 was built on top of that success.
It unified the building blocks of identity in version one, one of Sam with the inputs from sh initiative and also the labor alliances ation framework. Summer two was a very critical step towards the full convergence of federated. I standards open ID in two, five followed the footsteps of summer. It was initiated by the founder live journal, Brad Bradford Sprick even in, in open the basic principle behind it. And some was the same. Both can be used to facilitate single sign and novation, but open is more community friendly user-centric and decentralized in mid January, 2008.
Ed open support led July MySpace announced support for open ID and late October Google joined the party by December, 2009. There were more than 1 billion open enabled accounts because a huge success in your single sign on, but started to fade after all two and open ID connect. One of the very popular and very first open provider. My open ID was shut down on first, February, 2000, but summer to look at summer, it it's still stable. Even after Tenness Open connect has some history.
It has its fruits in oh two, although it's been developed outside, I F under open foundation, open connect is developed as a profile of or tool or two, basically a framework for delegated authorization. And it's a misconception to think if there's authentication. So people follow workarounds, but the main objective of two is not authentication.
It's the delegated access open ID is the one built on top of oh two or the open clinic is the one built on top of oh two to do authentication as in the case of, and open ID, both and open connect can be used for web single sign on and for post domain Federation, building a set up from scratch to 15 to these standards is not hard. Say, say you got a life Porwal which supports open ID based logging. You can enable federated login to Lifeway, to a partner who is having an open provider deployed or its own system. So it's open to open interaction.
Similarly, if you have a similar to ID provider deploying new environment, then you can federate the identity to cloud service providers like Salesforce or Google apps, which support some based logging. Basically that means the users from your domain will be able to log into Salesforce or Google apps using their corporate credentials. That's the easy part of I, how do you handle situations where you have a partnership and the applications running in your domain security tool should be accessible to your partner who is having an open ID connect ID provider.
So your service provider is supporting summer, but the ID provider can only talk open if you support through Y I D with no code changes, you should be able to let a user from the partner domain with an open connect token to log into your application, which is secure some to internet, always has an unsolved problem. Very frequently. You will see new standards and profiles up summer summer was dominating the last decay.
And, and still like, to some extent, summer is dominating open clinic and JWT could be dominating the next decay, hopefully, and as we go on, as we move on, there will be a lot of legacy around us. We need to find a way to get rid of these Federation silos and build a way to facilitate communication between different heterogeneous protocols. In addition to Federation silos, another anti pattern we see in large scale Federation deployment is disability identity.
You create many point to point cross relationships between multiple IMT providers and some multiple ID providers and service providers. And it becomes quite unmanageable even in a given Federation silo. How do you scale with increasing number of service providers? And I providers each service provider has to trust each I provider. And this leads into this identity anti with identity bus, a given service provider is not covered to a given T provider, and also not couple to a given Federation code.
A user should be able to log into a service provider, which accepts only someone to opens with an ID provider who only use open connects. The, I acts as a middleman who mediates and transforms ID tokens between these heterogeneous ID providers and heterogeneous service providers. Let's see some of the benefits of the IMT bus better. Introducing a new service provider is extremely easy. You only need to register service provider at the ID bus.
And from there, pick the clustered IDP IDP for the service provider, no need to add the service provider configuration to each and every ID provider, and also removing an existing service provider is extremely easy. You just need to remove it from the IP bus in the same way, provisioning and decommissioning. An ID provider is also extremely easy. You only need to add the IDP or introduce IDP to your IP bus, and that IDP will be available for your service provider. So if they trust, then once again, you can associate that IDP to the authentication chain of the corresponding service provider.
Then again, ability to do force authentication protocol centrally. If you look at most of the ID Federation standards, they do not rely on how user authenticates at the I D provider. It can be used password. It can be other multifactor authentication like Fido or any way with this approach. You can centrally add multiple authentication protocol support I bus, and you can configure based on service provider. If a request, if an authentication request come from service provider full, then just use an admin password.
If the request comes from service, whatever, then then the first step is using a password. Second step is fi likewise, you can configure multiple Porwal codes based on the service provider. The other one is claim transformation.
So in a, in a heterogeneous environment, different like different entities understand use attributes in different ways. For example, if you take Facebook, Facebook, Facebook has its own claim dialect to share attributes with the service providers. But if that claim dialect is not well understood by our service provider, then it's a claim that each provider has to implement a claim transformation by centrally managing all the authentication requests at the it bus T bus can transform claims.
So you get the requested claim from the service provider, and that claims will be transformed in a manner that can be understood by the IDP. Then you'll get the response where you have the claims in, in the T provider specific terminology. Then ID bus will transform those claims in a way that can be understood by the service provider. So the claim transformation would help and make the I more manageable. Then once again, role.
So if you, if you, if you look at the warehouse, Salesforce and Google apps work, even though you can delegate authentication to, to, to your incorporate provider using some still you need to ion the user. The reason is you need to ion the user because Salesforce and Google apps, they do their local authorization. So to do the local authorization, you need to find the user. So you need to approach the user and local the sales force or through the approaching API. You need to send the with program mapping. You don't need to do that.
So you get a, you get a, you get a response from the IDP, with the IDP roles, like the roles that user gets from the IDP, then service provider and IP bus can define a role mapping between service provided IDP. Then I bus will map those IDP roles to local roles of the user and send us summer response to any other authentication response to the service provider. The service provider now can just authorize the user by looking at the roles in the authentication response Just in time provision.
So once again, since we managed all authentication requests, centrally, you can just in time promotion users, whenever you log into us service provider through Facebook, you can provision that user to an internal user store. I know also, it's not just about just in time permission.
Also, you can outbound provision users to external entities, centralized monitoring, and auditing. So you can track like the, the different patterns, login patterns of the users and also different authentication requests. And also you can do for detection centrally. Then again, I to introduce new Federation protocols with minimal Fisher. So if you look at W2 RD server, so we do have support for summer open ID connect, open ID and Ws Federation. So these are the inbound authenticators and also outbound federated authenticators.
So a server can accept open ID, open ID clinic w Federation summer request. At the same time, a server can generate open ID, open ID, connect, Ws Federation, and similar frequent.
So, so we have an accessible architecture where if somebody wants to have their own proprie Federation protocol, then you can implement it. So one good example is so out of the works, we don't have cast support. So one of our customers wanted to have cast support and they implemented their own inbound authenticator and ed with IMT. And that authenticator will be available to any of the service providers in their environment. Yeah. So if we quickly look at the customer base, so we do business globally. And so we have many customers in USA.
If you look at eBay, Boeing, then Trimble, and if you go to middle east, we have, we have like large scale project for the Saudi government where they have deployed w to server one of 4 million user store, which is using as an open provider. And also Dubai government is using, I service some and open ID connect capabilities.
Similarly, we have many customers in Europe as well. I guess that's what I wanted to cover in this session over to do Well, thank you very much for Beth. That was certainly an interesting presentation. And hopefully you've convinced everybody they need to get on the bus. Now I'll remind everyone that we we'll go to the question and answer section now. Okay. The first question we had was whether or not the presentations will be available and they will be the entire webinar is being recorded.
It will be then edited to take out the extraneous parts and will be made available to all of the attendees. By tomorrow. You should get an email that tells you that they're available question for you. Proov while doing away with silos is obviously something we need to do. Can users still maintain multiple identities or multiple personas where they want to keep different parts of their life from overlapping? Is that possible? Yes. Yes. So basically it becomes a feature of the I bus to support multiple identities. And also the, the other thing is you can also map different identities.
Say, say you have the, like the best example is with the I bus, you'll be able to log into your sales corporate Salesforce account with just Facebook account. So how does that happen? So you can map your social accounts to enterprise login. So I bus will authenticate the user from Facebook, then find the mapping account or the map account in the bus. And in the summer response, it sends from it bus to the Salesforce, it'll send the enterprise ID. So that that's one use case.
Another use case is so we haven't done this yet, but if you, if you integrate the ID bus with the account, so then that will also itself bring more benefits and more, more, more like I patent. Oh, good. That's that's somebody's mind at ease. I think. And one thing that actually, I wasn't sure about here, because often when we're talking about these Federation type protocols, it becomes necessary for both parties in the transaction to have whatever the particular appliance is.
And from what I saw of your presentation, only one entity needs to have the, the w S O two identity server in the transaction. Is that correct? Yes.
The, the reason is since we are like the only patient open standards, so we don't need to worry about like what the other part is using. Even that's following a standard, It could even be run as a managed service, perhaps. Yes. That that's source of possible. Yeah. So if you look at the old personal products, we have like optimized deployment, and also it can be deployed as a private cloud. And also we have a public cloud hosted cloud deployment as well. Very good.
Well, once again, I want thank Prova for being with us today for this excellent presentation and remind you all that. We'll both be at the European ID conference next week and winter slice time, just outside Munich, Germany. And we invite you all to visit us with us there and to enjoy yourself. I understand there are still a few tickets available. If you go online to go cold.com, you should be able to find your way to getting those tickets. We thank you all for your attention today for your questions.
And at this point, I just wanna wish you all a very pleasant rest of the day, and hopefully you can lead into the weekend, have a good time, and then we'll see you all in Germany next week. And with that, we'll say good day,
