Webinar Recording

Access Management and Federation for the Agile, Connected Enterprise

Name: Access Management and Federation for the Agile, Connected Enterprise
Uploaded: 2015-03-11T12:00:00+01:00
Duration: 56 min 26 s

Posted on Mar 11, 2015

Two things are for sure in IT today: The cloud is here to stay. And on-premise IT at least in medium-sized and large organizations will not disappear quickly. IT environments are increasingly becoming hybrid. This requires well thought-out solutions for connecting the on-premise and the Cloud environments. Furthermore, allowing access of mobile users, supporting cloud-based directories for consumers and business partners, or integrating with apps and things imposes new challenges.

Webinar Presentation, KuppingerCole

Webinar Presentation, Forum Systems

Lead Sponsor

Video Description

Show Transcript

Good morning and good afternoon. I'm ladies and gentlemen, welcome to all our attendees. Welcome to this webinar. Our title for today is access management and Federation for the trial connected enterprise. The speakers today are me Martin Kuppinger I'm, founder and principal Analyst at keeping a call and chase Macy who's CTO of forum systems. Forum systems is supporting this webinar before we fully start some information about keeping a call, some housekeeping information for the webinar and a quick look at the agenda.

So keeping a call, we are providing enterprise it research advisory service decisions. Porwal networking for it professionals, particularly in the field of information security through our research services, our advisory services and our events, our main events, the upcoming European identity and cloud conference, which will be held next time May 5th to eight Munich. It's a master 10 conference when you're interested in information security, identity, access cloud, digital risk and related topics regarding the webinar. You are muted centrally, so you don't have to mute right, mute yourself.

We are controlling these features. We will record the webinar and the podcast recording will be available latest by tomorrow. The Q and a session will be at the end, but you can answer questions at any time using the questions feature you will find in the go-to webinar control panel, which is usually at the right side of your screen. So my proposal always is sort of once a question comes to your minds, this question, and then we will end up with a, a long list of questions for the Q and a session, which makes this even more interesting then. So let's have a look at the agenda.

The agenda for today is I will do the first part of the presentation and talk about challenges of today's and futures, access to systems to information. So connecting people, apps, things, and more, more the high level overview on these aspects. And the second part, then Jason Macy of forum systems will dive deeper into detail and talk about requirements, standards, technical components for future access management and Federation. So use for everyone and everything based on gateway approaches and illustrated by case status of customer based best practices.

In the third part, finally, we will do the Q and a session off already talked about. So if there are any questions, enter these questions and we will pick them during Q a, I will start with a slide to one or a few might have seen before our computing slide, which is still massively affecting the changes we are serving in it, where we have the cloud computing, social computing and mobile computing as the overarching trends, cloud computing was different types of deployment models. So we have more applications in the cloud or services. We need to access.

We have different types of user populations, and that's what I've fit under the term of social computing. So our external users are business partners, our customers, etcetera, we have to integrate, and we have far more types of devices. So we have an very increasing number of devices, a permanent trade in that area with types of devices, appearing on the market. Other types of devices becoming less relevant, cetera, et cetera. And this changing environment, information security also has to change.

So we have to support more deployment models, more user populations, more device types to protect our information, the information factors at the center of this. And regardless of where information, regardless who accesses it regardless, which device is used, we need to protect our information. That means access and Federation the to major topics for today, play in major role here, and to look at this from a little bit different angle, but also quite related to the slide I show I've shown before. What we really see in these days is everything becomes connected.

So we have in the center of this, of this graph, we have the people and these people, they are part of organizations and they act on behalf of organizations. They own devices. They use devices, they own and utilize things, devices and things communicate. There are things which are even devices because they are used by units and they are things because they act as anonymous, such as smart watches, where we already see a number in the market. And we have on the other hand, then clearly devices, which are owned by organizations and so on.

And all these things are communicating and this are, and things and humans are communicating. The organizations are related to this entire relationship becomes more complex. We have to deal with the apps which are running on devices, the software, which runs on the things, which might be something like a singlet or whatever. We call it in the future. And we have to classical bag end systems in the organization. So what really comes into play here as well as that, we are not only talking about sort of human-centric communication.

