Okay, good afternoon. My name is mark Vamal. I'm the founder actually, and CEO of trust builder corporation. We're actually a new, old kit on the block that doesn't, I don't point to my age, by the way, I'm pointing to something else. We we've been around in IM for almost 20 years. We started as another name, secure it as a specialized integrator in IM at the time that the time the term identity and access management didn't even exist yet over time, we evolved into a product vendor. And in last December, we transferred the company into, into a product company and, and baptized the trust builder corporation, the product being, being trust buildup, our solution is not new. It has been around already for some time in various industry areas, including financial institutions, government telecom, distribution, industry, industrial companies, and the like we have by now, we support over 40 million users to our solutions.
So that is not new. It's just the, the shape of the company that we have changed. And, and we are now in the process of expanding our reach across Europe and the USA in what area of IM are we working? Well, I try to give an overview of the scope of identity and access management is of course more details behind that. But in, in general, I can say we, we stick to the part that you see in green here, which is the identity and access management across organizations and from the organizations to the external world, from the external world to the organizations, that is the area where we specialize as well for APIs, web, and mobile. So it's not just about API. It is includes API, but it's not just about API. So let me go back a little bit in time to start. This is a picture that goes some 15 plus years ago, back in time.
Yeah. Where people needed access to applications that were under an organization's control within the organization's parameter. And in order to allow this, this single sign on to these applications, the identities of the people need to be validated. Yeah. And for that repositories were required. And depending on the use case, they might organizations may use several type of repositories, like active directory, of course, always databases or up type of directories and using different methods to validate the identity in other terms authentication. And again, the choice of a, a matter to authenticate a person is there is not a one size fits all solution. It is, it doesn't only depend on the strength during the assurance level of a particular matter. It's also the cost of ownership, which is, which is important for, for, for our, our customers. It's the user experiences more and more users become the king.
So we have to make it as easy and as transparent for them as possibly. And then regulations of course have an input as well. Now that model has been around for some time and we knew it very well, but we all know that the world is changing rapidly. Applications are no longer, only under the organization's control. They may reside somewhere in the cloud as a service provided by third parties, or they may be managed by a partner, supplier, reseller, whatever type of partner an organization has. And the same for identities, the identities, which used to be under the control and managed by the organizations in my, in the first part of my picture, even for external users, identities were managed by the organization themself. We see a tendency that identities will more and more be under control of the user, of course, and managed by somewhere a party that is not the organization itself.
That requires another approach to, to the access management part of it, of course, to the right, the right side of this picture. We are talking about mostly a Federation, but Federation isn't that, all that simple as the word says, there are multiple protocols. We all like in it. We all like have multiple solutions for the same to solve the same problem. So there are multiple protocols around like SAML. You have ol you have open ID connect, you have Ws Federation. So, and, and different IDPs and SPS use different protocols. They are not always using the same. In addition, the profiles that used can be very different depending on the provider. So it, it's not that simple to, to mix and match all these. And you have to also be able to map these and, and, and act as some kind of a bridge, a hub and a bridge to, to intermix these protocols between various IDPs and, and SPS.
That is becoming very, very important. In addition, the, the way users and identities are presented, presented are not necessarily the way the target applications know them. So some mapping of these, of, of these tokens or IDs to something that the target environment understands and, and knows about users is becoming very, very important. This is where the area where we focus on with our trust builder solution, by the way, and our vision of how this can be accomplished best is ex explained in the same in, in, in the next slide, we believe that a policy based approach is the right and potentially the only way to accommodate this complex world policies in order to provide organizations, flexibility, flexibility in the choice of what type of mechanisms will be used, the left and right, what, where information of the user is located, but also policies in, in terms of how can we make it as transparent as possible for the end users end users don't want to get involved with all this complexity must be simple for them straightforward and easy to use that's their requirement yet the organization wants it to be secure.
Of course. So by, by using a policy based approach, looking at also not just what type of credentials will be used, where the data will be of the user, but also context, context has become very, very important. It's not just about only the user who is that user? What did he want to do? But also what type of platform is he using? Is he using a platform he has been using before? Is it the same? Is it a different one? What's his location? What was his location an hour ago? And, and all kind of criteria parameters that we generally call attributes that can be taken into account in the decision making of what you will allow that user to do. And in what way his identity will be validated. And there's where the, an aback approach comes to the rescue. Because with an aback approach, you can decide in real time, at the time a user wants to start a session.
You can decide on the basis of different attributes, what you will and will not allow in what way is in these circumstances. The most appropriate way to validate is identity. What type of method for authentication should be invoked from in that particular situation? What kind of access afterwards, you will provide that vision, given the circumstances, or maybe you will force him to step up to a higher assurance level of education in order to have certain rights. So all this can be based, can be based on attributes. And by the way, a group overall is an attribute as well. And predefined set of attributes can be converted into a role as well. So the one doesn't exclude the other, but there is a main difference. I mean, if, if you look back in time, when, when our back came to, came to place, robust access control or group with Texas control, for that matter, what we did is look at people in organizations or wherever they were look at what departments or in what projects they're working.
I mean, gathering a number of parameters and decide, oh yeah. In these circumstances, it belongs to that role. Well, what is, and, and in many cases that ended up in more roles than people because you have so many combination possible looking back at it, why did we convert a very dynamic level into a static level? Because roles in Gupta static way of managing, you can more easily go back to the attributes and say, well, at the time he wants to do something, I'll look at these different attributes and then I'll decide, and I'll take in addition, other attributes about context. And so wanting to account to decide what I will allow this user to do at this stage, in what way I will authenticate that user in what way, and where will I get the information about, about the, the user, about the data of the user, his credentials and so on. So this in, in our view is a much more dynamic and, and much more risk sensitive way of dealing with the, the access rights. I mainly talked about the security services up till now, but of course, it's, it's not just that you need also ways to, to allow easy onboarding of, of users, applications, privileges, and, and the same for the self-service users. As certainly in the GDPR context, you must allow users to control his own ID. And that it seems at first sight easy. But I talked about earlier about the, the context of B2B B2C, but it's not only that it also B2B to C and B2B to E
We see much more multi-tier environments coming up where a company works with a partner who has done people or, or customers from that partner. And, and you need to provide a solution that will provide that user control of this ID across the tiers in, in, and that is not as simple as it sounds finally. And what, what we see is that organizations differ. In some cases you need gooey, but people can actually use an interface to, to do what they have to do. In other cases, APIs may be required so that it can easily be integrated into existing systems management environment. And so on what we did is actually provide the APIs and build our gooey on top of the same APIs, finally, being a central component in, in the access management environment, form people, you always, you, you gather a lot of information which can be useful for, for, by logging for useful, for auditing, for monitoring, for analysis, reporting about what is happening in addition. And certainly in the API context, you need also to provide control over priorities in, in, in terms of, at allocating the necessary to specific type of, of connections. That's not that obvious for web type of access, but in, in API environment, it is, it is crucial.
I have a slide on a couple of business cases, but I don't have the time to go deeper into, into the, in 20 minutes. I cannot cover them. We have, we have more in depth information about these cases. Our boot is just next door. So if you have a particular interest in one of the, the, the cases mentioned here, you can, you can come and, and visit us.
Okay.
We had some time for questions, or I'm sorry. Have I asked at the end? No,
Just final round up about the highlights of the, of, of our approach. What you should do is that the system is able to adapt to the customer's security and business policies, not way around, not the other way around. We have seen too much examples where actually the, the customer has to adapt the way he is working to a particular solution, because it can't be done. Otherwise we've taken a different, a totally different approach by this policy based approach. We've said, you missed the customer. You say what policy you want to implement, both from a security and business perspective. And we are able to take, to set the system in a way that you want it. That is very important in terms of, will I do local application, or will I use Federation? What type of technology will be, will be used for what type of application and for what type of user community, for instance, the other observation is that this allows for progressively centralized security policies. It makes the application simply because they don't, they don't have to be to worry about this anymore, but it also, from an it perspective, allows it to get more control and standardize and force corporate policies. Upon application level providers,
We've adapted an approach non-res approach. You could call it. We, we think that synchronizing databases, repository duplicating them is not really the good way to go. We think you're better have a solution that is able to, to use the, the, the real source of the information instead of duplicating it again. So we don't, we don't, we don't centralize identities. We don't duplicate or synchronize them. We just use the repositories where they are at the time being at the time we needed to, we reach out to the repositories be that ID of any ID of any other or any other environment that is needed in that, in that use case. Finally, we wanted to provide a solution that is able to integrate both cloud and on-premise services, because there will be around still for a long time. It's not all about cloud and, and, and, and the, like that the local, the local applications will still be around for, for quite an number of time. And that is able to serve the needs for both web mobile and API type application with one single solution. That was our, that was our design goal by that I'm rest
Resting. Thank you for your, thank you for your attention. If there are questions, if we are still time,
I have time for one question who, any question that we have, what will I have one? Sure. I noticed on your slide where you had a number of identity provider services, but only one arrow to the service provider. What protocols do you support on that service provider?
Well, there are different protocols, like, like SAML, oh, out open ID connect with Federation and service providers may need, may support one or combination of protocols or, and others may support other, other type of same for identity providers. Identity providers will also, depending on who they are. I mean, Google authenticator is oh, out. Yeah.
So you support multiple
Protocols. Yeah. We support and we make the bridge because given service provider is not necessarily using the same protocol as an identity provider. So we are acting as an identity hub and bridge, and actually support different protocols at both sides and make the link based on policies between those two. Great.
Thank you. Okay. Will you thank mark please for his presentation? Thank you.
