mirror of
https://github.com/kanidm/kanidm.git
synced 2025-02-23 12:37:00 +01:00
Resolve 139, 140, 141, 142 (#143)
This commit is contained in:
parent
516a128c5f
commit
4f28bb5bc3
|
@ -19,8 +19,15 @@ the database:
|
|||
|
||||
docker volume create kanidmd
|
||||
|
||||
You should have a ca.pem, cert.pem and key.pem in your kanidmd volume. It's up to you to put them
|
||||
in there some how.
|
||||
You should have a ca.pem, cert.pem and key.pem in your kanidmd volume. The reason for requiring
|
||||
TLS is explained in [why tls]. To put the certificates in place you can use a shell container
|
||||
that mounts the volume such as:
|
||||
|
||||
[why tls]: https://github.com/Firstyear/kanidm/blob/master/designs/why_tls.rst
|
||||
|
||||
docker run --rm -i -t -v kanidmd:/data -v /my/host/path/work:/work opensuse/leap:latest cp /work/* /data/
|
||||
OR for a shell into the volume:
|
||||
docker run --rm -i -t -v kanidmd:/data opensuse/leap:latest /bin/sh
|
||||
|
||||
Then you can setup the initial admin account and initialise the database into your volume.
|
||||
|
||||
|
@ -29,7 +36,7 @@ Then you can setup the initial admin account and initialise the database into yo
|
|||
You can now run the server - note that we provide all the options on the cli, but this pattern
|
||||
may change in the future.
|
||||
|
||||
docker run -p 443:8443 -v /Users/william/development/rsidm/insecure:/data firstyear/kanidmd:latest /home/kanidm/target/release/kanidmd server -D /data/kanidm.db -C /data/ca.pem -c /data/cert.pem -k /data/key.pem --bindaddr 0.0.0.0:8443 --domain localhost
|
||||
docker run -p 8443:8443 -v /Users/william/development/rsidm/insecure:/data firstyear/kanidmd:latest /home/kanidm/target/release/kanidmd server -D /data/kanidm.db -C /data/ca.pem -c /data/cert.pem -k /data/key.pem --bindaddr 0.0.0.0:8443 --domain localhost
|
||||
|
||||
# Using the cli
|
||||
|
||||
|
@ -43,8 +50,8 @@ After you check out the source, navigate to:
|
|||
Now you can check your instance is working. You may need to provide a CA certificate for verification
|
||||
with the -C parameter:
|
||||
|
||||
cargo run -- self whoami -C ../path/to/ca.pem -H https://localhost --name anonymous
|
||||
cargo run -- self whoami -H https://localhost --name anonymous
|
||||
cargo run -- self whoami -C ../path/to/ca.pem -H https://localhost:8443 --name anonymous
|
||||
cargo run -- self whoami -H https://localhost:8443 --name anonymous
|
||||
|
||||
Now you can take some time to look at what commands are available - things may still be rough so
|
||||
please ask for help at anytime.
|
||||
|
@ -221,16 +228,16 @@ of entries at once. Some examples are below, but generally we advise you to use
|
|||
above.
|
||||
|
||||
# Create from json (group or account)
|
||||
cargo run -- raw create -H https://localhost:8080 -C ../insecure/ca.pem -D admin example.create.account.json
|
||||
cargo run -- raw create -H https://localhost:8080 -C ../insecure/ca.pem -D idm_admin example.create.group.json
|
||||
cargo run -- raw create -H https://localhost:8443 -C ../insecure/ca.pem -D admin example.create.account.json
|
||||
cargo run -- raw create -H https://localhost:8443 -C ../insecure/ca.pem -D idm_admin example.create.group.json
|
||||
|
||||
# Apply a json stateful modification to all entries matching a filter
|
||||
cargo run -- raw modify -H https://localhost:8080 -C ../insecure/ca.pem -D admin '{"Or": [ {"Eq": ["name", "idm_person_account_create_priv"]}, {"Eq": ["name", "idm_service_account_create_priv"]}, {"Eq": ["name", "idm_account_write_priv"]}, {"Eq": ["name", "idm_group_write_priv"]}, {"Eq": ["name", "idm_people_write_priv"]}, {"Eq": ["name", "idm_group_create_priv"]} ]}' example.modify.idm_admin.json
|
||||
cargo run -- raw modify -H https://localhost:8080 -C ../insecure/ca.pem -D idm_admin '{"Eq": ["name", "idm_admins"]}' example.modify.idm_admin.json
|
||||
cargo run -- raw modify -H https://localhost:8443 -C ../insecure/ca.pem -D admin '{"Or": [ {"Eq": ["name", "idm_person_account_create_priv"]}, {"Eq": ["name", "idm_service_account_create_priv"]}, {"Eq": ["name", "idm_account_write_priv"]}, {"Eq": ["name", "idm_group_write_priv"]}, {"Eq": ["name", "idm_people_write_priv"]}, {"Eq": ["name", "idm_group_create_priv"]} ]}' example.modify.idm_admin.json
|
||||
cargo run -- raw modify -H https://localhost:8443 -C ../insecure/ca.pem -D idm_admin '{"Eq": ["name", "idm_admins"]}' example.modify.idm_admin.json
|
||||
|
||||
# Search and show the database representations
|
||||
cargo run -- raw search -H https://localhost:8080 -C ../insecure/ca.pem -D admin '{"Eq": ["name", "idm_admin"]}'
|
||||
cargo run -- raw search -H https://localhost:8443 -C ../insecure/ca.pem -D admin '{"Eq": ["name", "idm_admin"]}'
|
||||
> Entry { attrs: {"class": ["account", "memberof", "object"], "displayname": ["IDM Admin"], "memberof": ["idm_people_read_priv", "idm_people_write_priv", "idm_group_write_priv", "idm_account_read_priv", "idm_account_write_priv", "idm_service_account_create_priv", "idm_person_account_create_priv", "idm_high_privilege"], "name": ["idm_admin"], "uuid": ["bb852c38-8920-4932-a551-678253cae6ff"]} }
|
||||
|
||||
# Delete all entries matching a filter
|
||||
cargo run -- raw delete -H https://localhost:8080 -C ../insecure/ca.pem -D idm_admin '{"Eq": ["name", "test_account_delete_me"]}'
|
||||
cargo run -- raw delete -H https://localhost:8443 -C ../insecure/ca.pem -D idm_admin '{"Eq": ["name", "test_account_delete_me"]}'
|
||||
|
|
35
designs/why_tls.rst
Normal file
35
designs/why_tls.rst
Normal file
|
@ -0,0 +1,35 @@
|
|||
Why TLS is required?
|
||||
--------------------
|
||||
|
||||
In the getting started you may notice that we require TLS to be configure in
|
||||
your container - or that you provide something *with* TLS in front like haproxy.
|
||||
|
||||
This is due to a single setting on the server - secure_cookies
|
||||
|
||||
What are secure cookies?
|
||||
------------------------
|
||||
|
||||
Secure Cookies is a flag set in cookies that "asks" a client only to transmit them
|
||||
back to the origin site if and only if https is present in the URL.
|
||||
|
||||
CA verification is *not* checked - you can use invalid, out of date certificates,
|
||||
or even certificates where the subjectAltName does not match. But the client
|
||||
must see https:// as the destination else it *will not* send the cookies.
|
||||
|
||||
How does that affect kanidm?
|
||||
----------------------------
|
||||
|
||||
Kanidm's authentication system is a stepped challenge response design, where you
|
||||
initially request an "intent" to authenticated. Once you establish this intent
|
||||
the server set's up a session-id into a cookie, and we inform the client of
|
||||
what authentication methods can proceed.
|
||||
|
||||
When you then go to continue the authentication if you do NOT have a https url
|
||||
the cookie with the session-id is not transmitted. The server detects this as
|
||||
an invalid-state request in the authentication design and immediately disconnects
|
||||
you from attempting to continue the authentication as you may be using an insecure
|
||||
channel.
|
||||
|
||||
Simply put, we are trying to use settings like secure_cookies to add constraints
|
||||
to the server so that you *must* perform and adhere to best practices - such
|
||||
as having TLS present on your communication channels.
|
|
@ -1,22 +1,21 @@
|
|||
FROM opensuse/tumbleweed:latest
|
||||
MAINTAINER william@blackhats.net.au
|
||||
|
||||
EXPOSE 8080
|
||||
|
||||
COPY . /home/kanidm/
|
||||
|
||||
WORKDIR /home/kanidm/
|
||||
|
||||
RUN zypper install -y timezone cargo rust gcc sqlite3-devel libopenssl-devel && \
|
||||
RUSTC_BOOTSTRAP=1 cargo build --release && \
|
||||
zypper rm -u -y cargo rust gcc && \
|
||||
zypper clean
|
||||
RUSTC_BOOTSTRAP=1 cargo build --release
|
||||
|
||||
RUN cd /etc && \
|
||||
ln -sf ../usr/share/zoneinfo/Australia/Brisbane localtime
|
||||
FROM opensuse/tumbleweed:latest
|
||||
|
||||
EXPOSE 8080
|
||||
WORKDIR /
|
||||
COPY --from=0 /home/kanidm/target/release/kanidmd /sbin/
|
||||
|
||||
VOLUME /data
|
||||
|
||||
ENV RUST_BACKTRACE 1
|
||||
CMD ["/home/kanidm/target/release/kanidmd", "server", "-D", "/data/kanidm.db", "-C", "/data/ca.pem", "-c", "/data/cert.pem", "-k", "/data/key.pem", "--bindaddr", "0.0.0.0:8080"]
|
||||
CMD ["/sbin/kanidmd", "server", "-D", "/data/kanidm.db", "-C", "/data/ca.pem", "-c", "/data/cert.pem", "-k", "/data/key.pem", "--bindaddr", "0.0.0.0:8080"]
|
||||
|
||||
|
|
Loading…
Reference in a new issue