Like we did traditionally, where a human uses this computer to do something, to access a service, to access a website, whatever. But we have an increasing number of situations where API is used and apps or the software and things let's call them singles or the services at the back end, Western the cloud or not are communicating through APIs. And they, in many cases acting on behalf of a particular person. So we need to understand the identity context of the human behind the app.

We need to understand the identity of the app itself of the thing, et cetera, sourcing might belong to multiple persons device might be used for multiple persons, but it might be also related to a single person, the current user, which makes this entire picture of identities and their access even more complicated because it's not a sort of one, one relation anymore person accesses to service. But it's a multistep relation where a thing communicates on behalf of a person where an app is used on a device, which is owned by one person, but it's used by a different person, whatever.

So things are increasingly complex and we need to handle the challenges of access and Federation in this environment. And to add another picture we are talking about far more and even having those things in here, far more identities than ever before. So employees, something we, we have looked at when we look at identity and access, we have looked at for many years, business partners, some are in for quite a long time. Others are coming in here with more onboarding, new business models, new types of sales channels, et cetera.

But those are sort of relatively small numbers compared to the numbers of prospects, leads customers. So, so one of our advisory customers, they have 20,000, 27,000 employees and they have four or 3 million customers. And when we call count the number of things, we are talking about tens of millions in that particular organization. So we will see even more of that explosion over the next years.

And there are a lot of predictions around a number of things, but all of them are in the billions of things, managing identity, managing access will become an even more interesting challenge than it has been until now. So overall businesses are changing, and this is sort of the new ABC. We have these agile businesses that are connected. There are so many different terms. Internally. We find the term of industry further though for the first industrial revolution in other countries, we find the digital transformation of businesses. And so on.

In fact, it's really about the point that we have this, a agile B business C connected, which really makes up this entire transformation. So businesses have to be agile. This is a must in a changing competitive landscape in an area where we see a lot of information where we really see this digital transformation of formally very well sort of physical to services to more it services in the broader sense. So if you look at a simple example, such as the connected vehicle, so it's not only providing the good the vehicle, but it's also providing services.

And in some areas, the service becomes even more important than the physical good. So we have this need for agility. And we have, as a inevitable consequence, this aspect of connection things become connected. We have to deal with it. So what was we call it open enterprise connected enterprise, extended enterprise doesn't really matter, but we have a lot of change. We have new business models, new business process and changing business processes, different communication channels changes in the organization, the it applications on apps we've never had before and so on.

And we connect business partners, customers leads prospects information. So also social networks, things, whatever you can imagine. And this is really where we have to, to res rethink the way we are doing access, where we, we are doing Federation. So we see a lot of, and this is still without looking at the things which at another level of complexity.

But even when we look at sort of the down to earth aspects of how businesses are communicating with others, other projects, such as their business partners, the consumers, etcetera, then there are some very obvious demands we are facing virtually any organization. It's the use of cloud service. It's just a request of your business to use cloud services.

It's about accessing business partner systems with an ever tightening supply chain and collaboration between business partners and collaborate in industry networks and many industry, which are particularly the ones which are research intensive, such as healthcare, such as yeah. And a lot of others look at aerospace and defense and so on. Then we have a lot of collaboration in these networks. We have the need for enabling the mobile workforce. So people want to use their mobile devices and we have to need for onboarding business partners, difference channels, etc.

We need to handle customer interaction, which means we also need to provide an adequate supply, which is Federation, which is new types of directories. Sometimes as a identity management move to the cloud particular for the external priorities where authentication topic, I will touch on my next slide, risk and context based access management and authentication, or the entire adaptiveness. They taking context into account becoming more flexible because it's not someone is using his PC in the internal corporate network.

And so everything is fine, but it's far more complex scenario where the same person accessing the same system and information in some cases might cost more and other less risk. So if he's using a non-security device using unsecure wireless network, somewhere else in the world, it's a different story than when he works from the corporate network. And we need to do this because this is really supplying to this demand is really what drives business value.

So actually, as I've said, organizations need to be at trial compliance, protecting information anyway, in an, when we open up the entire environment and security, clearly also as a part innovation being able to, to, to, to work with business partners on innovation, for instance, collaboration, communication, new firms of collaboration, mobile works, mobile workforce, etcetera. So this is really the changing landscape we are in. And this has to do a lot with access and with identities. So at the end, it's about how can we protect information? How can we mitigate risks?

