Open Source @ Siemens

Summary

Florian gives an interesting talk at the Open Source @ Siemens event on why we built yet another identity & access management systems. He fives into what was generally missing, today's key challenges and how ZITADEL is made for Software/Infrastructure/Platform-as-a-Service providers.

Slides of the talk.

Mentions of tools & companies

contributers

• JoshMartin 41:35
• Smartive 41:35

companies and organizations

• Auth0 1:32
• CH Open 1:32
• Cloudflare 28:07
• Cloudscale 42:51
• CockroachLabs 28:07
• Exoscale 42:51
• FIDO 13:42
• GitLab 1:32, 28:07, 41:35
• Google 17:27
• Okta 1:32
• OpenID foundation 1:32
• Ory 42:51
• Siemens 42:51
• SwissMadeSoftware 1:32

tools

• ADFS 17:27
• Ambassador 39:55
• Angular 34:03
• AzureAD 1:32
• CockroachDB 30:11, 34:03
• Elasticsearch 39:55
• Gluu 1:32
• Golang 34:03
• Kubernetes 1:32
• Keycloak 1:32, 20:55, 39:55
• Microsoft 365 17:27
• MinIO 34:03
• OAuth2 Proxy 39:55
• ORBOS 42:51
• ServiceNow 39:55
• Splunk 39:55

Open Source @ Siemens

The annual event series by Siemens for all topics around open source software.

• opensource.siemens.io
• Recordings of the 2021 event

Transcript

This is an automated transcript of the talk.

Hello my name is Florian Forser and I'm the CEO of CAOS and I'm here today to talk about why we built yet another identity and access management solution. So let's start with my slides and I will give you a quick introduction about who we are and what we did and why especially we did the stuff I'm going to tell you today.

I will quickly dive into who we are because we need to have some background information of who we are and then why did we start the project, because we actually had some reasons to do it otherwise it wouldn't have made any sense to do something like this. Then I will tell you what makes the project special, actually I mean ZITADEL by that so we will dive into this a little and what else can he do for you like the classic stuff an identity system does.

That's the agenda for today. Feel free to write any questions to me, I will answer them at the end and I will try to time box a little so that we have enough spare time to really really dive into questions you guys have.

1:32 Who is “we”

So who is “we”? “We” actually is the company called CAOS, we founded our company in 2019 actually on the 1st of April, which is the official founding date of us - and is no joke. We have 11 employees focused in the identity and access management topic and also in the GitOps world because we need to be able to run our software as well. So we don't just build it, we run it as well so it's kind of the approach Gitlab does there, but I will go there in a minute.

We are a totally open source company. Most things we do, and I say most, not all, but most of the things we do are licensed with an Apache 2 license, so you can really reuse the things we do. We're also a member of the Swiss Made Software foundation and CH Open which is kind of the open source institution in Switzerland and we sponsor the OpenID foundation so that's kind of the standardization body for protocols like OpenID Connect.

So we're really deep into that specific corner so that you have some pictures of us. That's the 11 people. Two people haven't had yet the time to get the photo shot, because yeah you know it's corona still running and kicking. So we have introduced our lovely pet the giraffe called ‘Giggy’ which is our mascot. We needed to replace them.

What we're actually doing is, for one, we developed a cloud native identity and access management system called ZITADEL. I'm primarily talking about that today and we also have some kind of container runtime platform which is optimized for a GitOps-centered approach which we call ORBOS. They both work in combination together, so we run our ZITADEL clusters with ORBOS beneath and ORBOS provides the necessary abstraction like Kubernetes and all that stuff. But I will not delve into that too much.

We are one of the only companies in Europe that serve a proper Software-as-a-service identity and access management system. The differentiator is kind of it's not a managed service where you give us a call and we deploy you an instance of ZITADEL, but instead you can run through a self-registration GUI and create your organization. Something like you see with AzureAD and also Auth0. So it's kind of a proper SaaS model there. We operate our products as well for clients, so we do manage service also,we have kind of both worlds. We provide consulting and engineering in the identity and access management field and also devops. We do all of this but we are highly centered around that, so nothing like specialized projects and stuff like that. So much to the company CAOS.

