siloxide_security/lib.rs
1//! Standard SiLA authentication and authorization, over a backend the application supplies.
2//!
3//! Part C defines `AuthenticationService` and `AuthorizationService` but not what a credential, a
4//! token, or a permission is — deliberately, because those belong to the deployment. This crate
5//! draws the line in the same place: Siloxide owns the Feature Definitions, their wire mapping,
6//! their errors, and where in a call the authorization question is asked; the application owns
7//! identity, credentials, tokens, permissions, and whatever service it consults.
8//!
9//! ```ignore
10//! let server = Server::builder(config)
11//! .add_feature(authentication_service::default_feature(directory))?
12//! .add_feature(authorization_service::default_feature(policy, server_uuid))?
13//! .add_feature(balance::feature(Scale)?)?
14//! .build()?;
15//! ```
16//!
17//! Registering the second one protects every eligible call on the server, `Balance` included, and
18//! freezes that list at build. `SiLAService` is never protected — Part A p.57 forbids client
19//! metadata on it — and `AuthenticationService` is excluded, because a client that needs a token to
20//! call `Login` can never obtain one.
21//!
22//! Neither adapter implements `AuthorizationProviderService` or
23//! `AuthorizationConfigurationService`. Selecting a remote provider, persisting a configuration,
24//! and verifying a token against another server are separate behavior, and a default that pretended
25//! otherwise would be advertising something it does not do.
26
27mod adapters;
28pub mod authentication;
29pub mod authorization;
30pub mod secret;
31
32pub use adapters::{authentication_service, authorization_service};
33pub use authentication::{
34 AccessGrant, AuthenticationBackend, LoginRejection, LoginRequest, LogoutRejection,
35};
36pub use authorization::{
37 AuthorizationBackend, AuthorizationDecision, AuthorizationRequest, BackendUnavailable,
38};
39pub use secret::{AccessToken, Password};