openstack_keystone_core/
lib.rs

1// Licensed under the Apache License, Version 2.0 (the "License");
2// you may not use this file except in compliance with the License.
3// You may obtain a copy of the License at
4//
5//     http://www.apache.org/licenses/LICENSE-2.0
6//
7// Unless required by applicable law or agreed to in writing, software
8// distributed under the License is distributed on an "AS IS" BASIS,
9// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
10// See the License for the specific language governing permissions and
11// limitations under the License.
12//
13// SPDX-License-Identifier: Apache-2.0
14
15//! # OpenStack Keystone in Rust
16//!
17//! The legacy Keystone identity service (written in Python and maintained
18//! upstream by OpenStack Foundation) has served the OpenStack ecosystem
19//! reliably for years. It handles authentication, authorization, token
20//! issuance, service catalog, project/tenant management, and federation
21//! services across thousands of deployments. However, as we embarked on adding
22//! next-generation identity features—such as native WebAuthn (“passkeys”),
23//! modern federation flows, direct OIDC support, JWT login, workload
24//! authorization, restricted tokens and service-accounts—it became clear that
25//! certain design and performance limitations of the Python codebase would
26//! hamper efficient implementation of these new features.
27//!
28//! Consequently, we initiated a project termed “Keystone-NG”: a Rust-based
29//! component that augments rather than fully replaces the existing Keystone
30//! service. The original plan was to implement only the new feature-set in Rust
31//! and route those new API paths to the Rust component, while keeping the core
32//! Python Keystone service in place for existing users and workflows.
33//!
34//! As development progressed, however, the breadth of new functionality (and
35//! the opportunity to revisit some of the existing limitations) led to a
36//! partial re-implementation of certain core identity flows in Rust. This
37//! allows us to benefit from Rust's memory safety, concurrency model,
38//! performance, and modern tooling, while still preserving the upstream
39//! Keystone Python service as the canonical “master” identity service, routing
40//! only the new endpoints and capabilities through the Rust component.
41//!
42//! In practice, this architecture means:
43//!
44//! - The upstream Python Keystone remains the main identity interface,
45//!   preserving backward compatibility, integration with other OpenStack
46//!   services, existing user workflows, catalogs, policies and plugins.
47//!
48//! - The Rust “Keystone-NG” component handles new functionality, specifically:
49//!
50//!   - Native WebAuthN (passkeys) support for passwordless / phishing-resistant
51//!     MFA
52//!
53//!   - A reworked federation service, enabling modern identity brokering and
54//!     advanced federation semantics OIDC (OpenID Connect) Direct in Keystone,
55//!     enabling Keystone to act as an OIDC Provider or integrate with external
56//!     OIDC identity providers natively JWT login flows, enabling stateless,
57//!     compact tokens suitable for new micro-services, CLI, SDK, and
58//!     workload-to-workload scenarios
59//!
60//!   - Workload Authorization, designed for service-to-service authorization in
61//!     cloud native contexts (not just human users)
62//!
63//!   - Restricted Tokens and Service Accounts, which allow fine-grained,
64//!     limited‐scope credentials for automation, agents, and service accounts,
65//!     with explicit constraints and expiry
66//!
67//! By routing only the new flows through the Rust component we preserve the
68//! stability and ecosystem compatibility of Keystone, while enabling a
69//! forward-looking identity architecture. Over time, additional identity flows
70//! may be migrated or refactored into the Rust component as needed, but our
71//! current objective is to retain the existing Keystone Python implementation
72//! as the trusted, mature baseline and incrementally build the “Keystone-NG”
73//! Rust service as the complement.
74
75//use application_credential::ApplicationCredentialApi;
76
77//pub trait ServiceState {
78//    fn get_application_credential_provider(&self) -> &impl ApplicationCredentialApi;
79//}
80
81pub mod api;
82pub mod application_credential;
83pub mod assignment;
84pub mod auth;
85pub mod catalog;
86pub mod common;
87pub mod config;
88pub mod error;
89pub mod federation;
90pub mod identity;
91pub mod identity_mapping;
92pub mod k8s_auth;
93pub mod keystone;
94pub mod plugin_manager;
95pub mod policy;
96pub mod provider;
97pub mod resource;
98pub mod revoke;
99pub mod role;
100pub mod token;
101pub mod trust;
102
103#[cfg(test)]
104pub mod tests;
openstack_keystone_core/lib.rs

openstack_keystone_core/
lib.rs
