2019-12-12 23:49:32 +01:00
|
|
|
// Re-export as needed
|
2020-03-26 23:27:07 +01:00
|
|
|
|
|
|
|
pub mod acp;
|
|
|
|
pub mod entries;
|
2023-10-17 09:18:07 +02:00
|
|
|
pub mod groups;
|
2020-03-26 23:27:07 +01:00
|
|
|
pub mod schema;
|
2019-12-12 23:49:32 +01:00
|
|
|
pub mod system_config;
|
2020-03-26 23:27:07 +01:00
|
|
|
pub mod uuids;
|
2022-10-05 01:48:48 +02:00
|
|
|
pub mod values;
|
2020-03-26 23:27:07 +01:00
|
|
|
|
|
|
|
pub use crate::constants::acp::*;
|
|
|
|
pub use crate::constants::entries::*;
|
2023-10-17 09:18:07 +02:00
|
|
|
pub use crate::constants::groups::*;
|
2020-03-26 23:27:07 +01:00
|
|
|
pub use crate::constants::schema::*;
|
|
|
|
pub use crate::constants::system_config::*;
|
|
|
|
pub use crate::constants::uuids::*;
|
2022-10-05 01:48:48 +02:00
|
|
|
pub use crate::constants::values::*;
|
2019-12-12 23:49:32 +01:00
|
|
|
|
2022-10-17 12:09:47 +02:00
|
|
|
use std::time::Duration;
|
|
|
|
|
2019-11-29 01:48:22 +01:00
|
|
|
// Increment this as we add new schema types and values!!!
|
2023-08-01 07:12:35 +02:00
|
|
|
pub const SYSTEM_INDEX_VERSION: i64 = 30;
|
2023-01-17 05:14:11 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* domain functional levels
|
|
|
|
*
|
|
|
|
* The idea here is to allow topology wide upgrades to be performed. We have to
|
|
|
|
* assume that across multiple kanidm instances there may be cases where we have version
|
|
|
|
* N and version N minus 1 as upgrades are rolled out.
|
|
|
|
*
|
|
|
|
* Imagine we set up a new cluster. Machine A and B both have level 1 support.
|
|
|
|
* We upgrade machine A. It has support up to level 2, but machine B does not.
|
|
|
|
* So the overall functional level is level 1. Then we upgrade B, which supports
|
|
|
|
* up to level 2. We still don't do the upgrade! The topology is still level 1
|
|
|
|
* unless an admin at this point *intervenes* and forces the update. OR what
|
|
|
|
* happens we we update machine A again and it now supports up to level 3, with
|
|
|
|
* a target level of 2. So we update machine A now to level 2, and that can
|
|
|
|
* still replicate to machine B since it also supports level 2.
|
|
|
|
*
|
|
|
|
* effectively it means that "some features" may be a "release behind" for users
|
|
|
|
* who don't muck with the levels, but it means that we can do mixed version
|
|
|
|
* upgrades.
|
|
|
|
*/
|
2023-02-15 01:25:51 +01:00
|
|
|
pub type DomainVersion = u32;
|
|
|
|
|
2024-02-01 03:00:29 +01:00
|
|
|
pub const DOMAIN_LEVEL_0: DomainVersion = 0;
|
2023-02-15 01:25:51 +01:00
|
|
|
pub const DOMAIN_LEVEL_1: DomainVersion = 1;
|
2023-12-18 00:10:13 +01:00
|
|
|
pub const DOMAIN_LEVEL_2: DomainVersion = 2;
|
2023-12-21 05:44:20 +01:00
|
|
|
pub const DOMAIN_LEVEL_3: DomainVersion = 3;
|
2024-01-16 01:44:12 +01:00
|
|
|
pub const DOMAIN_LEVEL_4: DomainVersion = 4;
|
2024-02-01 03:00:29 +01:00
|
|
|
pub const DOMAIN_LEVEL_5: DomainVersion = 5;
|
2023-01-17 05:14:11 +01:00
|
|
|
// The minimum supported domain functional level
|
2024-02-01 03:00:29 +01:00
|
|
|
pub const DOMAIN_MIN_LEVEL: DomainVersion = DOMAIN_LEVEL_5;
|
2023-01-17 05:14:11 +01:00
|
|
|
// The target supported domain functional level
|
2024-02-01 03:00:29 +01:00
|
|
|
pub const DOMAIN_TGT_LEVEL: DomainVersion = DOMAIN_LEVEL_5;
|
2023-01-17 05:14:11 +01:00
|
|
|
// The maximum supported domain functional level
|
2024-02-01 03:00:29 +01:00
|
|
|
pub const DOMAIN_MAX_LEVEL: DomainVersion = DOMAIN_LEVEL_5;
|
2023-01-17 05:14:11 +01:00
|
|
|
|
2024-02-02 06:38:45 +01:00
|
|
|
// On test builds define to 60 seconds
|
2019-07-12 07:28:46 +02:00
|
|
|
#[cfg(test)]
|
2020-05-03 08:44:01 +02:00
|
|
|
pub const PURGE_FREQUENCY: u64 = 60;
|
2024-02-02 06:38:45 +01:00
|
|
|
// For production 10 minutes.
|
2019-07-12 07:28:46 +02:00
|
|
|
#[cfg(not(test))]
|
2020-05-03 08:44:01 +02:00
|
|
|
pub const PURGE_FREQUENCY: u64 = 600;
|
2020-03-24 23:21:49 +01:00
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
/// In test, we limit the changelog to 10 minutes.
|
2020-05-03 08:44:01 +02:00
|
|
|
pub const CHANGELOG_MAX_AGE: u64 = 600;
|
2020-03-24 23:21:49 +01:00
|
|
|
#[cfg(not(test))]
|
2024-02-01 03:00:29 +01:00
|
|
|
/// A replica may be up to 7 days out of sync before being denied updates.
|
|
|
|
pub const CHANGELOG_MAX_AGE: u64 = 7 * 86400;
|
2020-03-24 23:21:49 +01:00
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
/// In test, we limit the recyclebin to 5 minutes.
|
2020-05-03 08:44:01 +02:00
|
|
|
pub const RECYCLEBIN_MAX_AGE: u64 = 300;
|
2020-03-24 23:21:49 +01:00
|
|
|
#[cfg(not(test))]
|
|
|
|
/// In production we allow 1 week
|
2024-02-01 03:00:29 +01:00
|
|
|
pub const RECYCLEBIN_MAX_AGE: u64 = 7 * 86400;
|
2020-03-24 23:21:49 +01:00
|
|
|
|
2019-09-06 05:04:58 +02:00
|
|
|
// 5 minute auth session window.
|
2020-05-03 08:44:01 +02:00
|
|
|
pub const AUTH_SESSION_TIMEOUT: u64 = 300;
|
2020-04-10 07:50:45 +02:00
|
|
|
// 5 minute mfa reg window
|
2020-05-03 08:44:01 +02:00
|
|
|
pub const MFAREG_SESSION_TIMEOUT: u64 = 300;
|
2023-11-05 01:33:25 +01:00
|
|
|
pub const PW_MIN_LENGTH: u32 = 10;
|
2021-05-26 08:11:00 +02:00
|
|
|
|
2023-10-22 13:16:42 +02:00
|
|
|
// Maximum - Sessions have no upper bound.
|
|
|
|
pub const MAXIMUM_AUTH_SESSION_EXPIRY: u32 = u32::MAX;
|
|
|
|
// Default - sessions last for 1 day
|
2023-09-16 01:22:11 +02:00
|
|
|
pub const DEFAULT_AUTH_SESSION_EXPIRY: u32 = 86400;
|
|
|
|
pub const DEFAULT_AUTH_SESSION_LIMITED_EXPIRY: u32 = 3600;
|
2023-10-22 13:16:42 +02:00
|
|
|
// Maximum - privileges last for 1 hour.
|
|
|
|
pub const MAXIMUM_AUTH_PRIVILEGE_EXPIRY: u32 = 3600;
|
2023-04-20 00:34:21 +02:00
|
|
|
// Default - privileges last for 10 minutes.
|
2023-08-22 03:00:43 +02:00
|
|
|
pub const DEFAULT_AUTH_PRIVILEGE_EXPIRY: u32 = 600;
|
2023-04-20 00:34:21 +02:00
|
|
|
// Default - oauth refresh tokens last for 16 hours.
|
|
|
|
pub const OAUTH_REFRESH_TOKEN_EXPIRY: u64 = 3600 * 8;
|
2022-10-17 12:09:47 +02:00
|
|
|
|
|
|
|
// The time that a token can be used before session
|
|
|
|
// status is enforced. This needs to be longer than
|
|
|
|
// replication delay/cycle.
|
2023-02-19 04:32:47 +01:00
|
|
|
pub const GRACE_WINDOW: Duration = Duration::from_secs(300);
|
2022-10-17 12:09:47 +02:00
|
|
|
|
|
|
|
/// How long access tokens should last. This is NOT the length
|
|
|
|
/// of the refresh token, which is bound to the issuing session.
|
2023-04-20 00:34:21 +02:00
|
|
|
pub const OAUTH2_ACCESS_TOKEN_EXPIRY: u32 = 15 * 60;
|
2023-11-02 02:21:21 +01:00
|
|
|
|
|
|
|
/// The amount of time a suppliers clock can be "ahead" before
|
|
|
|
/// we warn about possible clock synchronisation issues.
|
|
|
|
pub const REPL_SUPPLIER_ADVANCE_WINDOW: Duration = Duration::from_secs(600);
|