Panel | Identity vs Authorization - Where to Draw the Line

So I'm sitting here because I'm the only one on site, but we have two colleagues remotely. I will just firmly introduce you. So we have one histo. I I'm hoping to pronouncing your name right. Because it's quite difficult for me. He's a solution architect from KPMG and Martin mano software architect, co builder international. The panel will be about identity versus authorization, where to draw the line. So maybe you are hearing us good.
Hello everyone. Yeah, I hear you. Perfect. And how it's on my end.
Great. So maybe you can say a short sentence about yourself, introducing your, what you are doing at your company, and then handing over to your colleague.
Sure. Thanks. My name is Christo Christo I'm solution architect at KPMG. I've been in the software industry quite many years. I've been in different roles there, but I have only always keep the strong focus on quote and on security topics. So I found this conference really useful place to make the trends and to, to announce the next directions, the future proof in those areas. So in short, we'll talk about identity and authorization. It's a very widely adopted topic. However, there some misconceptions or some aspects that are usually taken for granted and we will go deeper into them
At Martin. What about you?
Hello, I'm Martin man of I'm software architected COPI. I've been in the software industry for 10 years in, in different roles. And in the recent years we have moved successfully our portfolio into the qu and I find today's topic quite interesting because even though is quite mature. Now I see every day some misconceptions about it and about authorization itself. And I hope that this discussion will shed some light onto that.
Great to hear that. So the topic is talking about identity versus authorization. So my first question to you both would be isn't an authorization protocol or, and wouldn't or scope be a great instrument to replace roles.
Well, so all is of course, on neutralization protocol and it allows you the user to grant access to your private resources on one side, which is the resource server to another side, which is the qu and in this process, as you can see, there is no authentication happening. And this is one of the common misconception that while authentication protocol, it is not, it, it is in fact authorization protocol and maybe better because authorization, delegation, protocol, sorry, but the fact that it was that open ID connect wise on it causes maybe some misconceptions and or in the process of how there maybe even not, not user present in some ground types like qu credentials or resource on password credentials, there, there maybe not even authentication happening. So an access token is, is acquired by the quant application. And this access token is, is different that the different set of credentials than that, that the user and the qu the resource owner gets. So the prop all out makes a difference between between the resource owner and the quant. And that's, that's important thing because in the past, such a difference could not be made.
Great to hear that from your side Martin. So his, are you agreeing on your panel colleague or do you see this answer in a different way?
I fully agree. Actually it's very well said that there are two types of credentials and the access token actually is the credentials for the client. Then user izing, the client and client receives the, his, it sets of credential, the access token, but the access token is not representing the user, the user credentials, the user authorization is something else. So in fact, a better name would be a delegation protocol. And ti is dealing with the authorization of the client who, who receives permissions from end user, who, who has been delegated permissions in order to access the protected results. And if I should go further to the second part of the question about the, the roles and the scopes fact, the scopes are the permissions for the client by, by the scopes, the ized to access the protected resource and the roles are the means to Ize the user, him or herself.
I totally agree on that. And also your answer leads directly to my next question for your both. So we talked about, or, or, and the first question was, is it really a protocol? And your both agreed on that. So besides a few differences, but if we are looking at that is, or, or always about identity, but you always mentioned it before ISTA, that it's just either authorizing or delegating example, looking at an app service acting on behalf of a user. What's your opinion on that?
Yeah, actually this is maybe the most important misconception about there are two types of authorization and one type is the quant authorization. And then end user is delegating permissions on and the ized on behalf of the user. And it could be even a qu without the user with, within the Quan credential for, or even in the arrow C there may not be a user. It could be a programmatic implementation, even though it's totally bad practice. And on the other hand, we have the, the user, the user who should be authorized, but if we just close our eyes for a moment and remember the so common architecture diagram for authorization, we sees between the end user, the client, the authorization server, and the protected resource that is hosted on the resource server. And then we'll see that we are accessing the authorization server. We are requesting the access token we received, and then we are passing it to the, we, we expected that step when we receive the access token that we, we will receive the user authorization rules as well, but the best sector who can and actually deal only, and the best sector who can verify those user authorization rules is the protected resource on the resource server.
The identity provider by itself can know and hold the complex logic of business logic authorization. It may be complex enough and it may not be deterministic in each and every occasion in each and every usage, for example, different clients and APIs may use may different user authorization rules. And then we come to the scenario that we should make a double check on the resource server in order to verify the user authorization rules there. So we are, we are coding costs in, in a problem and we are doing it, these double checks. And if we put these authorization rules in the authorization server, and, and I know it, it sounds a little bit strange after it's an authorization server, it's called authorization server. Why, why not all the authorization logic should be there, but actually all is dealing with the client authorization, not the user authorization
You're already noted Martin. So you're agreeing on your colleague from his, or is there anything to add from your side?
Yeah, I totally agree with Kir and yeah, the, the, the difference between quant and user authorization is that you may, you may give your permission. You gave, you may say, okay to quant to use this resources on a resource server, but it, it doesn't mean in, in any ways that you have those permissions. So this is that you have to do bot user and qu authorization and all gives you qu authorization and the user authorization. You should handle it. I should handle it another way.
Interesting. So we talked before now about if, or is a protocol about the identity part about authorization and delegation. And before when I, when I looked at the topic, I thought maybe the, could it be that maybe roles are not the right concepts looking at identity versus authorization here? And should we think maybe in simple grouping or more over in policies, we also had different discussions today at different panels about maybe that the policies could be more the solutions for our problems. If I think about identity observation,
Yeah. Maybe before going into the roles and the policies we should mention the foundations, all it, it's the identity, the identity list down and everything is on top of it. And we are using both for authentication or authorization and for different types of implementation of the authorization. It could be withdrawal or with policies, but the identities, the foundations, the identity consists of claims. So we, we say something is true. We claim that my name is Christo Christo, and yeah, claims should be, should be always true, should be actually the identity should, should be mutable. It should be mutable at least throughout the session and the identity and the claims in an access token should be correct in each. And every scenario that they're used, we should not be in a situation. For example, having an access token with claims in it, and some of the claims be irrelevant or even wrong, if a certain application or client is using the access token.
But if I may use an example from the real world, it's the, the also the building box for role based access security is why adopted, but it's very important where to put the roles and how to use them. For example, if we take the board game bank, which was wild west team based card game, we used to play with my friends in university. You have a sheriff there, you have one or two deputy sheriffs. You have a couple of Outlaws and you may have Renegade as well. So each and every player in throughout the game has one role. And the role is deterministic throughout the whole game. You are on only in one role. So this means that throughout the whole session, you have only one role and your identity is linked to this role. So in this case, we see that a simple example with simple words will lead us to, to put the roles into the identity, but we should be very careful with this because if we take the real life as an example this morning, it was the first day of school for my son.
And there were a lot of emotions. I, I was in a role proud and excited father. And now I am in a role speaker on security topics. But meanwhile, I was, I was in a row of an architect and the employee for my company and the weekend, I may be in a row of a football fan or a hobby musician. So none of this is written in my identity. None of this is written down in my identity card. It's only my name, my date of birth, et cetera, but there's not written that I'm father or hobby musician or architect, etcetera, because those roles, they're not deterministic within the context. So if the roles are changing or they're getting too much, it it's strongly advisable to keep them outside of the identity. And this is on the part of the roles, even though it's, there are other means to achieve better and more dynamic authorization. Arabic is still widely adopted.
Great answer. So Martin, would you like to add something or should we go on to directly what history pointed out at the end?
Yeah, I, I, I just want to add that our back pec or attribute based access control or policy based access control, there is no, there is no the right choice, the right choice is according to the use case. So if you want to, to go on the way to the zero trust approach, yeah. They are dynamic and they could be better. However, the important thing here that it is the user authorization and you should handle it somehow.
Great. So you both talked about near last sentence about best practices, examples, how to shoot, how, how we should tackle that problem. And that leads also to my last question. So what we maybe requirements for best practices so that we can start implementing such things we talked about. Maybe we, we grabbing up your example, his and going on to explaining a bit before we answer session.
Yeah. For, for example, one key thing to keep in mind takeaway from here is that we should keep the identity clean immutable to be aware what we put in there, because it is the foundation. And after that, this will lead to problems. And another thing is to make analysis of the roles and make a triage, whether to put them and to link them to the identity, because it is always easier to inject a claim when it's needed than to remove one.
So, and maybe you have also an example or like a best practice from your side Martin, how we should tackle this implementation. If we want to do it
There for me, the most important thing is to understand the, the concepts and the basics and to, to make us a difference. And to know that client and user authorization are two different things and to use the proper technology for them. And yeah, as Chris said, not, not putting anything more than identity, then the identity should be clear, not putting permission. So brow in some cases and keep the tokens clean and small.
Great. So I've looked at it. So when we have at the no online questions at the moment, so I'm looking at the onsite. People may be having a questions here. So if yes, please raise your hand. Okay. I see no question. So maybe from you two, your key takeaway, beginning with Martin, from our audience, before we are getting you an applause for our short panel, what would be like the thing you would give in one or two sentences for our audience on the way?
Okay. So yeah, all out this authorization protocol, but the better name is a delegation protocol and you, we should, everyone should understand this and to use it right. And, and yeah, the client and user authorization are two important things to, to, to have and identity. Maybe the identity should, should be clean and immutable basis
For right statement. Of course. Thank you, Martin SOTA, what is your key takeaway key takeaway for audience
On top of Martin words? I would say, yeah, the difference between quant user authorization, for sure. The most important key takeaway, according to me as well. And also if we understand the concepts and there maybe they may see small details or we take them for granted, but they can, can get us to big troubles in time and scale. If we understand those concepts and basics, after that, we can go with, we can go with attribute, access control with policy based access control to, to, to get Porwal to the zero trust concept. But, but we should understand the, yeah. The basic principles,
Great. Two sentences and statements. So I think you're also deserving a small applause from our side, of course. So because it's very lately also today we are allow at the end of the session and from my side, all, this is also my last session today. Thank you. That you've been online here and maybe we are seeing again next year, maybe onsite in Berlin at the EIC 2020 wish you nice evening. And that we had this panel today. Thank you very much, Mr. Me and Martin.
Thank you. Thank you.