kanidm/examples/config

# This should be at /etc/kanidm/config or ~/.config/kanidm, and configures the kanidm command line tool
uri = "https://idm.example.com"
verify_ca = true
verify_hostnames = true

# Alternate instances can be specified and used with -I <name> to the cli tools.
["name"]
uri = "https://alternate.example.com"
Adding an example config file (#440) 2021-05-16 06:10:29 +02:00			`# This should be at /etc/kanidm/config or ~/.config/kanidm, and configures the kanidm command line tool`
			`uri = "https://idm.example.com"`
			`verify_ca = true`
			`verify_hostnames = true`
Begin the basis of the key provider model (#2640) This completely reworks how we approach and handle cryptographic keys in Kanidm. This is needed as a foundation for replication coordination which will require handling and rotation of cryptographic keys in automated ways. This change influences many other parts of the code base in it's implementation. The primary influences are: * Modification of how domain user signing keys are revoked or rotated. * Merging of all existing service-account token keys are retired (retained) keys into the domain to simplify token signing and validation * Allowing multiple configurations of local command line tools to swap between instances using disparate signing keys. * Modification of key retrieval to be key id based (KID), removing the need to embed the JWK into tokens A side effect of this change is that most user authentication sessions and oauth2 sessions will have to be re-established after upgrade. However we feel that session renewal after upgrade is an expected side effect of an upgrade. In the future this lays the ground work to remove a large number of legacy key handling processes that have evolved, which will allow large parts of code to be removed. 2024-04-16 01:44:37 +02:00
			`# Alternate instances can be specified and used with -I <name> to the cli tools.`
			`["name"]`
			`uri = "https://alternate.example.com"`