Enterprise IAM in the City of Zurich: Shaping the Future of Identity Together with iC Consult

First, thank you again for this award. We feel very, very honoured, of course.

And also, I'm very happy to show you some specifics about the project. Now, the project Miami, it includes – well, I'll just start with the agenda.

First, I want to introduce the City of Zurich, because it's very important to understand how the city works, to get the project concept, project scope, solution design. And then I want to talk about the specifics here that we implemented during the project.

Now, first, the City of Zurich, we are not a regular company. Of course, we are a city.

So, the city, it consists of nine divisions and over 80 departments. And those departments, they are special in a way that they are like their own companies.

So, when I'm talking about departments, I'm talking – and you see some examples here – transportation, department of schools, hospital, police, electricity. This is just an example of what we have, and you see how much the number of identities, for example, vary per department.

So, I have this example as well. We have only 12 identities here for the ombudsman, but then over 7,000 for the schools.

So, they really behave like their own companies. They have completely different contexts, business contexts.

I mean, they are self-organized. They have their own IT departments or units.

They have, most of the time, their own HR units as well. So, they really are self-organized, and they have a very high level of automation across the board, not only for identity access management, but for many other products and processes as well.

So, this is what makes or made this project very special, because we have to address the needs of over 80 different companies, and we all have to stuff this within or under one, let's say, umbrella, and we have to be security compliant and so on. But still, they need to be able to be self-managed or organized at the same time.

So, the project scope, and since this is about enterprise, I will not talk that much about the customer part, but the project, it includes both. We have the rollout or the implementation of a new identity access management solution in the enterprise, business to B2E and business to functional, business to employee and functional. And the CIA space, we are talking about citizens, so potentially over 300,000 in the city. We are also talking about other cantons, and we are talking about other companies or other organizations as well, like, for example, federal police, forensic institutes.

Those are all other organizations that we have to make a connection to, to work together. But in terms of enterprise EIM, it was extremely important to have a product that supports scoping, because we have those 80 different companies, and they are self-managed. They need to be able to only manage their own objects and artifacts, their identities, rights and roles, and so on.

So, we make heavy use of scoping in that part, and this is why we are using a specific product that I will show afterwards. Then we have the specific things like JML automated identity management, all scoped, and title management, all scoped, role management, all scoped.

So, I will talk about this later and show you why and how it is scoped. But first, for the solution design, we have two different products. We have SailPoint IAQ to make use of all those scoping capabilities, and also it's very flexible. It can be customized in a certain way. And then we use Ping Identity, former Fortrock, for the government to customer part. And it's all hosted. That's maybe special as well. We are hosting it in a bring-your-own-Kubernetes approach on our on-prem container management platform. It's Kubernetes-based, and we have the approach.

We use infrastructure as code, configuration as code. This is all deployed by using pipelines with GitLab.

So, that's just the design, how we host it. And we work together with IC Consult, which we need because they have the expertise when it comes to enterprise and customer IAM.

So, this was extremely helpful. We also work together with service layers for the hosting part of the Kubernetes containers and all that stuff. We rely and work together with service layers, but all on our own on-prem platform.

So, when it comes to automatic JML processes, this is maybe not that special. We had a system before. We had some level of automation already. We use the HR system to deliver all the different identities.

So, what's maybe special is we not only use SAP because we have other departments that use Abacus. So, we had to integrate two different HR systems, which was not that easy, but we managed to do so.

Now, we are live with SAP and Abacus at the same time. Then, when it comes to the mover process, I want to mention that there we trigger automatically recertification processes. Still not that very special. What is special is that we have the ability to use different recertification campaigns for the different departments because our departments have different requirements when it comes to that.

Sometimes, they are regulated and they have to use certain kinds of recertification. Others, they don't have to. For example, when you take a department with 13 employees, it's not the same as for the transportation department, for example.

So, we have that flexibility with IAQ and we can implement it in that way. So, that's very useful for us to use.

Then, the lever process is also all automated and triggered by the HR systems. At the end, we delete identities and accounts in all the applications that are connected, like Active Directory and Entry ID in this case.

So, identity management, this is where we need to use scoping, of course. And we have different rules for provisioning Active Directory accounts per department.

So, one department does not want to deploy, to provision an account for external employees, for example. So, it's not automated. All we have are specific rules per department to decide if we have to provision a specific account.

So, for example, for OICET internal employees, they always get an account 30 days before they start working. Then, the external ones, they don't get it automatically. It has to be ordered.

