Add User Grant has a documented optional parameter "x-zitadel-orgid" which is important for the correct execution of the function.

As far as I can tell, there's currently no way to set this header in the current function.

This also applies to other functions.

Potential segfault in localtime_r invocations

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.

Hi, thank you for creating this crate!

Would it be possbile to update axum to 0.7?

I also wondered how one could pass other states to axum through app.with_state() like a mongodb client while using the User extractor.

When I updated the package to 4.3.5, upon compiling it throws the following error:

Compiling zitadel v4.3.4
error[E0432]: unresolved import crate::api::interceptors
--> /home/temes/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zitadel-4.3.4/src/api/clients.rs:14:17
|
14 | use crate::api::interceptors::{AccessTokenInterceptor, ServiceAccountInterceptor};
| ^^^^^^^^^^^^ could not find interceptors in api

For more information about this error, try rustc --explain E0432.
error: could not compile zitadel (lib) due to 1 previous error

It is very strange because previously it compiled well and as far as I know there was no change in this api/client.rs file.
Any idea what the issue can be here? I am getting a little desperate...thank you.
(I am using rust 1.78)

Feature Request: Optional Support for Rocket-Okapi Integration in IntrospectedUser

Description

I propose integrating the rocket-okapi library as an optional feature in the zitadel-rust project, specifically by implementing the OpenApiResponderInner and/or OpenApiResponder traits in the IntrospectedUser type. This enhancement would enable OpenAPI specification support for Rocket-based applications, facilitating automated API documentation generation.

Motivation

Adding rocket-okapi support as an optional feature would improve the developer experience by providing automated API documentation generation capabilities, without imposing additional overhead on those who do not require this functionality. It is particularly useful for teams that need to maintain clear and accurate API documentation in fast-paced development environments.

Suggestion

The feature should be implemented as non-default, allowing developers to opt in as needed. Implementing the required traits in IntrospectedUser would make it straightforward to generate API documentation for services that utilize this type.

Possible Implementation Steps:

1. Modify the IntrospectedUser type to implement the OpenApiResponderInner and OpenApiResponder traits.
2. Implement the integration as a feature flag within the zitadel-rust project to keep it optional.
3. Create detailed examples and documentation to guide developers on how to enable and use the new feature.
4. Conduct comprehensive testing to ensure that enabling this feature does not affect the existing functionalities negatively.

Conclusion

Integrating rocket-okapi as an optional feature within IntrospectedUser could greatly enhance the capability of developers to maintain robust API documentation with minimal overhead. This feature would be particularly advantageous for projects requiring detailed and accurate API specs without disrupting the current project setup. I am eager to hear your thoughts and suggestions regarding this proposal.

Thank you for considering this feature request.

rocket-okapi GitHub Link

Potential segfault in the time crate

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc
• now

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

Workarounds

No workarounds are known.

References

time-rs/time#293

See advisory page for additional details.

Building the zitadel crate, also as a dependency, fails with the following error if you don't have protobuf development files installed:

   Compiling zitadel v3.1.9
error: failed to run custom build command for `zitadel v3.1.9`

Caused by:
  process didn't exit successfully: `/home/emelie/[...]/debug/build/zitadel-18a8719d73ee0e93/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-changed=external/zitadel/proto
  cargo:rerun-if-changed=external/protoc-gen-validate
  cargo:rerun-if-changed=external/googleapis
  cargo:rerun-if-changed=external/grpc-gateway

  --- stderr
  Error: Custom { kind: Other, error: "protoc failed: google/protobuf/descriptor.proto: File not found.\ngoogle/protobuf/struct.proto: File not found.\nprotoc-gen-openapiv2/options/openapiv2.proto:5:1: Import \"google/protobuf/struct.proto\" was not found or had errors.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:5:1: Import \"google/protobuf/descriptor.proto\" was not found or had errors.\nprotoc-gen-openapiv2/options/annotations.proto:6:1: Import \"protoc-gen-openapiv2/options/openapiv2.proto\" was not found or had errors.\nprotoc-gen-openapiv2/options/annotations.proto:10:8: \"google.protobuf.FileOptions\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:17:8: \"google.protobuf.MethodOptions\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:24:8: \"google.protobuf.MessageOptions\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:31:8: \"google.protobuf.ServiceOptions\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:38:8: \"google.protobuf.FieldOptions\" is not defined.\n" }
warning: build failed, waiting for other jobs to finish...

As far as I can tell this isn't documented anywhere. Documenting it could be quite helpful, as it's not immediately obvious what the problem is from the error message. On fedora the required package is protobuf-devel, I would assume it's protobuf-dev on apt-based distros.

TLDR

This crate uses both rustls and openssl. Because openssl can be difficult sometimes, it might be better to standardize on rustls.

Description

When using the credentials feature the following 2 dependencies are activated:

1. openidconnect
2. reqwest

openidconnect

The openidconnect dependency is pulled in with its default features:

• oauth2
• rustls-tls

These default features pull in the oauth2 dependency which then pulls in reqwest with rusttls-tls enabled.