Then why did we actually start the project because some would say there are already a lot of identity & access management solutions on the market. So from SaaS oriented approaches like Okta and Auth0 to open source projects like Keycloak and Gluu and all that. So yeah there are a lot of projects already available but we think we solve kind of a special part in the market and we have some nifty details which are a differentiator to all the other projects. I want to tell you a little bit about them because that's essentially the point why we built yet another identity and access management solution.

5:28 2019 - The Start

To start, I said we started in 2019 and we previously worked at the company which provides services to public government and they were kind of a service provider for that sector so they provided an infrastructure service that provides software as a service due to a public government sector and the problems they had were especially centered around how you operate and build an identity and access management system that can cope with different workloads and different topics from the government sector. As we did that we really figured out what things - and I will go to that in a minute - are missing in most public available solutions today. Because there are some deficiencies which needed to be addressed to make a really really great product for that market and at that point in 2019 it was clear to us that there was a space where somebody could build an identity and access management solution, especially built for the XaaS [Infrastructure-, Platform-, or Software-as-a-Service] market, any as a service constructs and and also service providers as well because you want to have some kind of a platform system which really is easily to integrate within your projects. That was kind of the origin story where it started in 2019 and so let's dive in into the topic.

7:12 The basic requirements of most (X)aaS project today

The basic requirement of mostly any software we have today not any but most of the software is you will have some kind of authentication, you will have some kind of authorization, and if you're going for a software as a service market you will end up needing self-service functions, because you don't want to do anything for your customers because this will hurt your business model really bad. You really need self-service functionalities and we think that this is the foundation for all the great projects that are out there.

7:51 What generally felt wrong or was missing

What went wrong from our perspective or what was missing or what was the missing piece? I will quickly explain those boxes because we think these are the problem domains we experienced in the past. We have kind of the feature part and the market, the technology, the pricing and the regulatory part. Each of them has different problems and I will quickly run through them.

8:20 Features

If we talk about features most of the systems that we have seen and evaluated do not really provide a solution for long-term audit trails and that's kind of an anti-pattern in the identity world. Because you will you will end up with a lot of log files and they do not really create a great foundation for doing analytics on top of them because the structure of log files is most of the times highly volatile. So it's not a great way to to bring a long-term audI trail to the party, if you need to dig through all those log files and find out what really happened. That's kind of one of the deficiencies we think is really a bummer because in a security incident you will need those data. We'll come back to that topic how we solve that because it's kind of the big thing with it.

Then self-service you have two areas where you need to provide stuff for customers like normal people and you need to provide self service for your partners. They function a little bit differently because in the end a customer is only able to manage its own user and a partner is able to manage all its users and also needs to be able to configure things like single sign on (SSO) with its existing IDPs. So those are the special things which are missing in most of the projects. But still you have some little features in some of the products, but not all of them.

One thing that is missing big time in the industry is delegation of access management. I will explain that in a second, but it is missing. Delegation is not that easy to achieve because you need to make sure that your data model works even when you're delegating things and you need to make sure that yjour ownership is correct and all that stuff. It's a missing link and I will go there in a second.

Then we found no identity in the access management system that had kind of the vision of becoming a platform. But most of them tend to be just either a software as a service product or an IAM as a service product or an open source product or a product you purchase. So it's not kind of a platform with great integrabilitiy and great features and we think that a platform IAM is missing.

11:00 Market

So regarding the market the identity access managed market is highly dominated by the American companies. That's not the bummer itself, but it's kind of intriguing for an European company to dive into that market. Because most of the countries we are located in, like the DACH area, have another ideology with regard to data privacy and so we have kind of um side effects there which point to the like regulatory side. Just to mention a few, I mean, the SaaS market is dominated actually by Okta, Auth0, AzureAD, Ping Identity, and all of them. So it's kind of a fragmented market, but it's a big market. In the product sector you have a lot of products, I mean, RedHat SSO, just to mention one, which is also the subsequent open source project KeyCloak. You have kind of the there approach there as well but it's always the US company that is in the lead and I find that Europe has the capabilities and abilities to run and build such a software. So why don't we push that thing? We think that's kind of our mission to enable Europe with an identity and access management system built for the cloud.

