Assignment Based Access

Thank you very much. This is actually my 10 year anniversary of speaking at Yesi, which is a little bit scary. So my name is Martin Sand, I'm the I am product lead at ikea, which is a part of Ikea modern company. And today I'm talking about assignment test access. So when I was pitching this, this talk, I realized a couple of weeks ago that you could see this as another, you know, feedback R back on, but it's actually not about that at all.

So in initial talk here, we talked about the strategy of how to have the different parts of an IM stack and how to explain that to the business, how to prioritize different parts. Here we are actually gonna go dive down into a business process and how to solve a specific problem that your business presents to you. And after this we have a good talk about sap, which I'm looking forward to, but before between you and the SAP is me and the assignment based access. So what is assignment based access?

Well, what Im organizations or identity partner organizations mostly do is joiner movie lever. Now join is usually driven by the simple fact that, you know, the business hires someone as an employee or a contractor and they need to start working. So usually the joiner flows are motivated by the simple fact that if you don't get that working, the manager of the joiner will show up up at your desk sooner or later and ask, where is my joiner? So usually you get that working. The lever part is usually motivated either by the CISO is asking, why are these people who left us not leaving us?

Or it can be by the auditors. Continue ask the same question. Why did these people not leave?

We have, we got lots of of plans sitting in your systems. But again, there's a very strong motivator to do this. Actually could argue that the lever part is the reason why we have an IM industry at all. Because a lot of the initial drive this came out Sabras Oxley back in the 2000, 4,006 time span. Now the the mover case is a little bit kind of more squishy. Movers can have lots of different reason why it's not working. Could be the IM side, could be someone else's Porwal.

But often if it doesn't work, at some point the managers or someone who needs someone to do something will find you and your team. So you have to solve it. So let's talk about a concrete example and typical enterprise architecture. And this is not a very complex case. It's probably a mid-size complex. You have two different lines of business.

Alpha, beta, you got the mother layer where the identities are born, typically in HR systems could of course be contract management system of different kinds, et cetera. You have an identity layer, couple of different identity management systems put in sale point on one identity as an example. That could be something else. Of course most cases you have on an active director layer, most enterprises, I've actually never, I don't think I've ever seen an enterprise that doesn't have an active directory somewhere.

It's not everywhere, but usually somewhere unless you're extremely modern and do everything in Asher or something like that. And then a cloud layer. And in this case you have three ads, which is not that much. A lot of companies have 2080s and to to as eighties. And the idea is to have these different groups of people, which are the different, let's call 'em ppe, the different PPE suppose was supposed to go to right places. So you have, you know, groups that are quite simple like the the blacked there.

They go into sale point, they go into brand ace ed and get pre reacted into the, the brand A or the the business line ace abstract directory. And you have others like the, the yellow ones that do the same kind of journey but end up in the, in the live business beta. And then you have the, the kind of complex things like the the blue ones who end up in two different like directories and then it's important that you correct them to the right Azure 80. So how many of you have seen things like this in your, your reality? Does this speak to your reality as well? Good.

I didn't invent something very special. So you have a business challenge. So you had this beautiful picture and then the business changes. So brand A is not doing so well, that's not good.

So, but the good news is that brand D is doing well. So business would like to move people from brand A to Brandi. Now we could of course fire the people from Brande, move them to Brandi, but that is likely gonna be quite impactful. And you know, we have to negotiate with the unions and all kinds of stuff. So you really don't want to do that. So we have a mover case, we want to move resources from brand A.

Now we are not moving them fully because they're still living in the brand a's motor system in the HR systems, but we want them to get access to resources systems that are in the brand D part of the graph. So how do we do this?

Well, many options. You get hungry, you want to buy meatballs, now you go to Ikea and buy an entire car. So on our menu today is geo identities, federations, and assure b2b.

Now, like always there is probably lots of other ways to do it, but it's are three things that I've usually been using in my, in my implementations. So let's talk about these options and what they mean and what the challenge you have when you implement them. So let's start with dual identities. Well the idea here is that well we ask, give them two identities what could go wrong? So we have the, the black plural piece up in the left, upper left corner. They now need to be in the lower right corner as directory and in the the ad here as well, the beta ad.

They also need their previous access because they're still in the, in for example in the HR system of business A. So they need their access in the existing systems. So what we've done now is that we created two identities and that, you know, it's not a huge amount of work, you just changed some of the logic in some places and suddenly you break the next identity as long as you don't get any naming convention problems of course with you sometimes do, but other than that you should be fine. Well let's talk about this. Why are dual entities bad?

Well, one is user experience. So your poor end users are gonna have two identities and it's not entirely clear what that means to them. And the amount of time I've spent trying to explain why, well you have two identities. So which identity do you want me to fix That is much more than what I like to think about. Password resets. Normally you have problem with password resets and if you reset the wrong password, then becomes easily 10 times the amount of effort. Of course you can have automated password reset systems, et cetera.

But for a lot of users, especially if you're multiple identities, it just gets very, very confusing. So they're gonna call the help desk and then you're gonna have the 70, 80, 90 euros a pop cost. So that's a major disadvantage. If you look, if you're in a decently modern setup, you're gonna have a number of things that you pay for proactive user a month. So there is some stuff that costs 20 euros per user a month. If you have a thousand of these dual users that's 20 k a month, at some point the the financial department is gonna come and talk to you and say, mm, this is not so ideal.

