forked from authentricity/authentricity
Dockerize, readme update
This commit is contained in:
parent
15eece9f46
commit
80c9892b0b
17
Dockerfile
Normal file
17
Dockerfile
Normal file
|
@ -0,0 +1,17 @@
|
|||
ARG ALPINE=3.18
|
||||
FROM golang:1.20-alpine${ALPINE} AS build
|
||||
WORKDIR /app
|
||||
COPY go.mod go.sum .
|
||||
RUN go mod download
|
||||
|
||||
ADD . /app
|
||||
RUN go build -o ./authentricity-webui ./cmd/authentricity-webui
|
||||
RUN go build -o ./authentricity-admin ./cmd/authentricity-admin
|
||||
|
||||
FROM alpine:${ALPINE}
|
||||
|
||||
WORKDIR /bin
|
||||
COPY --from=build /app/authentricity-webui /app/authentricity-admin .
|
||||
|
||||
WORKDIR /
|
||||
CMD ["/bin/authentricity-webui"]
|
48
README.md
48
README.md
|
@ -17,8 +17,52 @@ Unix logins. This component implements the systemd
|
|||
[User/Group Varlink API](https://systemd.io/USER_GROUP_API/) to support user and group
|
||||
lookups.
|
||||
|
||||
It is intended to be deployed as a systemd service. See [module.nix](./module.nix), which
|
||||
can be used to deploy this on NixOS for details
|
||||
|
||||
For both performance and resilience resaons, user information is cached locally:
|
||||
|
||||
* Information less than 60s old is considered up-to-date and Consul is not re-queried for it,
|
||||
speeding up user information requests and reducing Consul load, and
|
||||
* In cases where Consul is unable to service requests, then the cache will be considered valid
|
||||
indefinitely
|
||||
|
||||
A future version may limit the amount of time locally cached information is considered valid.
|
||||
|
||||
TODO: Provide raw systemd unit files
|
||||
|
||||
#### authentricity-webui
|
||||
SSO portal and user administration UI
|
||||
This implements
|
||||
|
||||
* A login system, and single-domain shared cookie SSO system
|
||||
* A portal which lets users add & remove SSH keys, change their password, etc,
|
||||
and
|
||||
* A UI which lets users explore other users and groups, and which lets admins manage
|
||||
users and groups
|
||||
* A UI which lets admins manipulate users and groups
|
||||
|
||||
This can be deployed as either
|
||||
|
||||
* A systemd service (see [module.nix](./module.nix)), or
|
||||
* A [container](https://git.shinra.systems/authentricity/-/packages/container/authentricity/)
|
||||
|
||||
TODO: Provide raw systemd unit files
|
||||
TODO: Provide example Kubernetes manifests/Kustomize chart?
|
||||
|
||||
#### authentricity-admin
|
||||
Command line administation tool (performing direct database accesses)
|
||||
Command line administation tool (performing direct database accesses)
|
||||
|
||||
### Future Components
|
||||
* Radius server
|
||||
* Likely minimal feature set at first (PAP, no EAP, etc)
|
||||
* TACACS+ server
|
||||
* For networking appliances
|
||||
* Separate cookie used for the Web UI from the auth proxy
|
||||
* We can then domain scope the Web UI cookie down to just the UI itself,
|
||||
protecting better against Cookie theft attacks
|
||||
* We can use asymmetric crypto for the domain-wide cookie and distribute the public
|
||||
keys to auth proxies via Consul
|
||||
* JWT/OAuth 2.0/OpenID Connect issuer
|
||||
* Integration of tokens into the Unix auth flow
|
||||
* Return something like a Kerberos TGT that can be exchanged for service JWTs?
|
||||
* Minimal authentication proxy without the Web UI?
|
||||
|
|
Loading…
Reference in a new issue