A lot of this anti stories really of are we able to manage all these identities of all the related parties and the things in future and to control the access, to keep these things under control. This is really the big story we are looking at. And when we look at the future for all syndication and authorization, which also means where, where access and, and access management and Federation are heading, then we see some change. So we have to service providers. This could be an internal application that can be something in the cloud. We need to authenticate and we need to authorize.

And then as of now, it's mainly authenticating people and the future it'll be increasingly, it's more authenticating apps in the context of users and the things will come in. Cetera, we need anyway to authenticate, to authorize, to define who's allowed to do what or what is allowed to do what future. And there are policies which control that there's the context. So which device, someone using directories, where we have the information about the users, the identity providers, which might deliver additional attributes and the credentials in use.

So which credential can be used by a particular type of device. And we have to change this, make more runtime decisions, not only static access control become more adaptive, become more flexible Moreira trial to support our at trial organizations, which in fact means we need versatility or adaptiveness regarding the credential supporting different types of authentication mechanisms for different use cases. We need to become dynamic.

So we, we can't trust rely on someone is authenticating. That he's good, but it depends on the context. It depends on a number of factors and all this happens in the context of risk. So we need to understand the risk, which is cost by our particular authentication and authorization request to really fulfill the business requirements we are facing in our organization. So this is where, where things are really moving. And I think we've we've for at least for a very long time, we've we, haven't seen such a big change request or change for, for the entire things we're doing around access.

We have more identities, we have different types of access. We have a far more complex environment to deal with and we need to find answers, which help us to move forward step by step. So not a big bang. So usually where we throw out all the old stuff or where we build up a separate infrastructure, we have to enable our infrastructure to cover better. The sort of the today's use cases, more types of business partners, external access cloud, whatever, more Federation and so on.

Plus the, all the things which are popping up, apps, things and so on. So this is my introduction to this topic. And right now I want to hand over to Jason who will then talk about requirements, standards, technical components for future access management and Federation solutions for everyone on everything based on gateway approaches and illustrated by case status from customer best practice.

So Jason, I will make you to percenter. Now, it's your term. Thank you, Martin.

So yes, my name is Jason Macy. I'm the chief technical officer with forum systems. And I am going to build off some of the concepts that Martin has put forth with regard to effectively recognizing and realizing the need for agility and how we really accomplish this, this next phase of identity integration access management of Federation in, in the modern enterprise forum systems has been around for a number of years. We actually were established back in 2001. And our core focus is on delivering the API security gateway called forum century.

It is the foundation of which we've built a secure architecture product that abstracts the concepts of security identity, access control, data mediation, and single sign-on in a technology component that is built for agility in order to combine many of these things as we'll talk about today to accomplish these concepts of Federation and, and integration and collaboration of disparate technologies.

And this is the foundation really of coupling security concepts with identity and access control and Federation so that we can reduce risk posture while still recognizing business agility and integration capabilities using technology that's that's designed to accomplish that the goal of our identity Federation is effectively to normalize the best degree possible, the identity formats to, to maximize interoperability and to simplify this, the, the notion of connecting and enabling all of these different points of, of communication from the various devices, things and people, and, and ultimately the notion of Federation of course, is the seamlessness of the experience whereby credentials and information exchange can be done and accomplished in a secure way with a, with an experience of, of the, from the user's perspective of being seamless with regard to that actual user experience.

And so we're gonna talk about some of the foundational technologies that, that go into this and, and focus also on, from an SSO perspective, the most common two that are prevalent in the industry, which are SAML and, and OA.

So I, I wanna build off for the slide that Martin built up to in his presentation around the achieving access management and Federation through a more versatile and dynamic means by which to authenticate authorized and control access by way of effectively combining many of these different aspects that go into the achievement of Federation and access management with, with a risk posture as, as the core security concept in that notion of business enablement.

So with that, what I want to do is effectively focus on what it takes to accomplish this concept of, you know, dynamic run, time decision making. So if we take the requirements, I don't wanna break 'em down into really four primary components, the authentication component, the role access control component, the content, the information is actually being exchanged that pertains to these user's devices and things.