Can you do something about this? If you're a bit more, more conventional in your setup, you are even gonna have dual laptops because you are going to need get different environments. And business might accept this for a small group of people for a small amount of time. But you know, after the first six months or something, you're gonna start getting calls. They're gonna say, why is my user having to log around two laptops? And if you look at the cost level, you know the 20 extra years per month per user is expensive. You have thousand users.

If you have to get on two laptops, that's gonna be absurdly expensive if you're talking about hundreds or thousands of users over a long time. So this is not an ideal solution. These two animals here is from our range. They are the, the shark and the the crocodile. There's a very cute Indonesian folk tale about the shark that run the rules. The sea and the, the crocodile that run that rules the land and they're fighting. It's available on YouTube.

What happens when you put the, the cute shark and the cute crocodile into a little girl's room and how they come together to clean the girls' room in the night, recommend it. So next option federations. And this is a quite good option if you are a, a major corporation leveraging federations to not having to provision identities in different places is it's a quite neat solutions, but it comes to certain disadvantages and things you should know about. So one is that not all applications support multiple ADPs. So sometimes they just export one idp. That's not good.

Obviously if you have the federation just built on business line alpha and don't have it for beta, then you have to federate all the extra applications. May not be a huge deal, but cost and effort, something that if you are a larger enterprise where you have this kind of split virtual IDPs are quite useful animals cause a lot of, of, if you have a thousand plus applications that you federate to, you know, 5%, 10% is not gonna be able to support multiple IDPs. There's quite a lot of good solutions available from this ping for example. Can I help you with that?

There are some applications that don't support multiple, multiple federations no matter what you do. For example, the the power platform they require Azure B2B account will not work. Another classical example is that lash stack, which has a lot of very, very complex complexities in its in its setup. If you have to support that lash, see if you can avoid it and then you take a very deep breath and then you fix it. One important factor is the user experience When you do access request. So if you do rule based, of course you can just change your rules and provision the new stuff.

But if you do request based, it is not self-evident that users in group A can actually even access the access request Porwal of line of business B. So either you have to add the applications to the X request for A or you have to add an ability for the end users to request in the request Porwal of line of business B. Now even if you do the, the latter one, even if that solves the problem, it does become very complex if you have, especially if you have like 3, 4, 5 lines of businesses.

The, the thickness of the user access requests, manuals in some cases, you know, if you're from here then you do this, this. If you're from there, you do that, that can become very thick. And of course it's a, it's a major extra workload and friction for your end users assure B2B accounts. This is a quite good solution to have in your pocket. And we see this is being used more and more by more and more, more enterprises. So what it basically gives you is a chance to give a presence in the non-home Azure. One thing to consider is that the B2B accounts will be very, very thin.

They will have very few attributes. So if your application needs a lot of attributes, they will not be able to get them out of that. Again here you can have the virtual IDPs might help. There's also improvements just coming in on the, on the Azure side that you might want to leverage for this as well. Access request again can be tricky. How are these B2B users are supposed to request access? They don't have access to the Porwal, the portals. Another nice feature from Microsoft that just have been released is they the Azure, Azure cross tenant sync.

So Mr, you don't have to do the invites either, you know, have to manually do the invites or seem automatic or write complex things yourself. The cross sync. Can I help you with this? So just to give a concrete example of, of the crossy, we, here again here we basically solve the problem by syncing the users using B2B accounts between the Azure tenants does of course not do anything if the problem was actually that users needed to be in active directories. But This is why you like to put your applications to the cloud layer.

So we have a few minutes left for questions, but thank you for listening and I hope that this helped a bit with some of the challenge us in the future. Thank you very much. So we are really into real life examples of how IGA works out right now and that what you're working on, so I think you are currently implementing that.

I, I assume at least, what are your key challenges by achieving that? So and how do you get the team, the people on board, the, the change management part of it?

Yeah, so this is kind of part of the, the identity weave overall. I think the, the key challenge is trying to to go out to the business and explain why is this important and why do we need these capabilities? And one other big challenge is that if you look at for many enterprises, you had an old world where you, you, in order to interact with the enterprise you had to get a, you know, a contractor account and there was lots of of checks on those.

But from my business perspective as well as from a technic perspective, you had the B3 cannot showed up where in many cases, you know, anyone can invite anyone, great, no checks on anything very, very fast. And one big challenge we have now is that we need to start saying that okay, we probably need something in between.

Like we, we can't have complete freedom. We can invite anyone, we have no idea who this person is or other than their email address which they had at some point. On the other hand, of course the old world where it takes, you know, months to get a company approved, all huge amount of paperwork and weeks to get that currency and it's not, it doesn't work in modern agile world. Okay. I say that's one of the biggest challenges.

Okay, great. Are there any questions from the audience to what Martin just presented? I think these are use cases that are quite relevant for many of you having to deal with restructuring et cetera. Questions? Nope.

Oh, they're down there. Okay. Bear with me. It's a long way to go. Thank you Martin. So I just want to know one thing. First of all, thank you for the presentation. So what happens if the user in Alpha brand needs to work on the B brand? So they also lose the access or they keep the access of their own brand and then on the top you are providing more access? Yes sir. So obviously in theory everything is driven from the business needs.

So in most enterprises you'll still need at least your base access because you still will be, for example, you still need access to the HR systems to register sick leave and vacation, et cetera. So usually you have an additive process, which means you get more access, which of course then means at some point you have to think about how do we kind of avoid that. People just accumulate more and more and more and more access. That's not very good. So initially you will always get an idea to process the trick is to try to figure out some way to squeeze down the access over time. Great.

Thank you very much Martin for your presentation. Really insightful. Thank you very much.