grim/hgkeeper

Update README.md for the auth changes

2019-09-10, Gary Kramlich
c486089a949b
Parents b4dd55fef66b
Children 21e7408ca1a0
Update README.md for the auth changes
1 files changed, 5 insertions(+), 66 deletions(-)
  • +5 -66
    README.md
    • --- a/README.md Tue Sep 10 21:18:34 2019 -0500
    +++ b/README.md Tue Sep 10 21:33:54 2019 -0500
    @@ -29,69 +29,8 @@
    # Access Control
    -Controlling access to the repositories is done via the `hgkeeper` repository.
    -The repository has a specific layout to make it easier to reason about.
    -
    -```
    -hgkeeper/
    - - keys/
    - - user1
    - - user2
    - - access.yml
    -```
    -
    -## keys/
    -
    -The keys directory contains a list of files that contain one or many SSH public
    -keys. It is entirely up to you on how to name these files and their contents,
    -but note that the filename is used in `access.yml` to delegate permissions.
    -
    -## access.yml
    -
    -`access.yml` is the access control configuration. When you initial setup
    -`hgkeeper` you will get an `access.yml` like the following.
    -
    -```yaml
    -global:
    - init:
    - - admins
    - read:
    - - public
    -groups:
    - admins:
    - - grim
    -patterns:
    - hgkeeper:
    - read:
    - - admins
    - write:
    - - admins
    -```
    -
    -There's a lot going on here, so let's talk about the basics here first. Access
    -is granted to user via the file name in the `keys/` directory or the name of a
    -group.
    -
    -The `groups` section contains the name of the group and the list of keys that
    -are in that group. So in the above example, the `admins` group has one file
    -who's keys will be put into the `admins` group. You can add a group to another
    -group. There is also a special built-in group named `public` which will allow
    -anyone to access the repository.
    -
    -Now that we have a basic understanding of how keys are specified, we can cover
    -how to grant and revoke their permissions to specific repositories.
    -
    -The `global` and `patterns` sections use a simple format to specify a list of
    -which keys are allowed to init (create), read, and write repositories.
    -
    -The `global` section contains the defaults for all repositories. In the above
    -example, it gives permission to `admins` to create repositories anywhere and
    -allows all users to read all repositories. These permissions will be used
    -only if a repository's matching pattern does not specify a value for this
    -field.
    -
    - The `patterns` section uses a key of a glob of what repositories to apply
    - these changes to. Since this is a glob pattern, that means it'll allow `*`
    - and `?` for wildcards. If an entry in a `patterns` entry does not specify
    - any of the init, read, and/or write permissions, the corresponding value from
    - the global section will be used.
    \ No newline at end of file
    +Access control is defined in the `hgkeeper` repository that is created via the
    +`hgkeeper setup` command. It is implemented via [casbin](https://casbin.org)
    +using the RBAC with deny-override model as a base. More information can be
    +found in the [files](setup/resources/) that are placed in the `hgkeeper`
    +repository.