And finally, the Federation concepts and single sign on concepts of unifying, an ecosystem where the identity and information can be shared and delegated and, and achieve a sort of a unified experience, a seamless experience. So we're gonna take each of these and break them down into the technology concepts and that go into it, we'll start with authentication. So one of the things that has evolved over the landscape of computing in the last 10 years is that there are at least a framework of standards that have evolved with regard to identity formats.

Now it's still quite broad in nature, but at least it's based and founded in a set of fairly well known token variants. Now this can be within soap messages within XML messages, within rest patterns on H CTP protocols or JMS protocols. But ultimately it is framed to a large degree in a set of sort of known context, whereby that user token information with the ability to go across all of those variants and be able to extract the relevant information that identifies the system, the device, or the user that's effectively being requesting that access or that communication channel.

If we can unify the ability to extract those credentials, then what we want to do is we want to couple that with the appropriate infrastructure systems, where that are the policy holders of record for those users, this could be L a active directory, many of the IBM systems out there like site mind, Tivoli access manager, database systems, some repository generally that has been built up over time that identifies which users are allowed and, and what their credentials are in, in the validity capabilities of I of taking those user credentials outta those formats on the left and identifying them as valid and, and, and, and, and legitimate based on IBM system, infrastructure, databases, LDAP directory systems on the right, what that gives us is a user effectively, or a context of a user concept.

This may not always be a physical user, could be a B2B system, could be a thing or a device, but it identifies a characteristic that will, will call an authentication token or a user as our first step. That's. Our first necessity is to know who it is or what it is that's attempting to make this con connection attempting to make this request. And if we can unify that across those, those token formats, we can, we can consolidate that effort and call it authentication rather than worrying about the diversity and complexities of the varying technologies out there.

If we frame it in terms of the standards, we can now unify all those technologies by way of leveraging those formats and extracting the credentials from those formats. Once we've accomplished that, we've now got a user that's identified, which is attempting to make a request to obtain some information across some API or information border effectively going into an infrastructure to retrieve, you know, some information from an app or a Porwal or a service or, or, or a database things of that nature, where there's some kind of information exchange being presented for requests.

Now, now that we've identified the user, what we want to do is correlate that further by a way of figuring out what, what that user has rights and responsibilities roles, what groups and memberships that user belongs to permissions from that user. And this often requires going into the environment where some of that information needs to be looked up and, and, and, and aggregated. It could be in databases. It could be in, in repositories that that aggregate user rights and, and information. We talked about a active directory.

That's often coupled with other systems that has additional criterion, but ultimately bring those together. If we can take that user that we've now extracted across those relevant token formats and, and, and couple that with the ability to integrate with systems that identify additional characteristics about that user. Now we can make more intelligent role based decisions about where that user's allowed to go, what that user's allowed to do based on the user itself. So that's where role-based access controller.

Our back comes into our, our next piece of the puzzle on taking that identified user and determining and assessing the roles affiliated with that identified user. And that allows us and enables some concepts of, of enablement of those communication flows. But that isn't enough. We've got to go further to that. And so the next phase in analysis of this communication exchange and, and, and business integration is also looking at the content.

So here's where it's essential from a dynamic collaboration and integration perspective, not only to rely on a trusted user and, and, and roles based on the user, but it's also the content and information flow that, that, that, that feeds from that user, as, as Martin pointed out in, in his presentation, the users often, you know, a, a, a component that's coming in through either, you know, you know, cars, infrastructure, you know, devices, mobile phones, so users a part of it, but there's also the information that's coming in.

And out of that information border in that API, that we want to couple with the roles and, and identification, and, and also use the content and information flows that are going back and forth. Now, these also, fortunately in the modern era have evolved to be reasonably structured and standards based to improve interoperability and to enhance integration. And so a lot of this has evolved to a, a framework of standards that are normally based upon the kind of technology on the infrastructure side, as well as on the client side.

So you'll see, you know, rash, XML and JSON, primarily in mobile app data exchange. And you'll see in web browsers, similar kinds of concepts, mobile apps and browser technologies are actually quite similar in the actual information formats that they exchange and B2B infrastructures are structured effectively around.