12:26 Technology

Okay, so then let's dive into technology. Oftentimes those projects feel quite a little bit faded. I don't want to say they're bad in any kind of way, but if you think, for example of a KeyCloak, it's quite hard to run and scale that thing. Especially if you're diving into topics like how to operate that thing across multiple data centers or regions, because it was not built for that purpose at that point. It was created initially so you need to really invest a lot of figures to make that happen or have the skills to do that. Also oftentimes those systems don't have great APIs, I mean it's 2021 and I today still see SOAP services today, and I see cookie based APIs, which gives me the shivers, because it's just hideous to use something like that in 2021. And so oftentimes they don't provide great APIs but that's kind of a turn off if you're trying to integrate such a system with your project.

13:42 Pricing

The pricing is also where the bad things are. Most providers tend to hide security relevant features like 2FA or multi-factor authentication and passwordless and other stuff behind the paywall. We find this kind of an anti-pattern because with an identity access management system as a platform you want to increase the security by using reproducible processes, which are really made secure from the beginning. You don't want to hurt the security of a project by just hiding 2FA behind a paywall. From our perspective it's kind of an anti-pattern and we already wrote a blog about that.

We also found that the pay-by-user or by-session pricing is kind of a bummer, because you want to get security into your product and if you need to pay by user you will decide with each user whether you create the user or not. That hinders any security because you will end up with things like a technical user or where somebody shares an account with different people. And they do that even with things like 2FA enabled today so it's not really helping a security effort. If you're pushing for passwordless you're going to have a bad time, if you do that.

Also one thing to mention there is that most IAM software differentiates between employees, customers, partners and machines, but from a data model perspective it's all the same. You have an account, the account may have roles, may have attributes, and that it's just it. The means of authenticating such an identity are different, though. The employee may use a FIDO key or and the machine may use something like a certificate to authenticate against the identity system, but in the end it's an identity. We don't differentiate that because it hinders the security effort.

15:52 Regulatory

GDPR is kind of a problem when you're diving into the regulatory part. And I can tell you: it's a challenge for us as well, because our great audit trail hinders that effort a little but you can redact things out. So GDPR needs to be fulfilled if you're running in Europe [and process data of European citizens], then broken privacy shields and safe harbor agreements tend to bombard all the SaaS products if they're originating from America or even if an American company is involved. To some degree there are a lot of uncertainties in that case and also you need to provide a way for your customers to own their data. That is especially true if you're relying on GDPR you need to make sure the data is portable in some kind of way. But it's an academic discussion at that point.

So these are the big things that felt wrong or missing and I will dive into four of them right now to just um give you a sense of what's tricky with them.

But first chance to sum it up what functions each project needs sooner or later right. You will need single sign-on, you will need secure authentication, you will need identity brokering - that I will explain in a minute -, you will need identity management and access management and great APIs, otherwise you can't really integrate that thing.

17:27 The Challenge 1 - Identity Brokering with self service

Let's try diving into the identity brokering challenge. The topic of identity brokering is not something new, so it's kind of an old thing, but the challenge here arises when you need to make identity brokering ready for a self-service centered world.

To quickly explain the graphic: On the left side you have kind of the consumer ecosystems think of Apple, think of Google, whatever you choose. On the right hand side you have an enterprise ecosystem: think of AzureAD, or Google Workspace, or ADFS, or whatever you have there. Our system abstracts both sides away so that one identity can be chosen to use against any software as a service provider. Just an example: Here it can be Microsoft Office 365, it can be Digitec [an Online Store], a retailer, it could be Bexio [Accounting SaaS], it could be Netflix, it could be anything. I just connect the SaaS service against ZITADEL and you can broker all those identities together. And you can build an audit trail on top of them.

