Files
authentik/website/docs/users-sources/access-control/permissions.md
Tana M Berry 6d5172d18a website: latest PR for new Docs structure (#11639)
* first pass

* dependency shenanigans

* move blueprints

* few broken links

* change config the throw errors

* internal file edits

* fighting links

* remove sidebarDev

* fix subdomain

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* fix relative URL

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* fix mismatched package versions

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* fix api reference build

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* test tweak

* links hell

* more links hell

* links hell2

* yep last of the links

* last broken link fixed

* re-add cves

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* add devdocs redirects

* add dir

* tweak netlify.toml

* move latest 2 CVES into dir

* fix links to moved cves

* typoed title fix

* fix link

* remove banner

* remove committed api docs

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* integrations: remove version dropdown

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* Update Makefile

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* change doc links in web as well

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* fix some more docs paths

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* fix more docs paths

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* ci: require ci-web.build for merging

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* Revert "ci: require ci-web.build for merging"

This reverts commit b99a4842a9.

* remove sluf for Application

* put slug back in

* minor fix to trigger deploy

* Spelled out Documentation in menu bar

* remove image redirects...

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* remove explicit index.md

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* remove mdx first

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* then remove .md

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* add missing prefix

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

---------

Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Co-authored-by: Tana M Berry <tana@goauthentik.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
2024-10-09 09:33:40 -05:00

2.8 KiB

title, description
title description
About permissions Learn about global and object permissions in authentik.

Permissions are the central components in all access control systems, the lowest-level components, the controlling pieces of access data. Permissions are assigned to (or removed from!) to define exactly WHO can do WHAT to WHICH part of the overall software system.

:::info Note that global and object permissions only apply to objects within authentik, and not to who can access certain applications (which are access-controlled using policies). :::

For instructions to add, remove, and manage permissions, refer to Manage Permissions.

Fundamentals of authentik permissions

There are two main types of permissions in authentik:

Global permissions

Global permissions define who can do what on a global level across the entire system. Some examples in authentik are the ability to add new flows or to create a URL for users to recover their login credentials.

You can assign global permissions to individual users or to roles. The most common and best practice is to assign permissions to roles.

Object permissions

Object permissions have two categories:

  • User object permissions: defines WHO (which user) can change the object
  • Role object permissions: defines which ROLE can change the object

Object permissions are assigned, as the name indicates, to an object (users, groups, roles, flows, and stages), and the assigned permissions state exactly what a user or role can do TO the object (i.e. what permissions does the user or role have on that object).

When working with object permissions it is important to understand that when you are viewing the page for an object, the permissions table shows which users or roles have permissions ON that specific object. Those permissions describe what those users or roles can do TO the object detailed on the page.

For example, the Admin interface UI shown below shows a user page for the user named Peter.

You can see in the User Object Permissions table that the Admin user (akadmin) and one other user (roberto) has permissions on Peter (that is, on the user object named Peter).

Looking at another example, with a flow object called default-recovery-flow, you can see that the Admin user (akadmin) has all object permissions on the flow, but roberto only has a few permissions on that flow.