reqwest

The reqwest dependency is included with its default features. This pulls in openssl when running on Linux/Docker. The final result of this is that the Zitadel crate includes a reqwest dependency that uses both rustls and openssl.

Suggested Solution

Normally, including extra unneeded dependencies is not a big problem, but openssl can be painful when building some docker images which do not include openssl in the base image (e.g Alpine Linux).

There is a simple one line change for this behaviour to standardize on rusttls and I can make a PR for this.

First of all thanks for this great create!

The Problem

Tonic Service Client are designed to be cloned in Multi-Threading/Multiplexing scenarios. There is a section "Multiplexing-Requests" on this in the tonic docs: https://docs.rs/tonic/latest/tonic/transport/struct.Channel.html#multiplexing-requests

As a result a tonic client implements Clone. When using a client build with this crate, a XXXServiceClient<InterceptedService<TonicChannel, ChainedInterceptor>> is returned. Everything except ChainedInterceptor implements Clone.

I need to use the client in a Multiplexing scenario and require the client to implement a lightweight clone to avoid opening a large number of channels.

The Solution

... is not as trivial as I would have though because ServiceAccountInterceptor requires mutability for the token. I changed it to use Interior Mutability instead.

I also had to introduce a new Interceptor trait which I don't like.
The only reason for the new interceptor trait is the ChainedInterceptor chain method which runs calls via the original Interceptor trait on &mut self. This breaks my interior mutability approach though.

I would argue that even if you decide to stick to the old implementation of the ChainedInterceptor , the changed ServiceAccountInterceptor and AccessTokenInterceptor are better off using interior mutability and can still be used in clone-able clients even though we couldn't use the ClientBuilder to obtain them.

PR is coming in a second, let me know if you have any better ideas!

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Could not access Cargo.toml

Cannot read properties of undefined (reading 'R_OK')

Good luck with your project ✨

Your semantic-release bot 📦🚀

Hi, been playing for a bit with this module, but can't get it running properly using Actix.
Is there any examples for that specific framework?

Hi!

I came across this library and tried to find out how to e.g. modify organization metadata. There is bulk_set_org_metadata, however, the API specification states, that the organization to be modified is set in the headers. Is there a way to set which organization to modify using this client?

This would probably be even more important for things like remove_org, where there is an empty request and the whole information which org to delete is in the headers.

Thank you!

When authenticating with Zitadel it is possible to add additional scopes, e.g urn:zitadel:iam:user:resourceowner and urn:zitadel:iam:user:metadata. If these scopes are used, it is possible to get extra information when calling OIDC Introspection.

Currently, only the default introspection fields are considered and any extra fields are ignored.

Would you be open to a PR that added support for these extra fields? I was thinking of something like using #[serde(flatten)] to support metadata: serde-rs/serde#941 (comment)

Marvin Attack: potential key recovery through timing sidechannels

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

Workarounds

The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

See advisory page for additional details.

Feature Request: Enhanced Cookie Authentication Support

Description

I propose to enhance the authentication mechanism in the zitadel-rust project by implementing support for setting and validating cookies in a Rocket-based backend. This feature would allow the backend to set a cookie for the frontend, which would then be used for authentication verification in the absence of an Authorization header.

Motivation

In many web applications, managing user sessions via cookies is essential, especially for providing a seamless user experience across multiple requests where setting headers manually might be inconvenient or infeasible. By supporting cookie-based authentication, we can offer more flexibility in how clients interact with our services, enhancing usability without compromising security.

Suggestion

The implementation would involve:

1. Cookie Setting: Utilizing Rocket's cookie API to set secure, HTTP-only cookies that can optionally be configured as 'secret cookies' for enhanced security.
2. Authentication Fallback: In cases where the Authorization header is missing, the backend would fallback to validating the session based on the cookie, ensuring continuous authentication.
3. Feature Flag: This functionality should be optional and controlled by a feature flag to maintain flexibility and performance for users who do not require cookie-based authentication.

Possible Implementation Steps:

1. Feature Flag Setup: Introduce a feature flag in Cargo.toml to enable or disable cookie-based authentication.
2. Cookie Management: Implement functions to securely set and retrieve cookies using Rocket's mechanisms.
3. Authentication Logic: Modify the authentication logic to check for a valid cookie if the Authorization header is absent.
4. Security Enhancements: Ensure that cookies are set with secure attributes like HttpOnly and Secure to prevent access from client-side scripts and transmission over non-HTTPS connections respectively.
5. Documentation and Examples: Provide clear documentation and examples on how to enable this feature and configure it appropriately.
6. Testing: Develop comprehensive tests to ensure the security and functionality of the cookie-based authentication.

Conclusion

Implementing cookie-based authentication as an optional feature would greatly enhance the flexibility and user experience of the zitadel-rust project's authentication system. It would provide an alternative method for maintaining user sessions, particularly in environments where using Authorization headers is less ideal.

Thank you for considering this feature request. I look forward to feedback and suggestions on improving this proposal.