-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
website/docs: add content about bindings #11787
Conversation
✅ Deploy Preview for authentik-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for authentik-storybook canceled.
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #11787 +/- ##
==========================================
- Coverage 92.77% 92.76% -0.02%
==========================================
Files 767 767
Lines 38522 38523 +1
==========================================
- Hits 35737 35734 -3
- Misses 2785 2789 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
authentik PR Installation instructions Instructions for docker-composeAdd the following block to your AUTHENTIK_IMAGE=ghcr.io/goauthentik/dev-server
AUTHENTIK_TAG=gh-abe2cfc0f62caaa51554d159e28d786c48f2a50d
AUTHENTIK_OUTPOSTS__CONTAINER_IMAGE_BASE=ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s For arm64, use these values: AUTHENTIK_IMAGE=ghcr.io/goauthentik/dev-server
AUTHENTIK_TAG=gh-abe2cfc0f62caaa51554d159e28d786c48f2a50d-arm64
AUTHENTIK_OUTPOSTS__CONTAINER_IMAGE_BASE=ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s Afterwards, run the upgrade commands from the latest release notes. Instructions for KubernetesAdd the following block to your authentik:
outposts:
container_image_base: ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s
global:
image:
repository: ghcr.io/goauthentik/dev-server
tag: gh-abe2cfc0f62caaa51554d159e28d786c48f2a50d For arm64, use these values: authentik:
outposts:
container_image_base: ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s
global:
image:
repository: ghcr.io/goauthentik/dev-server
tag: gh-abe2cfc0f62caaa51554d159e28d786c48f2a50d-arm64 Afterwards, run the upgrade commands from the latest release notes. |
Images automagically compressed by Calibre's image-actions ✨ Compression reduced images by 44.7%, saving 168.00 KB.
159 images did not require optimisation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a couple of concerns.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much more clear, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm approving because I suspect I may misunderstand some of the instructions. But if I misunderstand, others may as well, so I left comments.
|
||
- **Configure a Provider**: Provide a name (or accept the auto-provided name), the authorization flow to use for this provider, and any additional required configurations. | ||
|
||
- **Configure Bindings**: To manage the display of the new application on the **My applications** page, you can optionally define [bindings](../flows-stages/bindings/index.md) for a specific policy, group, or user. To do so in the Wizard, click **Bind existing policy/group/user** to add a binding. You can select an existing policy binding, or create a new binding specifically for a group or user. For example, if you select **User** and then choose an existing user from the drop-down menu, you create a new binding between the user and this specific application. Note that if you do not define any bindings, then all users have access to the application. For more information, refer to [authorization](#authorization). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I worry that this confuses the issue for experienced users. I don't know that there's a need to explain the difference between Users, Groups, and other Policies here. That's the problem with having "Policy" Policy bindings. Maybe we should call them something else, I dunno, "Custom" bindings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am interested in the idea of calling them something else... maybe Application bindings. And then once you say you want an application binding, you choose via radio buttons if you want to bind a Group, a User, or an existing Policy binding. So it ends up with same result, but the beginning part, with the three tabs, might not be so confusing.
title: Bindings | ||
--- | ||
|
||
A binding is, simply put, a connection between two components (a flow, stage, policy, user, or group) _that adds additional content_ to one those existing components. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Content" is such a weird word. "Functionality?" "Intelligence?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, content is not at all the right word here. Let me try to reword...
|
||
## Bind users and groups to a flow's stage binding | ||
|
||
You can use bindings to determine whehther or not a stage is presented to a single user or any users within a group. You do this by binding the user or group to a stage binding within a specific flow. For example, if you have a flow that contains a stage that prompts the user for multi-factor authentication, but you only want certain users to see this stage (and fulfill the MFA prompt), then you would bind the appropriate group (or single user) to the stage binding for that flow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So... what do the users who don't see this stage experience?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They just see the next stage (that they are allowed to see) in the flow. @BeryJu please confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Man, I'm in a nitpicky mood. Sorry about this. I still learned a lot just from reading it.
It's important to remember that bindings are instantiated objects themselves, and conceptually can be considered as the "connector" between two components. This is why you might read about "binding a binding", because technically, a binding is "spliced" into another binding, in order to intercept and enforce the criteria defined in the second binding. | ||
|
||
:::info | ||
Be aware that some stages and flows do not allow user or group bindings, because in certain scenarios (authentication or enrollment), the flow plan doesn't yet know who the user or group is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: "In scenarios where the user or group cannot be known, such as authentication or enrollment, user and group bindings will not work. To prevent mistakes, stages and flows meant to be seen by unauthorized or pre-authorized users will not permit user and group bindings." (Is this true?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not actually sure. The original sentence came from Jens telling me that before the system nows who a user is, they can't possibly create a bindings between the stage or flow and the [unknown] user. I think it is that simple, but will find out. So I don;t think it is as fancy as your second sentence... it's not that the system is explicitly preventing because the user is not supposed to see it (unauthorized to see it) but rather that the user is not yet authenticated, so we don't know what user object to bind too. @BeryJu?
/cherry-pick version-2024.12 |
Co-authored-by: Tana M Berry <tana@goauthentik.com> Co-authored-by: authentik-automation[bot] <135050075+authentik-automation[bot]@users.noreply.github.com>
Co-authored-by: Tana M Berry <tana@goauthentik.com> Co-authored-by: authentik-automation[bot] <135050075+authentik-automation[bot]@users.noreply.github.com>
website/docs: add content about bindings (#11787) Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Co-authored-by: Tana M Berry <tana@goauthentik.com> Co-authored-by: authentik-automation[bot] <135050075+authentik-automation[bot]@users.noreply.github.com>
This PR:
TODO:
entitlements
scope on line 51. (That link is broken for now until Jen's PR for app entitlements is merged.)Related to #11587
make website
)