Where things get hard is the trust relation from ZITADEL to any identity provider, like Apple ID or a company account with AzureAD needs to be controlled from a customer perspective. So if I'm a company and I'm purchasing software as a service for a product from you, then I want to be able to define which identity provider I would like to have as the original source for the identity broker. That's where things get tricky because most of the systems today do not really expose the feature of creating identity provider trusts - or so-called “federations” - and in a self-service manner. Most of the time you need to fill out the form and somebody will do the operation for you, in ticket-ops-style.

We say that hinders your self-service effort and that's one of the problems we decided to solve by providing all customers within our product the ability to choose and set up their own identity providers. That’s kind of the challenge, and self-service enables your customers to choose and set up their own identity providers.

And that's kind of a two-way topic because you have some part of it for the business part, like the companies who would like to reuse their identity providers, but also in the future or close future you will see a rise of something like that also in the private customer sector. We get government IDs in the future, we get social ID and we already have social IDs to some degree, and also something like self-sovereign identities will rise eventually. You don't want to manage all the IDPs at any cost because it will hinder your onboarding effort. You need to make sure that the identity provider setup is kind of self-service.

20:55 The Challenge 2 - Delegation of roles to other organizations

That's the thing the challenge one we try to solve then the challenge too is centered around delegation of roles or any part of access management, in that case to other organizations. I chose this diagram, which actually reflects the data model of ZITADEL. Everything has an organization and in that organization you have the users corresponding with that organization. If you're providing somebody with a project. Like if I’m Digitec [Online Retailer], I could be on the left side, then I'm providing the Digitec B2B portal to a third party, for example to CAOS. I am owning the application Digitec B2B partner, so it's on the lower left corner, where an application would be the “business portal”.

I have defined a set of roles for that business portal and you see we call that “project”. A project is actually a bundle of applications, like the web applications and mobile apps, that share a common access management catalog, in this case toles. If I, as Digitec, want to delegate the role “purchase administrator” to the company CAOS, then I can simply go there and give the company CAOS an organization, then grant the role “purchase administrator”. The ownership of the business to business application and also the ownership of the role still remains within the company Digitec but they delegate the management of who actually has the role to the right hand side. That's what we call an “organization grant”.

That's actually one of the biggest things you need to solve as a software service product because you always will retain the ownership of your projects, but you want that your customers can manage certain roles on their own. Not all of them but certain roles, and that's happening with that data model.

This is not really a solved problem in many products. They are, to a certain degree, solved but if you take a Keycloak for example it's not actually easily feasible to build something like that. Because you will end up in a pain when you choose either a realm-oriented design or a group-oriented design and either way it will hurt you at one point, because it's not optimized for that purpose. That's what we thought needed to be solved in a proper way and that's actually what we did. So the delegation is a vital part of that story for “as a service” provider.

23:55 The Challenge 3 - Audit Trail

Let's go to topic number three: The Audit Trail. I mentioned the audit trail is kind of an important thing. We think that changes from an identity system should be auditable over a long time frame, because most of the time you will have an incident where you need to have all data from like six months ago. Or you want to have compliance reports where you see ‘what happened in the last few months’ are vital for modernity security. We think that an audit trail should be at least 12 months or even longer because most times you have wrap-up windows of 12 months. So we normally provide about 13 months to customers.

They need to be able to look back at what happened and that's especially useful if you had a security breach like six months ago and you can go back and see how the data object looked at that time. You can reproduce what roles the user had or how many times he did log in and all that stuff.

You have all the information to do that and we built that on the foundation of “event sourcing” the whole system. The second point there is: the reason why we chose to solve that is because you need an efficient way of storing that set data. Because otherwise you will have a bad time. It's not easy just to pump all the audit data into a database and you can restructure your things around that, because you will have a bad time running multiple data stores with the redundant data to it and you will gain a lot of overhead. So we chose to event source ZITADEL which is, let's say “expensive part” from an economic standpoint, but it really enables cases for audit trails and an efficient storage format.

