authenticationauthentikauthorizationkubernetesoauth2oauth2-clientoauth2-serveroidcoidc-clientoidc-providerproxyreverse-proxysamlsaml-idpsaml-spsecuritysso
19e8b675ae
The project "Change Admin UI lists to have sublists per type" requires some initial changes to the UI to facilitate this request. The AdminSidebar is the principle target of this project, and it is embedded in the AdminInterface. To facilitate editing the AdminSidebar as an independent entity, AdminInterface has been moved into its own folder and the AdminSidebar extracted as a standalone Web Component. This removes, oh, about half the code from AdminInterface. A little cleanup with `classMap` was also committed. The rollup config was adjusted to find the new AdminInterface location. The Sidebar uses the global `config: Config` object to check for Enterprise capabilities. Rather than plumb all the way down through the Interface => AdminInterface -> AdminSidebar, I chose to make provide an alternative way of reaching the `config` object, as a *context*. Other configuration objects (Me, UiConfig, Tenant) interfaces will be contextualized as demand warrants. Demand will warrant. Just not yet. <sup>1</sup> The Sidebar has been refactored only slightly; the renderers are entirely the same as they were prior to extraction. What has been changed is the source of information: when we retrieve the current version we story *only* the information, and use type information to ensure that the version we store is the version we care about. The same is true of `impersonation`; we care only about the name of the person being impersonated being present, so we don't store anything else. Fetches have been moved from `firstUpdated` to the constructor. No reason to have the sidebar render twice if the network returns before the render is scheduled. Because the path used to identify the user being impersonated has changed, the `str()` references in the XLIFF files had to be adjusted. **This change is to a variable only and does not require translation.** --- <sup>1</sup> The code is littered with checks to `me()?`, `uiConfig?`, `config?`, etc. In the *context* of being logged in as an administrator those should never be in doubt. I intend to make our interfaces not have any doubt. |
||
|---|---|---|
| .github | ||
| .vscode | ||
| authentik | ||
| blueprints | ||
| cmd | ||
| internal | ||
| lifecycle | ||
| locale | ||
| schemas | ||
| scripts | ||
| tests | ||
| web | ||
| website | ||
| .bumpversion.cfg | ||
| .dockerignore | ||
| .editorconfig | ||
| .gitignore | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| docker-compose.yml | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| ldap.Dockerfile | ||
| LICENSE | ||
| Makefile | ||
| manage.py | ||
| poetry.lock | ||
| proxy.Dockerfile | ||
| pyproject.toml | ||
| radius.Dockerfile | ||
| README.md | ||
| schema.yml | ||
| SECURITY.md | ||
What is authentik?
authentik is an open-source Identity Provider that emphasizes flexibility and versatility. It can be seamlessly integrated into existing environments to support new protocols. authentik is also a great solution for implementing sign-up, recovery, and other similar features in your application, saving you the hassle of dealing with them.
Installation
For small/test setups it is recommended to use Docker Compose; refer to the documentation.
For bigger setups, there is a Helm Chart here. This is documented here.
Screenshots
| Light | Dark |
|---|---|
 |
 |
 |
 |
Development
Security
See SECURITY.md
Adoption and Contributions
Your organization uses authentik? We'd love to add your logo to the readme and our website! Email us @ hello@goauthentik.io or open a GitHub Issue/PR! For more information on how to contribute to authentik, please refer to our CONTRIBUTING.md file.