So, so XML JS O where we can take, and, and if we can analyze that information exchange, what we can do in addition to the trusted user in the roles and responsibilities is take a look at the information exchange across those API boundaries at those connection points of, of, of integration and information exchange and hone in on the specific characteristics of those message exchanges in order to have a more versatile means of, of, of not just relying purely on a trusted user roles and responsibilities, but have a more granular means of tying that to the expected communication patterns that you want those users to, to have.

And what this provides is a deeper context of, of access control, but a more dynamic means of doing it by the user based on the user, rather than a static sort of universal user gets in and gets everything. This is a more dynamic way of coupling all of these concepts together, not only relying on user and, and, and authentication, but relying on the payload, very similar to airport security. If I'm going through airport security, my identification is checked and, and, and of course I'm identified by having a, a ticket to, to board a plane, but my, my bags are checked as well.

The, the, the, the context of, of the user needs to be coupled with the information that, that user's bringing with them in and, and extracting out. And so that's where content based access controls.

Another part of this dynamic enablement, where we're connecting by way of assurance of the information exchange, where we can allow or deny information flows so that we reduce the risk posture, but we still maintain that business agility and that data enablement and integration enablement at a more granular context by focusing also on the payload, on the information exchange that's being that's, that's being put forth to, to communicate.

So those three things then lead to the ability or necessity or desire to federate such that these varying types of identity formats that we talked about earlier that fold into some credential, some trusted credential, once we've established a trusted credential, then we Confederate that credential, which is the means to sort of delegate that that particular user has been authenticated through some trusted means and other systems through trust enablement, which we'll talk about in a moment how we accomplish that can then allow this user with that one set of credentials to gain access to many different types of infrastructure, many different types of ecosystems, where the seamlessness of the user experience after that initial login is abstracted from its ability to access these other types of infrastructure technologies through the means of Federation.

And so the, the whole concept here brings together all those earlier concepts in terms of what data formats and information flow, but ultimately gives the seamlessness of that initial authentication that carries with it, characteristics of the roles, characteristics of the user, where the content is obviously different across these different variants and, and, and those access control provisions are still applying, but we have a single credential that we can utilize and build a trust model whereby that then can be a much more seamless ecosystem of communication without suffering from any degradation of, of risk or, or ability to identify the user and enable the roles and responsibilities that those users are, are allowed to have within each of these different kinds of service endpoint environments.

The two primary means by which to accomplish that are SAML and OA. And for good reason, the SAML assertion security assertion markup language standard is developed is, is effectively a means to provide authentication authorization and attribute information about a user that has been authenticated using some trusted means such that we can then delegate that authentication to what we call a relying party or some other component infrastructure environment, where we we've built a trust model using PKA PKA and deg, in other words, digital signatures.

And PKA where we establish a trust that suggests if we, as the source of authentication in authorization have accurately and, and, and, and adequately authenticated and identified user, what we're then going to do is delegate that authorization so that other infrastructure and other systems can leverage that without having to have all the infrastructure to call into an active directory and IBM systems, and all those other things don't exist. Oftentimes if you're going out into the cloud or you're going to a trading partner, they're not gonna be able to access all the characteristics of users.

So we use things like Sam and oof, to provide information about that user and extend that authentication boundary, using the concepts of delegated authentication, where we're providing then, and, and, and building off from that initial credential a means to carry forward a, a, an assertion token, if you will, which is a, a set of information about that user. And this Sam in and of itself is quite robust and versatile. It's built off the concept of being able to be used in so concepts and, and XML.

And so as well as HTD P and, and HTML such that it's, it's quite versatile in nature in terms of being able to sort of provide that framework to, to, to pass forward credentials, to, to all those different kinds of environments. Similarly, oof, has, has gained in adoption quite significantly over the past few years, primarily driven out of mobile technologies and social media, where there's been very broad adoption for this notion called open authentication.

And again, this is a delegated authentication mechanism where we first establish some strong authentication mechanism where we've identified a user and then utilizing SSO O tokens or a, a means by which to delegate then that, that, that particular user's been authenticated in. And here are, you know, various criteria about that user and roles and capabilities that can then be provided through a trust model in a delegated way.

