website/docs: re-organise core concepts

Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>

website/docs/core/applications.md

@@ -0,0 +1,41 @@
+---
+title: Applications
+slug: /applications
+---
+
+Applications in authentik are the counterpart of providers. They exist in a 1-to-1 relationship, each application needs a provider and every provider can be used with one application.
+
+Applications are used to configure and separate the authorization / access control and the appearance in the Library page.
+
+## Authorization
+
+Application access can be configured using (Policy) Bindings. You can use this to grant access to one or multiple users/groups, or dynamically give access using policies.
+
+By default, all users can access applications when no policies are bound.
+
+When multiple policies/groups/users are attached, you can configure the *Policy engine mode* to either
+
+    - Require users to pass all bindings/be member of all groups (ALL), or
+    - Require users to pass either binding/be member of either group (ANY)
+
+## Appearance
+
+The following aspects can be configured:
+
+    - *Name*: This is the name shown for the application card
+    - *Launch URL*: The URL that is opened when a user clicks on the application. When left empty, authentik tries to guess it based on the provider
+    - *Icon (URL)*: Optionally configure an Icon for the application
+    - *Publisher*: Text shown below the application
+    - *Description*: Subtext shown on the application card below the publisher
+
+Applications are shown to users when
+
+    - The user has access defined via policies (or the application has no policies bound)
+    - A Valid Launch URL is configured/could be guessed, this consists of URLs starting with http:// and https://
+
+
+#### Hiding applications
+
+To hide applications without modifying policy settings and without removing it, you can simply set the *Launch URL* to `blank://blank`, which will hide the application from users.
+
+Keep in mind, the users still have access, so they can still authorize access when the login process is started from the application.

website/docs/core/tenants.md

@@ -0,0 +1,22 @@
+---
+title: Tenants
+slug: /tenants
+---
+
+authentik support soft multi-tenancy. This means that you can configure several options depending on domain, but all the objects like applications, providers, etc, are still global. This can be handy to use the same authentik instance, but branded differently for different domains.
+
+The main settings that tenants influence are flows and branding.
+
+## Flows
+
+authentik picks a default flow by picking the flow that is selected in the current tenant, otherwise any flow that
+
+    - matches the required designation
+    - comes first sorted by slug
+    - is allowed by policies
+
+This means that if you want to select a default flow based on policy, you can just leave the tenant default empty.
+
+## Branding
+
+The tenant can configure the branding title (shown in website document title and several other places), and the sidebar/header logo.

website/docs/core/terminology.md

@@ -0,0 +1,51 @@
+---
+id: terminology
+title: Terminology
+slug: /terminology
+---
+
+![](/img/authentik_objects.svg)
+
+### System tasks
+
+These are longer-running tasks which authentik runs in the background. This is used to sync LDAP sources, backup the database, and other various tasks.
+
+### Application
+
+An application links together Policies with a Provider, allowing you to control access. It also holds Information like UI Name, Icon and more.
+
+### Source
+
+Sources are locations from which users can be added to authentik. For example, an LDAP Connection to import Users from Active Directory, or an OAuth2 Connection to allow Social Logins.
+
+### Provider
+
+A Provider is a way for other applications to authenticate against authentik. Common Providers are OpenID Connect (OIDC) and SAML.
+
+### Policy
+
+At a base level a policy is a yes/no gate. It will either evaluate to True or False depending on the Policy Kind and settings. For example, a "Group Membership Policy" evaluates to True if the user is member of the specified Group and False if not. This can be used to conditionally apply Stages, grant/deny access to various objects, and for other custom logic.
+
+See [Policies](./policies/index.md)
+
+### Stages & Stages
+
+Flows are an ordered sequence of stages. These flows can be used to define how a user authenticates, enrolls, etc.
+
+A stage represents a single verification or logic step. They are used to authenticate users, enroll users, and more. These stages can optionally be applied to a flow via policies.
+
+See [Flows](./flow/flows.md)
+
+### Property Mappings
+
+Property Mappings allow you to make information available for external applications. For example, if you want to login to AWS with authentik, you'd use Property Mappings to set the user's roles in AWS based on their group memberships in authentik.
+
+See [Property Mappings](./property-mappings/index.md)
+
+### Outpost
+
+An outpost is a separate component of authentik, which can be deployed anywhere, regardless of the authentik deployment. The outpost offers services that aren't implemented directly into the authentik core, like Reverse Proxying.
+
+Currently there is only a reverse-proxy outpost, in the future there will be more different outpost types.
+
+See [Outposts](./outposts/outposts.md)