Default policy attributes?

[leplatrem]

From https://github.com/mozilla/doorman/pull/93#pullrequestreview-92201852

service: SLocf7Sa1ibd5GN
ìdentityProvider: https://auth.mozilla.auth0.com
policies:
  -
    id: staff-only
    description: Staff only
    principals:
      - group:hris_staff
    actions:
      - <.*>
    resources:
      - <.*>
    effect: allow

Do I have to fill in all those things? It seems the only useful fields here are: identityProvider, id and principles.

Currently we don't set <.*> as the default policy attributes values. But we could.

Isn't the service implied by the .yaml file all these policies are in?

@peterbe what do you mean, use the filename as the service identifier?

Isn't the default, if the identity provider and group name match, to allow the user in?

Currently we don't use allow as the default value for effect. But we could.

[peterbe]

@peterbe what do you mean, use the filename as the service identifier?

Perhaps I haven't understood how the deployment is going to be done, but I envisioned a private githup repo that contains many .yml files. For example symbols.prod.yml. No? Or is it going to be one large policies.yml file?

[peterbe]

I know I raised those questions but after some more thinking I think there's a better way to reason about this.

The yaml file can continue to look more computer-friendly than human-friendly. The win is going to be in the tooling around. For example, there could be a cli app that asks you friendly questions that creates the file for you. Similar, to how npm init creates the first package.json. Or there might be a little single-page-app JS app that asks theses questions in the browser as a form and spits out the result, for copying, in a <pre> tag.

Ultimately, my head is thinking about the developer experience and that that feels easy more than anything otherwise Doorman won't be any fun to use.