And then, we have interfaces that will lead to the automatic provisioning of that account. So, 80 different companies, again, 80 different rules for provisioning those 80 accounts, which is complicated, but it's all doable because the system has that flexibility.

And then, the identities, of course, they need to be scoped. So, we have, for example, transportation department. They have their own IT unit, and this IT unit manages only their own identities. It's all in the same system, but it is in different scopes.

So, what they can do is they can view, create technical identities, for example, only within their scope, and that's very important. And then, what we do is we support multiple employments per department and also across departments because an employee can have, like, two or three different deployments within the same department, but also across and all at the same time, which is quite complicated.

But we have to use a specific logic to determine which is the main employment, for example, within the department, or if it is across departments, we have to use some other logic, which is all possible. Also, we have for NPIs, for non-personal, for the technical identities, we have implemented some escalation process to maintain a certain level of housekeeping, because otherwise, we have too many accounts and identities that are not used anymore, which is, of course, a vector security problem, I mean, and some other problems arise, of course, as well.

So, we have automatic processes people have when they leave, for example, they have to move this responsibility to another identity. If they don't do it, we automatically do that and give it to the manager and stuff like this.

So, that makes a lot of sense to get rid of non-used accounts and stuff like this. So, we also have, because it's always special, I guess, maybe probably for every company, is that apprentices can be rotated across departments, also within departments. And this is not an HR trigger, because they don't use the system in that way.

So, this is something that is specially or, let's say, tailor-made for us, so that we can rotate apprentices across all departments over the whole city. And the same thing we have with temporary placements, as if someone has to work or to help in another department for whatever reason, but this is not part of the HR system, it's not reflected there.

So, you can manually move or assign another function and departments and stuff like this and roles will automatically be assigned because of that. So, you see again, we have around 34,000 employees in the city and NPIs, technical identities, around 40,000, so quite a lot.

Now, entitlement management, this is something that we use mainly for Active Directory because this is the largest application that we have connected, of course. But IAQ in this case is not only used to assign those groups or rights, it's also used to manage, to create, to change, to delete Active Directory security groups in Active Directory.

So, this is special, we have to use a special plugin, only if it does, because it's not in the standard features, it's not included. So, also this is scoped, so that means that every department, they manage their own entitlements within the applications that are connected. In this case, mostly Active Directory, but we plan also to support Entra ID.

So, the IT units, they can then manage their own Entra ID security groups and also M365 groups via this plugin. So, M365 is always special because you need teams or SharePoint, you manage the memberships also there, but it's very important for us to use it in organizational roles, for example.

So, if you work in a specific unit, you automatically are part of a team and stuff like this, so this is all planned. So, as I said, this is scoped and it's the responsibility of the IT units of the different departments to handle and to configure their own Active Directory groups. And then we have some special cases, you know, I said, for example, where the owners of entitlements, they may vary. It's not only one group, it's different people because we are organized, you know, I said, we have different groups that do specific things within IAQ.

So, this is for entitlement management and as I said, heavily use of scoping and of course, same thing with role management. We need scopes because again, the different departments, they are responsible for their own roles. What we do is we provide the role concept.

So, it's an airbag approach, of course. We came up with the concept, we provide it and the different departments, they have to adopt it.

So, they know how the concept is and then they create their own roles and they manage it within their scope, of course. So, and then we have different role types, we have orderable roles and we have rule-based organizational roles. Or we have a specific, a custom-made role configuration plugin because if our departments have to maintain their own roles, this is not something that we could do with the, let's say, vanilla feature or functionality within IAQ because it's too complicated and it's too mighty, to be honest.

So, we had to come up with a specific plugin that makes, that facilitates the use and the management of roles for our departments. So, our departments, the IT units use that plugin to maintain, create, configure their own roles or to delete them. This is how it's done. They use also an internal rule configurator that makes it easier for them to configure specific rules. For example, automatic rules for managers or if you have a specific function or if you work at a specific address because all the departments are distributed all over the city.

So, not only scoping, but also the plugin features used here. Otherwise, it wouldn't work and we could not delegate it to our IT departments.

So, but despite we are using scoping sometimes, of course, the departments, they must collaborate on certain issues. So, we have the concept works that you can also create roles that can be ordered across all departments. This is also necessary or if you are within a specific department, you have access to your roles within your scope. You can order them for other departments as well, but not the other way around.

So, this is a way of collaboration that we had to come up with so the different departments, if necessary, can work together on certain things, which is often the case, but not always. And then what's maybe worth mentioning is that we also had to come up with a special logic for M365 license roles or license role management assignments.