26:05 The Challenge 4 - Analytics & Reporting

Also the challenge 4 which I think could be or is the future in the end, is that you can build or the customers need some kind of threat intelligence. You need to create data models or threat models of the old data and you can only do that when your data is actually quite well structured. With an event sourcing approach you do not have that as a particular problem because you need to solve that engineering problem up front and you just consume it afterwards.

We think that with right intelligence and machine learning, we can prevent attacks on users and you can also prevent malicious changes like if somebody gives somebody a tool high level of access rights. Machine learning models could mitigate that because it could be kind of a different behavior from different locations and all that stuff. If you have all the historical data to it you can build those threat models even “on the edge” rather than in a centralized way.

Each customer with ZITADEL in the future will be able to do this without giving us any data. We find that is a great thing for us to achieve in the future.

Also business representatives would like to have historic data: usage-wise “how many users we have”, “which application is most active” and all that stuff. You can easily generate all these things out of the data model that we actually run. So you can easily solve that problem in the future because you already have the data. But most times you just don't have to report yet but that's an easily solvable problem for the future.

Those are the actual four challenges we think are kind of a differentiator for ZITADEL for the market because it really enables some specialized topics where you need either data or have specialized needs for the delegation part and the brokering part.

28:07 Influential products to our vision

What influenced us on the way we're chosen to run? I always say we have kind of those three companies which influence our vision: Gitlab I would say they pioneered to some degree the idea of having a product you can run on-prem in your data center of your choice, or provide you with a cloud service.

We showed to you that it runs at scale so the 'eat your own dog food’ mentality really struck us and that's why we actually do the same process: You can run ZITADEL on your own on the cloud software you like. But we also run the cloud service and manage it at scale. So we see errors way more often than our customers do, because we have higher load, we have higher traffic, and we have more customers. So most of the time we see the edge cases before the customers do. It's kind of an interesting mentality they provided us there.

With CockroachLabs they're actually pushing the motto that you can run it mostly anywhere and you don't have to have a complex architecture to it. With Cockroach you just need to make sure you have a kind of disk and you can run the distributed database. We thought that ZITADEL needs to be the same: so you need to have one binary, you need to be able to run it everywhere and it just runs. If you need to scale, then just scale that deployment.You don't need to think of things like ‘I need to also manage my pub-sub system”, “I need to manage external components with scaling efforts” and all that stuff. We thought of keeping things clean and simple and that it really helped us gain some traction.

To say something to Cloudflare, they influenced our pricing model for our Software as a service because it's kind of a flat fee pricing. But I will tell you a little bit about that, but I'm not here to talk sales to you. So we're going for the open source products ZITADEL.

30:11 What makes ZITADEL (so) special?

So what makes ZITADEL so special? The vision for project ZITADEL is actually:

All the security features are not paid add-on. So 2FA, passwordless all that remains totally free in an Apache 2 licensed open source project. We find that imperative for the trust and transparency approach we've chosen. We want that customer can build secure and fast software as a service systems, when delegating ZITADEL some of the work that they need to do as a project. That's kind of the thing we think about it.

Then we also provide them with a way of long term storing the audit trail by natively building that into the data model. As said we are using event sourcing and CQRS there, which makes that happen.

Then we make no difference in account types. It's just an account be a machine, a human, makes no difference. You just manage them differently, but they have all the features to it that they need.

We provide the cloud native architecture and I said it's just one binary and you need to deploy it there. You need a Cockroach as a database and you need some kind of S3 storage for the assets. That's it. And then you can scale that thing easily to optimize for day two operations and scalability. We even provide you an operator which runs the thing on top of Kubernetes and which also automates things like backup and restore tasks and schema migrations of the database and certificate rotation with the MTLS client authentication between ZITADEL and the database. So it's easy to get running with a few commands, and we even have a CLI there and you can just use it with low effort.