So both of these have have pros and cons, but ultimately the, these are the two primary means of achieving single sign on in Federation, out there in the industry through, through utilizing these, these two standards that can unify those concepts of a single authentication that can be extended to, to, to, to the cloud and to the, to trading partners to different ecosystems whereby that we, we can recognize going back to this, to this picture, we can recognize that once we've established that credential, we can then build that trust model of integration collaboration without making the user log in, in different environments, in different places over and over again.

So the seamlessness of the user experience coupled with the business agility of, of integration with different, with different systems is the goal of Federation founded within principles of, of these standards. And so taking all those concepts together, this feeds into the foundation of achieving access management and Federation by bringing all of these capabilities into an AB a single technology component that can abstract these functions from the actual data and services being accessed. The key concept around achieving this type of thing is by way of abstracting through architecture design.

What we can do is we can recognize the agility through boundary protection mechanisms whereby that particular necessity to in consume different services across different dispar data formats and, and different environments that, you know, from web portals to, to TOB systems, to web services, to mobile apps and the disparity of clients and all those different formats of data information, all those formats of identity tokens, unifying, the ability to consume and authenticate provide role-based access control functionality at a uniform centralized location in the communication pattern, identifying and inspecting content to couple with, and make more intelligent, contextual decisions about user and data enablement all then wrapped up in the ability to federate into enable that those credential capabilities and access control and contact capabilities and unify that.

And it means that enable then the Federation and, and single sign on capabilities. So abstracting all this out, the concepts of, of, of what, you know, we as a company providing the API security gateway is really focused on this concept of enablement of access management and Federation for the enterprise by way of consolidated technology that can unify those disparities of different clients and, and, and, and, and different client side integration points and different service points of communication.

Because if you consider the complexity of all of that, of course, as Martin said, it can, can be in, in the billions of, of, of, of different areas of complexity, but fortunately framed still in relevant characteristics when it comes to the actual token formats and information formats that are being exchanged. Those are actually framed in a more reasonable boundary where gateway technologies designed to broker specifically those variants and enable the access management and Federation of those capabilities.

So I'm gonna actually showcase it as an example where this is we've, we've done this in the industry, and, you know, we've done it over and over again in many, many, many different places, but figured I'd use this one in the interest of time as a, as a deployment reference in terms of what we've done to accomplish this, using these principles of Federation and access control. So in the United States, a project was launched back in about 2005, 2006, that has evolved over over the years until today called MEF modernization E file.

This was the largest software project ever developed in the United States. And it was effectively taking a paper based filing system for us tax returns to electronic tax filings and enablement of an electronic ecosystem of tax filing for all businesses and, and personal filings in the United States.

And this really brought to bear many of the concepts that we've discussed up to this point that that has required an interoperable capability that can unify, you know, thousands of different kinds of client technologies, coupled with the necessity to do identification in this case two factor identification. So we have a very necessary means of accurately identifying, you know, who is trying to communicate into the us treasury infrastructure looking and inspecting information.

So the content access control and content analytics that go into the data exchange the need to provide a, a more seamless experience for the bigger organizations here in the United States that actually are aggregating file entities like Intuit H and R block price. Water Cooper are the big ones in the us that are actually a, a sort of staging area for, for tax returns and they deliver end end consumer products. So in order for those organizations to deliver more seamless capabilities into the e-file infrastructure, we needed to build, they needed to have a single sign on capability.

And all this is the founding principle of all of this is these capabilities are built into a secure technology component is itself as accreditations and, and, and can't be compromised.

And so conceptually, it looks like this, the, the central gateway as an API gateway provides those capabilities of, of, of, of, of integrated Federation across many different infrastructure services presenting an integration point to, to the outside clients, the big ones, as well as the, the several thousand of the individual ones whereby we're providing all the capabilities around single sign-on sample assertion, validation, data validation, and effectively unifying that presentation of tax processing infrastructure.

But enabling that through more modern technologies whereby the infrastructure itself doesn't need to have any of the concepts of Sam assertion and single sign on and, and, and, and effectively identity token variants, that's all abstracted through architecture design at the gateway layer, such that it can be more agile about in, on ramping, new types of clients and new types of infrastructures without coupling that directly to the services.