I mean, M365 license, it's not a security issue, but it's really about money and we have different requirements from the different departments. So, in one department, you have a lot of bus drivers, for example, they don't use a laptop, they use maybe only a tablet. They can use F3 licenses instead of E3 licenses, which is extremely, makes a lot, has a lot of impact on the cost side.

So, we had to come up with a special logic for M365 license assignments per department, where you have a bulk of licenses that are automatically applied. And then you can downgrade them, for example, for specific identity types or specific units within the department and stuff like this. This was quite complicated, so it's worth mentioning this. And I guess many other companies, they have the same problem when it comes to license management, because it's extremely cost efficient or effective.

So, last part is the technical aspects. We had how it's hosted. I told you this already, but we have, of course, we have some other special API that we had to implement to support the level of automation that we have in the city. I mentioned already SAP and Abacus.

Of course, we need those to manage the identities, the employee identities, I mean. But we also have or use APIs to the VoIP system, automatic assignment of telephone numbers, application deployment, works together with SCM, for example. If someone orders a specific application, we automatically apply or assign a role, because Microsoft concept heavily relies now on AD groups when it comes to application deployment. We have APIs to ITSM, and specifically to OST, which is a self-service platform within ITSM that can be used by the end customer.

So, all 34,000 employees, they use OST to make some orders. For example, they order a specific application, and that triggers then, on the other hand, role assignments. Or maybe they may also order specific licenses and stuff like this.

So, we have an ITSM integration. And then, of course, we have our core systems, Active Directory, Enter ID.

Also, Active Directory Lightweight Services is also integrated. And then, we have a few specials as well.

So, what I did not mention here, by the way, is Exchange. Of course, we are integrated with Exchange as well. And Exchange Online as well. We use both. There are some departments that do not use Exchange Online at this time because of security concerns.

So, we have also a specific configuration per department when it comes to Active Directory provisioning. Also, Exchange and Exchange Online provisioning, because there are differences from department to department. For example, they use different email domains. They use different proxy email addresses and so on, aliases and so on.

So, we have the possibility to do a specific configuration per department. We want to keep it simple as much as possible, but sometimes you have to do something custom for a specific department. And we have the capability to do this with IAQ.

So, we are very happy that we have this level of flexibility here. And then, also, stuff we had to scope, the audit log. This is custom integration because it's not out of the box, unfortunately.

So, we have also had to do a special audit log that is scoped. So, departments can use the audit log and only see the events that are important to them and nothing else.

So, that's it. I think it was around 20 minutes. I hope it was interesting for you and thank you again for the award.

Yeah, thank you very much, Andreas, for these insights. Also, very interesting to have a look in such an organization. Maybe first question, is there any question from the audience you want to ask, Andreas, now you would have the chance?

If not, of course, I have a question. The thing is, when you were showing at the beginning the different use cases, the different type of employees or user types you have, you have a very particular from, I guess, teachers somehow to police officers and so on. One could also say, why are you doing not, if you have local IT departments, why are you not also keeping the IAM also in the local authority and work with federation or whatever and say, okay, we have a limited scope, as you already said, and keep this not to decrease the complexity of our landscape.

So, what was the main driver for you to have it for the whole city and to go for one solution here and to have it centralized? Maybe from your perspective.

Well, as I said, it's responsible, let's say, for the bigger topics where we have, for example, to make sure that we are security compliant, if you want. So, we are really responsible that the city of Zurich is security compliant, that we meet all the requirements from the ISO certifications and stuff like this.

So, when it comes to bigger topics, be it active directory, be it exchange management and mail management or identity access management, we have to provide it to make sure that all the regulations are kept and that we are security compliant. So, this is like, let's say, a bigger responsibility, and we are the ones that have to enforce that. And it's really not possible to do it if we distribute the systems all over the departments. And then we have different departments that are very capable when it comes to also identity access management, but there are others which are very small.

It was just an example with the one with 12 employees. We have many others like this, and they don't have the expertise.

So, they have to use the YSET, and we have to make recommendations to implement the system that automatically enforces the rules that are necessary. So, this is the main purpose why it's like that. And by the way, it was much more, how do you say, it was much different like 10 or 15 years ago.

So, we have, this is really an evolution to harmonize the way that the city works and to manage it from a central position, but give freedom to them to still be different where it is necessary to address their specific use cases. But we maintain we are responsible for the whole security part and that we are compliant. Okay. Thank you very much. A nice closing statement with evolution. And that's, I think, perfect to hand over to Thomas and Tim for their talk. Thank you very much again. Thank you.