mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-06 06:12:16 +00:00
docs: fixed some typos, formatting, grammar (#11540)
# Which Problems Are Solved - Typos - Punctuation - Markdown table formatting - ... (A bunch of issues my editor gave) # How the Problems Are Solved # Additional Changes # Additional Context
This commit is contained in:
@@ -3,16 +3,16 @@ title: ZITADEL's In-built Audit Trail
|
||||
sidebar_label: Audit Trail
|
||||
---
|
||||
|
||||
ZITADEL provides you with an built-in audit trail to track all changes and events over an unlimited period of time.
|
||||
Most other solutions replace a historic record and track changes in a separate log when information is updated.
|
||||
ZITADEL only ever appends data in an [Eventstore](/concepts/eventstore/overview), keeping all historic record.
|
||||
ZITADEL provides you with a built-in audit trail to track all changes and events over an unlimited period of time.
|
||||
Most other solutions replace a historical record and track changes in a separate log when information is updated.
|
||||
ZITADEL only ever appends data in an [Eventstore](/concepts/eventstore/overview), keeping all historical record.
|
||||
The audit trail itself is identical to the state, since ZITADEL calculates the state from all the past changes.
|
||||
|
||||

|
||||
|
||||
This form of audit log has several benefits over storing classic audit logs.
|
||||
You can view past data in-context of the whole system at a single point in time.
|
||||
Reviewing a past state of the application can be important when tracing an incident that happened months back. Moreover the eventstore provides a truly complete and clean audit log.
|
||||
Reviewing a past state of the application can be important when tracing an incident that happened months back. Moreover, the eventstore provides a truly complete and clean audit log.
|
||||
|
||||
<Callout title="Future Plans">
|
||||
There will be three major areas for future development on the audit data
|
||||
@@ -28,7 +28,7 @@ There will be three major areas for future development on the audit data
|
||||
### Last changes of an object
|
||||
|
||||
You can check the last changes of most objects in the [Console](/guides/manage/console/console-overview).
|
||||
In the following screenshot you can see an example of last changes on an [user](/guides/manage/console/users-overview).
|
||||
In the following screenshot you can see an example of last changes on a [user](/guides/manage/console/users-overview).
|
||||
The same view is available on several other objects such as organization or project.
|
||||
|
||||

|
||||
@@ -42,7 +42,7 @@ Go to your default settings and then click on the Tab **Events** to open the Eve
|
||||
|
||||
### Event API
|
||||
|
||||
Since everything that is available in Management Console can also be called with our APIs, you can access all events and audit data trough our APIs:
|
||||
Since everything that is available in Management Console can also be called with our APIs, you can access all events and audit data through our APIs:
|
||||
|
||||
- [Event API Guide](/guides/integrate/zitadel-apis/event-api)
|
||||
- [API Documentation](/reference/api/admin)
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Identity Brokering
|
||||
sidebar_label: Identity Brokering
|
||||
---
|
||||
|
||||
Link social logins and external identity providers with your identity management platform allowing users to login with their preferred identity provider.
|
||||
Link social logins and external identity providers with your identity management platform allowing users to log in with their preferred identity provider.
|
||||
|
||||
Establish a trusted connection between your central identity provider (IdP) and third party identity providers.
|
||||
|
||||
@@ -26,7 +26,7 @@ A service provider that specializes in brokering access control between multiple
|
||||
Federated identity management is an arrangement that is made between two or more such identity brokers across organizations.
|
||||
|
||||
For example, if Google is configured as an identity provider in your organization, the user will get the option to use his Google Account on the Login Screen of ZITADEL.
|
||||
Because Google is registered as a trusted identity provider, the user will be able to login in with the Google account after the user is linked with an existing ZITADEL account (if the user is already registered) or a new one with the claims provided by Google.
|
||||
Because Google is registered as a trusted identity provider, the user will be able to log in with the Google account after the user is linked with an existing ZITADEL account (if the user is already registered) or a new one with the claims provided by Google.
|
||||
|
||||

|
||||
|
||||
@@ -41,9 +41,9 @@ The schema is a very simplified version, but shows the essential steps for ident
|
||||
## Is single-sign-on (SSO) the same as identity brokering?
|
||||
|
||||
Sometimes single-sign-on (SSO) and login with third party identity providers is used interchangeably.
|
||||
Typically SSO describes an authentication scheme that allows users to log in once at a central identity provider and access service providers (client applications) without to login again.
|
||||
Typically, SSO describes an authentication scheme that allows users to log in once at a central identity provider and access service providers (client applications) without having to login again.
|
||||
|
||||
Identity brokering describes an authentication scheme where users can login with external identity providers that have a established trust with an identity provider which facilitates the authentication for the requested applications.
|
||||
Identity brokering describes an authentication scheme where users can log in with external identity providers that have an established trust with an identity provider which facilitates the authentication for the requested applications.
|
||||
|
||||
The connection between the two lies in how SSO can be implemented as part of an identity brokering solution.
|
||||
In such cases, the identity broker uses SSO to enable seamless access across multiple systems, handling the complexities of different authentication protocols and standards behind the scenes.
|
||||
@@ -52,7 +52,7 @@ This allows users to log in once and gain access to multiple systems that the br
|
||||
## Multitenancy and identity brokering
|
||||
|
||||
In a multi-tenancy application, you want to be able to configure an external identity provider per tenant.
|
||||
For example some organizations might use their EntraID, some other want to login with their OKTA, or Google Workspace.
|
||||
For example some organizations might use their EntraID, some other want to log in with their OKTA, or Google Workspace.
|
||||
|
||||
Using an identity provider with strong multitenancy capabilities such as ZITADEL, you can configure a different set of external identity providers per organization.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user