And this builds back on those premises of those four, you know, primary requirements that were necessary to achieve this, this next phase of sort of Federation authentication access control, and unifying that at, at a technology layer in, in the network. So thank you for that. And I will turn it now back over to Martin. Thank you, Jason. And so let's directly continue with the Q and a, if we already have some questions here, and if you have additional questions, don't hesitate to enter them now so that we can pick them and answer them.

So I think our, the same question from two different people. So obviously one, we should pick first, the question is, are we not forgetting ID connect outside of someone else? Open ID connect is absolutely another consideration, open ID Deconnect and, and oof can, can actually be, sort of are, are, I think are converging in the industry, but absolutely that is another, another up and coming adopted capability though.

I, I, I still see that as, as a, as a third tier option to, in terms of adoption, because if you think about the major social media outlets, such as Google, Facebook, LinkedIn, Salesforce, all of those integration points have, have out the box oof and SAML connectors. And so those are, are well established capabilities that infrastructure vendors have already built into their stacks.

And so ultimately that it lends itself often when, when actually performing the integrations to, to choose those technologies since it's, it, it provides a, a broader versatility of, of existing technologies and integration points that have already adopted those as, as sort of existing capabilities. Hmm. Okay. When We are already talking about standards, what, what are your expectations regarding the upcoming a or UMAS standard? So user managed access, which also fits into this bigger O and open ID connect picture.

Well, this is an affirmation of the, of the, of the dynamic nature of, of, of, of business agility and all of these, all these things continue to evolve. It's, it's an, it's an important aspect, really, of what our concepts are stepping back in terms of, of gateway technology itself.

The concept of gateway technology is the ability to abstract the decision points of, of integration and, and, and user authentication and, and access control decision making in ways that can be more agile with not only existing business landscape, but the evolutionary nature of computing and, and, and, and, and standard adoption, so that we get away from the notion of tightly coupling systems together where being more agile and adopting of, of, of new innovative standards becomes more difficult because we have too many interconnecting points of, of legacy and modern systems.

So really the concept of, of, of a as well as other emerging standards is that through architecture, design of gateway technology, you get the advantages of, of, of, of an extracted layer whereby those innovative characteristics and can, can evolve and independent of sort of direct infrastructure, which can take advantage of that. And that's kind of how we look at this. We're always looking at emerging standards and looking at emerging capabilities, and this is always an ever evolving landscape.

So that's really where we, we focus on the concepts of, of, of architecture design and abstraction to achieve that agility in those things that not only apply today, but will apply in the, in the evolving landscape of comput. Okay, perfect.

So APIs, there's a sort of pretty short question. The question in fact says API available to public. This question came up when you talked about the APIs. So not sure whether the context is more APIs your system provides or APIs managed by your system. So APIs is a very interesting terminology that has evolved over the, over the years, but ultimately the API represents a communication point of data enablement of, of enabling communication channel to some service or data.

And that API public facing could be a different nature of API than the exact same service or exact same data consumed by internal employees or trusted a business partner environment. So think about an API as a level of abstraction that enables you to apply more or less identity access control and security in order to sort of at that border at that, at that API layer enable or not enable that communication pattern to the service. And so by doing that, you know, public APIs or private APIs are, are, are conceptually based upon what kinds of levels of, of security and, and identity access control.

You want to layer upon it in order to enable that communication pattern. And, and obviously that's different, depending on the nature of data, if you're talking about public kind of information like weather or things of that nature, it might be different than exposing, you know, more sensitive information like, you know, online banking information or things of that nature.

So APIs, whether public facing or private facing are that exact concept of being able to abstract the, the risk posture identification from the service. So the service can do what the service does, but enabling access to that through the API is, is what you can achieve, where you can achieve that, that agility and, and, and broader spectrum of integration. So there's a way of some more background on those questions.

So it, it's also about the API provided by your product. So are they available to public? Is there support for the API and common development environment?

So, and what, what, what does it need if you want to build an app to use the product? So how much do you need to reflect your sort of the firm system APIs, cetera, maybe you can dive a little bit deeper into that As I can. I can speak to that directly. The forum systems API is basically can be a direct mirror of what exactly the intended API was. So the concept is the forum C is, is a virtual API infrastructure, meaning that it's meant to present an API to a consumer in exact manner that the, the service itself was meant to be communicated.