One thing that was also really vital to us is to be able to operate across multiple regions out of the box. In combination with Cockroach that really works well because the database actually solves most of the problem. A stateful application would have by replicating data across different data sets and we kind of think that's a solved problem and we leave it to Cockroach to solve that. Because for the application ZITADEL you just need the database and there are your states, and it really works well.

We provide modern APIs, such as GRPC and REST services. They're already modern, so you can integrate with most of the frameworks we see today and I have some examples in the list down below.

And it is Apache 2 open source. We think that's the best trade-off for an open source license as of today because MIT is a little bit too fuzzy for, I would say, a mature project at that point. But that's just my personal opinion.

33:08 Made for (X)-as-a-Service Providers

To sum it up what ZITADEL does: it enables X-as-a-Service providers by reducing time-to-market.

You don't need to build self-service and that stuff, it is portable cloud-native, it can run on any Kubernetes cluster, the automation part is solved - I will show you a picture of how we see the world there -, security is already built-in, threat analytics and breach assessment with a ‘time travel feature’ (we call it), is already in there, but we just don't expose it in the graphical user interface yet.

And it is a proper open source project because we really want to build on trust and transparency. I I found the talk right before my talk (From Monitoring to DevOps: 10+ years OSS community building) interesting because it has really good inputs to us and I guess I will come to that at some point, because the community building part is actually the challenge for us right now.

34:03 Architecture & Technology

From the architecture and technology point it's mostly written in Go. So think of all server side parts and the login GUIs and all that stuff which is security relevant is built in Golang.

The console like the management UI where the users can manage their profile and an administrator can manage the instance and other stuff is built in Angular. We use our own APIs there, so it's ‘eat your own dog food mentality’. We use CockroachDB as a postgres-oriented storage layer for all the business data and MinIO to store assets like pictures and some customized logos and all that stuff.

It's easily scalable from a single node to multi-data center to multi-cloud deployments. Still with multi-cloud deployments there is the challenge of networking which needs to be solved. We can give you a lot of good insights there because we are actually doing a lot of the testing in regard to multi-cloud capabilities and we also run our instance across multiple clouds. And so we can give you great insights there.

Then it's an API-first design, so no feature is not in the API. Everything is visible on the API.

It runs on any CNCF-compliant Kubernetes. We have just one one special thing, you need to be aware of: We use GRCP and GRPC web so your ingress control is reflected, but that's no rocket science today.

It's a low footprint and starts running with 100 megabytes of memory, easily. You can give it more - and you should give it more, as it will perform better - but it runs with 100 megabytes easily.

It's event-sourced for unlimited records and analytics purposes. We also have a doc page where we explain the architecture a little bit more. But that's it for now.

35:58 Where ZITADEL aims at

No presentation is complete without the Venn diagram, I heard once. So I'll give you a Venn diagram.

Let's start in the lower corner. The lower middle ZITADEL is an open source project. We build constant transparency with proven and open standards and all security relevant features are already included. But we also need to make money at some point, and that's why we have kind of the both topics up on opposite sides.

ZITADEL is also a product. You can use it with support from us, and you can run it in the data center you chose. You can run the open source version, or you can run the product version with support from us. We even run the product version for you, if you don't want to run it. So it's a proper product at that point. To prove that it is able and scalable, we run the software as a service part which is called zitadel.com, which is the SaaS offering from us.

And I think the ZITADEL is right there in the middle of the three overlapping parts or rings. Because it checks all those boxes and you can really excel with the open source version already, because we're committed to that. And if you check out our GitHub repos, it's quite active and we have releases really often, because we think the velocity there should be high. You can really build up on the foundation of a product which is also an open source project. So it's kind of the mentality we have for that.

37:36 What else can ZITADEL do for you

What else can ZITADEL do for you? It's still an identity and access management system. We have seen that slide and actually it this really wraps up what an identity and access management system needs to do:

• it does single sign-on, it does secure authentication,
• we support even passwordless,
• it supports all the identity brokering for customers and partners,
• we support identity management so a company can manage its identities within ZITADEL,
• it can also manage it by hand or by running through our APIs
• you can do access management in a rule based fashion right now, and
• you can really easily integrate it with its APIs

