Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

Read the blog

Sign up

Login

Pricing

Jobs

Blog


IMO = In My Opinion is a blog format where a author reflects his own opinion

At this year's Worldwide Developers Conference (WWDC) 2021 Apple did announce something that really got me thinking about what the future for Risk Based Authentication (RIBA) holds.

In short Apple did announce a feature called “iCloud Private Relay”. What it basically does is to hide the user's origin from the services the user calls. This in a way that Apple and the egress provider should not be able to track the user. Whether that’s true or not is a thing we will see in the future. This design somewhat resembles what TOR does but with less privacy.

<img
  src="/blog/2021-07-07-imo-rba-is-broken-01.png"
  width="100%"
  alt="iCloud Private Relay"
/>

If a user enables this feature, your RIBA seriously will have a bad time. This is because, as you can see below, the user's IP Address will be more or less useless as a signal. As of writing this blog I was in Switzerland and the IP used to egress my traffic was in a region located in the US. If this also tends to change a lot and fast you can basically throw away IP addresses as data of your RIBA.

<img
  src="/blog/2021-07-07-imo-rba-is-broken-02.png"
  width="100%"
  alt="Settings Private Relay"
/>

```json
{
  "ip": "2a09:bac0:205::815:95a",
  "ip_decimal": 55878094235311776708809106431373805914,
  "country": "United States",
  "country_iso": "US",
  "country_eu": false,
  "latitude": 37.751,
  "longitude": -97.822,
  "time_zone": "America/Chicago",
  "asn": "AS13335",
  "asn_org": "CLOUDFLARENET",
  "user_agent": {
    "product": "curl",
    "version": "7.76.0",
    "raw_value": "curl/7.76.0"
  }
}
```

Some of you now might say: “Well we have cookies and browser fingerprinting”.
Yes but with Apple's recent announcement towards improving the privacy features of Safari things are getting harder as we speak. And this does not only apply to Apple but other browsers as well.

So what is the solution to all of this?  
To be frank with you, get rid of your RIBA process and start towards the passwordless journey. It both improves your security and the users' risk quite a lot. If you are interested I dearly recommend that you read my [IMO - Passkey in iCloud Keychain](/blog/imo-passkey-in-icloud-keychain/) as well.

So that’s it? Just throw RIBA away?  
Well there is a nuance to this, which I might encourage you to differ a little from that view. If we are talking about **re-authentication** and **session management**, I still recommend you to use signals you collect about the device and user, for example user-agent version, language, time, TLS version and cipher and so on to prevent things like “session cookie extraction” from the browser.

**But please stop relying on RIBA for the plain authentication of a user!**

## Resources

https://www.apple.com/newsroom/2021/06/apple-advances-its-privacy-leadership-with-ios-15-ipados-15-macos-monterey-and-watchos-8/

https://www.theverge.com/2021/6/10/22526881/apple-icloud-plus-privacy-subscription-services-revenue-wwdc-2021

https://www.heise.de/hintergrund/Die-Kruecke-fuer-Passwoerter-und-wie-sie-ausgenutzt-wird-4970547.html


Apple's “iCloud Private Relay” breaks risk based authentication (RIBA). You should get rid of your RIBA process and start towards the passwordless journey.

IMO - Risk Based Authentication is broken


<div className="my-4">
  <YouTube videoId={"Wly2jqbzP8Q"} containerClassName={"youtube-container"} />
</div>

## Outline of the Talk

- Introduction (00:00)
- Why did we actually start the project (07:24)
  - 2019 - the start (08:00)
  - The basic requirements of most (X)aaS project today (10:04)
  - What generally felt wrong or was missing (13:08)
  - What functions each project needs - sooner or later (28:02)
  - Challenge 1 - Identity Brokering with self-service (28:28)
  - Challenge 2 - Delegation of roles to other organizations (31:24)
  - Challenge 3 - Audit trail (34:15)
  - Challenge 4 - Analytics & Reporting (36:50)
  - Influential products to our vision (38:47)
- What makes ZITADEL so special (39:36)
- What else can ZITADEL do for you (43:40)

## Description

Abstract: The concepts of Authentication and Authorization play an important role for securing services and data. With the emergence of Multi- and Hybrid-Cloud Patterns a new challenge arises for secure Authentication across domains, while privacy of employee or customer information is more important than ever.

In this talk we want to explain some of the key challenges with today’s Identity & Access Management (IAM) and why we ultimately built a new open source IAM, ZITADEL, to change the traditional business-model and principles of IAM solutions for example by

- Optimizing for day-two operations and elasticity with a cloud-native architecture
- Including all security-related functions (like MFA, Passwordless) in the core of the product
- Building a solid audit trail through event-sourcing
- Encouraging automation and easy integration of lifecycle management

You will gain a better understanding of IAM concepts and themes such as

- Federation / IAM Service
- Human to machine interaction (SSO, Passwordless)
- Machine to machine interaction (Service Accounts, Delegation)
- Identity Brokering
- User and access management self-service
- Workflow integration with APIs & Webhooks

Speaker: Florian Forster, CEO of CAOS, is an IT security fanatic with extensive knowledge of electronic identities. Florian participated in the IAM workgroup of eCH, is a member of the OpenID Foundation and headed, prior to starting CAOS, an eGovernment team focussing on IAM topics.

## CH Open & CAOS

CH Open is the Association for the promotion of Open Source Software and Open Standards in Switzerland. CAOS manages the open source products ZITADEL and CAOS, and is member of the association since 2021.

## Further resources

