Hello 👋, I am Sawada, a developer of
authentication and authorization servers at TIER IV. In
this article, I describe how we replaced our in-house IdentityServer
infrastructure at TIER IV with (Ory Kratos,
Ory Hydra, and
Ory Oathkeeper).
Our ID infrastructure
TIER IV has many infrastructure services including a fleet management system, a
remote monitoring and control system, and a map editor for autonomous driving.
Our identity infrastructure is a small but extremely important component since
outages of this service will massively impact our availability. This ID
infrastructure is a very compact service that provides account management and ID
federation. Authorization is done by a separate service.
Why switch
Our existing ID infrastructure was not particularly old but had some problems.
The OpenID Provider library that we used was no longer maintained, requiring us
to fork and patch it ourselves. It had memory leaks and was sometimes getting
stuck on requests.
While we had these issues under control, we knew that this architecture would
reach scalability limits in the future. Anticipating more traffic and higher
levels of reliability, we decided to replace it while the number of users is
still small and the data is easier to migrate.
Data Migration
For our new system we want to use managed services like Cognito (we use AWS) but
only those that don't charge by users count and are based on open-source. We see
implementing from scratch only as the last resort. However, migration the
existing data severely limited our options. Specifically, we evaluated the
following requirements:
- Can we change the identifiers for existing account?
- Can we change the Client ID and OpenID Connect secrets?
- Can we force-reset user passwords?
Let's look at each question in more detail.
Can we change the identifier for existing accounts
No. Our microservice architecture persists IDs across various services. It would
be difficult to find them all and replace them consistently. Since our
Django-based system uses auto-incrementing IDs, we were unable to find a service
or open source alternative that could import existing account IDs without
modification. We worked around this problem with a mechanism that converts
issued IDs before adding them to our system.
Can Client ID and OpenID Connect secret be changed
Yes. Of course, it would have been nice to migrate the old secrets, but most of
the users inside and outside the company were beyond the scope of change here.
Can user passwords be force reset
No. Not only is this bad user experience, but there was a time in the past when
we did not verify that the email addresses are valid. So some of our users might
not be able to reset their password. We needed a new system to import
PBKDF2-hashed passwords and this disqualified AWS Cognito.
New identity infrastructure architecture
We decided to go with the Ory Stack. Ory Kratos as the
Identity Server, Ory Hydra as the OpenID Provider, and Ory Oathkeeper as the
Identity & Access Proxy. We also implemented service specific logic and
federated Kratos, Hydra, and the UI. Keycloak is a more well-known open source
identity infrastructure but we chose Ory's services for the following reasons:
- Ory provides each features as a micro-service. This makes it easy to maintain
compatibility when migrating existing data and features.
- We are familiar with the Go language. This makes it easy for us to work on the
source code when problems or questions arise.
- We have past experience using and contributing to Ory Hydra. So when we have
problems, we can solve them by contributing.
Next I will introduce each system component in our new ID infrastructure.
Ory Kratos
A headless Identity Server that implements user
management and authentication. The main features implemented are:
- Login, Logout
- User registration
- Profile Management
- Account Recovery
- Email Verification
- MFA
I already wrote about Ory Kratos for the
Qiita Advent Calendar 2021.
We had to make a decision wether to use Ory Kratos or not. It depended on
whether it could import our existing passwords hashed by PBKDF2. I
created an issue, implemented the
import, and finally opened a PR and
merged. Now Kratos can import passwords hashed by PBKDF2 and upgrade to them to
the primary algorithm (Argon2id or bcrypt). Ory Kratos can
create identities using the Admin API.
Ory Hydra
Ory Hydra is an
OpenID Connect Certified OpenID Provider.
Normally, Ory Hydra generates the Client ID and Secret automatically. But we can
import it if we set Client ID and Secret.
Ory Oathkeeper
This is an identity-aware proxy that
provides access control. It propagates user session information to upstream and
validates the scope of the access token. If you want to authorize users, you
need to use Ory Keto or a project like Open
Policy Agent, but we did not use them this time. We also use Ory Oathkeeper to
protect the administrative APIs of Kratos and Hydra. Eventually we would like to
authorize users, but we have issued an OAuth 2.0 client for the admin API, and
just scope authorization. This is enough for us at the moment.
My Application
This will be a component that implements miscellaneous missing items, in
particular:
- UI for each of the features provided by Kratos.
- additional validation or other processing before POST to Kratos.
- Working with Kratos and Hydra.
- Mapping for account identifier to be compatible with Django issued APIs to
federate to other system components.
- The ID infrastructure before the replacement was made in Python (Django), but
this time it was implemented in the Go language.
Final Thoughts
We were able to complete the migration of our identity infrastructure to the Ory
stack without any problems in three months. A major success factor was that we
minimized the migration scope by removing unnecessary features prior to the
migration. We collaborated with the business and legal departments to identify
them and notified our users about the sunset schedule. While that took a lot of
time, the process was smooth. If we would have to do the migation today, it
would required a considerable larger amount of time. Another big success factor
was that the Ory stack is Open Source. It allows us to add additional features
to our identity infrastructure from now on.