So the, the, the nature of gateway is seamless. The client doesn't know, gateway even exists, and neither does the service for that matter because it's a broker of information exchanged. It presents the virtual API to the consumer in, in, in the manner in which your service wants to present it. So you wanna rest API, mobile API, web Porwal API.

So API, HTML, API, any of those variants are just point and click policy enablements. So those API creation points are based upon the kind of service that you're exposing communication to. But the gateway itself is an intermediary it's it's to a client it's it's, it's presenting itself as the virtual service, and it's brokering on behalf of the client. So the service still thinks it's talking to the client.

So in, in both cases, it's actually meant to be a seamless intermediary that gives you that, that, that centralized location to, to extend those APIs. So things like if I have a soap service and I want to build a mobile app, I can go to the gateway and expose rest API, and a soap API for that service. So those are the, the other aspects that conceptually the abstraction layer of a gateway give you a much broader flexibility of enabling and, and, and adding APIs to system infrastructure that may otherwise have never been able to expose their data and services in that manner. Okay.

There's another question. I think I will answer that for provide my answer first, then you can add to this, or, or to my answer in parts, whatever. So if all major layers use open ID connect for interconnecting web apps, it's another sign that SAML is out of date. So my view on that is Sam is, is clearly something which is moving more towards, I would say, a legacy state.

However, there are a number of use cases, particularly if you look up business to business communication, where it's more for, for scenarios where it's more one to one scenario, federating parties, then Sam still has a very important role, and Sam will continue to be important. Because for instance, if you look at authentication to cloud services, then Sam is currently the defect of standards. So some so open ID connect and together are clearly gaining ground, but Sam will is here to stay.

And it's probably here to stay for a very, very long time with another option right now, or other options for, for different use case. But basically depends on the use case others are winning ground, but Sam state that's my view on it occasion.

Yeah, I would agree with that. I think what we are seeing is an emergence of an extension to OAuth, which is effectively bringing the, some of the concepts of Sam closer to OAuth, where Sam gives those, the ability of that strong authentication, the PKI component, the data security component of digital signature trust with PKI and effectively. What we're seeing is sort of a convergence.

And the, the idea is you want more flexible open capabilities, but you also need to sort of wrap that up in an additional security layer of, of, you know, reduction of, of, of the, of threat vectors and capabilities of, you know, sort of, you know, of, you know, not being able to protect tokens were open IDs, sort of coming, coming into that and trying to really take Ola and sort of move it in that direction of a little more wrapped up security and more of the concepts of what really SAML gives you, which is a digital signed capability through strong PKI trust, public private, key infrastructure trust.

That is a strong foundation of, of the trust model, but at, yeah, all these things that are evolving over time, stick around for a long time. And as, as Martin said, you know, in particular in so environments and legacy environments SAML is absolutely, you know, a foundational standard, but the web SSO profile and the ability to embed SS SAML within base 64 through simple HCB redirects is also given it a lot of adoption capability also in the mobile and Porwal and cloud world.

But, but certainly there's lots of space for, for these these standards to, to accomplish the goal of secure delegated authentication. Okay. And there's one final question I think here, which is more targeted to me. So it's about how to access the related research displayed. There are various options. So you can for time limit time, limited period, access some parts of our research using the select access, which you will find directly on, on as a right top of our website.

And there various types of subscriptions, you can then have to access full access to have access, to advise service addition or to preconfigured best practices, practices such as standard identity management processes, RFIs, and others types of content we are building. So there's a number of services we have and the basic, so the initial access to some part of the related research available through the select access sort of a trial type of access. And then there's a number of subscriptions. Hope that answer questions. So I think we are done done with all the questions.

So thank you to all the attendees for listening to this group, call webinar. Thank you, Jason, for your presentation on all the information you provided in response to the various questions and hope to see you all in one of our upcoming webinars or at the European identity in cloud conference in may. Thank you.

Like this?

Don't like this?

Why don't you like this?

Access Management and Federation for the Agile, Connected Enterprise