- [CH Open](https://www.ch-open.ch/en/)
- [OSS Directory](https://www.ossdirectory.com/)
- [CH Open Business Lunch](https://www.ch-open.ch/ch-open-business-events/ch-open-business-lunch/)


Our live stream from the CH Open Business Lunch event on June 10, 2021

CH Open Business Lunch - Why we built an open source Identity & Access Management


## Tl;dr

Kubernetes clusters along with all the tooling needed for operating a production grade service should be disposable just like its nodes and pods are disposable. This principle enables you to re-architect your whole infrastructure, solve a lot of your present problems and have a good sleep at night for your services’ full lifecycles.

Treating clusters as cattle enables you to run many small clusters, e.g. one for each domain and environment. As a result, you are comfortable with all day-two operations like keeping the Kubernetes, tooling, operating systems and package versions up-to-date, because you have perfect isolation and similar environments.

In order to achieve this similarity, you choose to follow the GitOps pattern, not only for your service deployments to be reproducible. Also the desired states for the tooling, the Kubernetes installation itself, CPU, memory, networking and storage you just declare in Git and let operator binaries do their work. With comprehensive GitOps, you have your day-one and day-two operations automated. And you get disaster recovery for free.

By relying on Vanilla Kubernetes instead of a complex platform orchestration machinery like OpenShift or Rancher and by having your infrastructure providers abstracted, you are free to choose and instantly change your vendors. If there is something wrong with the pasture grass, you just move your cattle somewhere else.

Having the reproducibility from GitOps combined with the flexibility of abstracted infrastructure providers and Vanilla Kubernetes makes treating clusters as cattle really easy. This way of automation enables you to run many small, isolated, secure and service oriented platforms whenever and wherever you need them. Luckily, we invented this wheel called [ORBOS](https://github.com/caos/orbos) already. It’s Open Source Software and free to use for everyone.

## The Shaping of Our Philosophy

We at CAOS AG founded our startup roughly two years ago. Back then, most of us worked on a self-developed Identity and Access Management System (IAM) at an E-Government company. As this IAM has grown in users and traffic, we found that we could massively improve the quality of our highly critical service, if we operated it ourselves on top of Kubernetes. As our company didn’t have any Kubernetes cluster available at that time, nor any experience with Kubernetes, we created and maintained one ourselves using Tectonic, which back then belonged to CoreOS (now RedHat). There is not that much to bootstrapping a new small cluster and we had a quick performance gain with all the convenience Kubernetes has to offer.

Soon, developers from other domains of the company started deploying their applications on our cluster too. It was inevitable that at some point in time we ran into pod limits and other problems that came with the cluster’s scale. Experiencing these issues from a service provider's perspective made us wonder if there isn’t a better solution. We concluded that dedicating a Kubernetes cluster to a service, including the infrastructure and tooling, improves a provider's ability to guarantee its quality. We saw our chance to go to market with a brand new Cloud Native IAM [ZITADEL](https://zitadel.com/) on our own, distinguishing it from other IAM vendors' products by including the automation for small and dedicated Kubernetes clusters.

If you need arguments for running many small clusters instead of a big one and solutions for doing so without increasing your operational costs, read on.

<div className="team-members">
  <img src="/blog/2021-06-30-cattle-not-pets-03.jpeg" alt="Florian" />
  <img src="/blog/2021-06-30-cattle-not-pets-04.jpeg" alt="Christian" />
  <img src="/blog/2021-06-30-cattle-not-pets-05.jpeg" alt="Silvan" />
  <img src="/blog/2021-06-30-cattle-not-pets-06.jpeg" alt="Fabienne" />
  <img src="/blog/2021-06-30-cattle-not-pets-07.jpeg" alt="Max Peintner" />
  <img src="/blog/2021-06-30-cattle-not-pets-08.jpeg" alt="Stefan" />
  <img src="/blog/2021-06-30-cattle-not-pets-09.jpeg" alt="Elio" />
  <img src="/blog/2021-06-30-cattle-not-pets-10.jpeg" alt="Michael" />
  <img src="/blog/2021-06-30-cattle-not-pets-11.jpeg" alt="Jürg" />
  <img src="/blog/2021-06-30-cattle-not-pets-12.jpeg" alt="Livio" />
  <img src="/blog/2021-06-30-cattle-not-pets-13.jpeg" alt="Max Panne" />
</div>

From left to right: Florian Forster, Christian Jakob, Silvan Reusser, Fabienne Gerschwiler, Max Peintner, Stefan Benz, Elio Bischof, Michael Wäger, Jürg Rinaldi, Livio Amstutz, Maximilian Panne

## Isolate Your Domains

Doing DevOps means that dev and ops engineers have a common goal, which is providing good service quality. The ops side traditionally needs to run many services from many domains with different quality requirements on the same infrastructure and platform. This makes it hard to serve the developers the exact infrastructure they need. Imagine each domain has its own production cluster and a set of test clusters. The clusters are guaranteed to never interfere with each other on the operating system level through NFS volumes, resource consumption and the like.

If the tech stack is siloed along its services all the way down to the infrastructure, not only can each stack be precisely tweaked to the domains and services needs. The tweaker is also more confident in doing so, because he is absolutely sure his tweaks have no unforeseen negative impacts on other domains. If something goes wrong, then not the whole company is at risk that the lights go out, but the blast radius is limited to that domain only. The improved confidence leads to more security updates, feature updates and configuration optimization of the infrastructure, tooling and the API Gateway.

<img
  src="/blog/2021-06-30-cattle-not-pets-01.jpg"
  width="100%"
  alt="Fireball Comparison"
/>{" "}

Fireball_comparison_pic.jpg found on [wikipedia.org](https://en.wikipedia.org/wiki/File:Fireball_comparison_pic.jpg)

## Manage Your Desired States Only

You might be thinking that the operational costs would grow almost linearly with the number of clusters. And that’s true for all tasks that you manually execute. Manual tasks are not only expensive and error prone, they also lead to hardly reproducible states which decreases your confidence and performance when doing day-two operations. So you are forced to automate each of them. Currently, the GitOps pattern is gaining adoption for Kubernetes workload deployment. But it’s very suitable for the platform and infrastructure as well. With GitOps, you focus on automating day-two operations and let a system reconcile its current state based on a declared desired state. If anybody changes something in the system, the reconciling operator reverts the changes immediately and brings the system back to its desired state. So with GitOps you are guaranteed to have a self healing and reproducible system over time.

In [this blog post](https://blog.atomist.com/kubernetes-clusters-pets-or-cattle/), David Dooling from Atomist is advocating the GitOps pattern for solving the reproducibility problem too. But he focuses on storing the Kubernetes resources declarations in Git and relies on managed services and third party CLI tools for bootstrapping new clusters. I think this doesn’t scale well if you want to run many small clusters instead of few big ones. If you need to reproduce a cluster along with its infrastructure, you need the desired infrastructure state to be declared somewhere, preferably in a provider independent way. The other point is, that when storing a mess of hundreds of Kubernetes resources in Git for many clusters in a “copy-and-own-way”, your clusters will start to behave differently from each other over time until their differences are not manageable anymore.

[ORBOS](https://github.com/caos/orbos) fills this gap. Our ORBOS operators interpret their self defined desired states and translate them into cloud and Kubernetes resources. This abstraction layer not only leads to having just a fraction of YAML stored in Git, also the differences in cloud provider infrastructure is as minimal as possible and transparent in their YAML. With ORBOS, you can scale to thousands of clusters without having to employ tons of engineers. [Here](https://github.com/caos/orbos/blob/master/examples/orbiter/gce/orbiter.yml) you find an example YAML for the infrastructure and [here](https://github.com/caos/orbos/blob/master/examples/boom/boom.yml) is a dead-simple one for the platform tooling that omits all default values.

<a href="https://github.com/caos/orbos">
  <img
    className="hidden dark:block"
    src="/blog/2021-06-30-cattle-not-pets-14.png"
    width="30%"
    alt="ORBOS Logo dark"
  />
  <img
    className="block dark:hidden"
    src="/blog/2021-06-30-cattle-not-pets-15.png"
    width="30%"
    alt="ORBOS Logo light"
  />
</a>

## Easily Recover from Disasters

When a cluster goes down, you need to be able to bring back your service’s last state from scratch. To prepare for this, you have to make your workload’s state declarable. This means for example, that all database schema changes should be tracked, tied to your services version and re-executable at any time in an idempotent way. For example, we built a ZITADEL operator that uses [Flyway](https://flywaydb.org/). Check it out on [GitHub](https://github.com/zitadel/zitadel). When your whole workload is declared, you can easily replicate it to another cluster. But in a disaster recovery case where the whole cluster goes down, you might be in trouble getting the declarations out of the broken cluster. Here is where GitOps is helping out again, because with GitOps, you have your desired state declarations stored out-of-band. For learning more about our understanding of using GitOps for workload deployment, checkout [Christian Jakob's blog post](https://zitadel.com/blog/dev-gitops-at-caos/) in German.

Now, combine that with a GitOpsed tooling, platform and infrastructure described in the previous chapter. If done right, a comprehensively “gitopsed” environment is absolutely bulletproof in almost all failure cases. As GitOps comes with perfect reproducibility, you can test if you’ve done it right as much as you want just by replicating your systems. Congratulations, from here on, you can just kill your cattle instead of taking them to a doctor like they were pets. For being bulletproof in not almost all but really all failure cases, read on.

<div className="giphy-wrapper">
  <iframe
    src="https://giphy.com/embed/QMHoU66sBXqqLqYvGO"
    width="100%"
    height="100%"
    frameBorder="0"
    className="giphy-embed"
    allowFullScreen
  ></iframe>
</div>
<p>
  <a href="https://giphy.com/gifs/this-is-fine-QMHoU66sBXqqLqYvGO">via GIPHY</a>
</p>

## Avoiding Lock-Ins

Cattle care less about its owner or territory than pets do. A Cluster on Google Compute Engine should be seamlessly reproducible with other cloud providers and also on-premises if your requirements for prices, data policies, locality etc. change. If you use managed Kubernetes clusters like GKE or AKS, you will have many fancy and integrated features like monitoring or networking. This is comfortable but comes at the cost of a vendor lock-in causing much headache when you try to move to another provider. Especially in cases of critical networking or hardware failures you are glad if you have multiple infrastructure providers abstracted so they are at your disposal immediately.

Also, your workload and Kubernetes API should not rely on the cluster and infrastructure management systems. The operator you use should utilize a generic tool like Kubeadm to maintain the clusters lifecycle and avoid depending on critical API server intermediating components that also need energy and time investments. Without these additional moving targets, you are way more safe from getting locked in to the operator vendor. For example, if you would like to stop using ORBOS and move to another infrastructure and platform management, the only thing you have to do is to delete its deployments. If the operator is stopped or the operator throws errors, neither your service quality nor the Kubernetes API is affected.

<a href="https://kubernetes.io/docs/reference/setup-tools/kubeadm/">
  <img
    src="/blog/2021-06-30-cattle-not-pets-02.png"
    width="20%"
    alt="Kubeadm Logo"
  />
</a>

kubeadm-stacked-color.png found on [kubernetes.io](https://kubernetes.io/docs/reference/setup-tools/kubeadm/)

## Real World Experience

Implementing our GitOps operators definitely took some time and energy. But in return, it enabled us to scale massively and maintain many clusters now. Each cluster is perfectly monitored in a centralized Grafana Cloud instance. If something goes wrong, we fix the operators' code and roll it out to all clusters. Instead of accidentally fixing the same issues again and again, we improved the maturity of our operators incrementally. Now they are in a solid state where they just work and let our customers and us have a good sleep each night.

Treating clusters as cattle enabled us to expand our business model in selling our IAM service [ZITADEL](https://zitadel.com) too. We are not only a Software-as-a-Service provider but also deliver the whole automation needed to run instances dedicated to customers in isolated environments of their choice too. It is crucial for many companies to have full control over all user data stored in our IAM solution, so they often need dedicated instances deployed in their own data centers. An IAM is a mission critical central system that has high quality and scalability requirements to the infrastructure. With our automation, customers yet do not have to assign engineers to the task of operating our product. So the costs that our product causes over time keep being limited and calculable, thanks to our GitOps operators. This gives us a significant advantage over our competitors.

Apart from selling ZITADEL, ORBOS also gave us the opportunity to offer maintenance and support for dedicated Kubernetes clusters. Also, there is a tech company that is running about twenty Kubernetes clusters using ORBOS, split along its domains. Another software agency is running their services on multiple ORBOS managed Kubernetes clusters dedicated to end customers.


I’m sure you know the phrase “treat NODES as cattle, not pets”. It means that we’d rather just replace a “sick” instance by a new healthy one than taking it to a doctor. We take it to another level and say “treat CLUSTERS as cattle, not pets”.

Treat Kubernetes Clusters as Cattle, Not Pets


## Introduction

Last week, something exciting happened: We were actually able to physically attend an event hosted by the [Research Center for Digital Sustainability](https://www.digitale-nachhaltigkeit.unibe.ch/index_eng.html) from the University of Bern. The main reason for the event was the publication of this year’s [Open Source Survey](https://oss-studie.ch/), but for us it was also a great opportunity to learn more about how other companies use or develop Open Source, build communities, and define the cultural aspect around Open Source. And if that was not exciting enough: actually being able to talk to other people over a cold beverage was definitely a big plus after the past months.

I want to share some insights and thoughts about the study, conversations and talks from the event, and finally about our Open\* journey with you.

## Open\*

In the [first talk of the event](https://www.digitale-nachhaltigkeit.unibe.ch/unibe/portal/fak_naturwis/a_dept_math/c_iinfamath/abt_digital/content/e90973/e1045995/e1046107/e1092040/e1092041/01DominicBranderSnowflake-Interoperabilitt_ger.pdf), Dominic Brander introduced us to the term Open\*. That term not only suggests being mindful about including others [1], but also makes it easy to refer to the broader context of Open Source, Open Data, and Open Standards.

I like this term. It makes things easier. And what I realized is that for us, and apparently for others as well, Open Source is not only about letting others see your code, Open Standards is not only about agreeing on a common denominator, and Open Data is not only about getting free data for your school work. It’s much more a cultural thing, for example a culture of trust, enabling collaboration yet not only through interoperability, but of transparency.

I will use the term in this article and most likely in the future.

<sub>
  [1] ‘*’ is also referred to as ‘Gender star’ and is a form to provide gender
  neutrality in a language that otherwise has a grammatical gender.
</sub>

## Insights from Swiss companies

My intention is not to comment on the study, but rather point out some subjectively interesting points for our business and our business area. I realize the study is only available in German, even more motivation to share some insights.

49% of participating companies (N ~150) declare themselves as “heavy users”, using Open Source in more than half of the suggested 28 categories. This figure is up from 29% in 2018. The study offers no more insight on share of total software used within a company, but this is still a good indicator that Open\* solutions are valued broadly.

Interestingly, “Interoperability” is both the top reason FOR and second most important obstacle AGAINST adoption of Open Source in organizations. This point was also discussed by Dominic in his talk: Open* != Interoperability, meaning being an Open* product is not a sufficient condition for being interoperable with every other product. We have to work on interoperability and need to get better at it.

Overall the top 5 objections mentioned against using Open Source:

- Uncertain future of Open Source projects, unclear business model
- Missing integration with other systems
- Lock-ins with current, proprietary system
- Missing features, no matching Open Source alternatives
- Lack of acceptance by end-users, not user-friendly

The authors argue that maintainers/vendors must provide more transparency on the long-term development of their products, coupled with overall more information about the Open Source business model. Likewise the authors urge Open Source communities to become more (end-)customer-centric and generally more accessible.

I fully support that. The same seems to be valid here as for the interoperability argument:  
Releasing your product under an Open License is not sufficient to immediately establish trust and gain a dominant competitive advantage over other solutions out there. Trust and product-leadership also comes from a clear goal with a plan and means to reach and satisfy your users’ needs (aka. “business model”).

Similarly, sharing your project using an Open License and making some processes more transparent out in the open, does not mean these processes are customer-centric. Customer centricity does not mean to collect and work through feedback, but rather to go through a phase of pattern finding, developing innovative ideas for these problem fields, and iterating potential solutions as early as possible with end-users (aka. “innovation process”)

So despite the objections, why are we in the Open\* game?

## Our motivation for Open\*

**Open Standards:**
Thoroughly reviewed, battle-tested protocols and processes are key for developing an application like ZITADEL, that serves as a serious trust anchor and holds sensitive data. We implement open standards wherever possible to guarantee the security and interoperability of our systems.

**Open Source:**
Use of our application is based on trust. Building this trust is demanding, but can be achieved amongst others with transparency and security at the core. Thus our code that runs on our shared-cloud service is shared openly along with our processes, availability strategies and providers (see [Trust](/trust)).

**Open Licence:**
We say “Own your data!”, some others call it “Digital sovereignty”. We both mean the same thing: Reducing vendor lock-in, dependence on a single platform, and the ability to process and store the data wherever you want - even without commercial support. Our software is licensed under Apache 2.0.

**Open Platform:**
We want to focus on what we do best, namely developing and operating an identity and access management system for SaaS-providers. Our users should be able to build their use cases on our platform, and integrate their favorite services with it. That’s why we employ an API-first approach and expose all functions via gRCP, REST and Webhooks.

**Open Community:**
We welcome contributions in every shape and form, and appreciate the time people invest. Eventually the discussions, external challenges, contributions to the platform or our business help us to get better every day and be open for new and innovative ideas.

For us the use of Open\* is much more a mindset that is reflected in our vision, strategy and architecture of our products, than just a process to follow or licence to grant.

What I realized while reflecting on this article is that we might want to figure out how we want to deal with Open Data in the future.

Now to the party-crasher: Sure, we can talk about Open Licenses etc, but should you trust us not pulling a [MongoDB license stunt](https://www.mongodb.com/licensing/server-side-public-license/faq)?

## Thoughts on SSPL license

Another particularly [interesting talk](https://www.digitale-nachhaltigkeit.unibe.ch/unibe/portal/fak_naturwis/a_dept_math/c_iinfamath/abt_digital/content/e90973/e1045995/e1046107/e1092040/e1092047/07SimonSchlauriRonzaniSchlauri-SSPL_ger.pdf) at the event was held by Simon Schlauri on the Server Side Public License (SSPL) and its implications. The situation is as expected: Organizations can publish their code under an SSPL license, so that a SaaS offering would be conditional to a copy-left license. This is concerning for many users who are not the main target of this license (ie. ‘Big Tech’). Lawyers already found clever ways to circumvent the copy-left part, if you still don’t want to pay a license. Frankly, it’s a messy business.

We have discussed the different options for licenses and decided for an Apache 2.0 license. Our business model is inspired by companies like Gitlab that are known for their great Open Source community and through that also being successful as a company.

## Does Open\* have any value, then?

Just right away - the thoughts mentioned above have non-monetary value on their own. Both for us and our users. Trust in our product and our team holds for us as a company and maintainer the greatest value.

We earn our salaries by offering ZITADEL, our identity and access management platform, as a service and charging a monthly subscription for support and some non-security related features. Moreover we offer managed instances or 3rd level support for customer instances. Yet you can use ZITADEL completely for free either by running it yourself or by using our free tier. Keeping up to date with security risks and operating the system in more complex and highly scalable scenarios (e.g. geo-redundant or hybrid setups), that is where we excel through our knowledge and experience. Hence our slogan “always run a changing system”. And ,at least for now, customers are happy to pay for this.

Regarding company value: From my experience until now I can say that neither the tax office nor investors make a big difference between open and closed source. Both parties are whether you have the ability to generate sustainable cash flows with the product. Sure, a patent would help to secure some kind of competitive advantage for a certain time, but in the SaaS world the proof lies in the scalable customer base.

During the event Peter Balsiger also remarked in [his talk](https://www.digitale-nachhaltigkeit.unibe.ch/unibe/portal/fak_naturwis/a_dept_math/c_iinfamath/abt_digital/content/e90973/e1045995/e1046107/e1092040/e1092044/04PeterBalsigerRedHat-CommunityEnterprise_ger.pdf) that IBM paid $34bn in 2018 to acquire Red Hat. That has been by far the biggest deal yet, but 2018 was really a [breakthrough year](https://www.wired.com/story/why-2018-breakout-year-open-source-deals/) regarding Open Source deals, affirming that Open Source companies are valuable.

## Afterthought: Contributing to Open Source as non-techie

After the end of the official event, I had a great conversation with Jannis Valaulta. You can check out [his talk](https://www.digitale-nachhaltigkeit.unibe.ch/unibe/portal/fak_naturwis/a_dept_math/c_iinfamath/abt_digital/content/e90973/e1045995/e1046107/e1092040/e1092042/02JannisValaultaAdfinis-DigitaleSouveranitat_ger.pdf) on digital sovereignty (“Own your data!”, remember?).

I posted the question how “non-techies” could approach contributing to Open Source. For me, as someone with an economics rather than engineering background, the contribution to Open Source projects seemed limited, since “I can’t contribute to fixing or improving stuff”. Other areas as Open Data seem much more approachable for me.

His recommendation was to start with contributing in your area of expertise, optimally in an upcoming hackathon. As an example a designer could contribute with graphics, logos or websites during the hackathon. Similarly, someone with an UX background could help to improve acceptance of users, and someone with a business background could support with figuring out the economic feasibility of the solution for both, customers and providers.

That suggestion seems trivial, but for me that was not so explicitly clear. I realize from my own experience that you most likely can’t excel in all areas that are required to operate a successful Open Source business and outside suggestions are always appreciated. So I think, the next time I might just offer my support, being also open to receive a “no thanks”.

## Great, now what?

If you want to learn more about the study and the talks:

- [View](https://oss-studie.ch) and download the study (German)
- [View](https://www.digitale-nachhaltigkeit.unibe.ch/dienstleistungen/auftragsforschung/oss_studie_2021/index_ger.html) and download all slides and view the talks (German)
- Checkout the Association for the promotion of Open Source Software and Open Standards in Switzerland
- Open Source [activity tracker](https://ossbenchmark.com/) of Swiss companies
- [Directory](https://www.ossdirectory.com/) of Swiss open source solutions

_Unfortunately the event was hosted in German only. Translating the website worked for me partially. Let me know in case you are interested but need help with the language part._

If you’re interested in our projects:

- Checkout our [Github](https://github.com/caos) with the two main projects [ZITADEL](https://github.com/zitadel/zitadel) and [ORBOS](https://github.com/caos/orbos)
- Do you want to share or ask something? [ZITADEL Discussions](https://github.com/zitadel/zitadel/discussions) and [ORBOS Discussions](https://github.com/caos/orbos/discussions)
- Can you [help us get better at engaging](https://github.com/zitadel/zitadel/discussions/1919) our Open Source community?
- Do you have [suggestions on how to make it easier to contribute](https://github.com/zitadel/zitadel/discussions/1920) to our project?
- Want to start contributing? Grab a [“good first issue”](https://github.com/zitadel/zitadel/issues?q=is%3Aissue+is%3Aopen--+label%3A%22good+first+issue%22) and checkout [how to contribute](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md)


What is our motivation for Open Source? Does it bring value to our business? Allow me to share some thoughts on an Open Source study and motivation for Open* with you.

The value of Open*


IMO = In My Opinion is a blog format where a author reflects his own opinion

With the recent announcement of Apple at their annual Worldwide Developers Conference (WWDC) 2021, our perception of how secure authentication should work will gradually shift towards a passwordless future.

The new(est) innovation from Apple to get rid of passwords and second factors is called “Passkeys in iCloud Keychain”. It basically works with the WebAuthN API by utilizing the FIDO2 specification (CTAP2) to create a private / public key pair for each login system. This is normally identified by its domain name of the server challenging your device for authentication. For this to work across devices it is necessary to synchronize the private key in some way.

[Edit: The video has been removed from youtube. You can watch it on developer.apple.com](https://developer.apple.com/videos/play/wwdc2021/10106/)

But wait … synchronizing a private key across your devices with a cloud solution does not sound exactly … sane!  
Well, ok. Let's argue for a minute what the “normal” user does anyway. Many users today rely on password managers to synchronize their passwords and sometimes even their second factors. By doing so, they already expose their secrets to some provider, for example Google, Apple, Microsoft, 1Password, and so on. Even if those providers claim that the secrets are encrypted, it is not a penny better from a security perspective than the synchronization of a private key with the same process. In the end, all private keys, passwords and OTP seed secrets are all **secrets** which allow access to your resources.

But then again, some of you might argue: “I totally control the sync process with a software I run on my own!”  
Well that does not really change the statement above because you end up using a device from one of those vendors anyway and most of them are closed source, so you have absolutely no guarantees that they don’t steal your credentials on the OS level anyway (some exceptions apply - looking at you Linux and to some degree Android).  
To make things worse on an OS or even browser level. Something, like a malicious browser extension or trojan horse, could steal things like access_token or cookies, which broadens the threat model a lot towards OS and browsers.

Oh and to make things worse… Out of band processes like OTP, SMS-TAN and email codes don’t help this effort. If you gain access to either the user's device, OS, or browser, then your whole security model is broken anyway. This is because a lot of today's users just use one device in which they login and also store, receive or generate their second factor.

Ah and yes don't even get me started about those pesky banking authentication apps!

So with this in mind is it still a bad thing to sync the private key?

Well, in my opinion, even with all the downsides like synchronization of private keys (secrets in general) we still gain an **improved user experience** and **phishing resistance**, which I find important these days **without any additional risk** (remember you have them anyway). Also, we reduce the attack surface by **preventing credential reuse** by the user.

So if you ask me: The tradeoff made here by Apple does outweigh the risk. And if you think this risk is too high for you, then just do not use iCloud Passkeys (and password managers in general) and stick to hardware keys.  
If you really care about security you would end up with mTLS (mutual TLS) anyway because this is the only way to mutually authenticate connections and mitigate Man-in-the-middle risk more or less completely (which FIDO2 does not). But this is a topic for another time.

If you want to test iCloud Passkeys today you are best off to use iOS 15, iPadOS 15 or macOS Monterey. Optimally you have multiple devices to see whether the keys get synced across your devices with iCloud Keychain.

As of today more and more systems and services offer the use of passwordless authentication methods. For example your Microsoft Login can be used in this way. Popular Open Source IAM Solutions like Keycloak also give you the option to use passwordless. Our IAM as a Service project ZITADEL does also provide support for the password authentication future.

But remember: Passkeys in iCloud Keychain are **not production ready yet** (technology preview) and are intended for testing only. So for your own sake, please register a fallback hardware key like the ones from our friends at SoloKeys or YubiKey. We recommend you to register multiple keys anyway.


Apple spearheads the push to a passwordless future. But is their proposal to sync your private keys with their iCloud a good idea?

IMO - Passkey in iCloud Keychain


## Introduction

As you have seen from the first part, ZITADEL runs on Kubernetes. You can use any available cluster with the minimal requirements needed to run ZITADEL (SMTP, SMS-Service, Database, Domain), and get started quickly with [ZITADELCTL](https://github.com/zitadel/zitadel/releases/latest). Use [ORBOS](https://github.com/caos/orbos), maybe tailored to use **your** favorite tools, to automate most of the infrastructure and tools.

Where the goal of the [first part](/blog/where-to-start-running-zitadel-1) of this article was to give you some guidance where to start with try or run ZITADEL on your own, in this sequel I want to give you some more insight how we run our ZITADEL SaaS.

## Our current infrastructure & tools

The current infrastructure is centered around locations in Switzerland and for this we use GCE’s compute instances to then manage everything on top through our product [ORBOS](https://github.com/caos/orbos).

As the following components are changeable and this is just our preferred toolset, if anyone needs or wants to use something different, this should be possible without any issues, just ignore our recommendations.

So we have the managed VMs, we use the combination [NGINX](https://www.nginx.com/) and [firewalld](https://github.com/firewalld/firewalld) to handle connections on the node and routing outside the cluster, Kubernetes with [Calico](https://github.com/projectcalico/calico), [Ambassador](https://github.com/datawire/ambassador) inside the cluster with NodePorts to provide connectivity and routing on the inside. Backups are currently made to Google Storage Buckets with CockroachDB native full backups, which makes the restore functionality easier to maintain. To hold metrics and logs to conveniently operate ZITADEL or any other tool we use, there also runs [Loki](https://github.com/grafana/loki) and [Prometheus](https://github.com/prometheus) inside the cluster and the visualization and alerting is possible through [Grafana](https://grafana.com/). We also use some operators that help us to maintain our tools, but maybe this will be a topic for another post.

## Why our Stack

So to just visualise our stack that was described in the section before:

<img
  src="/blog/2021-06-02-where-to-start-running-zitadel-2-01.png"
  width="100%"
  alt="our stack to run ZITADEL"
/>

As base we use VMs of the Google Cloud Engine because we can limit the region and zones so that we can hold our data still in Switzerland but at the same time we can use multiple zones for high availability. The usage of other hyperscalers where you can limit the resources to Switzerland would also be possible, but as we had prior experience and it covered everything we needed, we decided to go with Google Cloud initially.

We decided to make our own Kubernetes automation to provide a platform as a decentralised solution in combination with the advantages of Kubernetes, the usage of already available and tested tools and possibilities of GitOps.

As we want to use already existing tools, one part of ORBOS is the deployment of a set of tools in defined versions with additional integration of the components themselves, for example the scraping of all metrics of the toolset. The result is that there exists one file that contains all necessary configuration for the whole toolset.

Which results in a constellation on the cluster as follows:

<img
  src="/blog/2021-06-02-where-to-start-running-zitadel-2-02.png"
  width="100%"
  alt="our cluster to run ZITADEL"
/>

As our CDN/DNS we use [Cloudflare](https://www.cloudflare.com/) to register subdomains and define firewall-rules, the connections to the subdomains end up on the Ambassador in-cluster and will get routed to the ZITADEL pods. The database we currently use is CockroachDB, as mentioned before, and all backups are made into a Google Cloud Bucket.

For monitoring and alerting we use the combination of Loki (log persistence), Prometheus (metrics persistence) and Grafana (visualisation and alerting) as this combination is widespread and battle-tested, this components could be changed to other solutions but for our goal to be decentralized and low resource consumption we are really comfortable.

## Planned changes in the near future

To further improve the functionality of ORBOS we have different things in the pipeline. One of these is the possibility to use VMs of different zones on Google Cloud to have more options to provide high availability, another is the addition of different implementations of storage options to use for backups. As well as improvements on our own tooling, the current used version for Kubernetes and the used tools will get routinely updated and moved to the newest version. The operators will get new releases as well as the IAM gets new releases, where the operators will as mentioned self-reconcile if you just change the version in the configuration.

## Make or buy?

As you just read and also see in our other blog post “[Always run a changing system - The CAOS approach](/blog/always-run-a-changing-system)” we are all for it to use already implemented tools to make our work easier, but we automate everything we can so we don’t have to do thing multiple times by hand. At the same time we also have to maintain our own code with new releases from the used tooling.

There are advantages and disadvantages to this pattern, but currently the advantages overweigh. As you say “horses for courses”, we use tooling for tasks that are uniformly done for applications, but provide operators for tasks that are specific to ZITADEL, which also integrate the tools with each other.


Part (2/2) As you have seen from the first part, ZITADEL runs on Kubernetes. You can use any available cluster with the minimal requirements needed to run ZITADEL (SMTP, SMS-Service, Database, Domain), and get started quickly with ZITADELCTL. Use ORBOS, maybe tailored to use your favorite tools, to automate most of the infrastructure and tools.

Where should I start if I want to try out or run ZITADEL?


## Where should I start if I want to try out or run ZITADEL?

The first step to integrate a new application into an existing infrastructure is always to determine what the requirements are and the process you need to follow until it is ready to start with the first tests. See what we prepared to make it easy for you to start with ZITADEL and how few requirements you have to try out ZITADEL in the near future yourself.

## What is ZITADEL

ZITADEL is a "Cloud Native Identity and Access Management" solution built for the cloud era. ZITADEL uses a modern software stack consisting of Golang, Angular and CockroachDB as storage and follows an event sourced pattern. The Project is Open Source and we offer a SaaS solution or managed instances. Our approach is somewhat different to other open source alternatives, as we want to ship the APIs, GUIs, Database, and, if necessary the infrastructure automation, together for secure and easy day 2 operations.

To get more information about ZITADEL you can head over to our Website [zitadel.com](https://zitadel.com) or to the published blog "[Our Vision for ZITADEL](https://zitadel.com/blog/our-vision-for-zitadel/)" and if you want to try out ZITADEL without the hassle to prepare infrastructure or to just integrate an IAM into you application then I would recommend to use our cloud service at [zitadel.com](https://zitadel.com).

## What is ORBOS

In this post I will sometimes mention [ORBOS](https://github.com/caos/orbos), which is our solution to provide you with our option of optimal automation to streamline your ZITADEL, or any other application for that matter. It consists of different types of operators, where every single one covers a different component from infrastructure to Kubernetes, ops-tooling, networking, database and also ZITADEL.

## Where do I start?

As I already mentioned, if it’s just to test ZITADEL I would recommend registering your organisation on [zitadel.com](https://zitadel.com), otherwise there are still a lot of possible options. Our focus will be to run ZITADEL on a Kubernetes cluster, so as long as you have a Kubernetes cluster available in any way, you can use ZITADEL. Other constellations are possible as well, but we will currently only focus on running ZITADEL on Kubernetes as it brings so many advantages with the provided orchestration.

<img
  src="/blog/2021-05-27-where-to-start-running-zitadel-1-01.png"
  width="100%"
  alt="options to run ZITADEL"
/>

There are different points where you can start off to get a working Kubernetes cluster, if you not already have one available already:

- Managed K8s-cluster with GKE, Amazon EKS, AKS
- No available K8s-cluster, but an account on a Hyperscaler for VM provisioning (for example Google Cloud)
- No available K8s-cluster, but an account for a VM-provider(for example Cloudscale)
- No available K8s-cluster, but available VMs or servers internally

If you currently have no available cluster and don’t/can’t use any managed instances, you can use [kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/) or our product [ORBOS](https://github.com/caos/orbos) to quickly have one up and running on any VMs or hardware-nodes you have available.

We focus fully on the operator pattern to manage our infrastructure and our applications on the resulting Kubernetes cluster, which gives us full control over the applied resources and the possibility to reconcile the current state with the desired state. For example, if you want to upgrade an application, you only upgrade the operator and the newly deployed operator will take it from there.  
To make it as easy as possible upgrading to a newer version, the operators are self-reconciling, which is only possible through the orchestration-functionality of Kubernetes and provides the option to change the desired version of the operator in the respective desired state and the operator will deploy itself with the newer version.

## How do I start with ZITADEL

The fastest way to start ZITADEL in your cluster is currently to use our provided [ZITADELCTL](https://github.com/zitadel/zitadel/releases/latest) and all the necessary steps are explained in our [quickstarts](https://docs-v1.zitadel.com//docs/guides/installation/crd). As result you will have two running operators in your cluster, that start ZITADEL and CockroachDB in your desired configuration. These operators can be run in two modes, the [GitOps-mode](https://docs-v1.zitadel.com/docs/guides/installation/gitops), which reads the desired configuration out of a git repository, and the CRD-mode which reads the desired configuration out of an CRD inside the cluster.

Our recommendation is to run the operators in [GitOps-mode](https://docs-v1.zitadel.com//docs/guides/installation/gitops), to always have the desired state reconciled into the cluster, but it’s also possible to start the operators in [CRD-mode](https://docs-v1.zitadel.com//docs/guides/installation/crd) and provide the configuration you want to see in ZITADEL as CRD, which you can also reconcile with a GitOps-tool like [ArgoCD](https://github.com/argoproj/argo-cd) or [Flux](https://github.com/fluxcd/flux) if you still want to work with the GitOps-pattern.

## Requirements to run ZITADEL

First off, there are minimal requirements to run ZITADEL which also depend on how you intend to use it and on what functionality you need. That being said, for this we go for a full configuration to provide an example to run ZITADEL with all functions it provides.

The requirements can be split into three groups:

- “used by ZITADEL”
- “needed to run ZITADEL”
- “optional to better operate ZITADEL”

<img
  src="/blog/2021-05-27-where-to-start-running-zitadel-1-02.png"
  width="100%"
  alt="requirements to run ZITADEL"
/>

Let’s start with the **requirements which are used**, to this group belongs the SMTP configuration to be able to send emails, access to a Twilio account to send SMS’s and a database to store the data which has to be [CockroachDB](https://github.com/cockroachdb/cockroach) currently.

For the group **“needed to run ZITADEL”** there is only the need for a domain, where different subdomains can be registered to point at ZITADEL, optional through an Ingress/ API-Gateway/ LoadBalancer which manages the connections from outside the cluster to inside.

In **“optional to operate ZITADEL”** are some components that are less important for a first test, but will get more important later. Most functionalities are covered through our second product ORBOS with a component called BOOM which reconciles a defined toolset. If you need to manage the infrastructure yourself and/or can’t use BOOM then take this as our recommended components to add to your ops-stack.  
As with most of the current applications you have exposed metrics from ZITADEL in format of the [Prometheus data model](https://prometheus.io/docs/concepts/data_model/) which can be handled by most current time-based databases. Some examples for this are (obviously) Prometheus, [OpenTSDB](http://opentsdb.net/), [InfluxDB](https://www.influxdata.com/) and a lot of others. Besides the metrics there are also logs which can be persistent to have the ability to analyse them if an error occurs.

---

Stay tuned for the second part where I will provide more details about our current setup to run [zitadel.com](https://zitadel.com).

---

Stefan is a software engineer specialized, amongst many other domains, in DevOps and is deeply committed to Cloud Computing. When he's not listening to music while typing away, you may spot him cruising the mountain roads by motorcycle or car.

<div className="flex items-center">
  <img
    src="/blog/2021-05-27-where-to-start-running-zitadel-1-00.jpeg"
    width="60px"
    height="60px"
    alt="Stefan Benz"
  />
  <span className="mx-2 flex items-end">
    <span>Follow Stefan on&nbsp;</span>
    <a href="https://twitter.com/stebenz1" target="_blank" rel="noreferrer">
      Twitter
    </a>
    <span>&nbsp;or&nbsp;</span>
    <a
      className="m-0"
      href="https://github.com/stebenz"
      target="_blank"
      rel="noreferrer"
    >
      Github
    </a>
    <span>.</span>
  </span>
</div>


Part (1/2) The first step to integrate a new application into an existing infrastructure is always to determine what the requirements are and the process you need to follow until it is ready to start with the first tests. See what we prepared to make it easy for you to start with ZITADEL and how few  requirements you have to try out ZITADEL in the near future yourself.

A company's way to build and deploy modern software comes with many different advantages and disadvantages, joy and sweat in real life. See which challenges we had or still have and which strategy we follow to deal with it.

Always run a changing system - The CAOS approach


## What is ZITADEL

ZITADEL is a "Cloud Native Identity and Access Management" solution built for the cloud era. ZITADEL uses a modern software stack consisting of Golang, Angular and CockroachDB as sole storage and follows an event sourced pattern.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-01.png"
  width="100%"
  alt="ZITADEL Architecture"
/>

We built ZITADEL not only with the vision of becoming a great open source project but also as a superb platform to support developers building their applications, without need to handle secure user login and account management themselves. By platform we mean a system where multiple parties can integrate custom use-cases for digital identities on top of solid core features. To enable easy integration into your business case, nearly all functions can be accessed via an API. With this we achieve a proper separation of concern and don’t need to integrate custom code within our codebase.

## What features does the platform provide?

### Single-Sign-On / Single-Sign-Out

Use the convenience of a single sign-on (SSO) solution to login with every possible service. ZITADEL enables SSO via standard protocols such as OpenID Connect. Services that cannot be directly integrated can be integrated with identity aware proxy or web application firewalls (WAF). Session management is therefore handled identity-based within identity access management (IAM) and no longer solely in the application. In addition, third-party cloud applications can be easily connected in this way.

### Passwordless / Multi-factor authentication

Although you can use password policies and a range of 2FA and MFA options with ZITADEL to reduce security risks during login, even complex passwords can be compromised, for example through phishing, while user experience suffers greatly from cumbersome passwords and looking up secrets. ZITADEL allows your users to configure passwordless Login based on WebAuthN & CTAP (FIDO2). Passwordless works on all browsers and platforms, requires only one gesture such as FaceID, Fingerprint or PIN, and is phishing resistant through public-key cryptography.

### Identity Brokering

Identity Brokering enables you and your customers to reuse existing identity providers. For example, if you rely on Microsoft's AzureAD for identity management, then you can use ZITADEL’s Identity Brokering feature to link your existing account from AzureAD to your ZITADEL account. The benefits of this feature is that a user can link multiple external identities to it’s ZITADEL identity. Moreover, Identity brokering enables you to grant roles to the brokered users and disable their accounts if the need arises.

### Role Based Access Control

To manage the users' access to projects connected to ZITADEL it supports the use of Role Based Access Control (RBAC). RBAC allows you to design a sophisticated role catalog for each of your projects and granting granular access to users. To integrate these roles into your application you can simply integrate them by utilizing well established protocols like OAuth 2.0 and OpenID Connect. ZITADEL also lets you configure whether you want to assert the roles into access tokens or simply rely on the userfinot and introspect endpoints.

### Delegation

ZITADEL allows you to “delegate” roles of your projects to other organizations. With this feature you can enable other organizations to self-manage their users and the effective role they possess of your project. For example if you create an eCommerce service and you want to delegate the management of a specific tenant to your customer you could easily create a role “tenant owner” which you could grant to the customers organization.

### Strong Audit Trail

Traceability is an important basis for an IAM, which is why ZITADEL offers you an audit trail of all operations of an account and its actions. The audit trail is firmly anchored in the ZITADEL because the internal data model does not save it separately but derives it from an event stream. You have the ability to export the audit trail for advanced analytics or storage to other systems.

### API’s

To make for a great IAM platform ZITADEL provides close to all of its functionalities as APIs. Most important for integrators is the Management API: It provides all features to manage Organisations, Users, Projects for a certain Organisation. Furthermore OpenID Connect 1.0 and OAuth 2.0 are available to integrate your projects Authentication and Authorization requirements. Two more API’s that are available are the IAM and Auth API. The IAM API can be used to configure the whole IAM, this is mostly used in self-deployed (ZITADEL Enterprise) or managed deployments (ZITADEL Enterprise Cloud). Authentication and user information can be accessed through the Authentication API.

## How ZITADEL compares to other solutions

Let’s compare ZITADEL to other well established solutions with a strong focus towards Developers or Open Source.

### Auth0

Auth0 is a great IAM platform to integrate with your projects. Their developer support is exceptional and the API is well thought through. However we find that some things are not ideal, such as pricing, Closed Source, Audit Trail and improper on-premise support.

Where Auth0 is more mature

- More Protocols Supported (e.g SAML 2.0)
- Customization Support (Rules, UI, and so on)
- More stable API’s
- A lot of documentations and howtos

Where ZITADEL excels

- Runs on any cloud provider and on-premise (Cloud-Native)
- Built for multi-tenancy and [self-service delegation](https://zitadel.com/docs/guides/manage/console/organizations/)
- Better Audit Capabilities
- Tiered pricing depending on SLA and non-security requirements

### Keycloak

Keycloak is a mature IAM System with a lot of great features. It is also Open Source with an Apache 2.0 license (like ZITADEL) and has a well established reputation.

Where Keycloak is more mature

- More Protocols Supported (e.g SAML 2.0)
- Better customization (Private Labelling)
- Big Community

Where ZITADEL excels

- Built for Cloud-Native
- Better Audit Capabilities
- Multi- Cloud / Datacenter Support
- Less Resource Requirements

## Platform ecosystem

We think ZITADEL is a great platform for third parties (and ourselves) to integrate business requirements on a robust platform and enable people to build business value instead of focusing on secure Authentication and Authorization implementations.

In this chapter we will provide some use-case where ZITADEL can help you excel.

### Network Integration, Identity Aware Proxy (Zero Trust)

If you use ZITADEL, you can easily integrate your network equipment (Reverse Proxy / WAF) with ZITADEL for things like secure authentication. For example you might want to enforce multi-factor authentication when a user is not at a trusted site. Your identity aware proxy could easily (re)authenticate the user when someone leaves a trusted site by prompting for a more secure authentication method. ZITADEL will then proceed with ensuring the more secure method.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-02.png"
  width="100%"
  alt="Zero Trust"
/>

### Custom User Registration

If you have special requirements for your user registration (KYC, eHealth, eGovernment), you can easily rely on ZITADEL to build your own registration process by integrating your project with the ZITADEL management API. By building your integration you can reuse existing features to manage identities from our platform and combine them with your unique registration requirements.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-03.png"
  width="100%"
  alt="Custom User Registration"
/>

### Business Process integration (SaaS, MSP)

When building a service for your customers you may want to integrate your access management process into your order management. For example, if you have a SaaS solution where a customer can set up a new tenant by himself, you can delegate the ability to manage their own users directly to the customers. This may greatly reduce support requests from customers to setup users and access rights. With ZITADELs unique self-service capabilities it's even possible to let your customers register their existing identity solutions on their own.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-04.png"
  width="100%"
  alt="Business Process integration"
/>

### Custom Lifecycle Requirements (HR Systems)

If your business already has some systems in place that are responsible for managing your Human Resources or Business Processes, you can easily integrate them with ZITADEL. For example, if you have an HR System which already manages the employee lifecycle, you can use ZITADEL to handle the users identity, but leave the business process in the proper domain - within your HR System. With this approach you can reuse your employee process (joiner, mover, leaver) without leaking business processes into the IAM platform. We think that an IAM platform should not be the component in your architecture which executes business processes. Because if you implement business processes from domains like HR, CRM into the IAM Domain, you will eventually create a IAM which can not be easily replaced even if you use standard interfaces.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-05.png"
  width="100%"
  alt="Custom Lifecycle Requirements (HR Systems)"
/>

### Custom Access Management Requirements (ITSM)

Quite a lot of companies already rely on IT service management (ITSM) systems like ServiceNow to handle their fulfillment processing (access request, account reset, etc.). In such cases it makes sense to leave the IT service workflows in the tool that is optimized for business processes and integrate ZITADEL as an access Management system. Such an integration allows you to fully integrate your IT services process. For example the account of a user could be locked from the ZITADEL management interface and the unlock process could be built as a workflowinto your ITSM. This helps you build and maintain lean processes with low implementation and change cost.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-06.png"
  width="100%"
  alt="Custom Access Management Requirements (ITSM)"
/>

### Custom Sync of data (Sync any data source)

ZITADEL’s APIs enable you to manipulate and synchronize data from any system. For example, you can sync your applications users list with ZITADEL and even change user data from within your application. All of this without relying on ZITADEL’s management interface (console). If you care about a deep integration of the user experience this is a great way to enable your project. Furthermore some applications require an up-to-date list of all users for their processes. These applications can easily query ZITADEL for said data.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-07.png"
  width="100%"
  alt="Custom Sync of data"
/>

## How people use ZITADEL

Most of the time, our customers choose to use our platform's core features like Authentication and Authorization by utilizing protocols like OpenID Connect and OAuth 2.0. But in some cases they integrate even deeper with our API to improve their time to market, operational efficiency and security. Read about what people have already built in this chapter.

### Integration Case - Task Management

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-08.png"
  width="60%"
  alt="Hygeia"
/>

One of our customers built a SaaS Service for tracing pandemics. Right now this solution is used to trace the SARS-CoV-2 spread in some parts of Switzerland.
The special integration in this case is that the workers who use the solution need to be able to assign work to entitled people. To accomplish this, the software utilizes a service account to query ZITADELs management API in a scheduled manner and syncs this list into their database. With this they are able to provide an up-to-date list of all entitled users. Further ZITADEL enables their development by providing an IAM as a Service model, where CAOS takes care of all operation security questions.

Kudos to [JOSHMARTIN](https://joshmartin.ch/) for helping us through the pandemic by providing the government with a progressiv application that really enables the tracing effort.

**Used Features**

- Authentication (incl. MFA, Passwordless)
- Authorization
- OpenID Connect / OAuth 2.0
- Management API, Query Granted Users
- Service Accounts

**Tech Stack**

- Elixir
- Phoenix Live View

**Resources** <br></br>
[joshmartin.ch/en/projects/kanton-st-gallen-contact-tracing/](https://joshmartin.ch/en/projects/kanton-st-gallen-contact-tracing/)

### Integration Case - eCommerce Framework

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-09.png"
  width="60%"
  alt="Velox"
/>

The great people of [sly](https://sly.ch) are building a modern microservice oriented headless eCommerce Framework called [VELOX](https://velox.swiss) and choose ZITADEL as the solution for handling all of their authentication and authorization needs.

Kudos to sly for creating such a great and adaptive eCommerce solution!

**Used Features**

- Authentication incl. multi factor
- Authorization
- Single Sign On
- OpenID Connect / OAuth 2.0
- Management API
- Service Accounts

**Tech Stack**

- Java

**Resources** <br></br>
[velox.swiss](https://velox.swiss)

### Integration Case - multiple ASP.net Core Projects

The Zurich located development agency called [smartive](https://smartive.ch/) utilizes ZITADEL for their projects. As they often rely on ASP.net Core to build award winning projects they wanted to improve their time to market. To integrate ZITADEL with the existing Microsoft authorization ecosystem, they implemented the .net library and open sourced it. Go checkout the library on [Github](https://github.com/zitadel/zitadel-net).

Kudos to Christoph Bühler for implementing this!

**Used Features**

- Authentication (incl. MFA, Passwordless)
- Authorization
- Single Sign On
- OpenID Connect / OAuth 2.0 (incl. JWT Profile and introspect support)
- Management API
- Service Accounts

Tech Stack
ASP.NET Core

Resources
https://github.com/zitadel/zitadel-net

## Future Enhancements (subject to change)

We will improve ZITADEL over time with new features. To give you a small hint of what we are planning to release, have a look at the following list.

- API Docs with Swagger / OpenAPI - [Since creating this blog we released this feature](https://zitadel.com/docs/apis/introduction#swagger-documentation)
- Outbound Webhooks
- SCIM 2.0 API
- Expose Authentication Functions as API
- Conditional Access Rules API

If you have ideas of question feel free to engage with us on [Github Discussion Board](https://github.com/zitadel/zitadel/discussions)

## TL; DR Why you should consider ZITADEL your goto IAM Platform

ZITADEL is a proper **Open Source** project, offers competitive and fair **pricing**, is built by an experienced **team** and a **committed company** and has a **high velocity for developing new features** and constantly improving security.

**In short ZITADEL is the identity & access platform for your business!**

Feel free to contact us on these channels

- [hi@zitadel.com](mailto:hi@zitadel.com)
- [twitter.com/zitadel](https://twitter.com/zitadel)
- [github.com/zitadel/zitadel/discussions](https://github.com/zitadel/zitadel/discussions)

If you consider contributing we would also be happy to welcome you!


We built ZITADEL not only with the vision of  becoming a great open source project but also  as a superb platform to support developers building their applications, without need to handle secure user login and account management themselves.

Our Vision for ZITADEL


<div className="my-4">
  <YouTube videoId={"6FGDaqF3scg"} containerClassName={"youtube-container"} />
</div>

## Topics covered

- What makes ZITADEL better than other IAM services?
- Why did you choose Cockroach DB?
- What is CQRS and how do you use it in ZITADEL?
- Why use a spooler in an event-sourcing workload?
- How does ZITADEL avoid bad data?
- What are challenges of Kubernetes?
- What is ORBOS?
- How to use GitOps? What are the benefits?
- How to solve DNS problems from running Kubernetes in multiple regions?
- How to use CloudFlare's magic WAN?
- How to handle hybrid-cloud challenges?
- Why use geo-partitioning?
- Secondary indexes in Cockroach DB

## CockroachDB & ZITADEL

We use [CockroachDB](https://www.cockroachlabs.com/) as our storage. Check out their great product!

Read our joint Case-Study: [ZITADEL is building an IAM-as-a-service platform with CockroachDB & CQRS](https://resources.cockroachlabs.com/case-study/zitadel).

## Further resources

- [ZITADEL Architecture](https://zitadel.com/docs/concepts/architecture/software)
- [ORBOS - GitOps everything](https://github.com/caos/orbos)
- [Cloudflare Magic WAN](https://www.cloudflare.com/magic-wan/)
- [DNS Chaining | Cockroach Labs](https://www.cockroachlabs.com/blog/experience-report-running-across-multiple-kubernetes-clusters/)


Our live stream with Cockroach Labs on how we built ZITADEL.

How we built it with Cockroach Labs


## ZITADEL v1.0.0

As [announced on April 9](https://status.zitadel.ch/incidents/44183) we released the version [1.0.0](https://github.com/zitadel/zitadel/releases) on April 20.

**API Breaking Changes**. We have decided to fundamentally restructure our APIs. All command requests will only return the relevant data instead of the whole object. For example, for a newly created object, this is the ID. Only via read functions the complete data can be accessed.

Subscribe to our [status updates](https://status.zitadel.ch/) to stay informed.

## Updates to ZITADEL Cloud

We started with an soft-launch last year to get early feedback on functions and root out some of the operational challenges running the distributed [multi-cloud service](https://zitadel.com/trust). We now host over 80 organizations on ZITADEL Cloud.

Sincerely, thank you to all our early adopters providing us with feedback, support and trusting us to provide a critical component to your applications!

So what changes with this release for our SaaS offering ZITADEL Cloud:

1. **We enforce our feature set per subscription plan**. For more information check out the detailed list on our [pricing page](https://zitadel.com/pricing). Early adopters will keep their plans for free for a bit longer to get to know the different plans better.
2. **You can buy a subscription plan via ZITADEL Console**. We have integrated Stripe as payment provider for now. If you have any concerns or don't want to pay via Stripe, please get in [touch with us](mailto:hi@zitadel.ch).

Head over to [ZITADEL Docs](https://zitadel.com/docs/) to learn more about how to use ZITADEL. If you have any questions or something is not working as expected, then please [contact us](https://zitadel.com/contact/).

## What's next

We realize that there is still an important feature outstanding. We will work the next weeks on **improving private labeling** in ZITADEL. If you have any other feature requests, then please join the [discussion over at GitHub](https://github.com/zitadel/zitadel/discussions). Also [contributions](https://github.com/zitadel/zitadel/issues) to the open source version of ZITADEL are always welcome.

Moreover we will continuously update the documentation with manuals, guides, and quickstarts. Lastly, we will provide more details on the support and SLA terms & conditions of the service.


We released version 1.0.0 of ZITADEL on Apr 20, enabled our subscription plans and activated online billing via ZITADEL Cloud console. A brief overview.

ZITADEL Cloud ends introductory phase.


<div className="my-4">
  <YouTube
    videoId={"coupAc7TmWM?start=3310"}
    containerClassName={"youtube-container"}
  />
</div>

## Topics covered

- About CAOS
- What makes ZITADEL special? Our Challenges & Goals
- How we run ZITADEL in GitOps mode with ORBOS
- What is ORBOS?
- Which resources do we manage with GitOps?
- What did we learn?
- What's the plan for the future?

[Have a look at the slides](https://docs.google.com/presentation/d/1Byg6C5xd3MeEDUWNY2r_fcIj9zBbI2qTCgBjenTTYxM/edit)

## Cloud Native Bern

A great community for companies in Bern (and far beyond), working on Cloud Computing

https://www.meetup.com/cloudnativebern

https://cloudnativeday.ch/

## Further resources

- [More about GitOps @ CAOS](/blog/dev-gitops-at-caos)
- [ORBOS - GitOps everything](https://github.com/caos/orbos)
- [ZITADEL - Cloud-Native IAM](https://github.com/zitadel/zitadel)
- [ZITADEL Architecture](https://zitadel.com/docs/concepts/architecture/software)


Our talk at the Cloud Native Bern Meetup about how to run our cloud-native IAM with GitOps

Blog.

IMO - Risk Based Authentication is broken

CH Open Business Lunch - Why we built an open source Identity & Access Management

Treat Kubernetes Clusters as Cattle, Not Pets

The value of Open*

IMO - Passkey in iCloud Keychain

Where should I start if I want to try out or run ZITADEL?

Where should I start if I want to try out or run ZITADEL?

Always run a changing system - The CAOS approach

Our Vision for ZITADEL

How we built it with Cockroach Labs

ZITADEL Cloud ends introductory phase.

Cloud Native Bern Meetup, January 2021

WHY

EXPLORE

COMPANY