So the key features right now are about that.

• We have authentication,
• access management,
• identity management,
• IAM Administration - such as policies like password policy, or which kind of authenticator you need, you are able to use so - you can prevent your users from using username and password, and that stuff,
• we have a lot of going in the interoperability sector: we support the opaque tokens, JWT access tokens, id tokens and all that stuff is built-in,
• soon we also support outgoing web hooks to trigger your application if something changes within ZITADEL. That's easily achievable, as we have all the events already so we can trigger an external system with that side event easily, and
• we have some extensions and the extension part is more an enterprise oriented area where we provide some legacy protocols to customers and they are actually not part of the open source project because we need some kind of enabler for business customers but sometimes we chose to to ship them downwards to the open source version if we see enough traction for a certain feature

Right, so I've outlined some of them there and but you see it's mostly legacy protocols like LDAP, AD, and Kerberos and all that stuff and things like I can export all the events from ZITADEL and pump them in any system for analytics so these are kind of enterprise extensions right now.

39:55 Build your use cases on a solid IAM platform

How we think ZITADEL should be used. On the lower level is shown ZITADEL as a platform. so you can integrate it with your API gateway, with your identity-aware-proxy, or web application firewall. We often use Ambassador or OAuth2 Proxy there.

Then you can integrate ZITADEL with your HR processes. We don't build any business workflows into ZITADEL, because ZITADEL is not a workflow machine. It's actually just an identity and access management platform.

So the HR processes need to be solved in the HR domain and that gives proper separation of concern, and nobody will have the pain of upgrading ZITADEL at a certain point in time because they build custom code into it. I often see with Keycloak that people build java modules and that hurts the upgradability of the system overall.

So we prevent that by just providing great APIs, you can even integrate with IT service management processes. If I want to have two people signing off that somebody has access rights, then go with your identity for it service management tool, for example ServiceNow or whatever you have.

If you need analytics, then you can pump the data in Splunk, Elasticsearch, or whatever you like.

So ZITADEL at that point is a proper platform and everything I talked about there, so APIs and SDKs are open source, the add-ons are enterprise extensions.

41:35 Resources around ZITADEL

If you want to go check out ZITADEL we have a GitHub repository.

We have a .NET library, provided by a company we're working with Smartive. I need to do an honorable mention from us because they really did a great thing by providing a ZITADEL client, which abstracts the API and also the authentication so you can just plug and play. We have a Dart library, a go library, naturally, and even an elixir client from a company called JoshMartin. They built a contact tracing solution and they built it on top of ZITADEL and they are using elixir here and they provided us with the library. We will take the library into our GitHub Domain in the not far future.

Also we have some documentation. Feel free to start discussions on our GitHub page, because we're really building a community right now, but we're really early to that.

So the product is there and now we're shaping the future of a great open source product and we, simply said, we want to become the “next GitLab” in regard to identity and access management (and not in source control systems).

42:51 Q&A

So that was it. I guess I'm on time.

[Moderator] Absolutely perfect thank you Florian very much for the presentation. It's nice to see such a solution for a critical and important system that is even open source and auditable. That would be very nice also for Siemens. I think we could learn a lot from that.

[Florian] Yeah go go ahead just check our GitHub Repo. Our build processors are open. We just do NPM builds there and we do the Go builds there. It's a local file and you can use it, you can run it.

[Moderator] Let's get to the questions and we got one from Roger: “Do you get a lot of contributions on the open source project ZITADEL? How do you engage with the open source community?”

[Florian] We would like to have a lot of contributions but right now we're in the beginnings and so it would be absolutely lovely to have more people engaging with us directly. As of speaking here we are working on providing a contribution guide. We have seen we need to enable potential people that they can contribute by explaining how things run around here.

So “no” we don't get a lot of contributions, yet, but we have some from colleagues and companies which are also committed to bring forward the open source story. For example the .net library was built from another company for us and is also open source. It's kind of here trying to grow an ecosystem.

