mirror of
https://github.com/kanidm/kanidm.git
synced 2025-02-23 04:27:02 +01:00
Docs updates (#2961)
This commit is contained in:
James Hodgkinson
GitHub
parent
2e3b09ec8a
commit
3cbda02aa8
|
|
@ -185,11 +185,12 @@ moment.
|
|||
|
||||
An example:
|
||||
|
||||
> Alice should only be able to modify a user's password if that user is a member of the students
|
||||
> group.
|
||||
Alice should only be able to modify a user's password if that user is a member of the students group.
|
||||
|
||||
**Note:** `modify` does not imply `read` of the attribute. Care should be taken that we don't
|
||||
disclose the current value in any error messages if the operation fails.
|
||||
> [!NOTE]
|
||||
>
|
||||
> `modify` does not imply `read` of the attribute. Care should be taken that we don't
|
||||
> disclose the current value in any error messages if the operation fails.
|
||||
|
||||
## Targeting Requirements
|
||||
|
||||
|
|
@ -332,7 +333,9 @@ A complete schema would be:
|
|||
| access_control_modify | | `[acp_modify_removedattr, acp_modify_presentattr, acp_modify_class]` |
|
||||
| access_control_create | | `[acp_create_class, acp_create_attr]` |
|
||||
|
||||
**Important**: empty sets really mean empty sets!
|
||||
> [!NOTE]
|
||||
>
|
||||
> empty sets really mean empty sets!
|
||||
|
||||
The ACP code will assert that both `access_control_profile` _and_ one of the
|
||||
`search/delete/modify/create` classes exists on an ACP. An important factor of this design is now
|
||||
|
|
@ -411,10 +414,12 @@ However, a possible issue is that Option #2 means that a delete request of
|
|||
This is also a concern for modification, where the modification attempt may or may not fail
|
||||
depending on the entries and if you can/can't see them.
|
||||
|
||||
**IDEA:** You can only `delete`/`modify` within the read scope you have. If you can't read it (based
|
||||
on the read rules of `search`), you can't `delete` it. This is in addition to the filter rules of
|
||||
the `delete` applying as well. So performing a `delete` of `Pres(class)`, will only delete in your
|
||||
`read` scope and will never disclose if you are denied access.
|
||||
> [!NOTE]
|
||||
>
|
||||
> You can only `delete`/`modify` within the read scope you have. If you can't read it (based
|
||||
> on the read rules of `search`), you can't `delete` it. This is in addition to the filter rules of
|
||||
> the `delete` applying as well. So performing a `delete` of `Pres(class)`, will only delete in your
|
||||
> `read` scope and will never disclose if you are denied access.
|
||||
|
||||
<!-- TODO
|
||||
@yaleman: This goes back to the commentary on Option #2 and feels icky like SQL's `DELETE FROM <table>` just deleting everything. It's more complex from the client - you have to search for a set of things to delete - then delete them.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ responses belong to the same enum, the colors are meant to provide additional in
|
|||
response means that the input was valid and therefore it contains the next step in the identity
|
||||
verification flow, while a red response means the input was invalid and the flow terminates there.
|
||||
Note that the protocol is completely stateless, so the following diagram is not to be intended as a
|
||||
state machine, for the idv state machine go [here](#the-identity-verification-state-machine-idv).
|
||||
state machine, for the idv state machine go [here](#the-identity-verification-state-machine).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -328,7 +328,9 @@ KANIDM_BUILD_PROFILE=release_linux cargo build --release --bin kanidmd
|
|||
|
||||
### Building the Web UI
|
||||
|
||||
**NOTE:** There is a pre-packaged version of the Web UI at `/server/web_ui/pkg/`, which can be used
|
||||
> [!NOTE:]
|
||||
>
|
||||
> There is a pre-packaged version of the Web UI at `/server/web_ui/pkg/`, which can be used
|
||||
directly. This means you don't need to build the Web UI yourself.
|
||||
|
||||
The Web UI uses Rust WebAssembly rather than Javascript. To build this you need to set up the
|
||||
|
|
|
|||
|
|
@ -4,11 +4,17 @@ There are some cases where you may need to rename the domain. You should have co
|
|||
initially in the setup, however you may have a situation where a business is changing name, merging
|
||||
or other needs which may prompt this needing to be changed.
|
||||
|
||||
> **WARNING:** This WILL break ALL u2f/webauthn tokens that have been enrolled, which MAY cause
|
||||
> [!WARNING]
|
||||
>
|
||||
> This WILL break ALL u2f/webauthn tokens that have been enrolled, which MAY cause
|
||||
> accounts to be locked out and unrecoverable until further action is taken. DO NOT CHANGE the
|
||||
> domain name unless REQUIRED and have a plan on how to manage these issues.
|
||||
|
||||
> **WARNING:** This operation can take an extensive amount of time as ALL accounts and groups in the
|
||||
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> This operation can take an extensive amount of time as ALL accounts and groups in the
|
||||
> domain MUST have their Security Principal Names (SPNs) regenerated. This WILL also cause a large
|
||||
> delay in replication once the system is restarted.
|
||||
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ kanidm group create 'grafana_users'
|
|||
Setup the claim-map that will set what role each group will map to in Grafana:
|
||||
|
||||
```bash
|
||||
kanidmm oauth2 update-claim-map-join 'grafana' 'grafana_role' array
|
||||
kanidm system oauth2 update-claim-map-join 'grafana' 'grafana_role' array
|
||||
kanidm system oauth2 update-claim-map 'grafana' 'grafana_role' 'grafana_superadmins' 'GrafanaAdmin'
|
||||
kanidm system oauth2 update-claim-map 'grafana' 'grafana_role' 'grafana_admins' 'Admin'
|
||||
kanidm system oauth2 update-claim-map 'grafana' 'grafana_role' 'grafana_editors' 'Editor'
|
||||
|
|
@ -205,15 +205,19 @@ allow_assign_grafana_admin = true
|
|||
|
||||
## Vouch Proxy
|
||||
|
||||
> **WARNING** Vouch proxy requires a unique identifier but does not use the proper scope, "sub". It
|
||||
> [!WARNING]
|
||||
>
|
||||
> Vouch proxy requires a unique identifier but does not use the proper scope, "sub". It
|
||||
> uses the fields "username" or "email" as primary identifiers instead. As a result, this can cause
|
||||
> user or deployment issues, at worst security bypasses. You should avoid Vouch Proxy if possible
|
||||
> due to these issues.
|
||||
>
|
||||
> - <https://github.com/vouch/vouch-proxy/issues/309>
|
||||
> - <https://github.com/vouch/vouch-proxy/issues/310>
|
||||
|
||||
Note: **You need to run at least the version 0.37.0**
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> You need to run at least version 0.37.0
|
||||
|
||||
Vouch Proxy supports multiple OAuth and OIDC login providers. To configure it you need to pass:
|
||||
|
||||
|
|
|
|||
|
|
@ -52,13 +52,15 @@ You can also configure some unixd-specific options with the file /etc/kanidm/uni
|
|||
{{#rustdoc_include ../../../examples/unixd}}
|
||||
```
|
||||
|
||||
> **NOTICE:** All users in Kanidm can change their name (and their spn) at any time. If you change
|
||||
> [!NOTE]
|
||||
>
|
||||
> All users in Kanidm can change their name (and their spn) at any time. If you change
|
||||
> `home_attr` from `uuid` you _must_ have a plan on how to manage these directory renames in your
|
||||
> system. We recommend that you have a stable ID (like the UUID), and symlinks from the name to the
|
||||
> UUID folder. Automatic support is provided for this via the unixd tasks daemon, as documented
|
||||
> here.
|
||||
>
|
||||
> **NOTE:** Ubuntu users please see:
|
||||
> Ubuntu users please see:
|
||||
> [Why aren't snaps launching with home_alias set?](../frequently_asked_questions.md#why-arent-snaps-launching-with-home_alias-set)
|
||||
|
||||
You can then check the communication status of the daemon:
|
||||
|
|
@ -110,13 +112,17 @@ getent group testgroup
|
|||
testgroup:x:2439676479:testunix
|
||||
```
|
||||
|
||||
> **HINT** Remember to also create a UNIX password with something like
|
||||
> [!HINT]
|
||||
>
|
||||
> Remember to also create a UNIX password with something like
|
||||
> `kanidm account posix set_password --name idm_admin demo_user`. Otherwise there will be no
|
||||
> credential for the account to authenticate with.
|
||||
|
||||
## PAM
|
||||
|
||||
> **WARNING:** Modifications to PAM configuration _may_ leave your system in a state where you are
|
||||
> [!WARNING]
|
||||
>
|
||||
> Modifications to PAM configuration _may_ leave your system in a state where you are
|
||||
> unable to login or authenticate. You should always have a recovery shell open while making changes
|
||||
> (for example, root), or have access to single-user mode at the machine's console.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
# Fedora / CentOS
|
||||
|
||||
> **WARNING:** Kanidm currently has no support for SELinux policy - this may mean you need to run
|
||||
> [!WARNING]
|
||||
>
|
||||
> Kanidm currently has no support for SELinux policy - this may mean you need to run
|
||||
> the daemon with permissive mode for the `unconfined_service_t` daemon type. To do this run:
|
||||
> `semanage permissive -a unconfined_service_t`. To undo this run
|
||||
> `semanage permissive -d unconfined_service_t`.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,9 @@ authentication:
|
|||
/etc/pam.d/common-session
|
||||
```
|
||||
|
||||
> **IMPORTANT** By default these files are symlinks to their corresponding `-pc` file, for example,
|
||||
> [!IMPORTANT]
|
||||
>
|
||||
> By default these files are symlinks to their corresponding `-pc` file, for example,
|
||||
> `common-account -> common-account-pc`. If you directly edit these you are updating the inner
|
||||
> content of the `-pc` file and it WILL be reset on a future upgrade. To prevent this you must first
|
||||
> copy the `-pc` files. You can then edit the files safely.
|
||||
|
|
@ -67,5 +69,7 @@ session optional pam_kanidm.so
|
|||
session optional pam_env.so
|
||||
```
|
||||
|
||||
> **WARNING:** Ensure that `pam_mkhomedir` or `pam_oddjobd` are _not_ present in any stage of your
|
||||
> [!WARNING]
|
||||
>
|
||||
> Ensure that `pam_mkhomedir` or `pam_oddjobd` are _not_ present in any stage of your
|
||||
> PAM configuration, as they interfere with the correct operation of the Kanidm tasks daemon.
|
||||
|
|
|
|||
|
|
@ -149,7 +149,9 @@ You can then use this to run the Kanidm server in docker with a user:
|
|||
docker run --rm -i -t -u 1000:1000 -v kanidmd:/data kanidm/server:latest /sbin/kanidmd ...
|
||||
```
|
||||
|
||||
> **HINT** You need to use the UID or GID number with the `-u` argument, as the container can't
|
||||
> [!HINT]
|
||||
>
|
||||
> You need to use the UID or GID number with the `-u` argument, as the container can't
|
||||
> resolve usernames from the host system.
|
||||
|
||||
## Minimum TLS key lengths
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ WORKDIR /data
|
|||
|
||||
EXPOSE 8443 3636
|
||||
|
||||
ENV RUST_BACKTRACE 1
|
||||
ENV RUST_BACKTRACE=1
|
||||
|
||||
HEALTHCHECK \
|
||||
--interval=60s \
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ RUN \
|
|||
# == Construct the tools container
|
||||
FROM repos
|
||||
|
||||
ENV RUST_BACKTRACE 1
|
||||
ENV RUST_BACKTRACE=1
|
||||
|
||||
RUN \
|
||||
--mount=type=cache,id=zypp,target=/var/cache/zypp \
|
||||
|
|
|
|||
|
|
@ -54,11 +54,10 @@ RUN \
|
|||
--target-dir="/usr/src/kanidm/target/" && \
|
||||
sccache -s
|
||||
|
||||
# == Construct the orca container
|
||||
# == Construct the orca container
|
||||
FROM repos
|
||||
|
||||
ENV RUST_BACKTRACE 1
|
||||
|
||||
ENV RUST_BACKTRACE=1
|
||||
|
||||
COPY --from=builder /usr/src/kanidm/target/release/orca /sbin/
|
||||
COPY ./tools/orca/profile-sample.toml /etc/kanidm/profile-sample.toml
|
||||
|
|
|
|||
Loading…
Reference in a new issue