[Moderator] That's cool and when the community grows around it right that's let's say the goal at the end. Next question is: “Does ZITADEL support auth code flow with pkce and rotating refresh tokens?”

[Florian] Actually that's the default, yeah. [Moderator] Very nice. [Florian] We have built a wizard process for people who want to integrate your application and the result for most applications or for the front ends normally falls back to “pkce” standard process. The refresh tokens I'm not sure if we shipped it already or if we ship it today or tomorrow. So yes, provide refresh codes or refresh tokens in a rotating fashion so they are used once so each time you use it you get the new one.

[Moderator] Cool. Another question from Roger: “Did you give Exoscale a try?”

[Florian] Not yet. In the early days we committed to Google in the Europe West-6 region, which is the Zurich area where we actually run three data centers. We also run with a company called Cloudscale and it's a smaller company in Switzerland. They run two data centers and they provide beautiful APIs. So we can automatically create the ZITADEL instance with either Google, Cloud scale or an on-prem setup with SSH access in about 18 minutes with ORBOS. We use a CentOS image, we install Kubernetes and we pump all the platform tools on top like Loki, Grafana etc., then ZITADEL runs.

But right now we did not yet get the time to test Exoscale but actually there they are on my roadmap to see whether it's an interesting player to enable customers from us to run ZITADEL with exoscale by automating it into our tool suite.

[Moderator] We got another non-technical question, I guess: “Usually when using a software SSO solution, the customer product has to hand off the user to the SSO system that manages the front and customer interaction login form. I saw that citadel has API support, but is it full can I create login screen form and just use the API to authenticate a user against your API?”

[Florian] Actually that's one thing that's not yet there. Because the approach we have chosen is to provide a hosted login form with some degree of private labeling like logos, texts, colors and, also fonts. As of today that's the feasible part and in the future we will expose the authentication API as well. But we have chosen a security oriented start by providing a secure login site. Because we see a lot of unsecured login sites on the internet: Like HTTP headers missing, CSCP missing, external javascript dependencies, and all that stuff and we wanted to mitigate that at the beginning. You will be able to in the future. It's just a question of demand, we had not yet have enough demand for that feature.

[Moderator] Okay, so it's the process and the product is still developin. [Florian] Yeah definitely.

[Moderator] We got another question coming in: “On a purely technical level, where do you see the key differentiator between something like Ory, Hydra, and ZITADEL?”

[Florian] It's an interesting question because Ory took a different route. They are kind of a polyglot design where they really separated the components for different functionalities. So if you need to run Ory, you need to deploy all of them in the correct manner. They chose to do that like that.

I find that the overlapping area of ZITADEL and Ory is kind of like how we both do OpenID Connect, we both do OAuth2.0 that stuff, and user authentication.

But ZITADEL is more an all-in-one binary approach, where you have the GUIs and all that is already made for you and you just run the binary. With Ory you have kind of more flexibility in regard to building your own login GUIS and that stuff. We provide a great audit trail, they provide better flexibility in regard to customization.

We also took a different route with the open source project of Ory, it's a single tenant solution. Multi-tenancy is not built in there, because that's part of the commercial offering. We talk with Ory as well, so we know these guys, and so I know the difference is a little. We took the route of building multi-tenancy directly into ZITADEL. So that's kind of the difference we have.

[Moderator] Okay so it's kind of a balance, right? Depends on your use case. And “Maybe if I can ask how many customers you already have? And what kind of it ?”

[Florian] So it depends on what we are looking at. We're seeing for the SaaS offering, we have about 150 active organizations [updated: more than 250, as of writing], who are running their software projects on top of ZITADEL. Most of them, like 20 of them, are early adopters from us which we are closely engaged to really shape the product's future at that point. We see we have about three to five enterprise customers who run ZITADEL in a private data center and we support them in different ways. Either we run it, or they run it on their own and we provide support.

So we're quite early, I must tell. But it really works well. We have no major incidents right now so it seems like an interesting project.