diff --git a/site/index.html b/site/index.html index 5398f0287..c056252d1 100644 --- a/site/index.html +++ b/site/index.html @@ -210,6 +210,99 @@

Keycloak 日本語ドキュメント

+

23.0.7

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + Release Notes + + + Keycloak のリリースノートです。 +
+ + Securing Apps + + + Keycloak を利用したアプリケーションの保護方法についてのガイドです。 +
+ + Server Admin + + + Keycloak サーバーの管理方法についてのガイドです。 +
+ + Server Development + + + Keycloak サーバーのテーマやプロバイダーのカスタマイズ方法についてのガイドです。 +
+ + Authorization Services + + + アプリケーションとサービスのきめ細かい権限管理方法についてのガイドです。 +
+ + Upgrading + + + Keycloak サーバーのアップグレード方法についてのガイドです。 +
+

22.0.5

diff --git a/site/preview.html b/site/preview.html index 248fcc167..1601a3de0 100644 --- a/site/preview.html +++ b/site/preview.html @@ -210,6 +210,99 @@

Keycloak 日本語ドキュメント（プレビュー）

+

23.0.7

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + Release Notes + + + Keycloak のリリースノートです。 +
+ + Securing Apps + + + Keycloak を利用したアプリケーションの保護方法についてのガイドです。 +
+ + Server Admin + + + Keycloak サーバーの管理方法についてのガイドです。 +
+ + Server Development + + + Keycloak サーバーのテーマやプロバイダーのカスタマイズ方法についてのガイドです。 +
+ + Authorization Services + + + アプリケーションとサービスのきめ細かい権限管理方法についてのガイドです。 +
+ + Upgrading + + + Keycloak サーバーのアップグレード方法についてのガイドです。 +
+

22.0.5

diff --git a/src/23.0/authorization_services.po b/src/23.0/authorization_services.po new file mode 100644 index 000000000..4d1af5b6f --- /dev/null +++ b/src/23.0/authorization_services.po @@ -0,0 +1,3715 @@ +msgid "" +msgstr "" +"Content-Type: text/plain; charset=UTF-8\n" + +msgid "{authorizationguide_name}" +msgstr "" + +msgid "*{release_header_guide}* icon:angle-down[]" +msgstr "" + +msgid "{gettingstarted_link}[{gettingstarted_name_short}]" +msgstr "" + +msgid "{adapterguide_link}[{adapterguide_name_short}]" +msgstr "" + +msgid "{adminguide_link}[{adminguide_name_short}]" +msgstr "" + +msgid "{developerguide_link}[{developerguide_name_short}]" +msgstr "" + +msgid "{upgradingguide_link}[{upgradingguide_name_short}]" +msgstr "" + +msgid "{releasenotes_link}[{releasenotes_name_short}]" +msgstr "" + +msgid "Version *{project_version}*" +msgstr "" + +msgid "Authorization services overview" +msgstr "" + +msgid "{project_name} supports fine-grained authorization policies and is able to combine different access control mechanisms such as:" +msgstr "" + +msgid "**Attribute-based access control (ABAC)**" +msgstr "" + +msgid "**Role-based access control (RBAC)**" +msgstr "" + +msgid "**User-based access control (UBAC)**" +msgstr "" + +msgid "**Context-based access control (CBAC)**" +msgstr "" + +msgid "**Rule-based access control**" +msgstr "" + +msgid "Using JavaScript" +msgstr "" + +msgid "**Time-based access control**" +msgstr "" + +msgid "**Support for custom access control mechanisms (ACMs) through a Service Provider Interface (SPI)**" +msgstr "" + +msgid "{project_name} is based on a set of administrative UIs and a RESTful API, and provides the necessary means to create permissions for your protected resources and scopes, associate those permissions with authorization policies, and enforce authorization decisions in your applications and services." +msgstr "" + +msgid "Resource servers (applications or services serving protected resources) usually rely on some kind of information to decide if access should be granted to a protected resource. For RESTful-based resource servers, that information is usually obtained from a security token, usually sent as a bearer token on every request to the server. For web applications that rely on a session to authenticate users, that information is usually stored in a user's session and retrieved from there for each request." +msgstr "" + +msgid "Frequently, resource servers only perform authorization decisions based on role-based access control (RBAC), where the roles granted to the user trying to access protected resources are checked against the roles mapped to these same resources. While roles are very useful and used by applications, they also have a few limitations:" +msgstr "" + +msgid "Resources and roles are tightly coupled and changes to roles (such as adding, removing, or changing an access context) can impact multiple resources" +msgstr "" + +msgid "Changes to your security requirements can imply deep changes to application code to reflect these changes" +msgstr "" + +msgid "Depending on your application size, role management might become difficult and error-prone" +msgstr "" + +msgid "It is not the most flexible access control mechanism. Roles do not represent who you are and lack contextual information. If you have been granted a role, you have at least some access." +msgstr "" + +msgid "Considering that today we need to consider heterogeneous environments where users are distributed across different regions, with different local policies, using different devices, and with a high demand for information sharing, {project_name} Authorization Services can help you improve the authorization capabilities of your applications and services by providing:" +msgstr "" + +msgid "Resource protection using fine-grained authorization policies and different access control mechanisms" +msgstr "" + +msgid "Centralized Resource, Permission, and Policy Management" +msgstr "" + +msgid "Centralized Policy Decision Point" +msgstr "" + +msgid "REST security based on a set of REST-based authorization services" +msgstr "" + +msgid "Authorization workflows and User-Managed Access" +msgstr "" + +msgid "The infrastructure to help avoid code replication across projects (and redeploys) and quickly adapt to changes in your security requirements." +msgstr "" + +msgid "Architecture" +msgstr "" + +msgid "image:images/authz-arch-overview.png[alt=\"{project_name} AuthZ architecture overview\"]" +msgstr "" + +msgid "From a design perspective, Authorization Services is based on a well-defined set of authorization patterns providing these capabilities:" +msgstr "" + +msgid "**Policy Administration Point (PAP)**" +msgstr "" + +msgid "Provides a set of UIs based on the {project_name} Administration Console to manage resource servers, resources, scopes, permissions, and policies. Part of this is also accomplished remotely through the use of the <<_service_protection_api, Protection API>>." +msgstr "" + +msgid "**Policy Decision Point (PDP)**" +msgstr "" + +msgid "Provides a distributable policy decision point to where authorization requests are sent and policies are evaluated accordingly with the permissions being requested. For more information, see <<_service_obtaining_permissions, Obtaining Permissions>>." +msgstr "" + +msgid "**Policy Enforcement Point (PEP)**" +msgstr "" + +msgid "Provides implementations for different environments to actually enforce authorization decisions at the resource server side. {project_name} provides some built-in <<_enforcer_overview, Policy Enforcers>>." +msgstr "" + +msgid "**Policy Information Point (PIP)**" +msgstr "" + +msgid "Being based on {project_name} Authentication Server, you can obtain attributes from identities and runtime environment during the evaluation of authorization policies." +msgstr "" + +msgid "The authorization process" +msgstr "" + +msgid "Three main processes define the necessary steps to understand how to use {project_name} to enable fine-grained authorization to your applications:" +msgstr "" + +msgid "*Resource Management*" +msgstr "" + +msgid "*Permission and Policy Management*" +msgstr "" + +msgid "*Policy Enforcement*" +msgstr "" + +msgid "Resource management" +msgstr "" + +msgid "*Resource Management* involves all the necessary steps to define what is being protected." +msgstr "" + +msgid "image:images/resource-mgmt-process.png[alt=\"Resource management overview\"]" +msgstr "" + +msgid "First, you need to specify {project_name} what are you looking to protect, which usually represents a web application or a set of one or more services. For more information on resource servers see <<_overview_terminology, Terminology>>." +msgstr "" + +msgid "Resource servers are managed using the {project_name} Administration Console. There you can enable any registered client application as a resource server and start managing the resources and scopes you want to protect." +msgstr "" + +msgid "image:images/rs-r-scopes.png[alt=\"Resource Server overview\"]" +msgstr "" + +msgid "A resource can be a web page, a RESTFul resource, a file in your file system, an EJB, and so on. They can represent a group of resources (just like a Class in Java) or they can represent a single and specific resource." +msgstr "" + +msgid "For instance, you might have a _Bank Account_ resource that represents all banking accounts and use it to define the authorization policies that are common to all banking accounts. However, you might want to define specific policies for _Alice Account_ (a resource instance that belongs to a customer), where only the owner is allowed to access some information or perform an operation." +msgstr "" + +msgid "Resources can be managed using the {project_name} Administration Console or the <<_service_protection_api, Protection API>>. In the latter case, resource servers are able to manage their resources remotely." +msgstr "" + +msgid "Scopes usually represent the actions that can be performed on a resource, but they are not limited to that. You can also use scopes to represent one or more attributes within a resource." +msgstr "" + +msgid "Permission and policy management" +msgstr "" + +msgid "Once you have defined your resource server and all the resources you want to protect, you must set up permissions and policies." +msgstr "" + +msgid "This process involves all the necessary steps to actually define the security and access requirements that govern your resources." +msgstr "" + +msgid "image:images/policy-mgmt-process.png[alt=\"Permission and policy management overview\"]" +msgstr "" + +msgid "Policies define the conditions that must be satisfied to access or perform operations on something (resource or scope), but they are not tied to what they are protecting. They are generic and can be reused to build permissions or even more complex policies." +msgstr "" + +msgid "For instance, to allow access to a group of resources only for users granted with a role \"User Premium\", you can use RBAC (Role-based Access Control)." +msgstr "" + +msgid "{project_name} provides a few built-in policy types (and their respective policy providers) covering the most common access control mechanisms. You can even create policies based on rules written using JavaScript." +msgstr "" + +msgid "Once you have your policies defined, you can start defining your permissions. Permissions are coupled with the resource they are protecting. Here you specify what you want to protect (resource or scope) and the policies that must be satisfied to grant or deny permission." +msgstr "" + +msgid "Policy enforcement" +msgstr "" + +msgid "*Policy Enforcement* involves the necessary steps to actually enforce authorization decisions to a resource server. This is achieved by enabling a *Policy Enforcement Point* or PEP at the resource server that is capable of communicating with the authorization server, ask for authorization data and control access to protected resources based on the decisions and permissions returned by the server." +msgstr "" + +msgid "image:images/pep-pattern-diagram.png[alt=\"PEP overview\"]" +msgstr "" + +msgid "{project_name} provides some built-in <<_enforcer_overview, Policy Enforcers>> implementations that you can use to protect your applications depending on the platform they are running on." +msgstr "" + +msgid "Authorization services" +msgstr "" + +msgid "Authorization services consist of the following RESTFul endpoints:" +msgstr "" + +msgid "*Token Endpoint*" +msgstr "" + +msgid "*Resource Management Endpoint*" +msgstr "" + +msgid "*Permission Management Endpoint*" +msgstr "" + +msgid "Each of these services provides a specific API covering the different steps involved in the authorization process." +msgstr "" + +msgid "Token endpoint" +msgstr "" + +msgid "OAuth2 clients (such as front end applications) can obtain access tokens from the server using the token endpoint and use these same tokens to access resources protected by a resource server (such as back end services). In the same way, {project_name} Authorization Services provide extensions to OAuth2 to allow access tokens to be issued based on the processing of all policies associated with the resource(s) or scope(s) being requested. This means that resource servers can enforce access to their protected resources based on the permissions granted by the server and held by an access token. In {project_name} Authorization Services the access token with permissions is called a Requesting Party Token or RPT for short." +msgstr "" + +msgid "Additional resources" +msgstr "" + +msgid "<<_service_obtaining_permissions, Obtaining Permissions>>" +msgstr "" + +msgid "Protection API" +msgstr "" + +msgid "The *Protection API* is a set of https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-09.html[UMA-compliant] endpoint-providing operations for resource servers to help them manage their resources, scopes, permissions, and policies associated with them. Only resource servers are allowed to access this API, which also requires a *uma_protection* scope." +msgstr "" + +msgid "The operations provided by the Protection API can be organized in two main groups:" +msgstr "" + +msgid "Create Resource" +msgstr "" + +msgid "Delete Resource" +msgstr "" + +msgid "Find by Id" +msgstr "" + +msgid "Query" +msgstr "" + +msgid "*Permission Management*" +msgstr "" + +msgid "Issue Permission Tickets" +msgstr "" + +msgid "By default, Remote Resource Management is enabled. You can change that using the {project_name} Administration Console and only allow resource management through the console." +msgstr "" + +msgid "When using the UMA protocol, the issuance of Permission Tickets by the Protection API is an important part of the whole authorization process. As described in a subsequent section, they represent the permissions being requested by the client and that are sent to the server to obtain a final token with all permissions granted during the evaluation of the permissions and policies associated with the resources and scopes being requested." +msgstr "" + +msgid "<<_service_protection_api, Protection API>>" +msgstr "" + +msgid "Terminology" +msgstr "" + +msgid "Before going further, it is important to understand these terms and concepts introduced by {project_name} Authorization Services." +msgstr "" + +msgid "Resource Server" +msgstr "" + +msgid "Per OAuth2 terminology, a resource server is the server hosting the protected resources and capable of accepting and responding to protected resource requests." +msgstr "" + +msgid "Resource servers usually rely on some kind of information to decide whether access to a protected resource should be granted. For RESTful-based resource servers, that information is usually carried in a security token, typically sent as a bearer token along with every request to the server. Web applications that rely on a session to authenticate users usually store that information in the user's session and retrieve it from there for each request." +msgstr "" + +msgid "In {project_name}, any *confidential* client application can act as a resource server. This client's resources and their respective scopes are protected and governed by a set of authorization policies." +msgstr "" + +msgid "Resource" +msgstr "" + +msgid "A resource is part of the assets of an application and the organization. It can be a set of one or more endpoints, a classic web resource such as an HTML page, and so on. In authorization policy terminology, a resource is the _object_ being protected." +msgstr "" + +msgid "Every resource has a unique identifier that can represent a single resource or a set of resources. For instance, you can manage a _Banking Account Resource_ that represents and defines a set of authorization policies for all banking accounts. But you can also have a different resource named _Alice's Banking Account_, which represents a single resource owned by a single customer, which can have its own set of authorization policies." +msgstr "" + +msgid "Scope" +msgstr "" + +msgid "A resource's scope is a bounded extent of access that is possible to perform on a resource. In authorization policy terminology, a scope is one of the potentially many _verbs_ that can logically apply to a resource." +msgstr "" + +msgid "It usually indicates what can be done with a given resource. Example of scopes are view, edit, delete, and so on. However, scope can also be related to specific information provided by a resource. In this case, you can have a project resource and a cost scope, where the cost scope is used to define specific policies and permissions for users to access a project's cost." +msgstr "" + +msgid "Permission" +msgstr "" + +msgid "Consider this simple and very common permission:" +msgstr "" + +msgid "A permission associates the object being protected with the policies that must be evaluated to determine whether access is granted." +msgstr "" + +msgid "*X* CAN DO *Y* ON RESOURCE *Z*" +msgstr "" + +msgid "where ..." +msgstr "" + +msgid "*X* represents one or more users, roles, or groups, or a combination of them. You can also use claims and context here." +msgstr "" + +msgid "*Y* represents an action to be performed, for example, write, view, and so on." +msgstr "" + +msgid "*Z* represents a protected resource, for example, \"/accounts\"." +msgstr "" + +msgid "{project_name} provides a rich platform for building a range of permission strategies ranging from simple to very complex, rule-based dynamic permissions. It provides flexibility and helps to:" +msgstr "" + +msgid "Reduce code refactoring and permission management costs" +msgstr "" + +msgid "Support a more flexible security model, helping you to easily adapt to changes in your security requirements" +msgstr "" + +msgid "Make changes at runtime; applications are only concerned about the resources and scopes being protected and not how they are protected." +msgstr "" + +msgid "Policy" +msgstr "" + +msgid "A policy defines the conditions that must be satisfied to grant access to an object. Unlike permissions, you do not specify the object being protected but rather the conditions that must be satisfied for access to a given object (for example, resource, scope, or both). Policies are strongly related to the different access control mechanisms (ACMs) that you can use to protect your resources. With policies, you can implement strategies for attribute-based access control (ABAC), role-based access control (RBAC), context-based access control, or any combination of these." +msgstr "" + +msgid "{project_name} leverages the concept of policies and how you define them by providing the concept of aggregated policies, where you can build a \"policy of policies\" and still control the behavior of the evaluation. Instead of writing one large policy with all the conditions that must be satisfied for access to a given resource, the policies implementation in {project_name} Authorization Services follows the divide-and-conquer technique. That is, you can create individual policies, then reuse them with different permissions and build more complex policies by combining individual policies." +msgstr "" + +msgid "Policy provider" +msgstr "" + +msgid "Policy providers are implementations of specific policy types. {project_name} provides built-in policies, backed by their corresponding policy providers, and you can create your own policy types to support your specific requirements." +msgstr "" + +msgid "{project_name} provides an SPI (Service Provider Interface) that you can use to plug in your own policy provider implementations." +msgstr "" + +msgid "Permission ticket" +msgstr "" + +msgid "A permission ticket is a special type of token defined by the User-Managed Access (UMA) specification that provides an opaque structure whose form is determined by the authorization server. This structure represents the resources and/or scopes being requested by a client, the access context, as well as the policies that must be applied to a request for authorization data (requesting party token [RPT])." +msgstr "" + +msgid "In UMA, permission tickets are crucial to support person-to-person sharing and also person-to-organization sharing. Using permission tickets for authorization workflows enables a range of scenarios from simple to complex, where resource owners and resource servers have complete control over their resources based on fine-grained policies that govern the access to these resources." +msgstr "" + +msgid "In the UMA workflow, permission tickets are issued by the authorization server to a resource server, which returns the permission ticket to the client trying to access a protected resource. Once the client receives the ticket, it can make a request for an RPT (a final token holding authorization data) by sending the ticket back to the authorization server." +msgstr "" + +msgid "For more information on permission tickets, see <<_service_user_managed_access, User-Managed Access>> and the https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html[UMA] specification." +msgstr "" + +msgid "Getting Started" +msgstr "" + +msgid "For certain applications, you can look at the following resources to quickly get started with {project_name} Authorization Services:" +msgstr "" + +msgid "{quickstartRepo_link}/tree/latest/jakarta/servlet-authz-client[Securing a JakartaEE Application in Wildfly]" +msgstr "" + +msgid "{quickstartRepo_link}/tree/latest/spring/rest-authz-resource-server[Securing a Spring Boot Application]" +msgstr "" + +msgid "link:https://quarkus.io/guides/security-keycloak-authorization[Securing Quarkus Applications]" +msgstr "" + +msgid "{adapterguide_link_nodejs_adapter}[Securing Node.js Applications]" +msgstr "" + +msgid "Managing resource servers" +msgstr "" + +msgid "According to the OAuth2 specification, a resource server is a server hosting the protected resources and capable of accepting and responding to protected resource requests." +msgstr "" + +msgid "In {project_name}, resource servers are provided with a rich platform for enabling fine-grained authorization for their protected resources, where authorization decisions can be made based on different access control mechanisms." +msgstr "" + +msgid "Any client application can be configured to support fine-grained permissions. In doing so, you are conceptually turning the client application into a resource server." +msgstr "" + +msgid "Creating a client application" +msgstr "" + +msgid "The first step to enable {project_name} Authorization Services is to create the client application that you want to turn into a resource server." +msgstr "" + +msgid "Procedure" +msgstr "" + +msgid "Click *Clients*." +msgstr "" + +msgid "Clients" +msgstr "" + +msgid "image:images/resource-server/client-list.png[Clients]" +msgstr "" + +msgid "On this page, click *Create client*." +msgstr "" + +msgid "Add Client" +msgstr "" + +msgid "image:images/resource-server/client-create.png[Add Client]" +msgstr "" + +msgid "Type the `Client ID` of the client. For example, _my-resource-server_." +msgstr "" + +msgid "Click *Next*." +msgstr "" + +msgid "Toggle *Client authentication* to ON." +msgstr "" + +msgid "Click *Save*." +msgstr "" + +msgid "Type the `Root URL` for your application. For example:" +msgstr "" + +msgid "http://${host}:${port}/my-resource-server" +msgstr "" + +msgid "Click *Save*. The client is created and the client Settings page opens. A page similar to the following is displayed:" +msgstr "" + +msgid "Client Settings" +msgstr "" + +msgid "image:images/resource-server/client-enable-authz.png[alt=\"Client Settings\"]" +msgstr "" + +msgid "Enabling authorization services" +msgstr "" + +msgid "You can turn your OIDC client into a resource server and enable fine-grained authorization." +msgstr "" + +msgid "Toggle *Authorization Enabled* to *`On*." +msgstr "" + +msgid "image:images/resource-server/client-enable-authz.png[Enabling authorization services]" +msgstr "" + +msgid "A new Authorization tab is displayed for this client. Click the *Authorization* tab and a page similar to the following is displayed:" +msgstr "" + +msgid "Resource server settings" +msgstr "" + +msgid "image:images/resource-server/authz-settings.png[alt=\"Resource server settings\"]" +msgstr "" + +msgid "The Authorization tab contains additional sub-tabs covering the different steps that you must follow to actually protect your application's resources. Each tab is covered separately by a specific topic in this documentation. But here is a quick description about each one:" +msgstr "" + +msgid "*Settings*" +msgstr "" + +msgid "General settings for your resource server. For more details about this page see the xref:resource_server_settings[Resource Server Settings] section." +msgstr "" + +msgid "*Resource*" +msgstr "" + +msgid "From this page, you can manage your application's <<_resource_overview, resources>>." +msgstr "" + +msgid "*Authorization Scopes*" +msgstr "" + +msgid "From this page, you can manage <<_resource_overview, scopes>>." +msgstr "" + +msgid "*Policies*" +msgstr "" + +msgid "From this page, you can manage <<_policy_overview, authorization policies>> and define the conditions that must be met to grant a permission." +msgstr "" + +msgid "*Permissions*" +msgstr "" + +msgid "From this page, you can manage the <<_permission_overview, permissions>> for your protected resources and scopes by linking them with the policies you created." +msgstr "" + +msgid "*Evaluate*" +msgstr "" + +msgid "From this page, you can <<_policy_evaluation_overview, simulate authorization requests>> and view the result of the evaluation of the permissions and authorization policies you have defined." +msgstr "" + +msgid "*Export Settings*" +msgstr "" + +msgid "From this page, you can <<_resource_server_import_config, export>> the authorization settings to a JSON file." +msgstr "" + +msgid "On the Resource Server Settings page, you can configure the policy enforcement mode, allow remote resource management, and export the authorization configuration settings." +msgstr "" + +msgid "*Policy Enforcement Mode*" +msgstr "" + +msgid "Specifies how policies are enforced when processing authorization requests sent to the server." +msgstr "" + +msgid "*Enforcing*" +msgstr "" + +msgid "(default mode) Requests are denied by default even when there is no policy associated with a given resource." +msgstr "" + +msgid "*Permissive*" +msgstr "" + +msgid "Requests are allowed even when there is no policy associated with a given resource." +msgstr "" + +msgid "*Disabled*" +msgstr "" + +msgid "Disables the evaluation of all policies and allows access to all resources." +msgstr "" + +msgid "*Decision Strategy*" +msgstr "" + +msgid "This configurations changes how the policy evaluation engine decides whether or not a resource or scope should be granted based on the outcome from all evaluated permissions. `Affirmative` means that at least one permission must evaluate to a positive decision in order grant access to a resource and its scopes. `Unanimous` means that all permissions must evaluate to a positive decision in order for the final decision to be also positive. As an example, if two permissions for a same resource or scope are in conflict (one of them is granting access and the other is denying access), the permission to the resource or scope will be granted if the chosen strategy is `Affirmative`. Otherwise, a single deny from any permission will also deny access to the resource or scope." +msgstr "" + +msgid "*Remote Resource Management*" +msgstr "" + +msgid "Specifies whether resources can be managed remotely by the resource server. If false, resources can be managed only from the administration console." +msgstr "" + +msgid "Default Configuration" +msgstr "" + +msgid "When you create a resource server, {project_name} creates a default configuration for your newly created resource server." +msgstr "" + +msgid "The default configuration consists of:" +msgstr "" + +msgid "A default protected resource representing all resources in your application." +msgstr "" + +msgid "A policy that always grants access to the resources protected by this policy." +msgstr "" + +msgid "A permission that governs access to all resources based on the default policy." +msgstr "" + +msgid "The default protected resource is referred to as the *default resource* and you can view it if you navigate to the *Resources* tab." +msgstr "" + +msgid "Default resource" +msgstr "" + +msgid "image:images/resource-server/default-resource.png[alt=\"Default resource\"]" +msgstr "" + +msgid "This resource defines a `Type`, namely `urn:my-resource-server:resources:default` and a `URI` `/*`. Here, the `URI` field defines a wildcard pattern that indicates to {project_name} that this resource represents all the paths in your application. In other words, when enabling <<_enforcer_overview, policy enforcement>> for your application, all the permissions associated with the resource will be examined before granting access." +msgstr "" + +msgid "The `Type` mentioned previously defines a value that can be used to create <<_permission_typed_resource, typed resource permissions>> that must be applied to the default resource or any other resource you create using the same type." +msgstr "" + +msgid "The default policy is referred to as the *only from realm policy* and you can view it if you navigate to the *Policies* tab." +msgstr "" + +msgid "Default policy" +msgstr "" + +msgid "image:images/resource-server/default-policy.png[alt=\"Default policy\"]" +msgstr "" + +msgid "This policy is a <<_policy_js, JavaScript-based policy>> defining a condition that always grants access to the resources protected by this policy. If you click this policy you can see that it defines a rule as follows:" +msgstr "" + +msgid "" +"// by default, grants any permission associated with this policy\n" +"$evaluation.grant();" +msgstr "" + +msgid "Lastly, the default permission is referred to as the *default permission* and you can view it if you navigate to the *Permissions* tab." +msgstr "" + +msgid "Default Permission" +msgstr "" + +msgid "image:images/resource-server/default-permission.png[alt=\"Default Permission\"]" +msgstr "" + +msgid "This permission is a <<_permission_create_resource, resource-based permission>>, defining a set of one or more policies that are applied to all resources with a given type." +msgstr "" + +msgid "Changing the default configuration" +msgstr "" + +msgid "You can change the default configuration by removing the default resource, policy, or permission definitions and creating your own." +msgstr "" + +msgid "The default resource is created with a **URI** that maps to any resource or path in your application using a **/*** pattern. Before creating your own resources, permissions and policies, make sure the default configuration doesn't conflict with your own settings." +msgstr "" + +msgid "The default configuration defines a resource that maps to all paths in your application. If you are about to write permissions to your own resources, be sure to remove the *Default Resource* or change its ```URIS``` fields to a more specific paths in your application. Otherwise, the policy associated with the default resource (which by default always grants access) will allow {project_name} to grant access to any protected resource." +msgstr "" + +msgid "Export and import authorization configuration" +msgstr "" + +msgid "The configuration settings for a resource server (or client) can be exported and downloaded. You can also import an existing configuration file for a resource server. Importing and exporting a configuration file is helpful when you want to create an initial configuration for a resource server or to update an existing configuration. The configuration file contains definitions for:" +msgstr "" + +msgid "Protected resources and scopes" +msgstr "" + +msgid "Policies" +msgstr "" + +msgid "Permissions" +msgstr "" + +msgid "Exporting a configuration file" +msgstr "" + +msgid "Click *Clients* in the menu." +msgstr "" + +msgid "Click the client you created as a resource server." +msgstr "" + +msgid "Click the *Export* tab." +msgstr "" + +msgid "Export Settings" +msgstr "" + +msgid "image:images/resource-server/authz-export.png[Export Settings]" +msgstr "" + +msgid "The configuration file is exported in JSON format and displayed in a text area, from which you can copy and paste. You can also click *Download* to download the configuration file and save it." +msgstr "" + +msgid "Importing a configuration file" +msgstr "" + +msgid "You can import a configuration file for a resource server." +msgstr "" + +msgid "Navigate to the *Resource Server Settings* page." +msgstr "" + +msgid "Import Settings" +msgstr "" + +msgid "image:images/resource-server/authz-settings.png[Import Settings]" +msgstr "" + +msgid "Click *Import* and choose a file containing the configuration that you want to import." +msgstr "" + +msgid "Managing resources and scopes" +msgstr "" + +msgid "Resource management is straightforward and generic. After creating a resource server, you can start creating the resources and scopes that you want to protect. Resources and scopes can be managed by navigating to the *Resource* and *Authorization Scopes* tabs, respectively." +msgstr "" + +msgid "Viewing resources" +msgstr "" + +msgid "On the *Resource* page, you see a list of the resources associated with a resource server." +msgstr "" + +msgid "Resources" +msgstr "" + +msgid "image:images/resource/view.png[alt=\"Resources\"]" +msgstr "" + +msgid "The resource list provides information about the protected resources, such as:" +msgstr "" + +msgid "Type" +msgstr "" + +msgid "URIS" +msgstr "" + +msgid "Owner" +msgstr "" + +msgid "Associated scopes, if any" +msgstr "" + +msgid "Associated permissions" +msgstr "" + +msgid "From this list, you can also directly create a permission by clicking *Create Permission* for the resource for which you want to create the permission." +msgstr "" + +msgid "Before creating permissions for your resources, be sure you have already defined the policies that you want to associate with the permission." +msgstr "" + +msgid "Creating resources" +msgstr "" + +msgid "Creating a resource is straightforward and generic. Your main concern is the granularity of the resources you create. In other words, resources can be created to represent a set of one or more resources and the way you define them is crucial to managing permissions." +msgstr "" + +msgid "To create a new resource, click *Create resource*." +msgstr "" + +msgid "Add resource" +msgstr "" + +msgid "image:images/resource/create.png[alt=\"Add resource\"]" +msgstr "" + +msgid "In {project_name}, a resource defines a small set of information that is common to different types of resources, such as:" +msgstr "" + +msgid "*Name*" +msgstr "" + +msgid "A human-readable and unique string describing this resource." +msgstr "" + +msgid "*Type*" +msgstr "" + +msgid "A string uniquely identifying the type of a set of one or more resources. The type is a _string_ used to group different resource instances. For example, the default type for the default resource that is automatically created is `urn:resource-server-name:resources:default`" +msgstr "" + +msgid "*URIS*" +msgstr "" + +msgid "URIS that provides the locations/addresses for the resource. For HTTP resources, the URIS are usually the relative paths used to serve these resources." +msgstr "" + +msgid "*Scopes*" +msgstr "" + +msgid "One or more scopes to associate with the resource." +msgstr "" + +msgid "Resource attributes" +msgstr "" + +msgid "Resources may have attributes associated with them. These attributes can be used to provide additional information about a resource and to provide additional information to policies when evaluating permissions associated with a resource." +msgstr "" + +msgid "Each attribute is a key and value pair where the value can be a set of one or many strings. Multiple values can be defined for an attribute by separating each value with a comma." +msgstr "" + +msgid "Typed resources" +msgstr "" + +msgid "The type field of a resource can be used to group different resources together, so they can be protected using a common set of permissions." +msgstr "" + +msgid "Resource owners" +msgstr "" + +msgid "Resources also have an owner. By default, resources are owned by the resource server." +msgstr "" + +msgid "However, resources can also be associated with users, so you can create permissions based on the resource owner. For example, only the resource owner is allowed to delete or update a given resource." +msgstr "" + +msgid "Managing resources remotely" +msgstr "" + +msgid "Resource management is also exposed through the <<_service_protection_api, Protection API>> to allow resource servers to remotely manage their resources." +msgstr "" + +msgid "When using the Protection API, resource servers can be implemented to manage resources owned by their users. In this case, you can specify the user identifier to configure a resource as belonging to a specific user." +msgstr "" + +msgid "{project_name} provides resource servers complete control over their resources. In the future, we should be able to allow users to control their own resources as well as approve authorization requests and manage permissions, especially when using the UMA protocol." +msgstr "" + +msgid "Managing policies" +msgstr "" + +msgid "As mentioned previously, policies define the conditions that must be satisfied before granting access to an object." +msgstr "" + +msgid "Click the *Policy* tab to view all policies associated with a resource server." +msgstr "" + +msgid "image:images/policy/view.png[alt=\"Policies\"]" +msgstr "" + +msgid "On this tab, you can view the list of previously created policies as well as create and edit a policy." +msgstr "" + +msgid "To create a new policy, click *Create policy*, then select a policy type from the list." +msgstr "" + +msgid "Details about each policy type are described in this section." +msgstr "" + +msgid "User-based policy" +msgstr "" + +msgid "You can use this type of policy to define conditions for your permissions where a set of one or more users is permitted to access an object." +msgstr "" + +msgid "To create a new user-based policy, select *User* in the item list in the upper right corner of the policy listing." +msgstr "" + +msgid "Add a User Policy" +msgstr "" + +msgid "image:images/policy/create-user.png[alt=\"Add User Policy\"]" +msgstr "" + +msgid "Configuration" +msgstr "" + +msgid "A human-readable and unique string identifying the policy. A best practice is to use names that are closely related to your business and security requirements, so you can identify them more easily." +msgstr "" + +msgid "*Description*" +msgstr "" + +msgid "A string containing details about this policy." +msgstr "" + +msgid "*Users*" +msgstr "" + +msgid "Specifies which users are given access by this policy." +msgstr "" + +msgid "*Logic*" +msgstr "" + +msgid "The logic of this policy to apply after the other conditions have been evaluated." +msgstr "" + +msgid "<<_policy_logic, Positive and negative logic>>" +msgstr "" + +msgid "Role-based policy" +msgstr "" + +msgid "You can use this type of policy to define conditions for your permissions where a set of one or more roles is permitted to access an object." +msgstr "" + +msgid "By default, roles added to this policy are not specified as required and the policy will grant access if the user requesting access has been granted any of these roles. However, you can specify a specific role as <<_policy_rbac_required, required>> if you want to enforce a specific role. You can also combine required and non-required roles, regardless of whether they are realm or client roles." +msgstr "" + +msgid "Role policies can be useful when you need more restricted role-based access control (RBAC), where specific roles must be enforced to grant access to an object. For instance, you can enforce that a user must consent to allowing a client application (which is acting on the user's behalf) to access the user's resources. You can use {project_name} Client Scope Mapping to enable consent pages or even enforce clients to explicitly provide a scope when obtaining access tokens from a {project_name} server." +msgstr "" + +msgid "To create a new role-based policy, select *Role* from the policy type list." +msgstr "" + +msgid "Add Role Policy" +msgstr "" + +msgid "image:images/policy/create-role.png[alt=\"Add Role Policy\"]" +msgstr "" + +msgid "A human-readable and unique string describing the policy. A best practice is to use names that are closely related to your business and security requirements, so you can identify them more easily." +msgstr "" + +msgid "*Realm Roles*" +msgstr "" + +msgid "Specifies which *realm* roles are permitted by this policy." +msgstr "" + +msgid "*Client Roles*" +msgstr "" + +msgid "Specifies which *client* roles are permitted by this policy. To enable this field must first select a `Client`." +msgstr "" + +msgid "Defining a role as required" +msgstr "" + +msgid "When creating a role-based policy, you can specify a specific role as `Required`. When you do that, the policy will grant access only if the user requesting access has been granted *all* the *required* roles. Both realm and client roles can be configured as such." +msgstr "" + +msgid "Example of a required role" +msgstr "" + +msgid "image:images/policy/create-role.png[alt=\"Example of a required role\"]" +msgstr "" + +msgid "To specify a role as required, select the `Required` checkbox for the role you want to configure as required." +msgstr "" + +msgid "Required roles can be useful when your policy defines multiple roles but only a subset of them are mandatory. In this case, you can combine realm and client roles to enable an even more fine-grained role-based access control (RBAC) model for your application. For example, you can have policies specific for a client and require a specific client role associated with that client. Or you can enforce that access is granted only in the presence of a specific realm role. You can also combine both approaches within the same policy." +msgstr "" + +msgid "JavaScript-based policy" +msgstr "" + +msgid "If your policy implementation is using Attribute based access control (ABAC) as in the examples below, then please make sure that users are not able to edit the protected attributes and the corresponding attributes are read-only. See the details in the link:{adminguide_link}#mitigating_security_threats[Threat model mitigation] chapter." +msgstr "" + +msgid "You can use this type of policy to define conditions for your permissions using JavaScript. It is one of the rule-based policy types supported by {project_name}, and provides flexibility to write any policy based on the <<_policy_evaluation_api, Evaluation API>>." +msgstr "" + +msgid "To create a new JavaScript-based policy, select *JavaScript* in the item list in the upper right corner of the policy listing." +msgstr "" + +msgid "By default, JavaScript Policies can not be uploaded to the server. You should prefer deploying your JS Policies directly to the server as described in link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}]." +msgstr "" + +msgid "Creating a JS policy from a deployed JAR file" +msgstr "" + +msgid "{project_name} allows you to deploy a JAR file in order to deploy scripts to the server. Please, take a look at link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}] for more details." +msgstr "" + +msgid "Once you have your scripts deployed, you should be able to select the scripts you deployed from the list of available policy providers." +msgstr "" + +msgid "Examples" +msgstr "" + +msgid "Checking for attributes from the evaluation context" +msgstr "" + +msgid "Here is a simple example of a JavaScript-based policy that uses attribute-based access control (ABAC) to define a condition based on an attribute obtained from the execution context:" +msgstr "" + +msgid "" +"const context = $evaluation.getContext();\n" +"const contextAttributes = context.getAttributes();\n" +"\n" +"if (contextAttributes.containsValue('kc.client.network.ip_address', '127.0.0.1')) {\n" +" $evaluation.grant();\n" +"}" +msgstr "" + +msgid "Checking for attributes from the current identity" +msgstr "" + +msgid "Here is a simple example of a JavaScript-based policy that uses attribute-based access control (ABAC) to define a condition based on an attribute obtained associated with the current identity:" +msgstr "" + +msgid "" +"const context = $evaluation.getContext();\n" +"const identity = context.getIdentity();\n" +"const attributes = identity.getAttributes();\n" +"const email = attributes.getValue('email').asString(0);\n" +"\n" +"if (email.endsWith('@keycloak.org')) {\n" +" $evaluation.grant();\n" +"}" +msgstr "" + +msgid "Where these attributes are mapped from whatever claim is defined in the token that was used in the authorization request." +msgstr "" + +msgid "Checking for roles granted to the current identity" +msgstr "" + +msgid "You can also use Role-Based Access Control (RBAC) in your policies. In the example below, we check if a user is granted with a `keycloak_user` *realm* role:" +msgstr "" + +msgid "" +"const context = $evaluation.getContext();\n" +"const identity = context.getIdentity();\n" +"\n" +"if (identity.hasRealmRole('keycloak_user')) {\n" +" $evaluation.grant();\n" +"}" +msgstr "" + +msgid "Or you can check if a user is granted with a `my-client-role` *client* role, where `my-client` is the client id of the client application:" +msgstr "" + +msgid "" +"const context = $evaluation.getContext();\n" +"const identity = context.getIdentity();\n" +"\n" +"if (identity.hasClientRole('my-client', 'my-client-role')) {\n" +" $evaluation.grant();\n" +"}" +msgstr "" + +msgid "Checking for roles granted to a user" +msgstr "" + +msgid "To check for realm roles granted to a user:" +msgstr "" + +msgid "" +"const realm = $evaluation.getRealm();\n" +"\n" +"if (realm.isUserInRealmRole('marta', 'role-a')) {\n" +" $evaluation.grant();\n" +"}" +msgstr "" + +msgid "Or for client roles granted to a user:" +msgstr "" + +msgid "" +"const realm = $evaluation.getRealm();\n" +"\n" +"if (realm.isUserInClientRole('marta', 'my-client', 'some-client-role')) {\n" +" $evaluation.grant();\n" +"}" +msgstr "" + +msgid "Checking for roles granted to a group" +msgstr "" + +msgid "To check for realm roles granted to a group:" +msgstr "" + +msgid "" +"const realm = $evaluation.getRealm();\n" +"\n" +"if (realm.isGroupInRole('/Group A/Group D', 'role-a')) {\n" +" $evaluation.grant();\n" +"}" +msgstr "" + +msgid "Pushing arbitrary claims to the resource server" +msgstr "" + +msgid "To push arbitrary claims to the resource server in order to provide additional information on how permissions should be enforced:" +msgstr "" + +msgid "" +"const permission = $evaluation.getPermission();\n" +"\n" +"// decide if permission should be granted\n" +"\n" +"if (granted) {\n" +" permission.addClaim('claim-a', 'claim-a');\n" +" permission.addClaim('claim-a', 'claim-a1');\n" +" permission.addClaim('claim-b', 'claim-b');\n" +"}\n" +msgstr "" + +msgid "Checking for group membership" +msgstr "" + +msgid "" +"const realm = $evaluation.getRealm();\n" +"\n" +"if (realm.isUserInGroup('marta', '/Group A/Group B')) {\n" +" $evaluation.grant();\n" +"}" +msgstr "" + +msgid "Mixing different access control mechanisms" +msgstr "" + +msgid "You can also use a combination of several access control mechanisms. The example below shows how roles(RBAC) and claims/attributes(ABAC) checks can be used within the same policy. In this case we check if user is granted with `admin` role or has an e-mail from `keycloak.org` domain:" +msgstr "" + +msgid "" +"const context = $evaluation.getContext();\n" +"const identity = context.getIdentity();\n" +"const attributes = identity.getAttributes();\n" +"const email = attributes.getValue('email').asString(0);\n" +"\n" +"if (identity.hasRealmRole('admin') || email.endsWith('@keycloak.org')) {\n" +" $evaluation.grant();\n" +"}" +msgstr "" + +msgid "When writing your own rules, keep in mind that the *$evaluation* object is an object implementing *org.keycloak.authorization.policy.evaluation.Evaluation*. For more information about what you can access from this interface, see the <<_policy_evaluation_api, Evaluation API>>." +msgstr "" + +msgid "Time-based policy" +msgstr "" + +msgid "You can use this type of policy to define time conditions for your permissions." +msgstr "" + +msgid "To create a new time-based policy, select *Time* in the item list in the upper right corner of the policy listing." +msgstr "" + +msgid "Add Time Policy" +msgstr "" + +msgid "image:images/policy/create-time.png[alt=\"Add Time Policy\"]" +msgstr "" + +msgid "*Start time*" +msgstr "" + +msgid "Defines the time before which access must *not* be granted. Permission is granted only if the current date/time is later than or equal to this value." +msgstr "" + +msgid "*Expire time*" +msgstr "" + +msgid "Defines the time after which access must *not* be granted. Permission is granted only if the current date/time is earlier than or equal to this value. Select *Repeat* to repeat access being granted on a specific *Day of Month*, *Month*, *Year*, *Hour* or *Minute*." +msgstr "" + +msgid "*Day of Month*" +msgstr "" + +msgid "Defines the day of month that access must be granted. You can also specify a range of dates. In this case, permission is granted only if the current day of the month is between or equal to the two values specified." +msgstr "" + +msgid "*Month*" +msgstr "" + +msgid "Defines the month that access must be granted. You can also specify a range of months. In this case, permission is granted only if the current month is between or equal to the two values specified." +msgstr "" + +msgid "*Year*" +msgstr "" + +msgid "Defines the year that access must be granted. You can also specify a range of years. In this case, permission is granted only if the current year is between or equal to the two values specified." +msgstr "" + +msgid "*Hour*" +msgstr "" + +msgid "Defines the hour that access must be granted. You can also specify a range of hours. In this case, permission is granted only if current hour is between or equal to the two values specified." +msgstr "" + +msgid "*Minute*" +msgstr "" + +msgid "Defines the minute that access must be granted. You can also specify a range of minutes. In this case, permission is granted only if the current minute is between or equal to the two values specified." +msgstr "" + +msgid "Access is only granted if all conditions are satisfied. {project_name} will perform an _AND_ based on the outcome of each condition." +msgstr "" + +msgid "Aggregated policy" +msgstr "" + +msgid "As mentioned previously, {project_name} allows you to build a policy of policies, a concept referred to as policy aggregation. You can use policy aggregation to reuse existing policies to build more complex ones and keep your permissions even more decoupled from the policies that are evaluated during the processing of authorization requests." +msgstr "" + +msgid "To create a new aggregated policy, select *Aggregated* from the policy type list." +msgstr "" + +msgid "Add an aggregated policy" +msgstr "" + +msgid "image:images/policy/create-aggregated.png[alt=\"Add aggregated policy\"]" +msgstr "" + +msgid "Let's suppose you have a resource called _Confidential Resource_ that can be accessed only by users from the _keycloak.org_ domain and from a certain range of IP addresses. You can create a single policy with both conditions. However, you want to reuse the domain part of this policy to apply to permissions that operates regardless of the originating network." +msgstr "" + +msgid "You can create separate policies for both domain and network conditions and create a third policy based on the combination of these two policies. With an aggregated policy, you can freely combine other policies and then apply the new aggregated policy to any permission you want." +msgstr "" + +msgid "When creating aggregated policies, be mindful that you are not introducing a circular reference or dependency between policies. If a circular dependency is detected, you cannot create or update the policy." +msgstr "" + +msgid "A human-readable and unique string describing the policy. We strongly suggest that you use names that are closely related with your business and security requirements, so you can identify them more easily and also know what they mean." +msgstr "" + +msgid "A string with more details about this policy." +msgstr "" + +msgid "*Apply Policy*" +msgstr "" + +msgid "Defines a set of one or more policies to associate with the aggregated policy. To associate a policy you can either select an existing policy or create a new one by selecting the type of the policy you want to create." +msgstr "" + +msgid "The decision strategy for this permission." +msgstr "" + +msgid "Decision strategy for aggregated policies" +msgstr "" + +msgid "When creating aggregated policies, you can also define the decision strategy that will be used to determine the final decision based on the outcome from each policy." +msgstr "" + +msgid "*Unanimous*" +msgstr "" + +msgid "The default strategy if none is provided. In this case, _all_ policies must evaluate to a positive decision for the final decision to be also positive." +msgstr "" + +msgid "*Affirmative*" +msgstr "" + +msgid "In this case, _at least one_ policy must evaluate to a positive decision in order for the final decision to be also positive." +msgstr "" + +msgid "*Consensus*" +msgstr "" + +msgid "In this case, the number of positive decisions must be greater than the number of negative decisions. If the number of positive and negative decisions is the same, the final decision will be negative." +msgstr "" + +msgid "Client-based policy" +msgstr "" + +msgid "You can use this type of policy to define conditions for your permissions where a set of one or more clients is permitted to access an object." +msgstr "" + +msgid "To create a new client-based policy, select *Client* from the policy type list." +msgstr "" + +msgid "Add a Client Policy" +msgstr "" + +msgid "image:images/policy/create-client.png[alt=\"Add a Client Policy\"]" +msgstr "" + +msgid "*Clients*" +msgstr "" + +msgid "Specifies which clients have givenGroup-based policy access by this policy." +msgstr "" + +msgid "Group-based policy" +msgstr "" + +msgid "You can use this type of policy to define conditions for your permissions where a set of one or more groups (and their hierarchies) is permitted to access an object." +msgstr "" + +msgid "To create a new group-based policy, select *Group* from the policy type list." +msgstr "" + +msgid "Group Policy" +msgstr "" + +msgid "image:images/policy/create-group.png[alt=\"Add Group Policy\"]" +msgstr "" + +msgid "*Groups Claim*" +msgstr "" + +msgid "Specifies the name of the claim in the token holding the group names and/or paths. Usually, authorization requests are processed based on an ID Token or Access Token previously issued to a client acting on behalf of some user. If defined, the token must include a claim from where this policy is going to obtain the groups the user is a member of. If not defined, user's groups are obtained from your realm configuration." +msgstr "" + +msgid "*Groups*" +msgstr "" + +msgid "Allows you to select the groups that should be enforced by this policy when evaluating permissions. After adding a group, you can extend access to children of the group by marking the checkbox *Extend to Children*. If left unmarked, access restrictions only applies to the selected group." +msgstr "" + +msgid "Extending access to child groups" +msgstr "" + +msgid "By default, when you add a group to this policy, access restrictions will only apply to members of the selected group." +msgstr "" + +msgid "Under some circumstances, it might be necessary to allow access not only to the group itself but to any child group in the hierarchy. For any group added you can mark a checkbox *Extend to Children* in order to extend access to child groups." +msgstr "" + +msgid "image:images/policy/create-group-extend-children.png[alt=\"Extending access to child groups\"]" +msgstr "" + +msgid "In the example above, the policy is granting access for any user member of *IT* or any of its children." +msgstr "" + +msgid "Client scope-based policy" +msgstr "" + +msgid "You can use this type of policy to define conditions for your permissions where a set of one or more client scopes is permitted to access an object." +msgstr "" + +msgid "By default, client scopes added to this policy are not specified as required and the policy will grant access if the client requesting access has been granted any of these client scopes. However, you can specify a specific client scope as <<_policy_client_scope_required, required>> if you want to enforce a specific client scope." +msgstr "" + +msgid "To create a new client scope-based policy, select *Client Scope* from the policy type list." +msgstr "" + +msgid "Add Client Scope Policy" +msgstr "" + +msgid "image:images/policy/create-client-scope.png[alt=\"Add Client Scope Policy\"]" +msgstr "" + +msgid "*Client Scopes*" +msgstr "" + +msgid "Specifies which client scopes are permitted by this policy." +msgstr "" + +msgid "Defining a client scope as required" +msgstr "" + +msgid "When creating a client scope-based policy, you can specify a specific client scope as `Required`. When you do that, the policy will grant access only if the client requesting access has been granted *all* the *required* client scopes." +msgstr "" + +msgid "Example of required client scope" +msgstr "" + +msgid "image:images/policy/create-client-scope.png[alt=\"Example of required client scope\"]" +msgstr "" + +msgid "To specify a client scope as required, select the `Required` checkbox for the client scope you want to configure as required." +msgstr "" + +msgid "Required client scopes can be useful when your policy defines multiple client scopes but only a subset of them are mandatory." +msgstr "" + +msgid "Regex-Based Policy" +msgstr "" + +msgid "You can use this type of policy to define regex conditions for your permissions." +msgstr "" + +msgid "To create a new regex-based policy, select *Regex* from the policy type list." +msgstr "" + +msgid "This policy resolves attributes available from the current identity." +msgstr "" + +msgid "Add Regex Policy" +msgstr "" + +msgid "image:images/policy/create-regex.png[alt=\"Add Regex Policy\"]" +msgstr "" + +msgid "*Target Claim*" +msgstr "" + +msgid "Specifies the name of the target claim in the token. For JSON-based claims, you can use dot notation for nesting and square brackets to access array fields by index. For example, contact.address[0].country. If the target claim references a JSON object, the first path (for example, `contact`) should map to the attribute name holding the JSON object." +msgstr "" + +msgid "*Regex Pattern*" +msgstr "" + +msgid "Specifies the regex pattern." +msgstr "" + +msgid "The <<_policy_logic, Logic>> of this policy to apply after the other conditions have been evaluated." +msgstr "" + +msgid "Positive and negative logic" +msgstr "" + +msgid "Policies can be configured with positive or negative logic. Briefly, you can use this option to define whether the policy result should be kept as it is or be negated." +msgstr "" + +msgid "For example, suppose you want to create a policy where only users *not* granted with a specific role should be given access. In this case, you can create a role-based policy using that role and set its *Logic* field to *Negative*. If you keep *Positive*, which is the default behavior, the policy result will be kept as it is." +msgstr "" + +msgid "Policy evaluation API" +msgstr "" + +msgid "When writing rule-based policies using JavaScript, {project_name} provides an Evaluation API that provides useful information to help determine whether a permission should be granted." +msgstr "" + +msgid "This API consists of a few interfaces that provide you access to information, such as" +msgstr "" + +msgid "The permission being evaluated, representing both the resource and scopes being requested." +msgstr "" + +msgid "The attributes associated with the resource being requested" +msgstr "" + +msgid "Runtime environment and any other attribute associated with the execution context" +msgstr "" + +msgid "Information about users such as group membership and roles" +msgstr "" + +msgid "The main interface is *org.keycloak.authorization.policy.evaluation.Evaluation*, which defines the following contract:" +msgstr "" + +msgid "" +"public interface Evaluation {\n" +"\n" +" /**\n" +" * Returns the {@link ResourcePermission} to be evaluated.\n" +" *\n" +" * @return the permission to be evaluated\n" +" */\n" +" ResourcePermission getPermission();\n" +"\n" +" /**\n" +" * Returns the {@link EvaluationContext}. Which provides access to the whole evaluation runtime context.\n" +" *\n" +" * @return the evaluation context\n" +" */\n" +" EvaluationContext getContext();\n" +"\n" +" /**\n" +" * Returns a {@link Realm} that can be used by policies to query information.\n" +" *\n" +" * @return a {@link Realm} instance\n" +" */\n" +" Realm getRealm();\n" +"\n" +" /**\n" +" * Grants the requested permission to the caller.\n" +" */\n" +" void grant();\n" +"\n" +" /**\n" +" * Denies the requested permission.\n" +" */\n" +" void deny();\n" +"}" +msgstr "" + +msgid "When processing an authorization request, {project_name} creates an `Evaluation` instance before evaluating any policy. This instance is then passed to each policy to determine whether access is *GRANT* or *DENY*." +msgstr "" + +msgid "Policies determine this by invoking the `grant()` or `deny()` methods on an `Evaluation` instance. By default, the state of the `Evaluation` instance is denied, which means that your policies must explicitly invoke the `grant()` method to indicate to the policy evaluation engine that permission should be granted." +msgstr "" + +msgid "{apidocs_link}[JavaDocs Documentation]." +msgstr "" + +msgid "The evaluation context" +msgstr "" + +msgid "The evaluation context provides useful information to policies during their evaluation." +msgstr "" + +msgid "" +"public interface EvaluationContext {\n" +"\n" +" /**\n" +" * Returns the {@link Identity} that represents an entity (person or non-person) to which the permissions must be granted, or not.\n" +" *\n" +" * @return the identity to which the permissions must be granted, or not\n" +" */\n" +" Identity getIdentity();\n" +"\n" +" /**\n" +" * Returns all attributes within the current execution and runtime environment.\n" +" *\n" +" * @return the attributes within the current execution and runtime environment\n" +" */\n" +" Attributes getAttributes();\n" +"}" +msgstr "" + +msgid "From this interface, policies can obtain:" +msgstr "" + +msgid "The authenticated `Identity`" +msgstr "" + +msgid "Information about the execution context and runtime environment" +msgstr "" + +msgid "The `Identity` is built based on the OAuth2 Access Token that was sent along with the authorization request, and this construct has access to all claims extracted from the original token. For example, if you are using a _Protocol Mapper_ to include a custom claim in an OAuth2 Access Token you can also access this claim from a policy and use it to build your conditions." +msgstr "" + +msgid "The `EvaluationContext` also gives you access to attributes related to both the execution and runtime environments. For now, there only a few built-in attributes." +msgstr "" + +msgid "Execution and Runtime Attributes" +msgstr "" + +msgid "Name" +msgstr "" + +msgid "Description" +msgstr "" + +msgid "kc.time.date_time" +msgstr "" + +msgid "Current date and time" +msgstr "" + +msgid "String. Format `MM/dd/yyyy hh:mm:ss`" +msgstr "" + +msgid "kc.client.network.ip_address" +msgstr "" + +msgid "IPv4 address of the client" +msgstr "" + +msgid "String" +msgstr "" + +msgid "kc.client.network.host" +msgstr "" + +msgid "Client's host name" +msgstr "" + +msgid "kc.client.id" +msgstr "" + +msgid "The client id" +msgstr "" + +msgid "kc.client.user_agent" +msgstr "" + +msgid "The value of the 'User-Agent' HTTP header" +msgstr "" + +msgid "String[]" +msgstr "" + +msgid "kc.realm.name" +msgstr "" + +msgid "The name of the realm" +msgstr "" + +msgid "Managing permissions" +msgstr "" + +msgid "A permission associates the object being protected and the policies that must be evaluated to decide whether access should be granted." +msgstr "" + +msgid "After creating the resources you want to protect and the policies you want to use to protect these resources, you can start managing permissions. To manage permissions, click the *Permissions* tab when editing a resource server." +msgstr "" + +msgid "image:images/permission/view.png[alt=\"Permissions\"]" +msgstr "" + +msgid "Permissions can be created to protect two main types of objects:" +msgstr "" + +msgid "*Resources*" +msgstr "" + +msgid "To create a permission, select the permission type you want to create from the item list in the upper right corner of the permission listing. The following sections describe these two types of objects in more detail." +msgstr "" + +msgid "Creating resource-based permission" +msgstr "" + +msgid "A resource-based permission defines a set of one or more resources to protect using a set of one or more authorization policies." +msgstr "" + +msgid "To create a new resource-based permission, select *Create resource-based permission* from the *Create permission* dropdown." +msgstr "" + +msgid "Add Resource Permission" +msgstr "" + +msgid "image:images/permission/create-resource.png[alt=\"Add Resource Permission\"]" +msgstr "" + +msgid "A human-readable and unique string describing the permission. A best practice is to use names that are closely related to your business and security requirements, so you can identify them more easily." +msgstr "" + +msgid "A string containing details about this permission." +msgstr "" + +msgid "*Apply To Resource Type*" +msgstr "" + +msgid "Specifies if the permission is applied to all resources with a given type. When selecting this field, you are prompted to enter the resource type to protect." +msgstr "" + +msgid "Resource Type" +msgstr "" + +msgid "Defines the resource type to protect. When defined, this permission is evaluated for all resources matching that type." +msgstr "" + +msgid "Defines a set of one or more resources to protect." +msgstr "" + +msgid "*Policy*" +msgstr "" + +msgid "Defines a set of one or more policies to associate with a permission. To associate a policy you can either select an existing policy or create a new one by selecting the type of the policy you want to create." +msgstr "" + +msgid "The <<_permission_decision_strategies, Decision Strategy>> for this permission." +msgstr "" + +msgid "Typed resource permission" +msgstr "" + +msgid "Resource permissions can also be used to define policies that are to be applied to all resources with a given <<_resource_create_type, type>>. This form of resource-based permission can be useful when you have resources sharing common access requirements and constraints." +msgstr "" + +msgid "Frequently, resources within an application can be categorized (or typed) based on the data they encapsulate or the functionality they provide. For example, a financial application can manage different banking accounts where each one belongs to a specific customer. Although they are different banking accounts, they share common security requirements and constraints that are globally defined by the banking organization. With typed resource permissions, you can define common policies to apply to all banking accounts, such as:" +msgstr "" + +msgid "Only the owner can manage his account" +msgstr "" + +msgid "Only allow access from the owner's country and/or region" +msgstr "" + +msgid "Enforce a specific authentication method" +msgstr "" + +msgid "To create a typed resource permission, click <<_permission_create_resource_apply_resource_type, Apply to Resource Type>> when creating a new resource-based permission. With `Apply to Resource Type` set to `On`, you can specify the type that you want to protect as well as the policies that are to be applied to govern access to all resources with type you have specified." +msgstr "" + +msgid "Example of a typed resource permission" +msgstr "" + +msgid "image:images/permission/typed-resource-perm-example.png[alt=\"Example of a typed resource permission\"]" +msgstr "" + +msgid "Creating scope-based permissions" +msgstr "" + +msgid "A scope-based permission defines a set of one or more scopes to protect using a set of one or more authorization policies. Unlike resource-based permissions, you can use this permission type to create permissions not only for a resource, but also for the scopes associated with it, providing more granularity when defining the permissions that govern your resources and the actions that can be performed on them." +msgstr "" + +msgid "To create a new scope-based permission, select *Create scope-based permission* from the *Create permission* dropdown." +msgstr "" + +msgid "Add Scope Permission" +msgstr "" + +msgid "image:images/permission/create-scope.png[alt=\"Add Scope Permission\"]" +msgstr "" + +msgid "Restricts the scopes to those associated with the selected resource. If none is selected, all scopes are available." +msgstr "" + +msgid "Defines a set of one or more scopes to protect." +msgstr "" + +msgid "Policy decision strategies" +msgstr "" + +msgid "When associating policies with a permission, you can also define a decision strategy to specify how to evaluate the outcome of the associated policies to determine access." +msgstr "" + +msgid "In this case, _at least one_ policy must evaluate to a positive decision for the final decision to be also positive." +msgstr "" + +msgid "In this case, the number of positive decisions must be greater than the number of negative decisions. If the number of positive and negative decisions is equal, the final decision will be negative." +msgstr "" + +msgid "Evaluating and testing policies" +msgstr "" + +msgid "When designing your policies, you can simulate authorization requests to test how your policies are being evaluated." +msgstr "" + +msgid "You can access the Policy Evaluation Tool by clicking the `Evaluate` tab when editing a resource server. There you can specify different inputs to simulate real authorization requests and test the effect of your policies." +msgstr "" + +msgid "Policy evaluation tool" +msgstr "" + +msgid "image:images/policy-evaluation-tool/policy-evaluation-tool.png[alt=\"Policy evaluation tool\"]" +msgstr "" + +msgid "Providing identity information" +msgstr "" + +msgid "The *Identity Information* filters can be used to specify the user requesting permissions." +msgstr "" + +msgid "Providing contextual information" +msgstr "" + +msgid "The *Contextual Information* filters can be used to define additional attributes to the evaluation context, so that policies can obtain these same attributes." +msgstr "" + +msgid "Providing the permissions" +msgstr "" + +msgid "The *Permissions* filters can be used to build an authorization request. You can request permissions for a set of one or more resources and scopes. If you want to simulate authorization requests based on all protected resources and scopes, click *Add* without specifying any `Resources` or `Scopes`." +msgstr "" + +msgid "When you've specified your desired values, click *Evaluate*." +msgstr "" + +msgid "{project_name} Authorization Services are built on top of well-known standards such as the OAuth2 and User-Managed Access specifications." +msgstr "" + +msgid "In addition to the issuance of RPTs, {project_name} Authorization Services also provides a set of RESTful endpoints that allow resources servers to manage their protected resources, scopes, permissions and policies, helping developers to extend or integrate these capabilities into their applications in order to support fine-grained authorization." +msgstr "" + +msgid "Discovering authorization services endpoints and metadata" +msgstr "" + +msgid "{project_name} provides a discovery document from which clients can obtain all necessary information to interact with {project_name} Authorization Services, including endpoint locations and capabilities." +msgstr "" + +msgid "The discovery document can be obtained from:" +msgstr "" + +msgid "" +"curl -X GET \\\n" +" http://${host}:${port}{kc_realms_path}/${realm}/.well-known/uma2-configuration" +msgstr "" + +msgid "Where `${host}:${port}` is the hostname (or IP address) and port where {project_name} is running and `${realm}` is the name of a realm in {project_name}." +msgstr "" + +msgid "As a result, you should get a response as follows:" +msgstr "" + +msgid "" +"{\n" +"\n" +" // some claims are expected here\n" +"\n" +" // these are the main claims in the discovery document about Authorization Services endpoints location\n" +" \"token_endpoint\": \"http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token\",\n" +" \"token_introspection_endpoint\": \"http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token/introspect\",\n" +" \"resource_registration_endpoint\": \"http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/resource_set\",\n" +" \"permission_endpoint\": \"http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/permission\",\n" +" \"policy_endpoint\": \"http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy\"\n" +"}" +msgstr "" + +msgid "Each of these endpoints expose a specific set of capabilities:" +msgstr "" + +msgid "**token_endpoint**" +msgstr "" + +msgid "A OAuth2-compliant Token Endpoint that supports the `urn:ietf:params:oauth:grant-type:uma-ticket` grant type. Through this endpoint clients can send authorization requests and obtain an RPT with all permissions granted by {project_name}." +msgstr "" + +msgid "**token_introspection_endpoint**" +msgstr "" + +msgid "A OAuth2-compliant Token Introspection Endpoint which clients can use to query the server to determine the active state of an RPT and to determine any other information associated with the token, such as the permissions granted by {project_name}." +msgstr "" + +msgid "**resource_registration_endpoint**" +msgstr "" + +msgid "A UMA-compliant Resource Registration Endpoint which resource servers can use to manage their protected resources and scopes. This endpoint provides operations create, read, update and delete resources and scopes in {project_name}." +msgstr "" + +msgid "**permission_endpoint**" +msgstr "" + +msgid "A UMA-compliant Permission Endpoint which resource servers can use to manage permission tickets. This endpoint provides operations create, read, update, and delete permission tickets in {project_name}." +msgstr "" + +msgid "Obtaining permissions" +msgstr "" + +msgid "To obtain permissions from {project_name} you send an authorization request to the token endpoint. As a result, {project_name} will evaluate all policies associated with the resource(s) and scope(s) being requested and issue an RPT with all permissions granted by the server." +msgstr "" + +msgid "Clients are allowed to send authorization requests to the token endpoint using the following parameters:" +msgstr "" + +msgid "*grant_type*" +msgstr "" + +msgid "This parameter is *required*. Must be `urn:ietf:params:oauth:grant-type:uma-ticket`." +msgstr "" + +msgid "**ticket**" +msgstr "" + +msgid "This parameter is *optional*. The most recent permission ticket received by the client as part of the UMA authorization process." +msgstr "" + +msgid "**claim_token**" +msgstr "" + +msgid "This parameter is *optional*. A string representing additional claims that should be considered by the server when evaluating permissions for the resource(s) and scope(s) being requested. This parameter allows clients to push claims to {project_name}. For more details about all supported token formats see `claim_token_format` parameter." +msgstr "" + +msgid "**claim_token_format**" +msgstr "" + +msgid "This parameter is *optional*. A string indicating the format of the token specified in the `claim_token` parameter. {project_name} supports two token formats: `urn:ietf:params:oauth:token-type:jwt` and `https://openid.net/specs/openid-connect-core-1_0.html#IDToken`. The `urn:ietf:params:oauth:token-type:jwt` format indicates that the `claim_token` parameter references an access token. The `https://openid.net/specs/openid-connect-core-1_0.html#IDToken` indicates that the `claim_token` parameter references an OpenID Connect ID Token." +msgstr "" + +msgid "**rpt**" +msgstr "" + +msgid "This parameter is *optional*. A previously issued RPT which permissions should also be evaluated and added in a new one. This parameter allows clients in possession of an RPT to perform incremental authorization where permissions are added on demand." +msgstr "" + +msgid "**permission**" +msgstr "" + +msgid "This parameter is *optional*. A string representing a set of one or more resources and scopes the client is seeking access. This parameter can be defined multiple times in order to request permission for multiple resource and scopes. This parameter is an extension to `urn:ietf:params:oauth:grant-type:uma-ticket` grant type in order to allow clients to send authorization requests without a permission ticket. The format of the string must be: `RESOURCE_ID#SCOPE_ID`. For instance: `Resource A#Scope A`, `Resource A#Scope A, Scope B, Scope C`, `Resource A`, `#Scope A`." +msgstr "" + +msgid "**permission_resource_format**" +msgstr "" + +msgid "This parameter is *optional*. A string representing a format indicating the resource in the `permission` parameter. Possible values are `id` and `uri`. `id` indicates the format is `RESOURCE_ID`. `uri` indicates the format is `URI`. If not specified, the default is `id`." +msgstr "" + +msgid "**permission_resource_matching_uri**" +msgstr "" + +msgid "This parameter is *optional*. A boolean value that indicates whether to use path matching when representing resources in URI format in the `permission` parameter. If not specified, the default is false." +msgstr "" + +msgid "**audience**" +msgstr "" + +msgid "This parameter is *optional*. The client identifier of the resource server to which the client is seeking access. This parameter is mandatory in case the `permission` parameter is defined. It serves as a hint to {project_name} to indicate the context in which permissions should be evaluated." +msgstr "" + +msgid "**response_include_resource_name**" +msgstr "" + +msgid "This parameter is *optional*. A boolean value indicating to the server whether resource names should be included in the RPT's permissions. If false, only the resource identifier is included." +msgstr "" + +msgid "**response_permissions_limit**" +msgstr "" + +msgid "This parameter is *optional*. An integer N that defines a limit for the amount of permissions an RPT can have. When used together with `rpt` parameter, only the last N requested permissions will be kept in the RPT." +msgstr "" + +msgid "**submit_request**" +msgstr "" + +msgid "This parameter is *optional*. A boolean value indicating whether the server should create permission requests to the resources and scopes referenced by a permission ticket. This parameter only has effect if used together with the `ticket` parameter as part of a UMA authorization process." +msgstr "" + +msgid "**response_mode**" +msgstr "" + +msgid "This parameter is *optional*. A string value indicating how the server should respond to authorization requests. This parameter is specially useful when you are mainly interested in either the overall decision or the permissions granted by the server, instead of a standard OAuth2 response. Possible values are:" +msgstr "" + +msgid "`decision`" +msgstr "" + +msgid "Indicates that responses from the server should only represent the overall decision by returning a JSON with the following format:" +msgstr "" + +msgid "" +"{\n" +" 'result': true\n" +"}" +msgstr "" + +msgid "If the authorization request does not map to any permission, a `403` HTTP status code is returned instead." +msgstr "" + +msgid "`permissions`" +msgstr "" + +msgid "Indicates that responses from the server should contain any permission granted by the server by returning a JSON with the following format:" +msgstr "" + +msgid "" +"[\n" +" {\n" +" 'rsid': 'My Resource'\n" +" 'scopes': ['view', 'update']\n" +" },\n" +"\n" +" ...\n" +"]" +msgstr "" + +msgid "Example of an authorization request when a client is seeking access to two resources protected by a resource server." +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \\\n" +" -H \"Authorization: Bearer ${access_token}\" \\\n" +" --data \"grant_type=urn:ietf:params:oauth:grant-type:uma-ticket\" \\\n" +" --data \"audience={resource_server_client_id}\" \\\n" +" --data \"permission=Resource A#Scope A\" \\\n" +" --data \"permission=Resource B#Scope B\"" +msgstr "" + +msgid "Example of an authorization request when a client is seeking access to any resource and scope protected by a resource server. NOTE: This will not evaluate the permissions for all resources. Instead, the permissions for resources owned by the resource server, owned by the requesting user, and explicitly granted to the requesting user by other owners are evaluated." +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \\\n" +" -H \"Authorization: Bearer ${access_token}\" \\\n" +" --data \"grant_type=urn:ietf:params:oauth:grant-type:uma-ticket\" \\\n" +" --data \"audience={resource_server_client_id}\"" +msgstr "" + +msgid "Example of an authorization request when a client is seeking access to a UMA protected resource after receiving a permission ticket from the resource server as part of the authorization process:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \\\n" +" -H \"Authorization: Bearer ${access_token}\" \\\n" +" --data \"grant_type=urn:ietf:params:oauth:grant-type:uma-ticket\" \\\n" +" --data \"ticket=${permission_ticket}" +msgstr "" + +msgid "If {project_name} assessment process results in issuance of permissions, it issues the RPT with which it has associated the permissions:" +msgstr "" + +msgid "{project_name} responds to the client with the RPT" +msgstr "" + +msgid "" +"HTTP/1.1 200 OK\n" +"Content-Type: application/json\n" +"...\n" +"{\n" +" \"access_token\": \"${rpt}\",\n" +"}" +msgstr "" + +msgid "The response from the server is just like any other response from the token endpoint when using some other grant type. The RPT can be obtained from the `access_token` response parameter. If the client is not authorized, {project_name} responds with a `403` HTTP status code:" +msgstr "" + +msgid "{project_name} denies the authorization request" +msgstr "" + +msgid "" +"HTTP/1.1 403 Forbidden\n" +"Content-Type: application/json\n" +"...\n" +"{\n" +" \"error\": \"access_denied\",\n" +" \"error_description\": \"request_denied\"\n" +"}" +msgstr "" + +msgid "Client authentication methods" +msgstr "" + +msgid "Clients need to authenticate to the token endpoint in order to obtain an RPT. When using the `urn:ietf:params:oauth:grant-type:uma-ticket` grant type, clients can use any of these authentication methods:" +msgstr "" + +msgid "*Bearer Token*" +msgstr "" + +msgid "Clients should send an access token as a Bearer credential in an HTTP Authorization header to the token endpoint." +msgstr "" + +msgid "Example: an authorization request using an access token to authenticate to the token endpoint" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \\\n" +" -H \"Authorization: Bearer ${access_token}\" \\\n" +" --data \"grant_type=urn:ietf:params:oauth:grant-type:uma-ticket\"" +msgstr "" + +msgid "This method is especially useful when the client is acting on behalf of a user. In this case, the bearer token is an access token previously issued by {project_name} to some client acting on behalf of a user (or on behalf of itself). Permissions will be evaluated considering the access context represented by the access token. For instance, if the access token was issued to Client A acting on behalf of User A, permissions will be granted depending on the resources and scopes to which User A has access." +msgstr "" + +msgid "*Client Credentials*" +msgstr "" + +msgid "Clients can use any of the client authentication methods supported by {project_name}. For instance, client_id/client_secret or JWT." +msgstr "" + +msgid "Example: an authorization request using client id and client secret to authenticate to the token endpoint" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \\\n" +" -H \"Authorization: Basic cGhvdGg6L7Jl13RmfWgtkk==pOnNlY3JldA==\" \\\n" +" --data \"grant_type=urn:ietf:params:oauth:grant-type:uma-ticket\"" +msgstr "" + +msgid "Pushing claims" +msgstr "" + +msgid "When obtaining permissions from the server you can push arbitrary claims in order to have these claims available to your policies when evaluating permissions." +msgstr "" + +msgid "If you are obtaining permissions from the server *without* using a permission ticket (UMA flow), you can send an authorization request to the token endpoint as follows:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \\\n" +" --data \"grant_type=urn:ietf:params:oauth:grant-type:uma-ticket\" \\\n" +" --data \"claim_token=ewogICAib3JnYW5pemF0aW9uIjogWyJhY21lIl0KfQ==\" \\\n" +" --data \"claim_token_format=urn:ietf:params:oauth:token-type:jwt\" \\\n" +" --data \"client_id={resource_server_client_id}\" \\\n" +" --data \"client_secret={resource_server_client_secret}\" \\\n" +" --data \"audience={resource_server_client_id}\"" +msgstr "" + +msgid "The `claim_token` parameter expects a BASE64 encoded JSON with a format similar to the example below:" +msgstr "" + +msgid "" +"{\n" +" \"organization\" : [\"acme\"]\n" +"}" +msgstr "" + +msgid "The format expects one or more claims where the value for each claim must be an array of strings." +msgstr "" + +msgid "Pushing claims Using UMA" +msgstr "" + +msgid "For more details about how to push claims when using UMA and permission tickets, please take a look at <<_service_protection_permission_api_papi, Permission API>>" +msgstr "" + +msgid "User-managed access" +msgstr "" + +msgid "{project_name} Authorization Services is based on User-Managed Access or UMA for short. UMA is a specification that enhances OAuth2 capabilities in the following ways:" +msgstr "" + +msgid "*Privacy*" +msgstr "" + +msgid "Nowadays, user privacy is becoming a huge concern, as more and more data and devices are available and connected to the cloud. With UMA and {project_name}, resource servers can enhance their capabilities in order to improve how their resources are protected in respect to user privacy where permissions are granted based on policies defined by the user." +msgstr "" + +msgid "*Party-to-Party Authorization*" +msgstr "" + +msgid "Resource owners (e.g.: regular end-users) can manage access to their resources and authorize other parties (e.g: regular end-users) to access these resources. This is different than OAuth2 where consent is given to a client application acting on behalf of a user, with UMA resource owners are allowed to consent access to other users, in a completely asynchronous manner." +msgstr "" + +msgid "*Resource Sharing*" +msgstr "" + +msgid "Resource owners are allowed to manage permissions to their resources and decide who can access a particular resource and how. {project_name} can then act as a sharing management service from which resource owners can manage their resources." +msgstr "" + +msgid "{project_name} is a UMA 2.0 compliant authorization server that provides most UMA capabilities." +msgstr "" + +msgid "As an example, consider a user Alice (resource owner) using an Internet Banking Service (resource server) to manage her Bank Account (resource). One day, Alice decides to open her bank account to Bob (requesting party), an accounting professional. However, Bob should only have access to view (scope) Alice's account." +msgstr "" + +msgid "As a resource server, the Internet Banking Service must be able to protect Alice's Bank Account. For that, it relies on {project_name} Resource Registration Endpoint to create a resource in the server representing Alice's Bank Account." +msgstr "" + +msgid "At this moment, if Bob tries to access Alice's Bank Account, access will be denied. The Internet Banking Service defines a few default policies for banking accounts. One of them is that only the owner, in this case Alice, is allowed to access her bank account." +msgstr "" + +msgid "However, Internet Banking Service in respect to Alice's privacy also allows her to change specific policies for the banking account. One of these policies that she can change is to define which people are allowed to view her bank account. For that, Internet Banking Service relies on {project_name} to provide to Alice a space where she can select individuals and the operations (or data) they are allowed to access. At any time, Alice can revoke access or grant additional permissions to Bob." +msgstr "" + +msgid "Authorization process" +msgstr "" + +msgid "In UMA, the authorization process starts when a client tries to access a UMA protected resource server." +msgstr "" + +msgid "A UMA protected resource server expects a bearer token in the request where the token is an RPT. When a client requests a resource at the resource server without an RPT:" +msgstr "" + +msgid "Client requests a protected resource without sending an RPT" +msgstr "" + +msgid "" +"curl -X GET \\\n" +" http://${host}:${port}/my-resource-server/resource/1bfdfe78-a4e1-4c2d-b142-fc92b75b986f" +msgstr "" + +msgid "The resource server sends a response back to the client with a permission `ticket` and a `as_uri` parameter with the location of a {project_name} server to where the ticket should be sent in order to obtain an RPT." +msgstr "" + +msgid "Resource server responds with a permission ticket" +msgstr "" + +msgid "" +"HTTP/1.1 401 Unauthorized\n" +"WWW-Authenticate: UMA realm=\"${realm}\",\n" +" as_uri=\"https://${host}:${port}{kc_realms_path}/${realm}\",\n" +" ticket=\"016f84e8-f9b9-11e0-bd6f-0021cc6004de\"" +msgstr "" + +msgid "The permission ticket is a special type of token issued by {project_name} Permission API. They represent the permissions being requested (e.g.: resources and scopes) as well any other information associated with the request. Only resource servers are allowed to create those tokens." +msgstr "" + +msgid "Now that the client has a permission ticket and also the location of a {project_name} server, the client can use the discovery document to obtain the location of the token endpoint and send an authorization request." +msgstr "" + +msgid "Client sends an authorization request to the token endpoint to obtain an RPT" +msgstr "" + +msgid "The response from the server is just like any other response from the token endpoint when using some other grant type. The RPT can be obtained from the `access_token` response parameter. In case the client is not authorized to have permissions {project_name} responds with a `403` HTTP status code:" +msgstr "" + +msgid "Submitting permission requests" +msgstr "" + +msgid "As part of the authorization process, clients need first to obtain a permission ticket from a UMA protected resource server in order to exchange it with an RPT at the {project_name} Token Endpoint." +msgstr "" + +msgid "By default, {project_name} responds with a `403` HTTP status code and a `request_denied` error in case the client can not be issued with an RPT." +msgstr "" + +msgid "Such response implies that {project_name} could not issue an RPT with the permissions represented by a permission ticket." +msgstr "" + +msgid "In some situations, client applications may want to start an asynchronous authorization flow and let the owner of the resources being requested decide whether or not access should be granted. For that, clients can use the `submit_request` request parameter along with an authorization request to the token endpoint:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \\\n" +" -H \"Authorization: Bearer ${access_token}\" \\\n" +" --data \"grant_type=urn:ietf:params:oauth:grant-type:uma-ticket\" \\\n" +" --data \"ticket=${permission_ticket} \\\n" +" --data \"submit_request=true\"" +msgstr "" + +msgid "When using the `submit_request` parameter, {project_name} will persist a permission request for each resource to which access was denied. Once created, resource owners can check their account and manage their permissions requests." +msgstr "" + +msgid "You can think about this functionality as a `Request Access` button in your application, where users can ask other users for access to their resources." +msgstr "" + +msgid "Managing access to users resources" +msgstr "" + +msgid "Users can manage access to their resources using the {project_name} Account Console. To enable this functionality, you must first enable User-Managed Access for your realm." +msgstr "" + +msgid "Log into the Admin Console." +msgstr "" + +msgid "Click *Realm Settings* in the menu." +msgstr "" + +msgid "Toggle *User-Managed Access* to *ON*." +msgstr "" + +msgid "Click the user name at the top right of the Admin Console and select *Manage Account*." +msgstr "" + +msgid "image:images/service/account-my-resource.png[alt=\"My Resources\"]" +msgstr "" + +msgid "Click *My Resources* in the menu option. A page displays with the following options." +msgstr "" + +msgid "Manage *My resources*" +msgstr "" + +msgid "This section contains a list of all resources owned by the user. Users can click on a resource for more details and share the resource with others. When there is a permission requests awaiting approval an icon is put next to the name of the resource. These requests are connected to the parties (users) requesting access to a particular resource. Users are allowed to approve or deny these requests. You can do so by clicking the icon" +msgstr "" + +msgid "image:images/service/account-my-resource-detail.png[alt=\"Resource Detail\"]" +msgstr "" + +msgid "Manage *Resources shared with me*" +msgstr "" + +msgid "This section contains a list of all resources shared with the user." +msgstr "" + +msgid "Manage *People with access to this resource*" +msgstr "" + +msgid "This section contains a list of people with access to this resource. Users are allowed to revoke access by clicking on the `Revoke` button or by removing a specific `Permission`." +msgstr "" + +msgid "Share the resource with others" +msgstr "" + +msgid "By typing the username or e-mail of another user, the user is able to share the resource and select the permissions he wants to grant access." +msgstr "" + +msgid "The Protection API provides a UMA-compliant set of endpoints providing:" +msgstr "" + +msgid "With this endpoint, resource servers can manage their resources remotely and enable <<_enforcer_overview, policy enforcers>> to query the server for the resources that need protection." +msgstr "" + +msgid "In the UMA protocol, resource servers access this endpoint to create permission tickets. {project_name} also provides endpoints to manage the state of permissions and query permissions." +msgstr "" + +msgid "*Policy API*" +msgstr "" + +msgid "{project_name} leverages the UMA Protection API to allow resource servers to manage permissions for their users. In addition to the Resource and Permission APIs, {project_name} provides a Policy API from where permissions can be set to resources by resource servers on behalf of their users." +msgstr "" + +msgid "An important requirement for this API is that _only_ resource servers are allowed to access its endpoints using a special OAuth2 access token called a protection API token (PAT). In UMA, a PAT is a token with the scope *uma_protection*." +msgstr "" + +msgid "What is a PAT and how to obtain it" +msgstr "" + +msgid "A *protection API token* (PAT) is a special OAuth2 access token with a scope defined as *uma_protection*. When you create a resource server, {project_name} automatically creates a role, _uma_protection_, for the corresponding client application and associates it with the client's service account." +msgstr "" + +msgid "Service Account granted with *uma_protection* role" +msgstr "" + +msgid "image:images/service/rs-uma-protection-role.png[alt=\"Service Account granted with uma_protection role\"]" +msgstr "" + +msgid "Resource servers can obtain a PAT from {project_name} like any other OAuth2 access token. For example, using curl:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" -H \"Content-Type: application/x-www-form-urlencoded\" \\\n" +" -d 'grant_type=client_credentials&client_id=${client_id}&client_secret=${client_secret}' \\\n" +" \"http://localhost:8080{kc_realms_path}/${realm_name}/protocol/openid-connect/token\"" +msgstr "" + +msgid "The example above is using the *client_credentials* grant type to obtain a PAT from the server. As a result, the server returns a response similar to the following:" +msgstr "" + +msgid "" +"{\n" +" \"access_token\": ${PAT},\n" +" \"expires_in\": 300,\n" +" \"refresh_expires_in\": 1800,\n" +" \"refresh_token\": ${refresh_token},\n" +" \"token_type\": \"bearer\",\n" +" \"id_token\": ${id_token},\n" +" \"not-before-policy\": 0,\n" +" \"session_state\": \"ccea4a55-9aec-4024-b11c-44f6f168439e\"\n" +"}" +msgstr "" + +msgid "{project_name} can authenticate your client application in different ways. For simplicity, the *client_credentials* grant type is used here, which requires a _client_id_ and a _client_secret_. You can choose to use any supported authentication method." +msgstr "" + +msgid "Managing resources" +msgstr "" + +msgid "Resource servers can manage their resources remotely using a UMA-compliant endpoint." +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set" +msgstr "" + +msgid "This endpoint provides operations outlined as follows (entire path omitted for clarity):" +msgstr "" + +msgid "Create resource set description: POST /resource_set" +msgstr "" + +msgid "Read resource set description: GET /resource_set/{_id}" +msgstr "" + +msgid "Update resource set description: PUT /resource_set/{_id}" +msgstr "" + +msgid "Delete resource set description: DELETE /resource_set/{_id}" +msgstr "" + +msgid "List resource set descriptions: GET /resource_set" +msgstr "" + +msgid "For more information about the contract for each of these operations, see https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-09.html#reg-api[UMA Resource Registration API]." +msgstr "" + +msgid "Creating a resource" +msgstr "" + +msgid "To create a resource you must send an HTTP POST request as follows:" +msgstr "" + +msgid "" +"curl -v -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set \\\n" +" -H 'Authorization: Bearer '$pat \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +" \"name\":\"Tweedl Social Service\",\n" +" \"type\":\"http://www.example.com/rsrcs/socialstream/140-compatible\",\n" +" \"icon_uri\":\"http://www.example.com/icons/sharesocial.png\",\n" +" \"resource_scopes\":[\n" +" \"read-public\",\n" +" \"post-updates\",\n" +" \"read-private\",\n" +" \"http://www.example.com/scopes/all\"\n" +" ]\n" +" }'" +msgstr "" + +msgid "By default, the owner of a resource is the resource server. If you want to define a different owner, such as a specific user, you can send a request as follows:" +msgstr "" + +msgid "" +"curl -v -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set \\\n" +" -H 'Authorization: Bearer '$pat \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +" \"name\":\"Alice Resource\",\n" +" \"owner\": \"alice\"\n" +" }'" +msgstr "" + +msgid "Where the property `owner` can be set with the username or the identifier of the user." +msgstr "" + +msgid "Creating user-managed resources" +msgstr "" + +msgid "By default, resources created via Protection API can not be managed by resource owners through the <<_service_authorization_my_resources, Account Console>>." +msgstr "" + +msgid "To create resources and allow resource owners to manage these resources, you must set `ownerManagedAccess` property as follows:" +msgstr "" + +msgid "" +"curl -v -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set \\\n" +" -H 'Authorization: Bearer '$pat \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +" \"name\":\"Alice Resource\",\n" +" \"owner\": \"alice\",\n" +" \"ownerManagedAccess\": true\n" +" }'" +msgstr "" + +msgid "Updating resources" +msgstr "" + +msgid "To update an existing resource, send an HTTP PUT request as follows:" +msgstr "" + +msgid "" +"curl -v -X PUT \\\n" +" http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set/{resource_id} \\\n" +" -H 'Authorization: Bearer '$pat \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +" \"_id\": \"Alice Resource\",\n" +" \"name\":\"Alice Resource\",\n" +" \"resource_scopes\": [\n" +" \"read\"\n" +" ]\n" +" }'" +msgstr "" + +msgid "Deleting resources" +msgstr "" + +msgid "To delete an existing resource, send an HTTP DELETE request as follows:" +msgstr "" + +msgid "" +"curl -v -X DELETE \\\n" +" http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set/{resource_id} \\\n" +" -H 'Authorization: Bearer '$pat" +msgstr "" + +msgid "Querying resources" +msgstr "" + +msgid "To query the resources by `id`, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set/{resource_id}" +msgstr "" + +msgid "To query resources given a `name`, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?name=Alice Resource" +msgstr "" + +msgid "By default, the `name` filter will match any resource with the given pattern. To restrict the query to only return resources with an exact match, use:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?name=Alice Resource&exactName=true" +msgstr "" + +msgid "To query resources given an `uri`, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?uri=/api/alice" +msgstr "" + +msgid "To query resources given an `owner`, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?owner=alice" +msgstr "" + +msgid "To query resources given an `type`, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?type=albums" +msgstr "" + +msgid "To query resources given an `scope`, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?scope=read" +msgstr "" + +msgid "When querying the server for permissions use parameters `first` and `max` results to limit the result." +msgstr "" + +msgid "Managing permission requests" +msgstr "" + +msgid "Resource servers using the UMA protocol can use a specific endpoint to manage permission requests. This endpoint provides a UMA-compliant flow for registering permission requests and obtaining a permission ticket." +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission" +msgstr "" + +msgid "A <<_overview_terminology_permission_ticket, permission ticket>> is a special security token type representing a permission request. Per the UMA specification, a permission ticket is:" +msgstr "" + +msgid "`A correlation handle that is conveyed from an authorization server to a resource server, from a resource server to a client, and ultimately from a client back to an authorization server, to enable the authorization server to assess the correct policies to apply to a request for authorization data.`" +msgstr "" + +msgid "In most cases, you won't need to deal with this endpoint directly. {project_name} provides a <<_enforcer_overview, policy enforcer>> that enables UMA for your resource server so it can obtain a permission ticket from the authorization server, return this ticket to client application, and enforce authorization decisions based on a final requesting party token (RPT)." +msgstr "" + +msgid "The process of obtaining permission tickets from {project_name} is performed by resource servers and not regular client applications, where permission tickets are obtained when a client tries to access a protected resource without the necessary grants to access the resource. The issuance of permission tickets is an important aspects when using UMA as it allows resource servers to:" +msgstr "" + +msgid "Abstract from clients the data associated with the resources protected by the resource server" +msgstr "" + +msgid "Register in the {project_name} authorization requests which in turn can be used later in workflows to grant access based on the resource's owner consent" +msgstr "" + +msgid "Decouple resource servers from authorization servers and allow them to protect and manage their resources using different authorization servers" +msgstr "" + +msgid "Client wise, a permission ticket has also important aspects that its worthy to highlight:" +msgstr "" + +msgid "Clients don't need to know about how authorization data is associated with protected resources. A permission ticket is completely opaque to clients." +msgstr "" + +msgid "Clients can have access to resources on different resource servers and protected by different authorization servers" +msgstr "" + +msgid "These are just some of the benefits brought by UMA where other aspects of UMA are strongly based on permission tickets, specially regarding privacy and user controlled access to their resources." +msgstr "" + +msgid "Creating permission ticket" +msgstr "" + +msgid "To create a permission ticket, send an HTTP POST request as follows:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission \\\n" +" -H 'Authorization: Bearer '$pat \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '[\n" +" {\n" +" \"resource_id\": \"{resource_id}\",\n" +" \"resource_scopes\": [\n" +" \"view\"\n" +" ]\n" +" }\n" +"]'" +msgstr "" + +msgid "When creating tickets you can also push arbitrary claims and associate these claims with the ticket:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission \\\n" +" -H 'Authorization: Bearer '$pat \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '[\n" +" {\n" +" \"resource_id\": \"{resource_id}\",\n" +" \"resource_scopes\": [\n" +" \"view\"\n" +" ],\n" +" \"claims\": {\n" +" \"organization\": [\"acme\"]\n" +" }\n" +" }\n" +"]'" +msgstr "" + +msgid "Where these claims will be available to your policies when evaluating permissions for the resource and scope(s) associated with the permission ticket." +msgstr "" + +msgid "Other non UMA-compliant endpoints" +msgstr "" + +msgid "To grant permissions for a specific resource with id {resource_id} to a user with id {user_id}, as an owner of the resource send an HTTP POST request as follows:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission/ticket \\\n" +" -H 'Authorization: Bearer '$access_token \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +" \"resource\": \"{resource_id}\",\n" +" \"requester\": \"{user_id}\",\n" +" \"granted\": true,\n" +" \"scopeName\": \"view\"\n" +" }'" +msgstr "" + +msgid "Getting permission tickets" +msgstr "" + +msgid "" +"curl http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission/ticket \\\n" +" -H 'Authorization: Bearer '$access_token" +msgstr "" + +msgid "You can use any of these query parameters:" +msgstr "" + +msgid "`scopeId`" +msgstr "" + +msgid "`resourceId`" +msgstr "" + +msgid "`owner`" +msgstr "" + +msgid "`requester`" +msgstr "" + +msgid "`granted`" +msgstr "" + +msgid "`returnNames`" +msgstr "" + +msgid "`first`" +msgstr "" + +msgid "`max`" +msgstr "" + +msgid "Updating permission ticket" +msgstr "" + +msgid "" +"curl -X PUT \\\n" +" http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission/ticket \\\n" +" -H 'Authorization: Bearer '$access_token \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +" \"id\": \"{ticket_id}\"\n" +" \"resource\": \"{resource_id}\",\n" +" \"requester\": \"{user_id}\",\n" +" \"granted\": false,\n" +" \"scopeName\": \"view\"\n" +" }'" +msgstr "" + +msgid "Deleting permission ticket" +msgstr "" + +msgid "" +"curl -X DELETE http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission/ticket/{ticket_id} \\\n" +" -H 'Authorization: Bearer '$access_token" +msgstr "" + +msgid "Managing resource permissions using the Policy API" +msgstr "" + +msgid "The Policy API is available at:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/uma-policy/{resource_id}" +msgstr "" + +msgid "This API is protected by a bearer token that must represent a consent granted by the user to the resource server to manage permissions on his behalf. The bearer token can be a regular access token obtained from the token endpoint using:" +msgstr "" + +msgid "Resource Owner Password Credentials Grant Type" +msgstr "" + +msgid "Token Exchange, in order to exchange an access token granted to some client (public client) for a token where audience is the resource server" +msgstr "" + +msgid "Associating a permission with a resource" +msgstr "" + +msgid "To associate a permission with a specific resource you must send a HTTP POST request as follows:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{resource_id} \\\n" +" -H 'Authorization: Bearer '$access_token \\\n" +" -H 'Cache-Control: no-cache' \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +"\t\"name\": \"Any people manager\",\n" +"\t\"description\": \"Allow access to any people manager\",\n" +"\t\"scopes\": [\"read\"],\n" +"\t\"roles\": [\"people-manager\"]\n" +"}'" +msgstr "" + +msgid "In the example above we are creating and associating a new permission to a resource represented by `resource_id` where any user with a role `people-manager` should be granted with the `read` scope." +msgstr "" + +msgid "You can also create policies using other access control mechanisms, such as using groups:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{resource_id} \\\n" +" -H 'Authorization: Bearer '$access_token \\\n" +" -H 'Cache-Control: no-cache' \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +"\t\"name\": \"Any people manager\",\n" +"\t\"description\": \"Allow access to any people manager\",\n" +"\t\"scopes\": [\"read\"],\n" +"\t\"groups\": [\"/Managers/People Managers\"]\n" +"}'" +msgstr "" + +msgid "Or a specific client:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{resource_id} \\\n" +" -H 'Authorization: Bearer '$access_token \\\n" +" -H 'Cache-Control: no-cache' \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +"\t\"name\": \"Any people manager\",\n" +"\t\"description\": \"Allow access to any people manager\",\n" +"\t\"scopes\": [\"read\"],\n" +"\t\"clients\": [\"my-client\"]\n" +"}'" +msgstr "" + +msgid "Or even using a custom policy using JavaScript:" +msgstr "" + +msgid "{tech_feature_name} is *Deprecated* and will be removed in future releases. This feature is disabled by default." +msgstr "" + +msgid "To enable start the server with `{tech_feature_setting}` . For more details see the https://www.keycloak.org/server/features[Enabling and disabling features] {section}." +msgstr "" + +msgid "" +"curl -X POST \\\n" +" http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{resource_id} \\\n" +" -H 'Authorization: Bearer '$access_token \\\n" +" -H 'Cache-Control: no-cache' \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +"\t\"name\": \"Any people manager\",\n" +"\t\"description\": \"Allow access to any people manager\",\n" +"\t\"scopes\": [\"read\"],\n" +"\t\"condition\": \"my-deployed-script.js\"\n" +"}'" +msgstr "" + +msgid "It is also possible to set any combination of these access control mechanisms." +msgstr "" + +msgid "To update an existing permission, send an HTTP PUT request as follows:" +msgstr "" + +msgid "" +"curl -X PUT \\\n" +" http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{permission_id} \\\n" +" -H 'Authorization: Bearer '$access_token \\\n" +" -H 'Content-Type: application/json' \\\n" +" -d '{\n" +" \"id\": \"21eb3fed-02d7-4b5a-9102-29f3f09b6de2\",\n" +" \"name\": \"Any people manager\",\n" +" \"description\": \"Allow access to any people manager\",\n" +" \"type\": \"uma\",\n" +" \"scopes\": [\n" +" \"album:view\"\n" +" ],\n" +" \"logic\": \"POSITIVE\",\n" +" \"decisionStrategy\": \"UNANIMOUS\",\n" +" \"owner\": \"7e22131a-aa57-4f5f-b1db-6e82babcd322\",\n" +" \"roles\": [\n" +" \"user\"\n" +" ]\n" +"}'" +msgstr "" + +msgid "Removing a permission" +msgstr "" + +msgid "To remove a permission associated with a resource, send an HTTP DELETE request as follows:" +msgstr "" + +msgid "" +"curl -X DELETE \\\n" +" http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{permission_id} \\\n" +" -H 'Authorization: Bearer '$access_token" +msgstr "" + +msgid "Querying permission" +msgstr "" + +msgid "To query the permissions associated with a resource, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy?resource={resource_id}" +msgstr "" + +msgid "To query the permissions given its name, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy?name=Any people manager" +msgstr "" + +msgid "To query the permissions associated with a specific scope, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy?scope=read" +msgstr "" + +msgid "To query all permissions, send an HTTP GET request as follows:" +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy" +msgstr "" + +msgid "Requesting party token" +msgstr "" + +msgid "A requesting party token (RPT) is a https://datatracker.ietf.org/doc/html/rfc7519[JSON web token (JWT)] digitally signed using https://datatracker.ietf.org/doc/html/rfc7515[JSON web signature (JWS)]. The token is built based on the OAuth2 access token previously issued by {project_name} to a specific client acting on behalf of a user or on its own behalf." +msgstr "" + +msgid "When you decode an RPT, you see a payload similar to the following:" +msgstr "" + +msgid "" +"{\n" +" \"authorization\": {\n" +" \"permissions\": [\n" +" {\n" +" \"resource_set_id\": \"d2fe9843-6462-4bfc-baba-b5787bb6e0e7\",\n" +" \"resource_set_name\": \"Hello World Resource\"\n" +" }\n" +" ]\n" +" },\n" +" \"jti\": \"d6109a09-78fd-4998-bf89-95730dfd0892-1464906679405\",\n" +" \"exp\": 1464906971,\n" +" \"nbf\": 0,\n" +" \"iat\": 1464906671,\n" +" \"sub\": \"f1888f4d-5172-4359-be0c-af338505d86c\",\n" +" \"typ\": \"kc_ett\",\n" +" \"azp\": \"hello-world-authz-service\"\n" +"}" +msgstr "" + +msgid "From this token you can obtain all permissions granted by the server from the *permissions* claim." +msgstr "" + +msgid "Also note that permissions are directly related with the resources/scopes you are protecting and completely decoupled from the access control methods that were used to actually grant and issue these same permissions." +msgstr "" + +msgid "Introspecting a requesting party token" +msgstr "" + +msgid "Sometimes you might want to introspect a requesting party token (RPT) to check its validity or obtain the permissions within the token to enforce authorization decisions on the resource server side." +msgstr "" + +msgid "There are two main use cases where token introspection can help you:" +msgstr "" + +msgid "When client applications need to query the token validity to obtain a new one with the same or additional permissions" +msgstr "" + +msgid "When enforcing authorization decisions at the resource server side, especially when none of the built-in <<_enforcer_overview, policy enforcers>> fits your application" +msgstr "" + +msgid "Obtaining Information about an RPT" +msgstr "" + +msgid "The token introspection is essentially a https://datatracker.ietf.org/doc/html/rfc7662[OAuth2 token introspection]-compliant endpoint from which you can obtain information about an RPT." +msgstr "" + +msgid "http://${host}:${port}{kc_realms_path}/${realm_name}/protocol/openid-connect/token/introspect" +msgstr "" + +msgid "To introspect an RPT using this endpoint, you can send a request to the server as follows:" +msgstr "" + +msgid "" +"curl -X POST \\\n" +" -H \"Authorization: Basic aGVsbG8td29ybGQtYXV0aHotc2VydmljZTpzZWNyZXQ=\" \\\n" +" -H \"Content-Type: application/x-www-form-urlencoded\" \\\n" +" -d 'token_type_hint=requesting_party_token&token=${RPT}' \\\n" +" \"http://localhost:8080{kc_realms_path}/hello-world-authz/protocol/openid-connect/token/introspect\"" +msgstr "" + +msgid "The request above is using HTTP BASIC and passing the client's credentials (client ID and secret) to authenticate the client attempting to introspect the token, but you can use any other client authentication method supported by {project_name}." +msgstr "" + +msgid "The introspection endpoint expects two parameters:" +msgstr "" + +msgid "*token_type_hint*" +msgstr "" + +msgid "Use *requesting_party_token* as the value for this parameter, which indicates that you want to introspect an RPT." +msgstr "" + +msgid "*token*" +msgstr "" + +msgid "Use the token string as it was returned by the server during the authorization process as the value for this parameter." +msgstr "" + +msgid "As a result, the server response is:" +msgstr "" + +msgid "" +"{\n" +" \"permissions\": [\n" +" {\n" +" \"resource_id\": \"90ccc6fc-b296-4cd1-881e-089e1ee15957\",\n" +" \"resource_name\": \"Hello World Resource\"\n" +" }\n" +" ],\n" +" \"exp\": 1465314139,\n" +" \"nbf\": 0,\n" +" \"iat\": 1465313839,\n" +" \"aud\": \"hello-world-authz-service\",\n" +" \"active\": true\n" +"}" +msgstr "" + +msgid "If the RPT is not active, this response is returned instead:" +msgstr "" + +msgid "" +"{\n" +" \"active\": false\n" +"}" +msgstr "" + +msgid "Do I need to invoke the server every time I want to introspect an RPT?" +msgstr "" + +msgid "No. Just like a regular access token issued by a {project_name} server, RPTs also use the JSON web token (JWT) specification as the default format." +msgstr "" + +msgid "If you want to validate these tokens without a call to the remote introspection endpoint, you can decode the RPT and query for its validity locally. Once you decode the token, you can also use the permissions within the token to enforce authorization decisions." +msgstr "" + +msgid "This is essentially what the policy enforcers do. Be sure to:" +msgstr "" + +msgid "Validate the signature of the RPT (based on the realm's public key)" +msgstr "" + +msgid "Query for token validity based on its _exp_, _iat_, and _aud_ claims" +msgstr "" + +msgid "https://datatracker.ietf.org/doc/html/rfc7519[JSON web token (JWT)]" +msgstr "" + +msgid "<<_enforcer_overview, policy enforcers>>" +msgstr "" + +msgid "Authorization client java API" +msgstr "" + +msgid "Depending on your requirements, a resource server should be able to manage resources remotely or even check for permissions programmatically. If you are using Java, you can access the {project_name} Authorization Services using the Authorization Client API." +msgstr "" + +msgid "It is targeted for resource servers that want to access the different endpoints provided by the server such as the Token Endpoint, Resource, and Permission management endpoints." +msgstr "" + +msgid "Maven dependency" +msgstr "" + +msgid "" +"\n" +" \n" +" org.keycloak\n" +" keycloak-authz-client\n" +" ${KEYCLOAK_VERSION}\n" +" \n" +"" +msgstr "" + +msgid "The client configuration is defined in a ``keycloak.json`` file as follows:" +msgstr "" + +msgid "" +"{\n" +" \"realm\": \"hello-world-authz\",\n" +" \"auth-server-url\" : \"http://localhost:8080{kc_base_path}\",\n" +" \"resource\" : \"hello-world-authz-service\",\n" +" \"credentials\": {\n" +" \"secret\": \"secret\"\n" +" }\n" +"}" +msgstr "" + +msgid "*realm* (required)" +msgstr "" + +msgid "The name of the realm." +msgstr "" + +msgid "*auth-server-url* (required)" +msgstr "" + +msgid "The base URL of the {project_name} server. All other {project_name} pages and REST service endpoints are derived from this. It is usually in the form https://host:port{kc_base_path}." +msgstr "" + +msgid "*resource* (required)" +msgstr "" + +msgid "The client-id of the application. Each application has a client-id that is used to identify the application." +msgstr "" + +msgid "*credentials* (required)" +msgstr "" + +msgid "Specifies the credentials of the application. This is an object notation where the key is the credential type and the value is the value of the credential type." +msgstr "" + +msgid "The configuration file is usually located in your application's classpath, the default location from where the client is going to try to find a ```keycloak.json``` file." +msgstr "" + +msgid "Creating the authorization client" +msgstr "" + +msgid "Considering you have a ```keycloak.json``` file in your classpath, you can create a new ```AuthzClient``` instance as follows:" +msgstr "" + +msgid "" +" // create a new instance based on the configuration defined in a keycloak.json located in your classpath\n" +" AuthzClient authzClient = AuthzClient.create();" +msgstr "" + +msgid "Obtaining user entitlements" +msgstr "" + +msgid "Here is an example illustrating how to obtain user entitlements:" +msgstr "" + +msgid "" +"// create a new instance based on the configuration defined in keycloak.json\n" +"AuthzClient authzClient = AuthzClient.create();\n" +"\n" +"// create an authorization request\n" +"AuthorizationRequest request = new AuthorizationRequest();\n" +"\n" +"// send the entitlement request to the server in order to\n" +"// obtain an RPT with all permissions granted to the user\n" +"AuthorizationResponse response = authzClient.authorization(\"alice\", \"alice\").authorize(request);\n" +"String rpt = response.getToken();\n" +"\n" +"System.out.println(\"You got an RPT: \" + rpt);\n" +"\n" +"// now you can use the RPT to access protected resources on the resource server" +msgstr "" + +msgid "Here is an example illustrating how to obtain user entitlements for a set of one or more resources:" +msgstr "" + +msgid "" +"// create a new instance based on the configuration defined in keycloak.json\n" +"AuthzClient authzClient = AuthzClient.create();\n" +"\n" +"// create an authorization request\n" +"AuthorizationRequest request = new AuthorizationRequest();\n" +"\n" +"// add permissions to the request based on the resources and scopes you want to check access\n" +"request.addPermission(\"Default Resource\");\n" +"\n" +"// send the entitlement request to the server in order to\n" +"// obtain an RPT with permissions for a single resource\n" +"AuthorizationResponse response = authzClient.authorization(\"alice\", \"alice\").authorize(request);\n" +"String rpt = response.getToken();\n" +"\n" +"System.out.println(\"You got an RPT: \" + rpt);\n" +"\n" +"// now you can use the RPT to access protected resources on the resource server" +msgstr "" + +msgid "Creating a resource using the protection API" +msgstr "" + +msgid "" +"// create a new instance based on the configuration defined in keycloak.json\n" +"AuthzClient authzClient = AuthzClient.create();\n" +"\n" +"// create a new resource representation with the information we want\n" +"ResourceRepresentation newResource = new ResourceRepresentation();\n" +"\n" +"newResource.setName(\"New Resource\");\n" +"newResource.setType(\"urn:hello-world-authz:resources:example\");\n" +"\n" +"newResource.addScope(new ScopeRepresentation(\"urn:hello-world-authz:scopes:view\"));\n" +"\n" +"ProtectedResource resourceClient = authzClient.protection().resource();\n" +"ResourceRepresentation existingResource = resourceClient.findByName(newResource.getName());\n" +"\n" +"if (existingResource != null) {\n" +" resourceClient.delete(existingResource.getId());\n" +"}\n" +"\n" +"// create the resource on the server\n" +"ResourceRepresentation response = resourceClient.create(newResource);\n" +"String resourceId = response.getId();\n" +"\n" +"// query the resource using its newly generated id\n" +"ResourceRepresentation resource = resourceClient.findById(resourceId);\n" +"\n" +"System.out.println(resource);" +msgstr "" + +msgid "Introspecting an RPT" +msgstr "" + +msgid "" +"// create a new instance based on the configuration defined in keycloak.json\n" +"AuthzClient authzClient = AuthzClient.create();\n" +"\n" +"// send the authorization request to the server in order to\n" +"// obtain an RPT with all permissions granted to the user\n" +"AuthorizationResponse response = authzClient.authorization(\"alice\", \"alice\").authorize();\n" +"String rpt = response.getToken();\n" +"\n" +"// introspect the token\n" +"TokenIntrospectionResponse requestingPartyToken = authzClient.protection().introspectRequestingPartyToken(rpt);\n" +"\n" +"System.out.println(\"Token status is: \" + requestingPartyToken.getActive());\n" +"System.out.println(\"Permissions granted by the server: \");\n" +"\n" +"for (Permission granted : requestingPartyToken.getPermissions()) {\n" +" System.out.println(granted);\n" +"}" +msgstr "" + +msgid "Policy enforcers" +msgstr "" + +msgid "Policy Enforcement Point (PEP) is a design pattern and as such you can implement it in different ways. {project_name} provides all the necessary means to implement PEPs for different platforms, environments, and programming languages. {project_name} Authorization Services presents a RESTful API, and leverages OAuth2 authorization capabilities for fine-grained authorization using a centralized authorization server." +msgstr "" + +msgid "A PEP is responsible for enforcing access decisions from the {project_name} server where these decisions are taken by evaluating the policies associated with a protected resource. It acts as a filter or interceptor in your application in order to check whether or not a particular request to a protected resource can be fulfilled based on the permissions granted by these decisions." +msgstr "" + +msgid "{project_name} provides built-in support for enabling the *{project_name} Policy Enforcer* to Java applications with built-in support to secure JakartaEE-compliant frameworks and web containers. If you are using Maven, you should configure the following dependency to your project:" +msgstr "" + +msgid "" +"\n" +" org.keycloak\n" +" keycloak-policy-enforcer\n" +" ${keycloak.version}\n" +"" +msgstr "" + +msgid "When you enable the policy enforcer all requests sent to your application are intercepted and access to protected resources will be granted depending on the permissions granted by {project_name} to the identity making the request." +msgstr "" + +msgid "Policy enforcement is strongly linked to your application's paths and the <<_resource_overview, resources>> you created for a resource server using the {project_name} Administration Console. By default, when you create a resource server, {project_name} creates a <<_resource_server_default_config, default configuration>> for your resource server so you can enable policy enforcement quickly." +msgstr "" + +msgid "The policy enforcer configuration uses a JSON format and most of the time you don't need to set anything if you want to automatically resolve the protected paths based on the resources available from your resource server." +msgstr "" + +msgid "If you want to manually define the resources being protected, you can use a slightly more verbose format:" +msgstr "" + +msgid "" +"{\n" +" \"enforcement-mode\" : \"ENFORCING\",\n" +" \"paths\": [\n" +" {\n" +" \"path\" : \"/users/*\",\n" +" \"methods\" : [\n" +" {\n" +" \"method\": \"GET\",\n" +" \"scopes\" : [\"urn:app.com:scopes:view\"]\n" +" },\n" +" {\n" +" \"method\": \"POST\",\n" +" \"scopes\" : [\"urn:app.com:scopes:create\"]\n" +" }\n" +" ]\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "The following is a description of each configuration option:" +msgstr "" + +msgid "*enforcement-mode*" +msgstr "" + +msgid "Specifies how policies are enforced." +msgstr "" + +msgid "*ENFORCING*" +msgstr "" + +msgid "(default mode) Requests are denied by default even when no policy is associated with a given resource." +msgstr "" + +msgid "*PERMISSIVE*" +msgstr "" + +msgid "Requests are allowed even when no policy is associated with a given resource." +msgstr "" + +msgid "*DISABLED*" +msgstr "" + +msgid "Completely disables the evaluation of policies and allows access to any resource. When `enforcement-mode` is `DISABLED`, applications are still able to obtain all permissions granted by {project_name} through the <<_enforcer_authorization_context, Authorization Context>>" +msgstr "" + +msgid "*on-deny-redirect-to*" +msgstr "" + +msgid "Defines a URL where a client request is redirected when an \"access denied\" message is obtained from the server. By default, the adapter responds with a 403 HTTP status code." +msgstr "" + +msgid "*path-cache*" +msgstr "" + +msgid "Defines how the policy enforcer should track associations between paths in your application and resources defined in {project_name}. The cache is needed to avoid unnecessary requests to a {project_name} server by caching associations between paths and protected resources." +msgstr "" + +msgid "*lifespan*" +msgstr "" + +msgid "Defines the time in milliseconds when the entry should be expired. If not provided, default value is *30000*. A value equal to 0 can be set to completely disable the cache. A value equal to -1 can be set to disable the expiry of the cache." +msgstr "" + +msgid "*max-entries*" +msgstr "" + +msgid "Defines the limit of entries that should be kept in the cache. If not provided, default value is *1000*." +msgstr "" + +msgid "*paths*" +msgstr "" + +msgid "Specifies the paths to protect. This configuration is optional. If not defined, the policy enforcer discovers all paths by fetching the resources you defined to your application in {project_name}, where these resources are defined with `URIS` representing some paths in your application." +msgstr "" + +msgid "*name*" +msgstr "" + +msgid "The name of a resource on the server that is to be associated with a given path. When used in conjunction with a *path*, the policy enforcer ignores the resource's *URIS* property and uses the path you provided instead." +msgstr "" + +msgid "*path*" +msgstr "" + +msgid "(required) A URI relative to the application's context path. If this option is specified, the policy enforcer queries the server for a resource with a *URI* with the same value. Currently a very basic logic for path matching is supported. Examples of valid paths are:" +msgstr "" + +msgid "Wildcards: `/*`" +msgstr "" + +msgid "Suffix: `/*.html`" +msgstr "" + +msgid "Sub-paths: `/path/*`" +msgstr "" + +msgid "Path parameters: /resource/{id}" +msgstr "" + +msgid "Exact match: /resource" +msgstr "" + +msgid "Patterns: /{version}/resource, /api/{version}/resource, /api/{version}/resource/*" +msgstr "" + +msgid "*methods*" +msgstr "" + +msgid "The HTTP methods (for example, GET, POST, PATCH) to protect and how they are associated with the scopes for a given resource in the server." +msgstr "" + +msgid "*method*" +msgstr "" + +msgid "The name of the HTTP method." +msgstr "" + +msgid "*scopes*" +msgstr "" + +msgid "An array of strings with the scopes associated with the method. When you associate scopes with a specific method, the client trying to access a protected resource (or path) must provide an RPT that grants permission to all scopes specified in the list. For example, if you define a method _POST_ with a scope _create_, the RPT must contain a permission granting access to the _create_ scope when performing a POST to the path." +msgstr "" + +msgid "*scopes-enforcement-mode*" +msgstr "" + +msgid "A string referencing the enforcement mode for the scopes associated with a method. Values can be *ALL* or *ANY*. If *ALL*, all defined scopes must be granted in order to access the resource using that method. If *ANY*, at least one scope should be granted in order to gain access to the resource using that method. By default, enforcement mode is set to *ALL*." +msgstr "" + +msgid "*claim-information-point*" +msgstr "" + +msgid "Defines a set of one or more claims that must be resolved and pushed to the {project_name} server in order to make these claims available to policies. See <<_enforcer_claim_information_point, Claim Information Point>> for more details." +msgstr "" + +msgid "*lazy-load-paths*" +msgstr "" + +msgid "Specifies how the adapter should fetch the server for resources associated with paths in your application. If *true*, the policy enforcer is going to fetch resources on-demand accordingly with the path being requested. This configuration is specially useful when you do not want to fetch all resources from the server during deployment (in case you have provided no `paths`) or in case you have defined only a sub set of `paths` and want to fetch others on-demand." +msgstr "" + +msgid "*http-method-as-scope*" +msgstr "" + +msgid "Specifies how scopes should be mapped to HTTP methods. If set to *true*, the policy enforcer will use the HTTP method from the current request to check whether or not access should be granted. When enabled, make sure your resources in {project_name} are associated with scopes representing each HTTP method you are protecting." +msgstr "" + +msgid "Defines a set of one or more *global* claims that must be resolved and pushed to the {project_name} server in order to make these claims available to policies. See <<_enforcer_claim_information_point, Claim Information Point>> for more details." +msgstr "" + +msgid "Claim Information Point" +msgstr "" + +msgid "A Claim Information Point (CIP) is responsible for resolving claims and pushing these claims to the {project_name} server in order to provide more information about the access context to policies. They can be defined as a configuration option to the policy-enforcer in order to resolve claims from different sources, such as:" +msgstr "" + +msgid "HTTP Request (parameters, headers, body, etc)" +msgstr "" + +msgid "External HTTP Service" +msgstr "" + +msgid "Static values defined in configuration" +msgstr "" + +msgid "Any other source by implementing the Claim Information Provider SPI" +msgstr "" + +msgid "When pushing claims to the {project_name} server, policies can base decisions not only on who a user is but also by taking context and contents into account, based on who, what, why, when, where, and which for a given transaction. It is all about Contextual-based Authorization and how to use runtime information in order to support fine-grained authorization decisions." +msgstr "" + +msgid "Obtaining information from the HTTP request" +msgstr "" + +msgid "Here are several examples showing how you can extract claims from an HTTP request:" +msgstr "" + +msgid "keycloak.json" +msgstr "" + +msgid "" +"{\n" +" \"paths\": [\n" +" {\n" +" \"path\": \"/protected/resource\",\n" +" \"claim-information-point\": {\n" +" \"claims\": {\n" +" \"claim-from-request-parameter\": \"{request.parameter['a']}\",\n" +" \"claim-from-header\": \"{request.header['b']}\",\n" +" \"claim-from-cookie\": \"{request.cookie['c']}\",\n" +" \"claim-from-remoteAddr\": \"{request.remoteAddr}\",\n" +" \"claim-from-method\": \"{request.method}\",\n" +" \"claim-from-uri\": \"{request.uri}\",\n" +" \"claim-from-relativePath\": \"{request.relativePath}\",\n" +" \"claim-from-secure\": \"{request.secure}\",\n" +" \"claim-from-json-body-object\": \"{request.body['/a/b/c']}\",\n" +" \"claim-from-json-body-array\": \"{request.body['/d/1']}\",\n" +" \"claim-from-body\": \"{request.body}\",\n" +" \"claim-from-static-value\": \"static value\",\n" +" \"claim-from-multiple-static-value\": [\"static\", \"value\"],\n" +" \"param-replace-multiple-placeholder\": \"Test {keycloak.access_token['/custom_claim/0']} and {request.parameter['a']}\"\n" +" }\n" +" }\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "Obtaining information from an external HTTP service" +msgstr "" + +msgid "Here are several examples showing how you can extract claims from an external HTTP Service:" +msgstr "" + +msgid "" +"{\n" +" \"paths\": [\n" +" {\n" +" \"path\": \"/protected/resource\",\n" +" \"claim-information-point\": {\n" +" \"http\": {\n" +" \"claims\": {\n" +" \"claim-a\": \"/a\",\n" +" \"claim-d\": \"/d\",\n" +" \"claim-d0\": \"/d/0\",\n" +" \"claim-d-all\": [\n" +" \"/d/0\",\n" +" \"/d/1\"\n" +" ]\n" +" },\n" +" \"url\": \"http://mycompany/claim-provider\",\n" +" \"method\": \"POST\",\n" +" \"headers\": {\n" +" \"Content-Type\": \"application/x-www-form-urlencoded\",\n" +" \"header-b\": [\n" +" \"header-b-value1\",\n" +" \"header-b-value2\"\n" +" ],\n" +" \"Authorization\": \"Bearer {keycloak.access_token}\"\n" +" },\n" +" \"parameters\": {\n" +" \"param-a\": [\n" +" \"param-a-value1\",\n" +" \"param-a-value2\"\n" +" ],\n" +" \"param-subject\": \"{keycloak.access_token['/sub']}\",\n" +" \"param-user-name\": \"{keycloak.access_token['/preferred_username']}\",\n" +" \"param-other-claims\": \"{keycloak.access_token['/custom_claim']}\"\n" +" }\n" +" }\n" +" }\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "Static claims" +msgstr "" + +msgid "" +"{\n" +" \"paths\": [\n" +" {\n" +" \"path\": \"/protected/resource\",\n" +" \"claim-information-point\": {\n" +" \"claims\": {\n" +" \"claim-from-static-value\": \"static value\",\n" +" \"claim-from-multiple-static-value\": [\"static\", \"value\"]\n" +" }\n" +" }\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "Claim information provider SPI" +msgstr "" + +msgid "The Claim Information Provider SPI can be used by developers to support different claim information points in case none of the built-ins providers are enough to address their requirements." +msgstr "" + +msgid "For example, to implement a new CIP provider you need to implement `org.keycloak.adapters.authorization.ClaimInformationPointProviderFactory` and `ClaimInformationPointProvider` and also provide the file `META-INF/services/org.keycloak.adapters.authorization.ClaimInformationPointProviderFactory` in your application`s classpath." +msgstr "" + +msgid "Example of `org.keycloak.adapters.authorization.ClaimInformationPointProviderFactory`:" +msgstr "" + +msgid "" +"public class MyClaimInformationPointProviderFactory implements ClaimInformationPointProviderFactory {\n" +"\n" +" @Override\n" +" public String getName() {\n" +" return \"my-claims\";\n" +" }\n" +"\n" +" @Override\n" +" public void init(PolicyEnforcer policyEnforcer) {\n" +"\n" +" }\n" +"\n" +" @Override\n" +" public MyClaimInformationPointProvider create(Map config) {\n" +" return new MyClaimInformationPointProvider(config);\n" +" }\n" +"}" +msgstr "" + +msgid "Every CIP provider must be associated with a name, as defined above in the `MyClaimInformationPointProviderFactory.getName` method. The name will be used to map the configuration from the `claim-information-point` section in the `policy-enforcer` configuration to the implementation." +msgstr "" + +msgid "When processing requests, the policy enforcer will call the MyClaimInformationPointProviderFactory.create method in order to obtain an instance of MyClaimInformationPointProvider. When called, any configuration defined for this particular CIP provider (via claim-information-point) is passed as a map." +msgstr "" + +msgid "Example of `ClaimInformationPointProvider`:" +msgstr "" + +msgid "" +"public class MyClaimInformationPointProvider implements ClaimInformationPointProvider {\n" +"\n" +" private final Map config;\n" +"\n" +" public MyClaimInformationPointProvider(Map config) {\n" +" this.config = config;\n" +" }\n" +"\n" +" @Override\n" +" public Map> resolve(HttpFacade httpFacade) {\n" +" Map> claims = new HashMap<>();\n" +"\n" +" // put whatever claim you want into the map\n" +"\n" +" return claims;\n" +" }\n" +"}" +msgstr "" + +msgid "Obtaining the authorization context" +msgstr "" + +msgid "When policy enforcement is enabled, the permissions obtained from the server are available through `org.keycloak.AuthorizationContext`. This class provides several methods you can use to obtain permissions and ascertain whether a permission was granted for a particular resource or scope." +msgstr "" + +msgid "Obtaining the Authorization Context in a Servlet Container" +msgstr "" + +msgid "" +" HttpServletRequest request = // obtain javax.servlet.http.HttpServletRequest\n" +" AuthorizationContext authzContext = (AuthorizationContext) request.getAttribute(AuthorizationContext.class.getName());" +msgstr "" + +msgid "The authorization context helps give you more control over the decisions made and returned by the server. For example, you can use it to build a dynamic menu where items are hidden or shown depending on the permissions associated with a resource or scope." +msgstr "" + +msgid "" +"if (authzContext.hasResourcePermission(\"Project Resource\")) {\n" +" // user can access the Project Resource\n" +"}\n" +"\n" +"if (authzContext.hasResourcePermission(\"Admin Resource\")) {\n" +" // user can access administration resources\n" +"}\n" +"\n" +"if (authzContext.hasScopePermission(\"urn:project.com:project:create\")) {\n" +" // user can create new projects\n" +"}" +msgstr "" + +msgid "The `AuthorizationContext` represents one of the main capabilities of {project_name} Authorization Services. From the examples above, you can see that the protected resource is not directly associated with the policies that govern them." +msgstr "" + +msgid "Consider some similar code using role-based access control (RBAC):" +msgstr "" + +msgid "" +"if (User.hasRole('user')) {\n" +" // user can access the Project Resource\n" +"}\n" +"\n" +"if (User.hasRole('admin')) {\n" +" // user can access administration resources\n" +"}\n" +"\n" +"if (User.hasRole('project-manager')) {\n" +" // user can create new projects\n" +"}" +msgstr "" + +msgid "Although both examples address the same requirements, they do so in different ways. In RBAC, roles only _implicitly_ define access for their resources. With {project_name}, you gain the capability to create more manageable code that focuses directly on your resources whether you are using RBAC, attribute-based access control (ABAC), or any other BAC variant. Either you have the permission for a given resource or scope, or you do not have that permission." +msgstr "" + +msgid "Now, suppose your security requirements have changed and in addition to project managers, PMOs can also create new projects." +msgstr "" + +msgid "Security requirements change, but with {project_name} there is no need to change your application code to address the new requirements. Once your application is based on the resource and scope identifier, you need only change the configuration of the permissions or policies associated with a particular resource in the authorization server. In this case, the permissions and policies associated with the `Project Resource` and/or the scope `urn:project.com:project:create` would be changed." +msgstr "" + +msgid "Using the AuthorizationContext to obtain an Authorization Client Instance" +msgstr "" + +msgid "The ```AuthorizationContext``` can also be used to obtain a reference to the <<_service_client_api, Authorization Client API>> configured to your application:" +msgstr "" + +msgid "" +" ClientAuthorizationContext clientContext = ClientAuthorizationContext.class.cast(authzContext);\n" +" AuthzClient authzClient = clientContext.getClient();" +msgstr "" + +msgid "In some cases, resource servers protected by the policy enforcer need to access the APIs provided by the authorization server. With an ```AuthzClient``` instance in hands, resource servers can interact with the server in order to create resources or check for specific permissions programmatically." +msgstr "" + +msgid "JavaScript integration" +msgstr "" + +msgid "The {project_name} Server comes with a JavaScript library you can use to interact with a resource server protected by a policy enforcer. This library is based on the {project_name} JavaScript adapter, which can be integrated to allow your client to obtain permissions from a {project_name} Server." +msgstr "" + +msgid "You can obtain this library from a running a {project_name} Server instance by including the following `script` tag in your web page:" +msgstr "" + +msgid "" +msgstr "" + +msgid "Next, you can create a `KeycloakAuthorization` instance as follows:" +msgstr "" + +msgid "" +"const keycloak = ... // obtain a Keycloak instance from keycloak.js library\n" +"const authorization = new KeycloakAuthorization(keycloak);" +msgstr "" + +msgid "The *keycloak-authz.js* library provides two main features:" +msgstr "" + +msgid "Obtain permissions from the server using a permission ticket, if you are accessing a UMA protected resource server." +msgstr "" + +msgid "Obtain permissions from the server by sending the resources and scopes the application wants to access." +msgstr "" + +msgid "In both cases, the library allows you to easily interact with both resource server and {project_name} Authorization Services to obtain tokens with permissions your client can use as bearer tokens to access the protected resources on a resource server." +msgstr "" + +msgid "Handling authorization responses from a UMA-Protected resource server" +msgstr "" + +msgid "If a resource server is protected by a policy enforcer, it responds to client requests based on the permissions carried along with a bearer token. Typically, when you try to access a resource server with a bearer token that is lacking permissions to access a protected resource, the resource server responds with a *401* status code and a `WWW-Authenticate` header." +msgstr "" + +msgid "See <<_service_uma_authorization_process, UMA Authorization Process>> for more information." +msgstr "" + +msgid "What your client needs to do is extract the permission ticket from the ```WWW-Authenticate``` header returned by the resource server and use the library to send an authorization request as follows:" +msgstr "" + +msgid "" +"// prepare a authorization request with the permission ticket\n" +"const authorizationRequest = {};\n" +"authorizationRequest.ticket = ticket;\n" +"\n" +"// send the authorization request, if successful retry the request\n" +"Identity.authorization.authorize(authorizationRequest).then(function (rpt) {\n" +" // onGrant\n" +"}, function () {\n" +" // onDeny\n" +"}, function () {\n" +" // onError\n" +"});" +msgstr "" + +msgid "The `authorize` function is completely asynchronous and supports a few callback functions to receive notifications from the server:" +msgstr "" + +msgid "`onGrant`: The first argument of the function. If authorization was successful and the server returned an RPT with the requested permissions, the callback receives the RPT." +msgstr "" + +msgid "`onDeny`: The second argument of the function. Only called if the server has denied the authorization request." +msgstr "" + +msgid "`onError`: The third argument of the function. Only called if the server responds unexpectedly." +msgstr "" + +msgid "Most applications should use the `onGrant` callback to retry a request after a 401 response. Subsequent requests should include the RPT as a bearer token for retries." +msgstr "" + +msgid "Obtaining entitlements" +msgstr "" + +msgid "The ```keycloak-authz.js``` library provides an `entitlement` function that you can use to obtain an RPT from the server by providing the resources and scopes your client wants to access." +msgstr "" + +msgid "Example about how to obtain an RPT with permissions for all resources and scopes the user can access" +msgstr "" + +msgid "" +"authorization.entitlement('my-resource-server-id').then(function (rpt) {\n" +" // onGrant callback function.\n" +" // If authorization was successful you'll receive an RPT\n" +" // with the necessary permissions to access the resource server\n" +"});" +msgstr "" + +msgid "Example about how to obtain an RPT with permissions for specific resources and scopes" +msgstr "" + +msgid "" +"authorization.entitlement('my-resource-server', {\n" +" \"permissions\": [\n" +" {\n" +" \"id\" : \"Some Resource\"\n" +" }\n" +" ]\n" +"}).then(function (rpt) {\n" +" // onGrant\n" +"});" +msgstr "" + +msgid "When using the `entitlement` function, you must provide the _client_id_ of the resource server you want to access." +msgstr "" + +msgid "The `entitlement` function is completely asynchronous and supports a few callback functions to receive notifications from the server:" +msgstr "" + +msgid "Authorization request" +msgstr "" + +msgid "Both ```authorize``` and ```entitlement``` functions accept an authorization request object. This object can be set with the following properties:" +msgstr "" + +msgid "*permissions*" +msgstr "" + +msgid "An array of objects representing the resource and scopes. For instance:" +msgstr "" + +msgid "" +"const authorizationRequest = {\n" +" \"permissions\": [\n" +" {\n" +" \"id\" : \"Some Resource\",\n" +" \"scopes\" : [\"view\", \"edit\"]\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "*metadata*" +msgstr "" + +msgid "An object where its properties define how the authorization request should be processed by the server." +msgstr "" + +msgid "*response_include_resource_name*" +msgstr "" + +msgid "A boolean value indicating to the server if resource names should be included in the RPT's permissions. If false, only the resource identifier is included." +msgstr "" + +msgid "*response_permissions_limit*" +msgstr "" + +msgid "An integer N that defines a limit for the amount of permissions an RPT can have. When used together with `rpt` parameter, only the last N requested permissions will be kept in the RPT" +msgstr "" + +msgid "*submit_request*" +msgstr "" + +msgid "A boolean value indicating whether the server should create permission requests to the resources and scopes referenced by a permission ticket. This parameter will only take effect when used together with the `ticket` parameter as part of a UMA authorization process." +msgstr "" + +msgid "Obtaining the RPT" +msgstr "" + +msgid "If you have already obtained an RPT using any of the authorization functions provided by the library, you can always obtain the RPT as follows from the authorization object (assuming that it has been initialized by one of the techniques shown earlier):" +msgstr "" + +msgid "const rpt = authorization.rpt;" +msgstr "" + +msgid "Configuring TLS/HTTPS" +msgstr "" + +msgid "When the server is using HTTPS, ensure your policy enforcer is configured as follows:" +msgstr "" + +msgid "" +"{\n" +" \"truststore\": \"path_to_your_trust_store\",\n" +" \"truststore-password\": \"trust_store_password\"\n" +"}" +msgstr "" + +msgid "The configuration above enables TLS/HTTPS to the Authorization Client, making possible to access a {project_name} Server remotely using the HTTPS scheme." +msgstr "" + +msgid "It is strongly recommended that you enable TLS/HTTPS when accessing the {project_name} Server endpoints." +msgstr "" diff --git a/src/23.0/release_notes.po b/src/23.0/release_notes.po new file mode 100644 index 000000000..969646a28 --- /dev/null +++ b/src/23.0/release_notes.po @@ -0,0 +1,2166 @@ +msgid "" +msgstr "" +"Content-Type: text/plain; charset=UTF-8\n" + +msgid "{releasenotes_name}" +msgstr "" + +msgid "*{release_header_guide}* icon:angle-down[]" +msgstr "" + +msgid "{gettingstarted_link}[{gettingstarted_name_short}]" +msgstr "" + +msgid "{adapterguide_link}[{adapterguide_name_short}]" +msgstr "" + +msgid "{adminguide_link}[{adminguide_name_short}]" +msgstr "" + +msgid "{developerguide_link}[{developerguide_name_short}]" +msgstr "" + +msgid "{authorizationguide_link}[{authorizationguide_name_short}]" +msgstr "" + +msgid "{upgradingguide_link}[{upgradingguide_name_short}]" +msgstr "" + +msgid "Version *{project_version}*" +msgstr "" + +msgid "{project_name_full} 23.0.2" +msgstr "" + +msgid "Non-blocking health check for load balancers" +msgstr "" + +msgid "A new health check endpoint available at `/lb-check` was added. The execution is running in the event loop which means this check is responsive also in overloaded situations when Keycloak needs to handle many requests waiting in request queue. This behavior is useful, for example, in multi-site deployment where we do not want to fail over to the other site under heavy load. The endpoint is currently checking availability of the embedded and external Infinispan caches. Other checks may be added later." +msgstr "" + +msgid "This endpoint is not available by default. To enable it, run Keycloak with feature `multi-site`. Proceed to https://www.keycloak.org/server/features[Enabling and disabling features] guide for more details." +msgstr "" + +msgid "{project_name_full} 23.0.0" +msgstr "" + +msgid "OpenID Connect / OAuth 2.0" +msgstr "" + +msgid "FAPI 2 drafts support" +msgstr "" + +msgid "Keycloak has new client profiles `fapi-2-security-profile` and `fapi-2-message-signing`, which ensure Keycloak enforces compliance with the latest FAPI 2 draft specifications when communicating with your clients. Thanks to https://github.com/tnorimat[Takashi Norimatsu] for the contribution." +msgstr "" + +msgid "DPoP preview support" +msgstr "" + +msgid "Keycloak has preview for support for OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP). Thanks to https://github.com/tnorimat[Takashi Norimatsu] and https://github.com/dteleguin[Dmitry Telegin] for their contributions." +msgstr "" + +msgid "More flexibility for introspection endpoint" +msgstr "" + +msgid "In previous versions, introspection endpoint automatically returned most claims, which were available in the access token. Now there is new switch `Add to token introspection` on most of protocol mappers. This addition allows more flexibility as introspection endpoint can return different claims than access token. This is first step towards \"Lightweight access tokens\" support as access tokens can omit lots of the claims, which would be still returned by the introspection endpoint. When migrating from previous versions, the introspection endpoint should return same claims, which are returned from access token, so the behavior should be effectively the same by default after the migration. Thanks to https://github.com/skabano[Shigeyuki Kabano] for the contribution." +msgstr "" + +msgid "Feature flag for OAuth 2.0 device authorization grant flow" +msgstr "" + +msgid "The OAuth 2.0 device authorization grant flow now includes a feature flag, so you can easily disable this feature. This feature is still enabled by default. Thanks to https://github.com/thomasdarimont[Thomas Darimont] for the contribution." +msgstr "" + +msgid "Authentication" +msgstr "" + +msgid "Passkeys support" +msgstr "" + +msgid "Keycloak has preview support for https://fidoalliance.org/passkeys/[Passkeys]." +msgstr "" + +msgid "Passkey registration and authentication are realized by the features of WebAuthn. Therefore, users of Keycloak can do passkey registration and authentication by existing WebAuthn registration and authentication." +msgstr "" + +msgid "Both synced passkeys and device-bound passkeys can be used for both Same-Device and Cross-Device Authentication. However, passkeys operations success depends on the user's environment. Make sure which operations can succeed in https://passkeys.dev/device-support/[the environment]. Thanks to https://github.com/tnorimat[Takashi Norimatsu] for the contribution and thanks to https://github.com/thomasdarimont[Thomas Darimont] for the help with the ideas and testing of this feature." +msgstr "" + +msgid "WebAuthn improvements" +msgstr "" + +msgid "WebAuthn policy now includes a new field: `Extra Origins`. It provides better interoperability with non-Web platforms (for example, native mobile applications). Thanks to https://github.com/akunzai[Charley Wu] for the contribution." +msgstr "" + +msgid "You are already logged-in" +msgstr "" + +msgid "There was an infamous issue that when user had login page opened in multiple browser tabs and authenticated in one of them, the attempt to authenticate in subsequent browser tabs opened the page `You are already logged-in`. This is improved now as other browser tabs just automatically authenticate as well after authentication of first browser tab. There are still corner cases when the behaviour is not 100% correct, like the scenario with expired authentication session, which is then restarted just in one browser tab and hence other browser tabs won't follow automatically with the login. So we still plan improvements in this area." +msgstr "" + +msgid "Password policy for specify Maximum authentication time" +msgstr "" + +msgid "Keycloak supports new password policy, which allows to specify the maximum age of an authentication with which a password may be changed by user without re-authentication. When this password policy is set to 0, the user will be required to re-authenticate to change the password in the Account Console or by other means. You can also specify a lower or higher value than the default value of 5 minutes. Thanks to https://github.com/thomasdarimont[Thomas Darimont] for the contribution." +msgstr "" + +msgid "Deployments" +msgstr "" + +msgid "Preview support for multi-site active-passive deployments" +msgstr "" + +msgid "Deploying Keycloak to multiple independent sites is essential for some environments to provide high availability and a speedy recovery from failures. This release adds preview-support for active-passive deployments for Keycloak." +msgstr "" + +msgid "A lot of work has gone into testing and verifying a setup which can sustain load and recover from the failure scenarios. To get started, use the https://www.keycloak.org/guides#high-availability[high-availability guide] which also includes a comprehensive blueprint to deploy a highly available Keycloak to a cloud environment." +msgstr "" + +msgid "Adapters" +msgstr "" + +msgid "OpenID Connect WildFly and JBoss EAP" +msgstr "" + +msgid "OpenID Connect adapter for WildFly and JBoss EAP, which was deprecated in previous versions, has been removed in this release. It is being replaced by the Elytron OIDC adapter,which is included in WildFly, and provides a seamless migration from Keycloak adapters." +msgstr "" + +msgid "SAML WildFly and JBoss EAP" +msgstr "" + +msgid "The SAML adapter for WildFly and JBoss EAP is no longer distributed as a ZIP download, but rather a Galleon feature pack, making it easier and more seamless to install." +msgstr "" + +msgid "See the link:{adapterguide_link}[{adapterguide_name}] for the details." +msgstr "" + +msgid "Server distribution" +msgstr "" + +msgid "Load Shedding support" +msgstr "" + +msgid "Keycloak now features `http-max-queued-requests` option to allow proper rejecting of incoming requests under high load. For details refer to the https://www.keycloak.org/server/configuration-production[production guide]." +msgstr "" + +msgid "RESTEasy Reactive" +msgstr "" + +msgid "Keycloak has switched to RESTEasy Reactive. Applications using `quarkus-resteasy-reactive` should still benefit from a better startup time, runtime performance, and memory footprint, even though not using reactive style/semantics. SPI's that depend directly on JAX-RS API should be compatible with this change. SPI's that depend on RESTEasy Classic including `ResteasyClientBuilder` will not be compatible and will require update, this will also be true for other implementation of the JAX-RS API like Jersey." +msgstr "" + +msgid "User profile" +msgstr "" + +msgid "Declarative user profile is still a preview feature in this release, but we are working hard on promoting it to a supported feature. Feedback is welcome. If you find any issues or have any improvements in mind, you are welcome to create https://github.com/keycloak/keycloak/issues/new/choose[Github issue], ideally with the label `area/user-profile`. It is also recommended to check the link:{upgradingguide_link}[{upgradingguide_name}] with the migration changes for this release for some additional informations related to the migration." +msgstr "" + +msgid "Group scalability" +msgstr "" + +msgid "Performance around searching of groups is improved for the use-cases with many groups and subgroups. There are improvements, which allow paginated lookup of subgroups. Thanks to https://github.com/alice-wondered[Alice] for the contribution." +msgstr "" + +msgid "Themes" +msgstr "" + +msgid "Localization files for themes default to UTF-8 encoding" +msgstr "" + +msgid "Message properties files for themes are now read in UTF-8 encoding, with an automatic fallback to ISO-8859-1 encoding." +msgstr "" + +msgid "See the migration guide for more details." +msgstr "" + +msgid "Storage" +msgstr "" + +msgid "Removal of the Map Store" +msgstr "" + +msgid "The Map Store has been an experimental feature in previous releases. Starting with this release, it is removed and users should continue to use the current JPA store. See the migration guide for details." +msgstr "" + +msgid "{project_name_full} 22.0.3" +msgstr "" + +msgid "Security vulnerability when registering or updating user through templates" +msgstr "" + +msgid "A security vulnerability was introduced in Keycloak 22.0.2. We highly recommend not upgrading to 22.0.2, and for anyone that has deployed 22.0.2 in production to upgrade to 22.0.3 immediately." +msgstr "" + +msgid "For users that has self-registered after Keycloak was upgraded to 22.0.2 their password is not stored securely, and can be exposed to administrators of Keycloak. This only affects users that has registered after the upgrade was rolled-out, and does not affect any previously registered users." +msgstr "" + +msgid "Any realm using the preview declarative user profile is not affected by this issue, and only realms using the default user profile provider is affected." +msgstr "" + +msgid "To identify if there are any affected users in your deployment you can query these by accessing the database, and running the following SQL statement:" +msgstr "" + +msgid "" +"SELECT DISTINCT U.ID, U.USERNAME, U.EMAIL, U.REALM_ID FROM USER_ENTITY U\n" +" INNER JOIN USER_ATTRIBUTE UA ON U.ID = UA.USER_ID\n" +" WHERE UA.NAME IN ('password','password-confirm')" +msgstr "" + +msgid "We recommend contacting any affected users as well as adding the update password required action for them." +msgstr "" + +msgid "If there are any affected users we also recommend removing these attributes from the database by running the following SQL statement:" +msgstr "" + +msgid "DELETE FROM USER_ATTRIBUTE UA WHERE UA.NAME IN ('password','password-confirm')" +msgstr "" + +msgid "If any backups have been done of the database after the 22.0.2 release and there are affected users, we recommend deleting these." +msgstr "" + +msgid "Custom user storage providers" +msgstr "" + +msgid "Any deployments with custom user storage federation providers may also be affected if the provider is delegating to Keycloak storing user attributes, please verify your custom user storage to identify if this is an issue." +msgstr "" + +msgid "To identify if there are any federated user affected in your deployment, you can query these by accessing the database, and running the following SQL statement:" +msgstr "" + +msgid "" +"SELECT DISTINCT USER_ID,REALM_ID,STORAGE_PROVIDER_ID FROM FED_USER_ATTRIBUTE\n" +" WHERE NAME IN ('password','password-confirm')" +msgstr "" + +msgid "If there are any affected federated users, we also recommend removing these attributes from the database by running the following SQL statement:" +msgstr "" + +msgid "DELETE FROM FED_USER_ATTRIBUTE UA WHERE UA.NAME IN ('password','password-confirm')" +msgstr "" + +msgid "If your custom user storage provider is managing attributes itself, you should look at your custom storage to remove the `password` and `password-confirm` attributes." +msgstr "" + +msgid "{project_name_full} 22.0.2" +msgstr "" + +msgid "Improvements in LDAP and Kerberos integration" +msgstr "" + +msgid "Keycloak now supports multiple LDAP providers in a realm, which support Kerberos integration with the same Kerberos realm. When an LDAP provider is not able to find the user which was authenticated through Kerberos/SPNEGO, Keycloak ties to fallback to the next LDAP provider. Keycloak has also better support for the case when single LDAP provider supports multiple Kerberos realms, which are in trust with each other." +msgstr "" + +msgid "{project_name_full} 22.0.0" +msgstr "" + +msgid "Server Distribution" +msgstr "" + +msgid "Java 11 support removed" +msgstr "" + +msgid "Running the Keycloak server with Java 11 is no longer supported. Java 11 was deprecated in Keycloak 21 with the announced plan to be removed in Keycloak 22." +msgstr "" + +msgid "Upgrade to Quarkus 3.x" +msgstr "" + +msgid "Keycloak upgraded to version 3.2.0.Final of the Quarkus Java framework. Quarkus 3.x continues the tradition of propelling Java development by moving fast and providing a cutting-edge user experience with the latest technologies." +msgstr "" + +msgid "Transition from Java EE to Jakarta EE" +msgstr "" + +msgid "As part of upgrading to Quarkus 3.x Keycloak migrated its codebase from Java EE (Enterprise Edition) to its successor Jakarta EE, which brings various changes into Keycloak. We have upgraded all Jakarta EE specifications in order to support Jakarta EE 10." +msgstr "" + +msgid "Context and dependency injection no longer enabled to JAX-RS Resources" +msgstr "" + +msgid "In order to provide a better runtime and leverage as much as possible the underlying stack, all injection points for contextual data using the `javax.ws.rs.core.Context` annotation were removed. The expected improvement in performance involves no longer creating proxies instances multiple times during the request lifecycle, and drastically reducing the amount of reflection code at runtime." +msgstr "" + +msgid "Upgrade to Hibernate ORM 6" +msgstr "" + +msgid "Keycloak now benefits from the upgrade to Hibernate ORM 6.2, which includes improved performance, better SQL, modern JDK support, and support for modern RDBMS features." +msgstr "" + +msgid "Elytron credential store replacement" +msgstr "" + +msgid "The previous and now removed WildFly distribution provided a built-in vault provider that reads secrets from a keystore-backed Elytron credential store. As this is no longer available, we have added a new implementation of the Keycloak Vault SPI called Keycloak KeyStore Vault. As the name suggests, this implementation reads secrets from a Java keystore file. Such secrets can be then used within multiple places of the Administration Console. For further details, see https://www.keycloak.org/server/vault[our guide] and the latest https://www.keycloak.org/docs/latest/server_admin/index.html#_vault-administration[documentation]." +msgstr "" + +msgid "KeyStore Config Source added" +msgstr "" + +msgid "In relation to the KeyStore Vault news, we also integrated Quarkus's recently released feature called KeyStore Config Source. This means that among the already existing configuration sources (CLI parameters, environment variables and files), you can now configure your Keycloak server via configuration properties stored in a Java keystore file. You can learn more about this feature in the https://www.keycloak.org/server/configuration[Configuration guide]." +msgstr "" + +msgid "Hostname debug tool" +msgstr "" + +msgid "As a number of users have had problems with configuring the hostname for the server correctly there is now a new helper tool to allow debugging the configuration." +msgstr "" + +msgid "Passthrough proxy mode changes" +msgstr "" + +msgid "Installations which use Keycloak's `--proxy` configuration setting with mode *passthrough* should review the documentation as the behavior of this mode has changed." +msgstr "" + +msgid "Export and Import perform an automatic build" +msgstr "" + +msgid "In previous releases, the `export` and `import` commands required a `build` command to be run first. Starting with this release, the `export` and `import` commands perform an automatic rebuild of Keycloak if a build time configuration has changed." +msgstr "" + +msgid "Admin Console" +msgstr "" + +msgid "Account Console v1 removal" +msgstr "" + +msgid "The old Account Console (v1) is now completely removed. This version of the Account Console was marked as deprecated in Keycloak 12." +msgstr "" + +msgid "Account Console v3 promoted to preview" +msgstr "" + +msgid "In version 21.1.0 of Keycloak the new Account Console (version 3) was introduced as an experimental feature. Starting this version it has been promoted to a preview feature." +msgstr "" + +msgid "Account Console template variables removed" +msgstr "" + +msgid "Two of the variables exposed to the Account Console V2 and V3 templates (`isEventsEnabled` and `isTotpConfigured`) were left unused, and have been removed in this release." +msgstr "" + +msgid "It is possible that if a developer extended the Account Console theme, he or she could make use of these variables. So make sure that these variables are no longer used if you are extending the base theme." +msgstr "" + +msgid "Changes to custom Admin Console messages" +msgstr "" + +msgid "The Admin Console (and soon also the new Account Console) works slightly different than the rest of Keycloak in regards to how keys for internationalized messages are parsed. This is due to the fact that it uses the https://www.i18next.com/[i18next] library for internationalization. Therefore when defining custom messages for the Admin Console under \"Realm Settings\" ➡ \"Localization\" best practices for i18next must be taken into account. Specifically, when defining a message for the Admin Console it is it important to specify a https://www.i18next.com/principles/namespaces[namespace] in the key of your message." +msgstr "" + +msgid "For example, let's assume we want to overwrite the https://github.com/keycloak/keycloak/blob/025778fe9c745316f80b53fe3052aeb314e868ef/js/apps/admin-ui/public/locales/en/dashboard.json#L3[`welcome`] message shown to the user when a new realm has been created. This message is located in the `dashboard` namespace, same as the name of the original file that holds the messages (`dashboard.json`). If we wanted to overwrite this message we'll have to use the namespace as a prefix followed by the key of the message separated by a colon, in this case it would become `dashboard:welcome`." +msgstr "" + +msgid "JavaScript adapter" +msgstr "" + +msgid "Legacy Promise API removed" +msgstr "" + +msgid "With this release, we have removed the legacy Promise API methods from the Keycloak JS adapter. This means that calling `.success()` and `.error()` on promises returned from the adapter is no longer possible." +msgstr "" + +msgid "Required to be instantiated with the `new` operator" +msgstr "" + +msgid "In a previous release we started to actively log deprecation warnings when the Keycloak JS adapter is constructed without the `new` operator. Starting this release doing so will throw an exception instead. This is to align with the expected behavior of https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes[JavaScript classes], which will allow further refactoring of the adapter in the future." +msgstr "" + +msgid "Admin API" +msgstr "" + +msgid "Renamed Admin library artifacts" +msgstr "" + +msgid "After the upgrade to Jakarta EE, artifacts for Keycloak Admin clients were renamed to more descriptive names with consideration for long-term maintainability. We still provide two separate Keycloak Admin clients, one with Jakarta EE and the other with Java EE support." +msgstr "" + +msgid "Support for count users based on custom attributes" +msgstr "" + +msgid "The User API now supports querying the number of users based on custom attributes. For that, a new `q` parameter was added to the `/{realm}/users/count` endpoint." +msgstr "" + +msgid "The `q` parameter expects the following format `q=: :`. Where `` and `` represent the attribute name and value, respectively." +msgstr "" + +msgid "Operator" +msgstr "" + +msgid "k8s.keycloak.org/v2alpha1 changes" +msgstr "" + +msgid "The are additional fields available in the keycloak.status to facilitate keycloak being a scalable resource. There are also additional fields that make the status easier to interpret such as observedGeneration and condition observedGeneration and lastTransitionTime fields." +msgstr "" + +msgid "The condition status field was changed from a boolean to a string for conformance with standard Kubernetes conditions. In the CRD it will temporarily be represented as accepting any content, but it will only ever be a string. Please make sure any of your usage of this field is updated to expect the values \"True\", \"False\", or \"Unknown\", rather than true or false." +msgstr "" + +msgid "Co-management of Operator Resources" +msgstr "" + +msgid "In scenarios where advanced management is needed you may now directly update most fields on operator managed resources that have not been set by the operator directly. This can be used as an alternative to the unsupported stanza of the Keycloak spec. Like the unsupported stanza these direct modifications are not considered supported. If your modifications prevent the operator from being able to manage the resource, there Keycloak CR will show this error condition and the operator will log it." +msgstr "" + +msgid "Identity Brokering" +msgstr "" + +msgid "Essential claim configuration in OpenID Connect identity providers" +msgstr "" + +msgid "OpenID Connect identity providers support a new configuration to specify that the ID tokens issued by the identity provider must have a specific claim, otherwise the user can not authenticate through this broker." +msgstr "" + +msgid "The option is disabled by default; when it is enabled, you can specify the name of the JWT token claim to filter and the value to match (supports regular expression format)." +msgstr "" + +msgid "Support for JWE encrypted ID Tokens and UserInfo responses in OpenID Connect providers" +msgstr "" + +msgid "The OpenID Connect providers now support https://datatracker.ietf.org/doc/html/rfc7516[Json Web Encryption (JWE)] for the ID Token and the UserInfo response. The providers use the realm keys defined for the selected encryption algorithm to perform the decryption." +msgstr "" + +msgid "Hardcoded group mapper" +msgstr "" + +msgid "The new hardcorded group mapper allows adding a specific group to users brokered from an Identity Provider." +msgstr "" + +msgid "User session note mapper" +msgstr "" + +msgid "The new user session note mapper allows mapping a claim to the user session notes." +msgstr "" + +msgid "LDAP Federation" +msgstr "" + +msgid "LDAPS-only Truststore option removed" +msgstr "" + +msgid "LDAP option to use truststore SPI `Only for ldaps` has been removed. This parameter is used to select truststore for TLS-secured LDAP connection: either internal Keycloak truststore is picked (`Always`), or the global JVM one (`Never`)." +msgstr "" + +msgid "Deployments where `Only for ldaps` was used will automatically behave as if `Always` option was selected for TLS-secured LDAP connections." +msgstr "" + +msgid "Removed Openshift integration feature" +msgstr "" + +msgid "The `openshift-integration` preview feature that allowed replacing the internal IdP in OpenShift 3.x with Keycloak was removed from Keycloak codebase into separate extension project." +msgstr "" + +msgid "{project_name_full} 21.1.2" +msgstr "" + +msgid "Changes in validating schemes for valid redirect URIs" +msgstr "" + +msgid "If an application client is using non http(s) custom schemes, from now on the validation requires that a valid redirect pattern explicitly allows that scheme. Example patterns for allowing `custom` scheme are `custom:/test`, `custom:/test/\\*` or `custom:*`. For security reasons a general pattern like `*` does not cover them anymore." +msgstr "" + +msgid "{project_name_full} 21.1.0" +msgstr "" + +msgid "Monorepo" +msgstr "" + +msgid "In the past Keycloak was maintained across multiple GitHub repositories:" +msgstr "" + +msgid "https://github.com/keycloak/keycloak-documentation[Documentation repository]" +msgstr "" + +msgid "https://github.com/keycloak/keycloak-ui[UI repository]" +msgstr "" + +msgid "https://github.com/keycloak/keycloak-nodejs-admin-client[Node.js admin client repository]" +msgstr "" + +msgid "Having multiple repositories introduced a lot of complexity and toil. For example frequently multiple pull requests had to be sent to different repositories for a single change." +msgstr "" + +msgid "To simplify things we have now migrated everything into the https://github.com/keycloak/keycloak[main repository]." +msgstr "" + +msgid "FIPS 140-2 support" +msgstr "" + +msgid "FIPS 140-2 support in Keycloak, which was preview in the previous release, is now promoted to be officially supported." +msgstr "" + +msgid "Experimental Account Console version 3" +msgstr "" + +msgid "The Account Console version 3 is now available as an experimental feature in Keycloak. This version supports custom fields created with the 'User Profile' feature. If you are looking to try it out and provide us with some early feedback you can enable it as follows:" +msgstr "" + +msgid "bin/kc.sh start-dev --features=account3" +msgstr "" + +msgid "Changes to Keycloak Authorization Services support in Keycloak Java-based Adapters" +msgstr "" + +msgid "As part of the removal of the https://www.keycloak.org/2023/03/adapter-deprecation-update[deprecated] adapters, the Keycloak Policy Enforcer was extracted from the adapters code base into a separate dependency:" +msgstr "" + +msgid "" +"\n" +" org.keycloak\n" +" keycloak-policy-enforcer\n" +" 21.1.0\n" +"" +msgstr "" + +msgid "By providing this dependency, we expect making it possible to integrate the policy enforcer with the Java stack of your preference." +msgstr "" + +msgid "It also provides built-in support for enabling the policy enforcer to Jakarta applications protected with https://docs.wildfly.org/26/Admin_Guide.html#Elytron_OIDC_Client[Wildfly Elytron]." +msgstr "" + +msgid "For now, this dependency is not yet GA as we are still working on the quickstarts and documentation." +msgstr "" + +msgid "This work should not impact existing applications using the deprecated adapters. = Javascript engine available by default" +msgstr "" + +msgid "In the previous version, when Keycloak was used on Java 17 with Javascript providers it was needed to add the Nashorn javascript engine to the distribution. This is no longer needed as Nashorn javascript engine is available in Keycloak server by default." +msgstr "" + +msgid "{project_name_full} 21.0.0" +msgstr "" + +msgid "Old Admin Console removed" +msgstr "" + +msgid "In Keycloak 19 the new admin console was graduated to the new default admin console, and the old admin console was deprecated. In this release the old admin console has been removed completely." +msgstr "" + +msgid "Keycloak uses Micrometer for metrics" +msgstr "" + +msgid "Keycloak provides an optional a metrics endpoint which exports metrics in the Prometheus format. In this release the implementation to provide this data switched from SmallRye to Micrometer. Due to this change, metrics have been renamed." +msgstr "" + +msgid "See the migration guide for details." +msgstr "" + +msgid "Java 11 support for Keycloak server deprecated" +msgstr "" + +msgid "Running the Keycloak server with Java 11 is now deprecated, and planned to be removed in Keycloak 22." +msgstr "" + +msgid "Adapters remain supported on Java 8, Java 11, and Java 17. However, we are planning to remove support for Java 8 in the not too distant future." +msgstr "" + +msgid "Hashicop Vault no longer supported" +msgstr "" + +msgid "We removed the out-of-box support for Hashicorp vault in this release." +msgstr "" + +msgid "See this https://github.com/keycloak/keycloak/discussions/16446[discussion] for more details." +msgstr "" + +msgid "SAML SP metadata changes" +msgstr "" + +msgid "Prior to this release, SAML SP metadata contained the same key for both signing and encryption use. Starting with this version of Keycloak, we include only encryption intended realm keys for encryption use in SP metadata. For each encryption key descriptor we also specify the algorithm that it is supposed to be used with. The following table shows the supported XML-Enc algorithms with the mapping to Keycloak realm keys. See the link:{upgradingguide_link}[{upgradingguide_name}] for more details." +msgstr "" + +msgid "*XML-Enc algorithm*" +msgstr "" + +msgid "*Keycloak realm key algorithm*" +msgstr "" + +msgid "https://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#rsa-oaep-mgf1p[rsa-oaep-mgf1p]" +msgstr "" + +msgid "RSA-OAEP" +msgstr "" + +msgid "https://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#rsa-1_5[rsa-1_5]" +msgstr "" + +msgid "RSA1_5" +msgstr "" + +msgid "Deprecated methods from user session provider were removed" +msgstr "" + +msgid "Several deprecated methods were removed from user session provider. If not done already, their usage needs to be replaced with the corresponding replacement documented in Javadoc of Keycloak 20 release. See link:{upgradingguide_link}[{upgradingguide_name}] for more details." +msgstr "" + +msgid "New storage: `IS_CLIENT_ROLE` searchable field was deprecated" +msgstr "" + +msgid "The `IS_CLIENT_ROLE` searchable field from the `RoleModel` was deprecated. It should be replaced with the `CLIENT_ID` searchable field used with the operators `EXISTS` or `NOT_EXISTS`. See JavaDoc of Keycloak 21 for more details." +msgstr "" + +msgid "FIPS 140-2 preview support" +msgstr "" + +msgid "FIPS 140-2 support in Keycloak, which was experimental in the previous release, is now promoted to preview. There were many fixes and improvements to create this preview version. For the details, see the https://www.keycloak.org/server/fips[FIPS documentation]. Feedback is welcome!" +msgstr "" + +msgid "Thanks again to https://github.com/david-rh[David Anderson], https://github.com/sudeepd[Sudeep Das] and https://github.com/isaacjensen[Isaac Jensen] for their huge help with this feature." +msgstr "" + +msgid "Support for the standard `Forwarded` header when running behind a reverse proxy" +msgstr "" + +msgid "In addition to recognize the non-standard `X-Forwarded-*` to fetch information added by proxies that would otherwise be altered or lost when proxy servers are involved in the path of the request, Keycloak can now leverage the standard `Forwarded` header for the same purpose." +msgstr "" + +msgid "For more details, see the https://www.keycloak.org/server/reverseproxy[Using a reverse proxy] {section}." +msgstr "" + +msgid "Please, make sure your proxy is also overriding the `Forwarded` header when making requests to Keycloak nodes." +msgstr "" + +msgid "The container image is now based on ubi9-micro" +msgstr "" + +msgid "To enhance security, the https://quay.io/repository/keycloak/keycloak?tab=info[Keycloak Container Image] has been modified in two ways: First, it is now based on UBI9, rather than UBI8. Second, we have switched to `+-micro+`, whereas `+-minimal+` was used before." +msgstr "" + +msgid "The change to UBI9 will not have any impact on most users. In rare cases the glibc error https://github.com/keycloak/keycloak/issues/17290[CPU does not support x86-64-v2] may appear. `+x86-64-v2+` has been available from processors since 2009. You're most likely to encounter this issue when your virtualization environment is misconfigured." +msgstr "" + +msgid "The change from `+-minimal+` to `+-micro+` has more potential impact. Users making simple customizations to the image won't notice any difference, however any user that installs RPMs will need to change how they do that. The https://www.keycloak.org/server/containers[Running Keycloak in a container] {section} has been updated to show you how." +msgstr "" + +msgid "As a result of these changes, there has been an 82% reduction in known CVEs affecting the Keycloak Container Image!" +msgstr "" + +msgid "Other improvements" +msgstr "" + +msgid "Option to disable client registration access token rotation. Thanks to https://github.com/reda-alaoui[Réda Housni Alaoui]" +msgstr "" + +msgid "{project_name_full} 20.0.0" +msgstr "" + +msgid "WildFly distribution removed" +msgstr "" + +msgid "In Keycloak 17.0.0 the new Quarkus based distribution of Keycloak, while the WildFly based distribution was deprecated. With this release the WildFly distribution has been removed, and is no longer supported." +msgstr "" + +msgid "If you are still using the WildFly distribution we highly encourage migrating to the Quarkus distribution as soon as possible, see the https://www.keycloak.org/migration/migrating-to-quarkus[Migration Guide] for more details." +msgstr "" + +msgid "New Keycloak Operator upgrade" +msgstr "" + +msgid "We are happy to announce that the new Keycloak Operator for the Quarkus based distribution is no longer a preview feature. We added new functionality as well as a number of improvements, some which has resulted in breaking changes." +msgstr "" + +msgid "Realm Operator" +msgstr "" + +msgid "As the new Operator currently lacks some of the CRs (e.g. Client and User), we're introducing a temporary workaround in the form of a Realm Operator. Please see its https://github.com/keycloak/keycloak-realm-operator[GitHub Repository] for more details. See also https://www.keycloak.org/2022/09/operator-crs[\"The future of Keycloak Operator CRs\" blogpost]." +msgstr "" + +msgid "Supported OpenJDK versions" +msgstr "" + +msgid "Keycloak now supports OpenJDK 17 both for the server and adapters." +msgstr "" + +msgid "With the removal of the WildFly based distribution there is no longer support for running the Keycloak server on OpenJDK 8. We also plan to remove support for Keycloak adapters on OpenJDK 8 in Keycloak 21." +msgstr "" + +msgid "Starting with Keycloak 22 we plan to only support the latest OpenJDK LTS release and aiming to quickly also support the latest OpenJDK release. That means we will be also removing OpenJDK 11 support for the Keycloak server in Keycloak 22." +msgstr "" + +msgid "Hostname provider now supports configuring the complete base URL" +msgstr "" + +msgid "In this release, we are introducing two additional server options to set the base URL for frontend request and the Admin Console:" +msgstr "" + +msgid "`hostname-url`" +msgstr "" + +msgid "`hostname-admin-url`" +msgstr "" + +msgid "More details can be found at the https://www.keycloak.org/server/hostname[Configuring the Hostname] {section}." +msgstr "" + +msgid "Improvements to `kc.bat` when running Keycloak on Windows" +msgstr "" + +msgid "In this release, we are making important changes to `kc.bat` to give the same experience as when running on Linux." +msgstr "" + +msgid "Upgrade of embedded H2 database" +msgstr "" + +msgid "{project_name} ships for development purposes with an H2 database driver. As it is intended for development purposes only, it should never be used in a production environment." +msgstr "" + +msgid "In this release, the H2 driver has been upgraded from version 1.x to version 2.x." +msgstr "" + +msgid "Feature guard for hosting the Keycloak JavaScript adapter" +msgstr "" + +msgid "Applications are able to load `keycloak.js` directly from the Keycloak server. As it's not considered a best-practice to load JavaScript libraries this way there is now a feature guard that allows disabling this ability." +msgstr "" + +msgid "In Keycloak 21 we will deprecate this option, and in Keycloak 22 we plan to completely remove the ability to load `keycloak.js` from the Keycloak server." +msgstr "" + +msgid "OTP Application SPI" +msgstr "" + +msgid "In previous releases the list of OTP applications displayed to users was hard-coded in Keycloak. With the introduction of the OTP Application SPI it is now possible to disable built-in OTP applications, as well as adding custom OTP Applications." +msgstr "" + +msgid "Custom Identity Providers can now set an icon for the provider" +msgstr "" + +msgid "A custom identity provider can now set the icon used on the login pages. Thanks to https://github.com/klausbetz[Klaus Betz], who happens also to maintain https://github.com/klausbetz/apple-identity-provider-keycloak[an extension to Keycloak to support log in with AppleID]." +msgstr "" + +msgid "FIPS 140-2 experimental support" +msgstr "" + +msgid "There is now experimental support for deploying Keycloak into a FIPS 140-2 enabled environment. There will be a blog post with the details shortly after the release with the details how you can try it. Feedback is welcome!" +msgstr "" + +msgid "Thanks to https://github.com/david-rh[David Anderson], who contributed parts of this feature. Also, thanks to https://github.com/sudeepd[Sudeep Das] and https://github.com/isaacjensen[Isaac Jensen] for their initial prototype effort, which was used as an inspiration." +msgstr "" + +msgid "Search groups by attribute" +msgstr "" + +msgid "It is now possible to search groups by attribute through the Admin REST API. Thanks to https://github.com/alice-wondered[Alice] for this contribution." +msgstr "" + +msgid "View group membership in the account console" +msgstr "" + +msgid "It is now possible to allow users to view their group memberships in the account console. Thanks to https://github.com/cgeorgilakis[cgeorgilakis] for this contribution." +msgstr "" + +msgid "Deprecated methods from data providers and models were removed" +msgstr "" + +msgid "Several deprecated methods were removed from data providers and models. If not done already, their usage needs to be replaced with the corresponding replacement documented in Javadoc of Keycloak 19 release. See link:{upgradingguide_link}[{upgradingguide_name}] for more details." +msgstr "" + +msgid "{project_name_full} 19.0.0" +msgstr "" + +msgid "OpenID Connect and SAML Adapters End-of-life" +msgstr "" + +msgid "Some Keycloak OpenID Connect adapters have reached end-of-life and are not included in this release." +msgstr "" + +msgid "Fuse 6 and 7 (OpenID Connect)" +msgstr "" + +msgid "Keycloak will no longer be providing adapters for Fuse 6 or 7. If you need adapters for Fuse please leverage https://access.redhat.com/products/red-hat-single-sign-on/[Red Hat Single Sign-On] 7.x adapters." +msgstr "" + +msgid "JBoss AS 7 and EAP 6 (OpenID Connect and SAML)" +msgstr "" + +msgid "JBoss AS 7 has been unmaintained for a very long time. If you are still using JBoss AS 7 we recommend migrating to WildFly and leveraging the native OIDC support in WildFly." +msgstr "" + +msgid "Red Hat customers using Red Hat JBoss Enterprise Application Platform 6.x should use https://access.redhat.com/products/red-hat-single-sign-on/[Red Hat Single Sign-On] 7.x adapters. These can be used in combination with the Keycloak server." +msgstr "" + +msgid "Jetty 9.2 and 9.3 (OpenID Connect and SAML)" +msgstr "" + +msgid "Jetty 9.2 reached end of life in 2018, while Jetty 9.3 reached end of life in 2020. If you are still using these versions we recommend upgrading to Jetty 9.4 as soon as possible." +msgstr "" + +msgid "Spring Boot 1 (OpenID Connect)" +msgstr "" + +msgid "Spring Boot 1.x reached end of life in 2019. If you are still using Spring Boot 1 we recommend upgrading to Spring Boot 2 as soon as possible." +msgstr "" + +msgid "WildFly legacy security layer (OpenID Connect and SAML)" +msgstr "" + +msgid "In WildFly 25 the legacy security layer was removed, going forward only Elytron will be supported. We recommend anyone using an older version of WildFly to upgrade and leverage native OIDC support in WildFly." +msgstr "" + +msgid "Red Hat customers using Red Hat JBoss Enterprise Application Platform 7.x should use https://access.redhat.com/products/red-hat-single-sign-on/[Red Hat Single Sign-On] 7.x adapters. These can be used in combination with the Keycloak server." +msgstr "" + +msgid "New Admin Console graduation" +msgstr "" + +msgid "The new Admin Console is now graduated to the default admin console, with the old console now deprecated. The old console will be removed in Keycloak 21." +msgstr "" + +msgid "Changes in Keycloak storage" +msgstr "" + +msgid "The Keycloak storage is changing, and the current storage, while still supported, will eventually be replaced with a brand-new implementation. This change brings better support for cloud-native storages, no-downtime abilities, and better support for implementing custom storages for additional areas apart from users." +msgstr "" + +msgid "It means several deep changes in the supported features of the current store will become _legacy_ features. The legacy store and the new store cannot be used simultaneously; only one store can be active at a time." +msgstr "" + +msgid "The most visible change is that the User Storage SPI is incompatible with the new storage API, the Map Storage API. Thus, the User Storage SPI will be deprecated with legacy store and will move to a separate module called `keycloak-model-legacy`. This change impacts several areas, especially areas related to user federation and custom user providers." +msgstr "" + +msgid "Furthermore, APIs have been consolidated so that the details of the storage layer will be transparent to the REST service layer. Specifically, the services will not be able to differentiate cached and non-cached objects, nor specifically access federated versus local storage." +msgstr "" + +msgid "Hence, custom extensions that access objects in local storage or cache through `KeycloakSession` methods must be reviewed. See link:{upgradingguide_link}[{upgradingguide_name}] for details." +msgstr "" + +msgid "OIDC Logout changes" +msgstr "" + +msgid "In the previous release, we added support for OIDC logout. This release contains a few other fixes and polishing. The highlights include:" +msgstr "" + +msgid "Support for the `client_id` parameter, which was added in recent draft of the OIDC RP-Initiated Logout specification. As a result, no need exists to use the `Consent Required` flag of the client to show the logout confirmation screen." +msgstr "" + +msgid "Configuration option `Valid Post Logout Redirect URIs` added to the OIDC client. This change is aligned with the OIDC specification, which allows you to use a different set of redirect URIs for redirect after login and logout. Value `+` used for `Valid Post Logout Redirect URIs` means that the logout will use the same set of redirect URIs as specified by the option of `Valid Redirect URIs`. This change also matches the default behavior when migrating from a previous version due to backwards compatibility." +msgstr "" + +msgid "For more details, see the link:{adminguide_link}#_oidc-logout[{adminguide_name}]." +msgstr "" + +msgid "Update Email Workflow" +msgstr "" + +msgid "There is new preview feature `UPDATE_EMAIL`. When it is enabled and corresponding flag enabled in the realm, the users will be required to confirm updating their email by clicking the link, which will be sent to their new email address. For more details, see the link:{adminguide_link}#_update-email-workflow[{adminguide_name}]. Thanks to https://github.com/reda-alaoui[Réda Housni Alaoui] for the contribution." +msgstr "" + +msgid "Deprecated `podDisruptionBudget` in the legacy {project_operator}" +msgstr "" + +msgid "With this release, we have deprecated `podDisruptionBudget` field in the Keycloak CR of the https://github.com/keycloak/keycloak-operator[legacy {project_operator}]. This optional field will be ignored when the Operator is deployed on Kubernetes version 1.25 and higher." +msgstr "" + +msgid "As a workaround, you can manually create the Pod Disruption Budget in your cluster, for example:" +msgstr "" + +msgid "" +"apiVersion: policy/v1\n" +"kind: PodDisruptionBudget\n" +"metadata:\n" +" labels:\n" +" app: keycloak\n" +" name: keycloak\n" +"spec:\n" +" maxUnavailable: 1\n" +" selector:\n" +" matchLabels:\n" +" component: keycloak" +msgstr "" + +msgid "See also the https://kubernetes.io/docs/tasks/run-application/configure-pdb/[Kubernetes Documentation]." +msgstr "" + +msgid "Initial Support for centralized logging" +msgstr "" + +msgid "Starting with version 19, Keycloak supports sending logs using GELF to centralized logging solutions like ELK, EFK or Graylog out of the box." +msgstr "" + +msgid "You can find the documentation and examples to get you up and running quickly in the https://www.keycloak.org/server/logging#_centralized_logging_using_gelf[logging] {section}." +msgstr "" + +msgid "{project_name_full} 18.0.0" +msgstr "" + +msgid "New Operator preview" +msgstr "" + +msgid "With this release, we're introducing a brand new {project_operator} as a preview. Apart from being rewritten from scratch, the main user-facing change from the legacy Operator is the used {project_name} distribution – the new Operator uses the Quarkus distribution of {project_name}. With that, the API (in form of Custom Resource Definitions) has changed. For details, incl. installation and migration instructions, see the https://www.keycloak.org/guides#operator[Operator related guides]." +msgstr "" + +msgid "The link:{operatorRepo_link}[legacy Operator] will receive updates until Keycloak 20 when the {project_name} WildFly distribution reaches EOL." +msgstr "" + +msgid "OperatorHub versioning scheme" +msgstr "" + +msgid "To avoid version conflicts with the legacy Operator, the 18.0.0 version of the new Operator is released as version `20.0.0-alpha.1` on OperatorHub. The legacy Operator versioning scheme remains the same, i.e. it is released as 18.0.0." +msgstr "" + +msgid "The same pattern will apply for future {project_name} 18 and 19 releases, until version 20 where the legacy Operator reaches EOL." +msgstr "" + +msgid "New Admin Console preview" +msgstr "" + +msgid "The new Admin Console is now graduated to preview, with the plan for it to become the default admin console in Keycloak 19." +msgstr "" + +msgid "If you find any issues with the new console, or have some suggestions for improvements, please let us know through https://github.com/keycloak/keycloak/discussions/categories/new-admin-console[GitHub Discussions]." +msgstr "" + +msgid "Step-up authentication" +msgstr "" + +msgid "{project_name} now supports Step-up authentication. This feature was added in Keycloak 17, and was further polished in this version." +msgstr "" + +msgid "For more details, see link:{adminguide_link}#_step-up-flow[{adminguide_name}]." +msgstr "" + +msgid "Thanks to https://github.com/CorneliaLahnsteiner[Cornelia Lahnsteiner] and https://github.com/romge[Georg Romstorfer] for the contribution." +msgstr "" + +msgid "Client secret rotation" +msgstr "" + +msgid "{project_name} now supports Client Secret Rotation through customer policies. This feature is now available as a preview feature and allows that confidential clients can be provided with realm policies allowing the use up to two secrets simultaneously." +msgstr "" + +msgid "For more details, see link:{adminguide_link}#_secret_rotation[{adminguide_name}]." +msgstr "" + +msgid "Recovery Codes" +msgstr "" + +msgid "Recovery Codes as another way to do two-factor authentication is now available as a preview feature." +msgstr "" + +msgid "OpenID Connect Logout Improvements" +msgstr "" + +msgid "Some fixes and improvements were made to make sure that {project_name} is now fully compliant with all the OpenID Connect logout specifications:" +msgstr "" + +msgid "OpenID Connect RP-Initiated Logout 1.0" +msgstr "" + +msgid "OpenID Connect Front-Channel Logout 1.0" +msgstr "" + +msgid "OpenID Connect Back-Channel Logout 1.0" +msgstr "" + +msgid "OpenID Connect Session Management 1.0" +msgstr "" + +msgid "For more details, see link:{adminguide_link}#_oidc-logout[{adminguide_name}]." +msgstr "" + +msgid "{project_name} now supports WebAuthn id-less authentication. This feature allows that WebAuthn Security Key will identify the user during authentication as long as the security key supports Resident Keys. For more details, see link:{adminguide_link}#_webauthn_loginless[{adminguide_name}]. Thanks to https://github.com/vanrar68[Joaquim Fellmann] for the contribution." +msgstr "" + +msgid "There are more WebAuthn improvements and fixes in addition to that." +msgstr "" + +msgid "The deprecated `upload-script` feature was removed" +msgstr "" + +msgid "The `upload-script` feature has been marked as deprecated for a very long time. In this release, it was completely removed, and it is no longer supported." +msgstr "" + +msgid "If you are using any of these capabilities:" +msgstr "" + +msgid "OpenID Connect Script Mapper" +msgstr "" + +msgid "Script Authenticator (Authentication Execution)" +msgstr "" + +msgid "JavaScript Policies" +msgstr "" + +msgid "You should consider reading this https://www.keycloak.org/docs/latest/server_development/#_script_providers[documentation] in order to understand how to still rely on these capabilities but deploying your scripts to the server rather than managing them through the management interfaces." +msgstr "" + +msgid "Session limits" +msgstr "" + +msgid "{project_name} now supports limits on the number of sessions a user can have. Limits can be placed at the realm level or at the client level." +msgstr "" + +msgid "For more details, see link:{adminguide_link}#_user_session_limits[{adminguide_name}]. Thanks to https://github.com/mfdewit[Mauro de Wit] for the contribution." +msgstr "" + +msgid "SAML ECP Profile is disabled by default" +msgstr "" + +msgid "To mitigate the risk of abusing SAML ECP Profile, {project_name} now blocks this flow for all SAML clients that do not allow it explicitly. The profile can be enabled using _Allow ECP Flow_ flag within client configuration, see link:{adminguide_link}#_client-saml-configuration[{adminguide_name}]." +msgstr "" + +msgid "Quarkus distribution" +msgstr "" + +msgid "Import realms at startup" +msgstr "" + +msgid "The {project_name} Quarkus distribution now supports importing your realms directly at start-up. For more information, check the corresponding https://www.keycloak.org/server/importExport[guide]." +msgstr "" + +msgid "JSON and File Logging improvements" +msgstr "" + +msgid "The {project_name} Quarkus distribution now initially supports logging to a File and logging structured data using JSON." +msgstr "" + +msgid "For more information on the improvements, check the corresponding https://www.keycloak.org/server/logging[Logging] {section}." +msgstr "" + +msgid "Environment variable expansion for values in keycloak.conf" +msgstr "" + +msgid "The {project_name} Quarkus distribution now supports expanding values in keycloak.conf from environment variables." +msgstr "" + +msgid "For more information, check the corresponding https://www.keycloak.org/server/configuration[guide]." +msgstr "" + +msgid "New Option db-url-port" +msgstr "" + +msgid "You can now change the port of your jdbc connection string explicitly by setting the new `db-url-port` configuration option. As for the other convenience options, this option will be overridden by the value of a full `db-url`, if set." +msgstr "" + +msgid "Split metrics-enabled option into health-enabled and metrics-enabled" +msgstr "" + +msgid "The `metrics-enabled` option now only enables the metrics for {project_name}. To enable the readiness and liveness probe, there's the new build option `health-enabled`. This allows more fine-grained usage of these options." +msgstr "" + +msgid "Account console alignments with latest PatternFly release." +msgstr "" + +msgid "Support for encrypted User Info endpoint response. Thanks to https://github.com/giacomoa[Giacomo Altiero]" +msgstr "" + +msgid "Support for the algorithm RSA-OAEP with A256GCM used for encryption keys. Thanks to https://github.com/fbrissi[Filipe Bojikian Rissi]" +msgstr "" + +msgid "Support for login with GitHub Enterprise server. Thanks to https://github.com/nngo[Neon Ngo]" +msgstr "" + +msgid "{project_name_full} 17.0.0" +msgstr "" + +msgid "Highlights" +msgstr "" + +msgid "Quarkus distribution is now fully supported" +msgstr "" + +msgid "The default Keycloak distribution is now based on Quarkus. The new distribution is faster, leaner, and a lot easier to configure!" +msgstr "" + +msgid "We appreciate migrating from the WildFly distribution is not going to be straightforward for everyone, since how you start and configure Keycloak has radically changed. With that in mind we will continue to support the WildFly distribution until June 2022." +msgstr "" + +msgid "For information on how to migrate to the new distribution check out the https://www.keycloak.org/migration/migrating-to-quarkus[Quarkus Migration Guide]." +msgstr "" + +msgid "Quarkus distribution updates" +msgstr "" + +msgid "A lot of effort went into polishing and improving the Quarkus distribution to make it as good as an experience as possible. A few highlights include:" +msgstr "" + +msgid "A new approach to documentation in form of server guides to help you install and configure Keycloak" +msgstr "" + +msgid "Upgraded Quarkus to 2.7.0.Final" +msgstr "" + +msgid "Configuration file is no longer Java specific, and aligns configuration keys with CLI arguments" +msgstr "" + +msgid "Clearer separation between `build options` and `runtime configuration`." +msgstr "" + +msgid "`h2-mem` and `h2-file` databases renamed to `dev-mem` and `dev-file`." +msgstr "" + +msgid "Simplified enabling and disabling features" +msgstr "" + +msgid "Custom, and unsupported, Quarkus configuration is done through `conf/quarkus.properties`." +msgstr "" + +msgid "Ability to add custom Java Options via JAVA_OPTS_APPEND (thanks to https://github.com/dasniko[dasniko])" +msgstr "" + +msgid "Initial logging capabilities" +msgstr "" + +msgid "Initial support for Cross-DC" +msgstr "" + +msgid "User-defined profiles are no longer supported but using different configuration files to achieve the same goal" +msgstr "" + +msgid "Quickstarts updated to use the new distribution == Other improvements" +msgstr "" + +msgid "Offline sessions lazy loaded" +msgstr "" + +msgid "The offline sessions are now lazily fetched from the database by default instead of preloading during the server startup. To change the default behavior, see link:{adminguide_link}#offline-sessions-preloading[{adminguide_name}]." +msgstr "" + +msgid "Improved User Search" +msgstr "" + +msgid "{project_name} now supports a glob-like syntax for the user search when listing users in the Admin Console, which allows for three different types of searches: prefix (`foo*` which became the default search), infix (`\\*foo*`), and exact `\"foo\"`)" +msgstr "" + +msgid "{project_name_full} 16.1.0" +msgstr "" + +msgid "Upgrade to Wildfly 26.0.0" +msgstr "" + +msgid "Keycloak server was upgraded to use Wildfly 26.0.0.Final as the underlying container." +msgstr "" + +msgid "For more information on WildFly 26 refer to the https://www.wildfly.org/news/2021/12/16/WildFly26-Final-Released/[WildFly 26 release notes]." +msgstr "" + +msgid "{project_name_full} 16.0.0" +msgstr "" + +msgid "Upgrade to Wildfly 25.0.1" +msgstr "" + +msgid "Keycloak server was upgraded to use Wildfly 25.0.1.Final as the underlying container." +msgstr "" + +msgid "WildFly 25 drops support for the legacy security subsystem, which is being replaced fully by Elytron. This requires significant changes to how Keycloak is configured. Please, refer to the migration guide for more details." +msgstr "" + +msgid "For more information on WildFly 25 refer to the https://www.wildfly.org/news/2021/10/05/WildFly25-Final-Released/[WildFly 25 release notes]." +msgstr "" + +msgid "Upgrade to Quarkus 2.5.3" +msgstr "" + +msgid "Keycloak.X Quarkus preview distribution was upgraded to Quarkus 2.5.3." +msgstr "" + +msgid "{project_name_full} 15.1.0" +msgstr "" + +msgid "Quarkus distribution preview" +msgstr "" + +msgid "Without comparison the biggest highlight of this release is all the improvements that have been made to the Quarkus distribution. So many in fact, that it will be hard to list them all." +msgstr "" + +msgid "The CLI has been polished to hell and back, and we believe it now provides a very simple and convenient approach to configuring and running Keycloak. It's almost so simple that documentation shouldn't be needed." +msgstr "" + +msgid "To get started, just unpack the distribution, then type `bin/kc.[sh|bat] -h` to discover awesomeness!" +msgstr "" + +msgid "That doesn't mean we don't plan to provide documentation for configuring Keycloak, but it didn't quite make it this time around. In lack of documentation expect a blog post to follow the release introducing all the changes to the Quarkus distribution, as well as an overview on how to use it." +msgstr "" + +msgid "We are rapidly moving towards making the Quarkus distribution our default distribution, and will soon deprecate the WildFly distribution. With this in mind it is important that as many people as possible give it a test-run and provide us with feedback if you find any usability issues, are not able to configure something with it, or if you discover any bugs." +msgstr "" + +msgid "We'd love to hear your thoughts and get your feedback in https://github.com/keycloak/keycloak/discussions/8654[GitHub Discussions]!" +msgstr "" + +msgid "The new admin console is shaping up really nicely, and a preview is included in the main distribution. It is not quite feature complete yet, but there are still loads of things to try out." +msgstr "" + +msgid "WildFly update" +msgstr "" + +msgid "Upgrading from WildFly 23 to WildFly 25 has taken a lot longer than we would have liked. We're still working hard on this and are hoping to release Keycloak 16 as soon as possible with the upgrade, but as we wanted to get the updates to the Quarkus distribution out there we are doing this release in the meantime." +msgstr "" + +msgid "WildFly adapter deprecation" +msgstr "" + +msgid "In WildFly 25 there is now excellent native OpenID Connect support without the need for the Keycloak adapter. With this in mind we are deprecating our WildFly adapter and will not support WildFly 25, but it will be around for a while for older WildFly versions and Red Hat JBoss Enterprise Application Platform 7.y." +msgstr "" + +msgid "Spring Security and Boot adapter deprecation" +msgstr "" + +msgid "A long time ago, with Spring Security 5.0, there is now native support for OAuth 2.0 and OpenID Connect in Spring. With this in mind now is the time to start deprecating our Spring Boot and Security adapters." +msgstr "" + +msgid "OpenID Connect Front-Channel Logout Support" +msgstr "" + +msgid "{project_name} now supports https://openid.net/specs/openid-connect-frontchannel-1_0.html[OpenID Connect Front-Channel Logout 1.0]." +msgstr "" + +msgid "For more details, take a look at link:{adminguide_link}#_oidc-logout[{adminguide_name}]." +msgstr "" + +msgid "Thanks to https://github.com/rhyamada[Ronaldo Yamada] for the contribution." +msgstr "" + +msgid "Deprecated features in the {project_operator}" +msgstr "" + +msgid "With this release, we have deprecated and/or marked as unsupported some features in the {project_operator}. This concerns the Backup CRD and the operator managed Postgres Database." +msgstr "" + +msgid "{project_name_full} 15.0.1" +msgstr "" + +msgid "This release contains some important bug fixes. In addition, We would like to thank https://github.com/leandrobortoli[Leandro José de Bortoli] for his contributions to the FAPI related functionalities such as JARM support and improvements in CIBA." +msgstr "" + +msgid "{project_name_full} 15.0.0" +msgstr "" + +msgid "Financial-grade API (FAPI) Improvements, FAPI CIBA and Open Banking Brasil" +msgstr "" + +msgid "The {project_name} server has improved support for the Financial-grade API (FAPI). More specifically, {project_name} is now compliant with FAPI CIBA and with OpenBanking Brasil. We also have support for CIBA ping mode. Thanks to https://github.com/tnorimat[Takashi Norimatsu], who did most of the work on FAPI CIBA and who is continually doing a really awesome job for the {project_name} project. Also thanks to https://github.com/DmitryMishchuk[Dmytro Mishchuk], https://github.com/andriimurashkin[Andrii Murashkin], https://github.com/HryhoriiHevorkian[Hryhorii Hevorkian] and https://github.com/leandrobortoli[Leandro José de Bortoli], who did a great deal of the work on the FAPI compliance as well. Finally thanks to all the members of the https://github.com/keycloak/kc-sig-fapi/blob/main/members.adoc[FAPI Special interest group] for their help and feedback." +msgstr "" + +msgid "{project_name_full} 14.0.0" +msgstr "" + +msgid "Client Policies and Financial-grade API (FAPI) Support" +msgstr "" + +msgid "The {project_name} server has now official support for client policies and Financial-grade API (FAPI). This capability was previewed in earlier versions, but now it is more polished and properly documented. Thanks to https://github.com/tnorimat[Takashi Norimatsu], who did most of the work on this. Also thanks to https://github.com/DmitryMishchuk[Dmytro Mishchuk], https://github.com/andriimurashkin[Andrii Murashkin] and https://github.com/HryhoriiHevorkian[Hryhorii Hevorkian], who did a great deal of the work on this feature as well. Finally thanks to all the members of the https://github.com/keycloak/kc-sig-fapi/blob/main/members.adoc[FAPI Special interest group] for their help and feedback." +msgstr "" + +msgid "Improvements to User Profile SPI and support for declarative configuration" +msgstr "" + +msgid "In this version, there were several improvements to the User Profile SPI in order to prepare the ground on how users profiles are managed in {project_name}." +msgstr "" + +msgid "One of these improvements is the support for configuring user profiles through the administration console. For more details proceed to link:{adminguide_link}#user-profile[{adminguide_name}]" +msgstr "" + +msgid "Thanks to the community and all the individuals involved in this effort." +msgstr "" + +msgid "Improvements to offline sessions" +msgstr "" + +msgid "Offline session preloading has been improved and should be faster thanks to https://github.com/Flintholm[Peter Flintholm]." +msgstr "" + +msgid "As a preview feature, offline session preloading can be skipped in favor of lazy loading thanks to https://github.com/thomasdarimont[Thomas Darimont]'s efforts. This feature has to be explicitly activated in the server configuration, see Server administration guide for details." +msgstr "" + +msgid "The support for configuring maximum number of active authentication sessions. The default value is set to 300 authentication sessions (browser tabs) per a browser's session" +msgstr "" + +msgid "{project_name_full} 13.0.0" +msgstr "" + +msgid "Upgrade to Wildfly 23" +msgstr "" + +msgid "The {project_name} server was upgraded to use Wildfly 23.0.2.Final as the underlying container." +msgstr "" + +msgid "OAuth 2.0 Device Authorization Grant (RFC 8628)" +msgstr "" + +msgid "Support for OAuth 2.0 Device Authorization Grant is now available." +msgstr "" + +msgid "Thanks to Hiroyuki Wada, https://github.com/splatch[Łukasz Dywicki] and https://github.com/Michito-Okai[Michito Okai]." +msgstr "" + +msgid "OpenID Connect Client Initiated Backchannel Authentication (CIBA)" +msgstr "" + +msgid "Support for OpenID Connect Client Initiated Backchannel Authentication (CIBA) is now available." +msgstr "" + +msgid "Thanks to https://github.com/tnorimat[Takashi Norimatsu], https://github.com/andriimurashkin[Andrii Murashkin], https://github.com/c4r1570p4e[Christophe Lannoy] and members of the FAPI WG for the implementation and feedback." +msgstr "" + +msgid "SAML Artifact binding in server to client communication" +msgstr "" + +msgid "Keycloak now supports communication with clients using SAML _Artifact_ binding. A new `Force Artifact Binding` option was introduced in the client configuration, that forces communication with the client using artifact messages. For more details proceed to link:{adminguide_link}#_client-saml-configuration[{adminguide_name}]. Please note, that with this version, Keycloak SAML client adapter does NOT support Artifact binding." +msgstr "" + +msgid "Thanks to https://github.com/AlistairDoswald[AlistairDoswald] and https://github.com/harture[harture]." +msgstr "" + +msgid "Support PKCE for identity brokering" +msgstr "" + +msgid "Keycloak can now leverage PKCE when brokering to an external OpenID Connect IdP." +msgstr "" + +msgid "Thanks to https://github.com/thomasdarimont[thomasdarimont]." +msgstr "" + +msgid "Default roles processing improvement" +msgstr "" + +msgid "Default roles are now internally stored as composite roles of a new role usually named `default-roles-`. Instead of assigning both realm and all client default roles directly to newly created users or users imported through Identity Brokering, just the role is assigned to them and the rest of default roles are assigned as effective roles. This change improves performance of default roles processing, especially with larger number of clients, because it is no longer necessary to go through all clients." +msgstr "" + +msgid "{project_name_full} 12.0.0" +msgstr "" + +msgid "Keycloak.X distribution preview" +msgstr "" + +msgid "Introduction a preview of the new and upcoming Keycloak.X distribution. This distribution is powered by Quarkus, bringing significant improvements to startup time and memory consumption, as well as making it a lot easier to configure Keycloak." +msgstr "" + +msgid "New Account console is now the default" +msgstr "" + +msgid "The new account console is no longer a preview feature and is now the default account console in Keycloak. The old account console will stay around for a while. For those that have a custom theme for the old account console the old console will be used by default, giving you the time to update your custom theme to the new account console." +msgstr "" + +msgid "OpenID Connect Back-Channel Logout" +msgstr "" + +msgid "Support for OpenID Connect Back-Channel Logout is now available, thanks to https://github.com/DaSmoo[DaSmoo] and https://github.com/benjamin37[benjamin37]." +msgstr "" + +msgid "Upgrade to Wildfly 21" +msgstr "" + +msgid "The {project_name} server was upgraded to use Wildfly 21 as the underlying container." +msgstr "" + +msgid "Ability to request AuthnContext in SAML identity provider" +msgstr "" + +msgid "Support for specification of AuthnContext section in authentication requests issued by SAML identity provider has been added." +msgstr "" + +msgid "Thanks to https://github.com/lscorcia[lscorcia]" +msgstr "" + +msgid "FAPI RW support and initial support to Client policies" +msgstr "" + +msgid "There was lots of the work done to have support for Financial-grade API Read and Write API Security Profile (FAPI RW). This is available with the usage of Client policies and it is still in the preview state. You can expect more polishing in the next releases. Thanks to https://github.com/tnorimat[Takashi Norimatsu] and all the members of the https://github.com/keycloak/kc-sig-fapi[FAPI Special interest group]." +msgstr "" + +msgid "Upgrade login theme to PatternFly 4" +msgstr "" + +msgid "The {project_name} login theme components have been upgraded to PatternFly 4. The old PatternFly 3 runs simultaneously with the new one, so it's possible to have PF3 components there." +msgstr "" + +msgid "There are also design changes in the login theme for better user experience. You can even define an icon for your custom Identity providers. For details, please refer to the link:{developerguide_link}#custom-identity-providers-icons[docs]." +msgstr "" + +msgid "Gatekeeper EOL" +msgstr "" + +msgid "Gatekeeper reached end of life, in November 21. This means that we no longer support, or update it. The announcement is available https://www.keycloak.org/2020/08/sunsetting-louketo-project.adoc[here]." +msgstr "" + +msgid "Support for OAuth2 Client Credentials grant without refresh token and without user session. Thanks to https://github.com/thomasdarimont[Thomas Darimont]" +msgstr "" + +msgid "Support for send access tokens to the OAuth2 Revocation endpoint" +msgstr "" + +msgid "{project_name_full} 11.0.0" +msgstr "" + +msgid "LDAPv3 password modify operation" +msgstr "" + +msgid "Support for LDAPv3 password modify operation was added. Also the ability in the admin console to request metadata from the configured LDAP server to see if it supports LDAPv3 password modify operation." +msgstr "" + +msgid "Thanks to https://github.com/cachescrubber[cachescrubber]" +msgstr "" + +msgid "Namespace support for LDAP group mapper" +msgstr "" + +msgid "Namespace support for LDAP group mapper allows you to map groups from LDAP under specified branch (namespace) of the Keycloak groups tree. Previously groups from LDAP were always added as the top level groups in Keycloak." +msgstr "" + +msgid "Thanks to https://github.com/tjuerge[Torsten Juergeleit]" +msgstr "" + +msgid "Upgrade to WildFly 20" +msgstr "" + +msgid "Keycloak server was upgraded to use WildFly 20.0.1.Final under the covers. For more details, please take a look at link:{upgradingguide_link_latest}[{upgradingguide_name}]." +msgstr "" + +msgid "SAML POST binding is broken in the latest versions of browsers" +msgstr "" + +msgid "The `SameSite` value `None` for `JSESSIONID` cookie is necessary for correct behavior of the {project_name} SAML adapter. Usage of a different value is causing resetting of the container's session with each request to {project_name}, when the SAML POST binging is used. Refer to the following steps for link:{adapterguide_link}#_saml-jboss-adapter-samesite-setting[Wildfly] and link:{adapterguide_link}#_saml-tomcat-adapter-samesite-setting[Tomcat] to keep the correct behavior. Notice, that this workaround should be working also with the previous versions of the adapter." +msgstr "" + +msgid "Support for client offline session lifespan. Thanks to https://github.com/y-tabata[Yoshiyuki Tabata]" +msgstr "" + +msgid "Czech translation. Thanks to https://github.com/jakubknejzlik[Jakub Knejzlík]" +msgstr "" + +msgid "Possibility to fetch additional fields from the Facebook identity provider. Thanks to https://github.com/BartoszSiemienczuk[Bartosz Siemieńczuk]" +msgstr "" + +msgid "Support for AES 192 and AES 256 algorithms used for signed and encrypted ID tokens. Thanks to https://github.com/tnorimat[Takashi Norimatsu]" +msgstr "" + +msgid "Ability to specify signature algorithm in Signed JWT Client Authentication. Thanks to https://github.com/tnorimat[Takashi Norimatsu]" +msgstr "" + +msgid "{project_name_full} 10.0.0" +msgstr "" + +msgid "Identity Brokering Sync Mode" +msgstr "" + +msgid "With Identity Brokering Sync Mode it is now possible to control if user profiles are updated on first login, or every login from an external Identity Provider. It is also possible to override this behaviour on individual mappers." +msgstr "" + +msgid "Thanks to https://github.com/Martin-Idel-SI[Martin Idel]" +msgstr "" + +msgid "Client Session Timeout for OpenID Connect / OAuth 2.0" +msgstr "" + +msgid "Typically, an SSO session last for days if not months, while individual client sessions should ideally be a lot shorter. With the introduction of client session timeout it is now possible to configure a separate timeout for individual clients, as well as a default for all clients within a realm." +msgstr "" + +msgid "Thanks to https://github.com/y-tabata[Yoshiyuki Tabata]" +msgstr "" + +msgid "OAuth 2.0 Token Revocation (RFC 7009)" +msgstr "" + +msgid "For applications that use Keycloak as an OAuth 2.0 Authorization Server there is now support to revoke refresh tokens through the token revocation endpoint." +msgstr "" + +msgid "Security Headers SPI and Response Filter" +msgstr "" + +msgid "A new SPI was introduced to allow better flexibility when setting security related headers on responses. This provides a cleaner implementation within Keycloak, but also allows full customisation if needed. Security headers are now set by a response filter instead of within the code itself, which makes it less error-prone, removing the chance that some response are missing headers." +msgstr "" + +msgid "Upgrade to WildFly 19" +msgstr "" + +msgid "Keycloak server was upgraded to use WildFly 19 under the covers." +msgstr "" + +msgid "Support for invoking Application Initiated Actions added to Keycloak JavaScript adapter" +msgstr "" + +msgid "Performance improvements to fetching resources and policies during evaluation" +msgstr "" + +msgid "{project_name_full} 9.0.1" +msgstr "" + +msgid "PromiseType removed from JavaScript adapter" +msgstr "" + +msgid "The promiseType init option has been removed from the JavaScript adapter. Instead a promise that supports both native promise API and legacy Keycloak promise API is returned. This allows gradually migration of applications from the legacy/deprecated API to the native promise API." +msgstr "" + +msgid "Reverted breaking API changes to LocaleSelectorSPI" +msgstr "" + +msgid "In 9.0.0 a breaking API change was introduced to LocaleSelectorSPI. With 9.0.1 the changes to this API is now reverted, and a new LocaleUpdaterSPI has been introduced." +msgstr "" + +msgid "Fixed the automatic resolution of `KeycloakConfigResolver` instances for Spring Boot Applications" +msgstr "" + +msgid "In previous releases, Spring Boot applications had to manually implement the `KeycloakConfigResolver` interface or extend the built-in `org.keycloak.adapters.springboot.KeycloakSpringBootConfigResolver`." +msgstr "" + +msgid "This release fixes the backward compatibility issue by resolving instances automatically in case none is provided. As well as still allowing applications to provide their own configuration resolver implementations." +msgstr "" + +msgid "{project_name_full} 9.0.0" +msgstr "" + +msgid "Drools Policy Removed" +msgstr "" + +msgid "The Drools Policy was finally removed after the deprecation period. If you need more complex policies you can still use JavaScript-based policies." +msgstr "" + +msgid "Pagination support for clients" +msgstr "" + +msgid "Pagination support was added to clients in the Admin Console and REST API. Thanks to https://github.com/saibot94[saibot94]." +msgstr "" + +msgid "New Elytron Credential Store Vault Provider" +msgstr "" + +msgid "A new built-in vault provider that reads secrets from a keystore-backed Elytron credential store has been added as a WildFly extension. The creation and management of the credential store is handled by Elytron using either the `elytron` subsystem or the `elytron-tool.sh` script." +msgstr "" + +msgid "More updates to W3C WebAuthn and Authentication flows" +msgstr "" + +msgid "In this release, we did some usability improvements to the authentication flows. It should be easier for the end user to choose between available authentication mechanisms for two-factor authentication. It should be more intuitive to log in with OTP or WebAuthn considering the fact that user can have more OTP or WebAuthn credentials. There is also better support for passwordless WebAuthn authentication. Finally, we did some work on defects related to the authentication flows." +msgstr "" + +msgid "Improved handling of user locale" +msgstr "" + +msgid "A number of improvements have been made to how the locale for the login page is selected, as well as when the locale is updated for a user." +msgstr "" + +msgid "Authorization Header token is only considered now when type is Bearer on Gatekeeper. Thanks to https://github.com/HansK-p[HansK-p]" +msgstr "" + +msgid "More algorithms are supported for the client authentication with signed client secret JWT. Namely HS384 and HS512 algorithms were added. Thanks to https://github.com/tnorimat[tnorimat]" +msgstr "" + +msgid "{project_name_full} 8.0.2" +msgstr "" + +msgid "SameSite cookie changes with upcoming Google Chrome update" +msgstr "" + +msgid "Starting with version 80, Google Chrome will change the default value for the `SameSite` cookie parameter to `Lax`. Therefore, changes were required to several {project_name} cookies (especially those which are used within the Javascript adapter for checking the session status using the iframe) to set `SameSite` parameter to `None`. Please note that this setting also requires setting the `Secure` parameter, hence starting with this version, the Javascript adapter will only be fully functional when using the SSL / TLS connection on the {project_name} side." +msgstr "" + +msgid "{project_name_full} 8.0.1" +msgstr "" + +msgid "LDAP Issue" +msgstr "" + +msgid "This release fixes a critical vulnerability in LDAP introduced in Keycloak 7. If you are using Keycloak 7.0.0, 7.0.1 or 8.0.0 in production we strongly suggest that you upgrade immediately." +msgstr "" + +msgid "WildFly 18.0.1.Final" +msgstr "" + +msgid "Upgrade to WildFly 18.0.1.Final which includes updates to a number of CVEs in third-party libraries." +msgstr "" + +msgid "{project_name_full} 8.0.0" +msgstr "" + +msgid "Vault" +msgstr "" + +msgid "Several configuration fields can obtain their value from a vault instead of entering the value directly: LDAP bind password, SMTP password, and identity provider secrets." +msgstr "" + +msgid "Furthermore, new vault SPI has been introduced to enable development of extensions to access secrets from custom vaults." +msgstr "" + +msgid "New Default Hostname provider" +msgstr "" + +msgid "The fixed and request hostname providers have been replaced with a single new default hostname provider. This provider comes with a number of improvements, including:" +msgstr "" + +msgid "No need to change provider to set fixed base URL" +msgstr "" + +msgid "Support different base URL for frontend and backend requests" +msgstr "" + +msgid "Support changing context-path in cases where Keycloak is exposed on a different context-path through a reverse proxy" +msgstr "" + +msgid "Messages in theme resources" +msgstr "" + +msgid "Message bundles in theme resources enables internationalization of custom providers such as authenticators. They are also shared between all theme types, making it possible to for example share messages between the login and account console. Thanks to https://github.com/micedre[micedre]." +msgstr "" + +msgid "RoleMappingsProvider SPI for the SAML adapters" +msgstr "" + +msgid "We have added a new SPI that allows for the configuration of custom role mappers that are used by the SAML adapters to map the roles extracted from the SAML assertion into roles that exist in the SP application environment. This is particularly useful when the adapters need to communicate with third party IDPs and the roles set by the IDP in the assertion do not correspond to the roles that were defined for the SP application. The provider to be used can be configured in the `keycloak-saml.xml` file or in the `keycloak-saml` subsystem. An implementation that performs the role mappings based on the contents of a properties file was also provided." +msgstr "" + +msgid "Notice that when {project_name} acts as the IDP we can use the built-in role mappers to perform any necessary mappings before setting the roles into the assertion, so this SPI will probably be redundant in this case. The `RoleMappingsProvider` SPI was designed for situations when the IDP offer no way to map roles before adding them to the assertion." +msgstr "" + +msgid "WildFly 18 Upgrade" +msgstr "" + +msgid "Keycloak server was upgraded to use WildFly 18 under the covers." +msgstr "" + +msgid "W3C Web Authentication support" +msgstr "" + +msgid "In this release, we added initial support for W3C Web Authentication (WebAuthn). There are a few limitations in current implementation, however we are working on further improvements in this area. Thanks to https://github.com/tnorimat[tnorimat] for the contribution. Also thanks to ynojima for the help and feedback." +msgstr "" + +msgid "Support for password-less authentication, multi-factor authentication and multiple credentials per user" +msgstr "" + +msgid "With the arrival of W3C Web Authentication support, we've refined the authentication flow system to be able to allow a user to select which authentication method is preferred for login (for example, the choice between an OTP credential and a WebAuthn credential). The new mechanisms also allow an administrator to craft flows for password-less login, for example just using WebAuthn as an authentication method. Please note that with these changes, any custom authentication flow you have created may need to be adapted to the new flow logic." +msgstr "" + +msgid "As a result of these changes, users can now have multiple OTP devices and multiple WebAuthn devices. The same system that allows a user to select which type of device to use during login also allows that user to select which specific device to use. Thanks to the https://github.com/cloudtrust[Cloudtrust] team: https://github.com/AlistairDoswald[AlistairDoswald], https://github.com/fperot74[sispeo] and https://github.com/Fratt[Fratt] for their contributions, and to https://github.com/harture[harture] and https://github.com/lagess[Laurent] for their help." +msgstr "" + +msgid "Other Improvements" +msgstr "" + +msgid "System properties and environment variables support in theme.properties" +msgstr "" + +msgid "It is now possible to use system properties and environment variables within theme.properties file. Thanks to https://github.com/Opa-[Opa-]" +msgstr "" + +msgid "Support more signing algorithms for client authentication with signed JWT" +msgstr "" + +msgid "Thanks to https://github.com/tnorimat[tnorimat], we support more signing algorithms for client authentication with signed JWT." +msgstr "" + +msgid "Configurable client authentication method for OIDC Identity providers" +msgstr "" + +msgid "In this release, possibility to authenticate OIDC providers with signed JWT or basic authentication was added. So all the client authentication methods mentioned in the https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication[OIDC specification] are supported now. Thanks to https://github.com/madgaet[madgaet] and https://github.com/rradillen[rradillen] for contributions." +msgstr "" + +msgid "Support enable/disable logging into the JavaScript adapter" +msgstr "" + +msgid "Thanks to https://github.com/jonkoops[jonkoops] now it's possible to enable or disable logging for the JS adapter." +msgstr "" + +msgid "Credentials support removed from the JavaScript adapter" +msgstr "" + +msgid "The option to provide client credentials in the JavaScript adapter was removed. Thanks to https://github.com/jonkoops[jonkoops]" +msgstr "" + +msgid "Updates for Gatekeeper" +msgstr "" + +msgid "Secure token and logout endpoint were included in Gatekeeper. Thanks to https://github.com/fredbi[fredbi]" +msgstr "" + +msgid "There was a bug on Gatekeeper which was making cookies to be applied to subdomains. Thanks to https://github.com/daniel-ac-martin[daniel-ac-martin] the issue was fixed" +msgstr "" + +msgid "Now Gatekeeper provides support to Same-site cookies. Thanks to https://github.com/fiji-flo[fiji-flo]" +msgstr "" + +msgid "Deploying Scripts to the Server" +msgstr "" + +msgid "Please take a look at link:{releasenotes_link}#keycloak-7-0-1[7.0.1 {releasenotes_name}] for more details on how you can now deploy and run scripts to customize specific behavior." +msgstr "" + +msgid "{project_name_full} 7.0.1" +msgstr "" + +msgid "Until now, administrators were allowed to upload scripts to the server through the {project_name} Administration Console as well as through the RESTful Admin API." +msgstr "" + +msgid "For now on, this capability is *disabled* by default and users should prefer to deploy scripts directly to the server. For more details, please take a look at link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}]." +msgstr "" + +msgid "{project_name_full} 7.0.0" +msgstr "" + +msgid "WildFly 17 Upgrade" +msgstr "" + +msgid "Keycloak server was upgraded to use WildFly 17 under the covers." +msgstr "" + +msgid "Tomcat 9 adapter support" +msgstr "" + +msgid "Java adapter for Apache Tomcat 8 and Apache Tomcat 9 was unified and now it serves for both of them." +msgstr "" + +msgid "New Account Console" +msgstr "" + +msgid "A lot of work has been done on the new Account Console and Account REST API. It's not quite ready yet, but it's getting there and hopefully will be fully done for Keycloak 8." +msgstr "" + +msgid "Signed and Encrypted ID Token Support" +msgstr "" + +msgid "{project_name} can support the signed and encrypted ID token according to the Json Web Encryption (JWE) specification. Thanks to https://github.com/tnorimat[tnorimat]." +msgstr "" + +msgid "Testing and release automation" +msgstr "" + +msgid "The Keycloak team has spent a significant amount of time on automation around testing and releases both for Keycloak and Red Hat Single Sign-On." +msgstr "" + +msgid "PKCE support added to JavaScript adapter. Thanks to https://github.com/thomasdarimont[thomasdarimont]" +msgstr "" + +msgid "Oracle database support added to Keycloak container image. Thanks to https://github.com/nerdstep[nerdstep]" +msgstr "" + +msgid "Clock Skew support added to SAML adapter. Thanks to https://github.com/steevebtib[steevebtib]" +msgstr "" + +msgid "TypeScript support for Node.js adapter. Thanks to https://github.com/evanshortiss[evanshortiss]" +msgstr "" + +msgid "Gatekeeper now allows to provide unencrypted token in header, while encrypting in cookie. There was also a bug on Gatekeeper when `Revoke Refresh Token` is enabled on the Keycloak server. The issue was fixed. Thanks to https://github.com/fredbi[fredbi]" +msgstr "" + +msgid "New tab in the Admin console to display the list of users for client roles. Thanks to https://github.com/unly[unly]" +msgstr "" + +msgid "{project_name_full} 6.0.0" +msgstr "" + +msgid "WildFly 16 Upgrade" +msgstr "" + +msgid "Keycloak server was upgraded to use WildFly 16 under the covers." +msgstr "" + +msgid "SmallRye Health and Metrics extensions" +msgstr "" + +msgid "Keycloak now comes enabled with the SmallRye Health and Metrics extensions which provides standard health and metrics endpoints. We will add some documentation as well as Keycloak specific metrics soon." +msgstr "" + +msgid "PS256 support" +msgstr "" + +msgid "Thanks to https://github.com/tnorimat[tnorimat] Keycloak now has support for signing and verifying tokens with PS256." +msgstr "" + +msgid "MP-JWT Client Scope" +msgstr "" + +msgid "New built-in client scope to make it easy to issue tokens following the Eclipse MicroProfile specification." +msgstr "" + +msgid "{project_name_full} 5.0.0" +msgstr "" + +msgid "WildFly 15 Upgrade" +msgstr "" + +msgid "Keycloak server was upgraded to use WildFly 15 under the covers." +msgstr "" + +msgid "{project_name_full} 4.8.0.Final" +msgstr "" + +msgid "OpenShift Integration" +msgstr "" + +msgid "It is now possible to fully secure OpenShift 3.11 with {project_name}, including the ability to automatically expose Service Accounts as OAuth clients as clients to {project_name}." +msgstr "" + +msgid "This is currently a technology preview feature." +msgstr "" + +msgid "Rules/Drools Policy Marked as a Technology Preview Feature" +msgstr "" + +msgid "Until now, Drools policies were enabled by default. But now, this policy type is only available as a technology preview feature and to use it you need to enable the preview profile or the corresponding feature. Take a look at the link:{authorizationguide_link}[{authorizationguide_name}] for more details." +msgstr "" + +msgid "Support for DB2 removed" +msgstr "" + +msgid "DB2 support has been deprecated for a while. With this release we have removed all support for DB2." +msgstr "" + +msgid "{project_name_full} 4.7.0.Final" +msgstr "" + +msgid "Enhanced Remember Me" +msgstr "" + +msgid "Introduced the ability to specify different session idle and max timeouts for remember me sessions. This enables remember me sessions to live longer than regular sessions." +msgstr "" + +msgid "Pagination support for Groups" +msgstr "" + +msgid "Large numbers of groups have previously caused issues in the admin console. This is now resolved by the introduction of pagination of groups." +msgstr "" + +msgid "Improve startup time with large number of offline sessions" +msgstr "" + +msgid "In the past, starting the server could take a long time if there were many offline sessions. This startup time has now been significantly reduced." +msgstr "" + +msgid "{project_name_full} 4.6.0.Final" +msgstr "" + +msgid "Upgrade to WildFly 14" +msgstr "" + +msgid "The {project_name} server was upgraded to use WildFly 14 under the covers." +msgstr "" + +msgid "Keycloak Gatekeeper" +msgstr "" + +msgid "Keycloak Gatekeeper provides a security proxy that can be used to secure applications and services without an adapter. It can be installed locally alongside your application or as a sidecar on OpenShift or Kubernetes." +msgstr "" + +msgid "Huge thanks to https://github.com/gambol99[gambol99] for contributing this work to Keycloak." +msgstr "" + +msgid "{project_name_full} 4.5.0.Final" +msgstr "" + +msgid "Signature SPI" +msgstr "" + +msgid "The Signature SPI makes it possible to plug-in additional signature algorithms. This enables additional signatures and also enables changing how signatures are generated. For example, using this allows using an HSM device to sign tokens." +msgstr "" + +msgid "Thanks to https://github.com/tnorimat[tnorimat] for contributing a significant part of this work." +msgstr "" + +msgid "New Signature Algorithms" +msgstr "" + +msgid "Alongside the Signature SPI there is now also support for additional signature algorithms." +msgstr "" + +msgid "Keycloak now has support for RS256, RS384, RS512, ES256, ES384, ES512, HS256, HS384 and HS512." +msgstr "" + +msgid "Elliptic Curve Digital Signature Algorithm (ES256/384/512) are very interesting as they provide similar security properties as RSA signatures, but use significantly less CPU." +msgstr "" + +msgid "HMAC (HS256/384/512) are also very useful when you do not want your application to verify the signature itself. Since these are symmetric signatures only Keycloak is able to verify the signature, which requires the application to use the token introspection endpoint to verify tokens." +msgstr "" + +msgid "Better Audience Support for OpenID Connect clients" +msgstr "" + +msgid "It is now possible to specify the audiences in the tokens issued for OpenID Connect clients. There is also support for verification of audience on the adapter side." +msgstr "" + +msgid "Minor improvements" +msgstr "" + +msgid "Added LocaleSelector SPI, which allows to change the way how the locale will be resolved for a particular request. Thanks to https://github.com/knutz3n[knutz3n]" +msgstr "" + +msgid "Added an authenticator to automatically link Identity Provider identity to an existing account after first Idp authentication. Thanks to https://github.com/slominskir[slominskir]" +msgstr "" + +msgid "{project_name_full} 4.4.0.Final" +msgstr "" + +msgid "Upgrade to WildFly 13" +msgstr "" + +msgid "The {project_name} server was upgraded to use WildFly 13 under the covers. This means update of the underlying dependencies and also some changes in the configuration. We now also support WildFly 13 adapter and we upgraded the underlying JDG/Infinispan server version for the Cross-DC setup. See link:{upgradingguide_link}[{upgradingguide_name}] for more details." +msgstr "" + +msgid "Authorization Services support in Node.js" +msgstr "" + +msgid "Having authorization services support in Node.js makes it very easy to do fine-grained central authorization with the Node.js adapter." +msgstr "" + +msgid "Update design for the welcome page" +msgstr "" + +msgid "Allow passing current locale to OAuth2 IdPs. Thanks to https://github.com/knutz3n[knutz3n]" +msgstr "" + +msgid "Support Content-Security-Policy-Report-Only security header. Thanks to https://github.com/knutz3n[knutz3n]" +msgstr "" + +msgid "Script based ProtocolMapper for SAML. Thanks to https://github.com/AlistairDoswald[AlistairDoswald]" +msgstr "" + +msgid "{project_name_full} 4.3.0.Final" +msgstr "" + +msgid "Hostname SPI" +msgstr "" + +msgid "The hostname SPI introduces a more flexible way to configure the hostname for {project_name}. There are two built-in providers. The first is request, which uses the request headers to determine the hostname. The second is fixed, which allows configuring a fixed hostname. The latter makes sure that only valid hostnames can be used and also allows internal applications to invoke {project_name} through an alternative URL." +msgstr "" + +msgid "For more details refer to the threat mitigation section in the link:{adminguide_link}[{adminguide_name}]." +msgstr "" + +msgid "X509 Client Authenticator" +msgstr "" + +msgid "The newly added Client Authenticator uses X509 Client Certificates and Mutual TLS to secure a connection from the client. In addition to that the Keycloak Server validates Subject DN field of the client's certificate." +msgstr "" + +msgid "Performance improvements to Authorization Services" +msgstr "" + +msgid "For this release, we improved policy evaluation performance across the board, increasing reliability and throughput. The main changes we did were related with trying to optimize the policy evaluation path by avoiding unnecessary flows and collect decisions as soon as they happen. We also introduced a policy decision cache on a per-request basis, avoiding redundant decisions from policies previously evaluated." +msgstr "" + +msgid "We are also working on other layers of cache which should give a much better experience. See https://issues.redhat.com/browse/KEYCLOAK-7952[KEYCLOAK-7952]." +msgstr "" + +msgid "Choosing the response mode when obtaining permissions from the server" +msgstr "" + +msgid "In previous versions, permissions were always returned from the server using standard OAuth2 response, containing the access and refresh tokens. In this release, clients can use a `response_mode` parameter to specify how the server should respond to an authorization request. This parameter accepts two values:" +msgstr "" + +msgid "`decision`" +msgstr "" + +msgid "Indicating that responses should only contain a flag indicating whether or not permissions were granted by the server. Otherwise a `403` HTTP status code is returned." +msgstr "" + +msgid "`permissions`" +msgstr "" + +msgid "Indicating that a response should contain every single permission granted by the server using a JSON format." +msgstr "" + +msgid "NodeJS Policy Enforcer" +msgstr "" + +msgid "The https://github.com/keycloak/keycloak-nodejs-connect[keycloak-nodejs-connect], an adapter for NodeJS, now supports constructs to protect resources based on decisions taken from the server. The new construct allows users to protect their resources using fine-grained permissions as follows:" +msgstr "" + +msgid "" +"app.get('/protected/resource', keycloak.enforcer('resource:view'), function (req, res) {\n" +" res.json({message: 'access granted'});\n" +"});" +msgstr "" + +msgid "Support hosted domain for Google logins" +msgstr "" + +msgid "Login with Google now supports the `hd` parameter to restrict Google logins to a specific hosted domain at Google. When this is specified in the identity provider any login from a different domain is rejected." +msgstr "" + +msgid "Thanks to https://github.com/brushmate[brushmate] for the contribution." +msgstr "" + +msgid "Escape unsafe tags in HTML output" +msgstr "" + +msgid "Most HTML output is already escaped for HTML tags, but there are some places where HTML tags are permitted. These are only where admin access is needed to update the value. Even though it would require admin access to update such fields we have added an extra layer of defence and are now escaping unsafe elements like `\n" +"\n" +"" +msgstr "" + +msgid "Remember that this page must be served by your application at the specified location in `silentCheckSsoRedirectUri` and is _not_ part of the adapter." +msgstr "" + +msgid "_Silent_ `check-sso` functionality is limited in some modern browsers. Please see the <<_modern_browsers,Modern Browsers with Tracking Protection Section>>." +msgstr "" + +msgid "To enable `login-required` set `onLoad` to `login-required` and pass to the init method:" +msgstr "" + +msgid "" +"keycloak.init({\n" +" onLoad: 'login-required'\n" +"});" +msgstr "" + +msgid "After the user is authenticated the application can make requests to RESTful services secured by {project_name} by including the bearer token in the `Authorization` header. For example:" +msgstr "" + +msgid "" +"async function fetchUsers() {\n" +" const response = await fetch('/api/users', {\n" +" headers: {\n" +" accept: 'application/json',\n" +" authorization: `Bearer ${keycloak.token}`\n" +" }\n" +" });\n" +"\n" +" return response.json();\n" +"}" +msgstr "" + +msgid "One thing to keep in mind is that the access token by default has a short life expiration so you may need to refresh the access token prior to sending the request. You refresh this token by calling the `updateToken()` method. This method returns a Promise, which makes it easy to invoke the service only if the token was successfully refreshed and displays an error to the user if it was not refreshed. For example:" +msgstr "" + +msgid "" +"try {\n" +" await keycloak.updateToken(30);\n" +"} catch (error) {\n" +" console.error('Failed to refresh token:', error);\n" +"}\n" +"\n" +"const users = await fetchUsers();" +msgstr "" + +msgid "Session Status iframe" +msgstr "" + +msgid "By default, the adapter creates a hidden iframe that is used to detect if a Single-Sign Out has occurred. This iframe does not require any network traffic. Instead the status is retrieved by looking at a special status cookie. This feature can be disabled by setting `checkLoginIframe: false` in the options passed to the `init()` method." +msgstr "" + +msgid "You should not rely on looking at this cookie directly. Its format can change and it's also associated with the URL of the {project_name} server, not your application." +msgstr "" + +msgid "Session Status iframe functionality is limited in some modern browsers. Please see <<_modern_browsers,Modern Browsers with Tracking Protection Section>>." +msgstr "" + +msgid "Implicit and hybrid flow" +msgstr "" + +msgid "By default, the adapter uses the https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code] flow." +msgstr "" + +msgid "With this flow, the {project_name} server returns an authorization code, not an authentication token, to the application. The JavaScript adapter exchanges the `code` for an access token and a refresh token after the browser is redirected back to the application." +msgstr "" + +msgid "{project_name} also supports the https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth[Implicit] flow where an access token is sent immediately after successful authentication with {project_name}. This flow may have better performance than the standard flow because no additional request exists to exchange the code for tokens, but it has implications when the access token expires." +msgstr "" + +msgid "However, sending the access token in the URL fragment can be a security vulnerability. For example the token could be leaked through web server logs and or browser history." +msgstr "" + +msgid "To enable implicit flow, you enable the *Implicit Flow Enabled* flag for the client in the {project_name} Admin Console. You also pass the parameter `flow` with the value `implicit` to `init` method:" +msgstr "" + +msgid "" +"keycloak.init({\n" +" flow: 'implicit'\n" +"})" +msgstr "" + +msgid "Note that only an access token is provided and no refresh token exists. This situation means that once the access token has expired, the application has to redirect to {project_name} again to obtain a new access token." +msgstr "" + +msgid "{project_name} also supports the https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth[Hybrid] flow." +msgstr "" + +msgid "This flow requires the client to have both the *Standard Flow* and *Implicit Flow* enabled in the Admin Console. The {project_name} server then sends both the code and tokens to your application. The access token can be used immediately while the code can be exchanged for access and refresh tokens. Similar to the implicit flow, the hybrid flow is good for performance because the access token is available immediately. But, the token is still sent in the URL, and the security vulnerability mentioned earlier may still apply." +msgstr "" + +msgid "One advantage in the Hybrid flow is that the refresh token is made available to the application." +msgstr "" + +msgid "For the Hybrid flow, you need to pass the parameter `flow` with value `hybrid` to the `init` method:" +msgstr "" + +msgid "" +"keycloak.init({\n" +" flow: 'hybrid'\n" +"});" +msgstr "" + +msgid "Hybrid Apps with Cordova" +msgstr "" + +msgid "{project_name} supports hybrid mobile apps developed with https://cordova.apache.org/[Apache Cordova]. The adapter has two modes for this: `cordova` and `cordova-native`:" +msgstr "" + +msgid "The default is `cordova`, which the adapter automatically selects if no adapter type has been explicitly configured and `window.cordova` is present. When logging in, it opens an https://cordova.apache.org/docs/en/latest/reference/cordova-plugin-inappbrowser/[InApp Browser] that lets the user interact with {project_name} and afterwards returns to the app by redirecting to `http://localhost`. Because of this behavior, you whitelist this URL as a valid redirect-uri in the client configuration section of the Admin Console." +msgstr "" + +msgid "While this mode is easy to set up, it also has some disadvantages:" +msgstr "" + +msgid "The InApp-Browser is a browser embedded in the app and is not the phone's default browser. Therefore it will have different settings and stored credentials will not be available." +msgstr "" + +msgid "The InApp-Browser might also be slower, especially when rendering more complex themes." +msgstr "" + +msgid "There are security concerns to consider, before using this mode, such as that it is possible for the app to gain access to the credentials of the user, as it has full control of the browser rendering the login page, so do not allow its use in apps you do not trust." +msgstr "" + +msgid "Use this example app to help you get started: https://github.com/keycloak/keycloak/tree/master/examples/cordova" +msgstr "" + +msgid "The alternative mode is`cordova-native`, which takes a different approach. It opens the login page using the system's browser. After the user has authenticated, the browser redirects back into the application using a special URL. From there, the {project_name} adapter can finish the login by reading the code or token from the URL." +msgstr "" + +msgid "You can activate the native mode by passing the adapter type `cordova-native` to the `init()` method:" +msgstr "" + +msgid "" +"keycloak.init({\n" +" adapter: 'cordova-native'\n" +"});" +msgstr "" + +msgid "This adapter requires two additional plugins:" +msgstr "" + +msgid "https://github.com/google/cordova-plugin-browsertab[cordova-plugin-browsertab]: allows the app to open webpages in the system's browser" +msgstr "" + +msgid "https://github.com/e-imaxina/cordova-plugin-deeplinks[cordova-plugin-deeplinks]: allow the browser to redirect back to your app by special URLs" +msgstr "" + +msgid "The technical details for linking to an app differ on each platform and special setup is needed. Please refer to the Android and iOS sections of the https://github.com/e-imaxina/cordova-plugin-deeplinks/blob/master/README.md[deeplinks plugin documentation] for further instructions." +msgstr "" + +msgid "Different kinds of links exist for opening apps: * custom schemes, such as `myapp://login` or `android-app://com.example.myapp/https/example.com/login` * https://developer.apple.com/ios/universal-links/[Universal Links (iOS)]) / https://developer.android.com/training/app-links/deep-linking[Deep Links (Android)]. While the former are easier to set up and tend to work more reliably, the latter offer extra security because they are unique and only the owner of a domain can register them. Custom-URLs are deprecated on iOS. For best reliability, we recommend that you use universal links combined with a fallback site that uses a custom-url link." +msgstr "" + +msgid "Furthermore, we recommend the following steps to improve compatibility with the adapter:" +msgstr "" + +msgid "Universal Links on iOS seem to work more reliably with `response-mode` set to `query`" +msgstr "" + +msgid "To prevent Android from opening a new instance of your app on redirect add the following snippet to `config.xml`:" +msgstr "" + +msgid "" +msgstr "" + +msgid "There is an example app that shows how to use the native-mode: https://github.com/keycloak/keycloak/tree/master/examples/cordova-native" +msgstr "" + +msgid "Custom Adapters" +msgstr "" + +msgid "In some situations, you may need to run the adapter in environments that are not supported by default, such as Capacitor. To use the JavasScript client in these environments, you can pass a custom adapter. For example, a third-party library could provide such an adapter to make it possible to reliably run the adapter:" +msgstr "" + +msgid "" +"import Keycloak from 'keycloak-js';\n" +"import KeycloakCapacitorAdapter from 'keycloak-capacitor-adapter';\n" +"\n" +"const keycloak = new Keycloak();\n" +"\n" +"keycloak.init({\n" +" adapter: KeycloakCapacitorAdapter,\n" +"});" +msgstr "" + +msgid "This specific package does not exist, but it gives a pretty good example of how such an adapter could be passed into the client." +msgstr "" + +msgid "It's also possible to make your own adapter, to do so you will have to implement the methods described in the `KeycloakAdapter` interface. For example the following TypeScript code ensures that all the methods are properly implemented:" +msgstr "" + +msgid "" +"import Keycloak, { KeycloakAdapter } from 'keycloak-js';\n" +"\n" +"// Implement the 'KeycloakAdapter' interface so that all required methods are guaranteed to be present.\n" +"const MyCustomAdapter: KeycloakAdapter = {\n" +" login(options) {\n" +" // Write your own implementation here.\n" +" }\n" +"\n" +" // The other methods go here...\n" +"};\n" +"\n" +"const keycloak = new Keycloak();\n" +"\n" +"keycloak.init({\n" +" adapter: MyCustomAdapter,\n" +"});" +msgstr "" + +msgid "Naturally you can also do this without TypeScript by omitting the type information, but ensuring implementing the interface properly will then be left entirely up to you." +msgstr "" + +msgid "Modern Browsers with Tracking Protection" +msgstr "" + +msgid "In the latest versions of some browsers, various cookies policies are applied to prevent tracking of the users by third parties, such as SameSite in Chrome or completely blocked third-party cookies. Those policies are likely to become more restrictive and adopted by other browsers over time. Eventually cookies in third-party contexts may become completely unsupported and blocked by the browsers. As a result, the affected adapter features might ultimately be deprecated." +msgstr "" + +msgid "The adapter relies on third-party cookies for Session Status iframe, _silent_ `check-sso` and partially also for regular (non-silent) `check-sso`. Those features have limited functionality or are completely disabled based on how restrictive the browser is regarding cookies. The adapter tries to detect this setting and reacts accordingly." +msgstr "" + +msgid "Browsers with \"SameSite=Lax by Default\" Policy" +msgstr "" + +msgid "All features are supported if SSL / TLS connection is configured on the {project_name} side as well as on the application side. For example, Chrome is affected starting with version 84." +msgstr "" + +msgid "Browsers with Blocked Third-Party Cookies" +msgstr "" + +msgid "Session Status iframe is not supported and is automatically disabled if such browser behavior is detected by the adapter. This means the adapter cannot use a session cookie for Single Sign-Out detection and must rely purely on tokens. As a result, when a user logs out in another window, the application using the adapter will not be logged out until the application tries to refresh the Access Token. Therefore, consider setting the Access Token Lifespan to a relatively short time, so that the logout is detected as soon as possible. For more details, see link:{adminguide_link}#_timeouts[Session and Token Timeouts]." +msgstr "" + +msgid "_Silent_ `check-sso` is not supported and falls back to regular (non-silent) `check-sso` by default. This behavior can be changed by setting `silentCheckSsoFallback: false` in the options passed to the `init` method. In this case, `check-sso` will be completely disabled if restrictive browser behavior is detected." +msgstr "" + +msgid "Regular `check-sso` is affected as well. Since Session Status iframe is unsupported, an additional redirect to {project_name} has to be made when the adapter is initialized to check the user's login status. This check is different from the standard behavior when the iframe is used to tell whether the user is logged in, and the redirect is performed only when the user is logged out." +msgstr "" + +msgid "An affected browser is for example Safari starting with version 13.1." +msgstr "" + +msgid "API Reference" +msgstr "" + +msgid "Constructor" +msgstr "" + +msgid "" +"new Keycloak();\n" +"new Keycloak('http://localhost/keycloak.json');\n" +"new Keycloak({ url: 'http://localhost{kc_base_path}', realm: 'myrealm', clientId: 'myApp' });" +msgstr "" + +msgid "Properties" +msgstr "" + +msgid "authenticated" +msgstr "" + +msgid "Is `true` if the user is authenticated, `false` otherwise." +msgstr "" + +msgid "token" +msgstr "" + +msgid "The base64 encoded token that can be sent in the `Authorization` header in requests to services." +msgstr "" + +msgid "tokenParsed" +msgstr "" + +msgid "The parsed token as a JavaScript object." +msgstr "" + +msgid "subject" +msgstr "" + +msgid "The user id." +msgstr "" + +msgid "idToken" +msgstr "" + +msgid "The base64 encoded ID token." +msgstr "" + +msgid "idTokenParsed" +msgstr "" + +msgid "The parsed id token as a JavaScript object." +msgstr "" + +msgid "realmAccess" +msgstr "" + +msgid "The realm roles associated with the token." +msgstr "" + +msgid "resourceAccess" +msgstr "" + +msgid "The resource roles associated with the token." +msgstr "" + +msgid "refreshToken" +msgstr "" + +msgid "The base64 encoded refresh token that can be used to retrieve a new token." +msgstr "" + +msgid "refreshTokenParsed" +msgstr "" + +msgid "The parsed refresh token as a JavaScript object." +msgstr "" + +msgid "timeSkew" +msgstr "" + +msgid "The estimated time difference between the browser time and the {project_name} server in seconds. This value is just an estimation, but is accurate enough when determining if a token is expired or not." +msgstr "" + +msgid "responseMode" +msgstr "" + +msgid "Response mode passed in init (default value is fragment)." +msgstr "" + +msgid "flow" +msgstr "" + +msgid "Flow passed in init." +msgstr "" + +msgid "adapter" +msgstr "" + +msgid "Allows you to override the way that redirects and other browser-related functions will be handled by the library. Available options:" +msgstr "" + +msgid "\"default\" - the library uses the browser api for redirects (this is the default)" +msgstr "" + +msgid "\"cordova\" - the library will try to use the InAppBrowser cordova plugin to load keycloak login/registration pages (this is used automatically when the library is working in a cordova ecosystem)" +msgstr "" + +msgid "\"cordova-native\" - the library tries to open the login and registration page using the phone's system browser using the BrowserTabs cordova plugin. This requires extra setup for redirecting back to the app (see <>)." +msgstr "" + +msgid "\"custom\" - allows you to implement a custom adapter (only for advanced use cases)" +msgstr "" + +msgid "responseType" +msgstr "" + +msgid "Response type sent to {project_name} with login requests. This is determined based on the flow value used during initialization, but can be overridden by setting this value." +msgstr "" + +msgid "Methods" +msgstr "" + +msgid "*init(options)*" +msgstr "" + +msgid "Called to initialize the adapter." +msgstr "" + +msgid "Options is an Object, where:" +msgstr "" + +msgid "useNonce - Adds a cryptographic nonce to verify that the authentication response matches the request (default is `true`)." +msgstr "" + +msgid "onLoad - Specifies an action to do on load. Supported values are `login-required` or `check-sso`." +msgstr "" + +msgid "silentCheckSsoRedirectUri - Set the redirect uri for silent authentication check if onLoad is set to 'check-sso'." +msgstr "" + +msgid "silentCheckSsoFallback - Enables fall back to regular `check-sso` when _silent_ `check-sso` is not supported by the browser (default is `true`)." +msgstr "" + +msgid "token - Set an initial value for the token." +msgstr "" + +msgid "refreshToken - Set an initial value for the refresh token." +msgstr "" + +msgid "idToken - Set an initial value for the id token (only together with token or refreshToken)." +msgstr "" + +msgid "scope - Set the default scope parameter to the {project_name} login endpoint. Use a space-delimited list of scopes. Those typically reference link:{adminguide_link}#_client_scopes[Client scopes] defined on a particular client. Note that the scope `openid` will always be added to the list of scopes by the adapter. For example, if you enter the scope options `address phone`, then the request to {project_name} will contain the scope parameter `scope=openid address phone`. Note that the default scope specified here is overwritten if the `login()` options specify scope explicitly." +msgstr "" + +msgid "timeSkew - Set an initial value for skew between local time and {project_name} server in seconds (only together with token or refreshToken)." +msgstr "" + +msgid "checkLoginIframe - Set to enable/disable monitoring login state (default is `true`)." +msgstr "" + +msgid "checkLoginIframeInterval - Set the interval to check login state (default is 5 seconds)." +msgstr "" + +msgid "responseMode - Set the OpenID Connect response mode send to {project_name} server at login request. Valid values are `query` or `fragment`. Default value is `fragment`, which means that after successful authentication will {project_name} redirect to JavaScript application with OpenID Connect parameters added in URL fragment. This is generally safer and recommended over `query`." +msgstr "" + +msgid "flow - Set the OpenID Connect flow. Valid values are `standard`, `implicit` or `hybrid`." +msgstr "" + +msgid "enableLogging - Enables logging messages from Keycloak to the console (default is `false`)." +msgstr "" + +msgid "pkceMethod - The method for Proof Key Code Exchange (https://datatracker.ietf.org/doc/html/rfc7636[PKCE]) to use. Configuring this value enables the PKCE mechanism. Available options:" +msgstr "" + +msgid "\"S256\" - The SHA256 based PKCE method" +msgstr "" + +msgid "acrValues - Generates the `acr_values` parameter which refers to authentication context class reference and allows clients to declare the required assurance level requirements, e.g. authentication mechanisms. See https://openid.net/specs/openid-connect-modrna-authentication-1_0.html#acr_values[Section 4. acr_values request values and level of assurance in OpenID Connect MODRNA Authentication Profile 1.0]." +msgstr "" + +msgid "messageReceiveTimeout - Set a timeout in milliseconds for waiting for message responses from the Keycloak server. This is used, for example, when waiting for a message during 3rd party cookies check. The default value is 10000." +msgstr "" + +msgid "locale - When onLoad is 'login-required', sets the 'ui_locales' query param in compliance with https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest[section 3.1.2.1 of the OIDC 1.0 specification]." +msgstr "" + +msgid "Returns a promise that resolves when initialization completes." +msgstr "" + +msgid "*login(options)*" +msgstr "" + +msgid "Redirects to login form." +msgstr "" + +msgid "Options is an optional Object, where:" +msgstr "" + +msgid "redirectUri - Specifies the uri to redirect to after login." +msgstr "" + +msgid "prompt - This parameter allows to slightly customize the login flow on the {project_name} server side. For example enforce displaying the login screen in case of value `login`. See link:{adapterguide_link}#_params_forwarding[Parameters Forwarding Section] for the details and all the possible values of the `prompt` parameter." +msgstr "" + +msgid "maxAge - Used just if user is already authenticated. Specifies maximum time since the authentication of user happened. If user is already authenticated for longer time than `maxAge`, the SSO is ignored and he will need to re-authenticate again." +msgstr "" + +msgid "loginHint - Used to pre-fill the username/email field on the login form." +msgstr "" + +msgid "scope - Override the scope configured in `init` with a different value for this specific login." +msgstr "" + +msgid "idpHint - Used to tell {project_name} to skip showing the login page and automatically redirect to the specified identity provider instead. More info in the link:{adminguide_link}#_client_suggested_idp[Identity Provider documentation]." +msgstr "" + +msgid "acr - Contains the information about `acr` claim, which will be sent inside `claims` parameter to the {project_name} server. Typical usage is for step-up authentication. Example of use `{ values: [\"silver\", \"gold\"], essential: true }`. See OpenID Connect specification and link:{adminguide_link}#_step-up-flow[Step-up authentication documentation] for more details." +msgstr "" + +msgid "action - If value is `register` then user is redirected to registration page, if the value is `UPDATE_PASSWORD` then the user will be redirected to the reset password page (if not authenticated will send user to login page first and redirect after authenticated), otherwise to login page." +msgstr "" + +msgid "locale - Sets the 'ui_locales' query param in compliance with https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest[section 3.1.2.1 of the OIDC 1.0 specification]." +msgstr "" + +msgid "cordovaOptions - Specifies the arguments that are passed to the Cordova in-app-browser (if applicable). Options `hidden` and `location` are not affected by these arguments. All available options are defined at https://cordova.apache.org/docs/en/latest/reference/cordova-plugin-inappbrowser/. Example of use: `{ zoom: \"no\", hardwareback: \"yes\" }`;" +msgstr "" + +msgid "*createLoginUrl(options)*" +msgstr "" + +msgid "Returns the URL to login form." +msgstr "" + +msgid "Options is an optional Object, which supports same options as the function `login` ." +msgstr "" + +msgid "*logout(options)*" +msgstr "" + +msgid "Redirects to logout." +msgstr "" + +msgid "redirectUri - Specifies the uri to redirect to after logout." +msgstr "" + +msgid "*createLogoutUrl(options)*" +msgstr "" + +msgid "Returns the URL to log out the user." +msgstr "" + +msgid "*register(options)*" +msgstr "" + +msgid "Redirects to registration form. Shortcut for login with option action = 'register'" +msgstr "" + +msgid "Options are same as for the login method but 'action' is set to 'register'" +msgstr "" + +msgid "*createRegisterUrl(options)*" +msgstr "" + +msgid "Returns the url to registration page. Shortcut for createLoginUrl with option action = 'register'" +msgstr "" + +msgid "Options are same as for the createLoginUrl method but 'action' is set to 'register'" +msgstr "" + +msgid "*accountManagement()*" +msgstr "" + +msgid "Redirects to the Account Management Console." +msgstr "" + +msgid "*createAccountUrl(options)*" +msgstr "" + +msgid "Returns the URL to the Account Management Console." +msgstr "" + +msgid "redirectUri - Specifies the uri to redirect to when redirecting back to the application." +msgstr "" + +msgid "*hasRealmRole(role)*" +msgstr "" + +msgid "Returns true if the token has the given realm role." +msgstr "" + +msgid "*hasResourceRole(role, resource)*" +msgstr "" + +msgid "Returns true if the token has the given role for the resource (resource is optional, if not specified clientId is used)." +msgstr "" + +msgid "*loadUserProfile()*" +msgstr "" + +msgid "Loads the users profile." +msgstr "" + +msgid "Returns a promise that resolves with the profile." +msgstr "" + +msgid "" +"try {\n" +" const profile = await keycloak.loadUserProfile();\n" +" console.log('Retrieved user profile:', profile);\n" +"} catch (error) {\n" +" console.error('Failed to load user profile:', error);\n" +"}" +msgstr "" + +msgid "*isTokenExpired(minValidity)*" +msgstr "" + +msgid "Returns true if the token has less than minValidity seconds left before it expires (minValidity is optional, if not specified 0 is used)." +msgstr "" + +msgid "*updateToken(minValidity)*" +msgstr "" + +msgid "If the token expires within minValidity seconds (minValidity is optional, if not specified 5 is used) the token is refreshed. If -1 is passed as the minValidity, the token will be forcibly refreshed. If the session status iframe is enabled, the session status is also checked." +msgstr "" + +msgid "Returns a promise that resolves with a boolean indicating whether or not the token has been refreshed." +msgstr "" + +msgid "" +"try {\n" +" const refreshed = await keycloak.updateToken(5);\n" +" console.log(refreshed ? 'Token was refreshed' : 'Token is still valid');\n" +"} catch (error) {\n" +" console.error('Failed to refresh the token:', error);\n" +"}" +msgstr "" + +msgid "*clearToken()*" +msgstr "" + +msgid "Clear authentication state, including tokens. This can be useful if application has detected the session was expired, for example if updating token fails." +msgstr "" + +msgid "Invoking this results in onAuthLogout callback listener being invoked." +msgstr "" + +msgid "Callback Events" +msgstr "" + +msgid "The adapter supports setting callback listeners for certain events. Keep in mind that these have to be set before the call to the `init()` method." +msgstr "" + +msgid "keycloak.onAuthSuccess = () => console.log('Authenticated!');" +msgstr "" + +msgid "The available events are:" +msgstr "" + +msgid "*onReady(authenticated)* - Called when the adapter is initialized." +msgstr "" + +msgid "*onAuthSuccess* - Called when a user is successfully authenticated." +msgstr "" + +msgid "*onAuthError* - Called if there was an error during authentication." +msgstr "" + +msgid "*onAuthRefreshSuccess* - Called when the token is refreshed." +msgstr "" + +msgid "*onAuthRefreshError* - Called if there was an error while trying to refresh the token." +msgstr "" + +msgid "*onAuthLogout* - Called if the user is logged out (will only be called if the session status iframe is enabled, or in Cordova mode)." +msgstr "" + +msgid "*onTokenExpired* - Called when the access token is expired. If a refresh token is available the token can be refreshed with updateToken, or in cases where it is not (that is, with implicit flow) you can redirect to the login screen to obtain a new access token." +msgstr "" + +msgid "{project_name} Node.js adapter" +msgstr "" + +msgid "{project_name} provides a Node.js adapter built on top of https://github.com/senchalabs/connect[Connect] to protect server-side JavaScript apps - the goal was to be flexible enough to integrate with frameworks like https://expressjs.com/[Express.js]." +msgstr "" + +msgid "The library can be downloaded directly from https://www.npmjs.com/package/keycloak-connect[ {project_name} organization] and the source is available at https://github.com/keycloak/keycloak-nodejs-connect[GitHub]." +msgstr "" + +msgid "To use the Node.js adapter, first you must create a client for your application in the {project_name} Admin Console. The adapter supports public, confidential, and bearer-only access type. Which one to choose depends on the use-case scenario." +msgstr "" + +msgid "Once the client is created click the `Installation` tab, select `{project_name} OIDC JSON` for `Format Option`, and then click `Download`. The downloaded `keycloak.json` file should be at the root folder of your project." +msgstr "" + +msgid "Assuming you've already installed https://nodejs.org[Node.js], create a folder for your application:" +msgstr "" + +msgid "mkdir myapp && cd myapp" +msgstr "" + +msgid "Use `npm init` command to create a `package.json` for your application. Now add the {project_name} connect adapter in the dependencies list:" +msgstr "" + +msgid "" +" \"dependencies\": {\n" +" \"keycloak-connect\": \"{project_versionNpm}\"\n" +" }" +msgstr "" + +msgid "Instantiate a Keycloak class" +msgstr "" + +msgid "The `Keycloak` class provides a central point for configuration and integration with your application. The simplest creation involves no arguments." +msgstr "" + +msgid "In the root directory of your project create a file called `server.js` and add the following code:" +msgstr "" + +msgid "" +" const session = require('express-session');\n" +" const Keycloak = require('keycloak-connect');\n" +"\n" +" const memoryStore = new session.MemoryStore();\n" +" const keycloak = new Keycloak({ store: memoryStore });" +msgstr "" + +msgid "Install the `express-session` dependency:" +msgstr "" + +msgid " npm install express-session" +msgstr "" + +msgid "To start the `server.js` script, add the following command in the 'scripts' section of the `package.json`:" +msgstr "" + +msgid "" +" \"scripts\": {\n" +" \"test\": \"echo \\\"Error: no test specified\\\" && exit 1\",\n" +" \"start\": \"node server.js\"\n" +" }," +msgstr "" + +msgid "Now we have the ability to run our server with following command:" +msgstr "" + +msgid " npm run start" +msgstr "" + +msgid "By default, this will locate a file named `keycloak.json` alongside the main executable of your application, in our case on the root folder, to initialize {project_name} specific settings such as public key, realm name, various URLs." +msgstr "" + +msgid "In that case a {project_name} deployment is necessary to access {project_name} admin console." +msgstr "" + +msgid "Please visit links on how to deploy a {project_name} admin console with https://www.keycloak.org/getting-started/getting-started-podman[Podman] or https://www.keycloak.org/getting-started/getting-started-docker[Docker]" +msgstr "" + +msgid "Now we are ready to obtain the `keycloak.json` file by visiting the {project_name} Admin Console -> clients (left sidebar) -> choose your client -> Installation -> Format Option -> Keycloak OIDC JSON -> Download" +msgstr "" + +msgid "Paste the downloaded file on the root folder of our project." +msgstr "" + +msgid "Instantiation with this method results in all the reasonable defaults being used. As alternative, it's also possible to provide a configuration object, rather than the `keycloak.json` file:" +msgstr "" + +msgid "" +" const kcConfig = {\n" +" clientId: 'myclient',\n" +" bearerOnly: true,\n" +" serverUrl: 'http://localhost:8080{kc_base_path}',\n" +" realm: 'myrealm',\n" +" realmPublicKey: 'MIIBIjANB...'\n" +" };\n" +"\n" +" const keycloak = new Keycloak({ store: memoryStore }, kcConfig);" +msgstr "" + +msgid "Applications can also redirect users to their preferred identity provider by using:" +msgstr "" + +msgid " const keycloak = new Keycloak({ store: memoryStore, idpHint: myIdP }, kcConfig);" +msgstr "" + +msgid "Configuring a web session store" +msgstr "" + +msgid "If you want to use web sessions to manage server-side state for authentication, you need to initialize the `Keycloak(...)` with at least a `store` parameter, passing in the actual session store that `express-session` is using." +msgstr "" + +msgid "" +" const session = require('express-session');\n" +" const memoryStore = new session.MemoryStore();\n" +"\n" +" // Configure session\n" +" app.use(\n" +" session({\n" +" secret: 'mySecret',\n" +" resave: false,\n" +" saveUninitialized: true,\n" +" store: memoryStore,\n" +" })\n" +" );\n" +"\n" +" const keycloak = new Keycloak({ store: memoryStore });" +msgstr "" + +msgid "Passing a custom scope value" +msgstr "" + +msgid "By default, the scope value `openid` is passed as a query parameter to {project_name}'s login URL, but you can add an additional custom value:" +msgstr "" + +msgid " const keycloak = new Keycloak({ scope: 'offline_access' });" +msgstr "" + +msgid "Installing middleware" +msgstr "" + +msgid "Once instantiated, install the middleware into your connect-capable app:" +msgstr "" + +msgid "In order to do so, first we have to install Express:" +msgstr "" + +msgid " npm install express" +msgstr "" + +msgid "then require Express in our project as outlined below:" +msgstr "" + +msgid "" +" const express = require('express');\n" +" const app = express();" +msgstr "" + +msgid "and configure Keycloak middleware in Express, by adding at the code below:" +msgstr "" + +msgid " app.use( keycloak.middleware() );" +msgstr "" + +msgid "Last but not least, let's set up our server to listen for HTTP requests on port 3000 by adding the following code to `main.js`:" +msgstr "" + +msgid "" +" app.listen(3000, function () {\n" +" console.log('App listening on port 3000');\n" +" });" +msgstr "" + +msgid "Configuration for proxies" +msgstr "" + +msgid "If the application is running behind a proxy that terminates an SSL connection Express must be configured per the link:https://expressjs.com/en/guide/behind-proxies.html[express behind proxies] guide. Using an incorrect proxy configuration can result in invalid redirect URIs being generated." +msgstr "" + +msgid "Example configuration:" +msgstr "" + +msgid "" +" const app = express();\n" +"\n" +" app.set( 'trust proxy', true );\n" +"\n" +" app.use( keycloak.middleware() );" +msgstr "" + +msgid "Protecting resources" +msgstr "" + +msgid "Simple authentication" +msgstr "" + +msgid "To enforce that a user must be authenticated before accessing a resource, simply use a no-argument version of `keycloak.protect()`:" +msgstr "" + +msgid " app.get( '/complain', keycloak.protect(), complaintHandler );" +msgstr "" + +msgid "Role-based authorization" +msgstr "" + +msgid "To secure a resource with an application role for the current app:" +msgstr "" + +msgid " app.get( '/special', keycloak.protect('special'), specialHandler );" +msgstr "" + +msgid "To secure a resource with an application role for a *different* app:" +msgstr "" + +msgid " app.get( '/extra-special', keycloak.protect('other-app:special'), extraSpecialHandler );" +msgstr "" + +msgid "To secure a resource with a realm role:" +msgstr "" + +msgid " app.get( '/admin', keycloak.protect( 'realm:admin' ), adminHandler );" +msgstr "" + +msgid "Resource-Based Authorization" +msgstr "" + +msgid "Resource-Based Authorization allows you to protect resources, and their specific methods/actions,**** based on a set of policies defined in Keycloak, thus externalizing authorization from your application. This is achieved by exposing a `keycloak.enforcer` method which you can use to protect resources.*" +msgstr "" + +msgid " app.get('/apis/me', keycloak.enforcer('user:profile'), userProfileHandler);" +msgstr "" + +msgid "The `keycloak-enforcer` method operates in two modes, depending on the value of the `response_mode` configuration option." +msgstr "" + +msgid " app.get('/apis/me', keycloak.enforcer('user:profile', {response_mode: 'token'}), userProfileHandler);" +msgstr "" + +msgid "If `response_mode` is set to `token`, permissions are obtained from the server on behalf of the subject represented by the bearer token that was sent to your application. In this case, a new access token is issued by Keycloak with the permissions granted by the server. If the server did not respond with a token with the expected permissions, the request is denied. When using this mode, you should be able to obtain the token from the request as follows:" +msgstr "" + +msgid "" +" app.get('/apis/me', keycloak.enforcer('user:profile', {response_mode: 'token'}), function (req, res) {\n" +" const token = req.kauth.grant.access_token.content;\n" +" const permissions = token.authorization ? token.authorization.permissions : undefined;\n" +"\n" +" // show user profile\n" +" });" +msgstr "" + +msgid "Prefer this mode when your application is using sessions and you want to cache previous decisions from the server, as well automatically handle refresh tokens. This mode is especially useful for applications acting as a client and resource server." +msgstr "" + +msgid "If `response_mode` is set to `permissions` (default mode), the server only returns the list of granted permissions, without issuing a new access token. In addition to not issuing a new token, this method exposes the permissions granted by the server through the `request` as follows:" +msgstr "" + +msgid "" +" app.get('/apis/me', keycloak.enforcer('user:profile', {response_mode: 'permissions'}), function (req, res) {\n" +" const permissions = req.permissions;\n" +"\n" +" // show user profile\n" +" });" +msgstr "" + +msgid "Regardless of the `response_mode` in use, the `keycloak.enforcer` method will first try to check the permissions within the bearer token that was sent to your application. If the bearer token already carries the expected permissions, there is no need to interact with the server to obtain a decision. This is specially useful when your clients are capable of obtaining access tokens from the server with the expected permissions before accessing a protected resource, so they can use some capabilities provided by Keycloak Authorization Services such as incremental authorization and avoid additional requests to the server when `keycloak.enforcer` is enforcing access to the resource." +msgstr "" + +msgid "By default, the policy enforcer will use the `client_id` defined to the application (for instance, via `keycloak.json`) to reference a client in Keycloak that supports Keycloak Authorization Services. In this case, the client can not be public given that it is actually a resource server." +msgstr "" + +msgid "If your application is acting as both a public client(frontend) and resource server(backend), you can use the following configuration to reference a different client in Keycloak with the policies that you want to enforce:" +msgstr "" + +msgid " keycloak.enforcer('user:profile', {resource_server_id: 'my-apiserver'})" +msgstr "" + +msgid "It is recommended to use distinct clients in Keycloak to represent your frontend and backend." +msgstr "" + +msgid "If the application you are protecting is enabled with Keycloak authorization services and you have defined client credentials in `keycloak.json`, you can push additional claims to the server and make them available to your policies in order to make decisions. For that, you can define a `claims` configuration option which expects a `function` that returns a JSON with the claims you want to push:" +msgstr "" + +msgid "" +" app.get('/protected/resource', keycloak.enforcer(['resource:view', 'resource:write'], {\n" +" claims: function(request) {\n" +" return {\n" +" \"http.uri\": [\"/protected/resource\"],\n" +" \"user.agent\": // get user agent from request\n" +" }\n" +" }\n" +" }), function (req, res) {\n" +" // access granted" +msgstr "" + +msgid "For more details about how to configure Keycloak to protected your application resources, please take a look at the link:{authorizationguide_link}[{authorizationguide_name}]." +msgstr "" + +msgid "Advanced authorization" +msgstr "" + +msgid "To secure resources based on parts of the URL itself, assuming a role exists for each section:" +msgstr "" + +msgid "" +" function protectBySection(token, request) {\n" +" return token.hasRole( request.params.section );\n" +" }\n" +"\n" +" app.get( '/:section/:page', keycloak.protect( protectBySection ), sectionHandler );" +msgstr "" + +msgid "Advanced Login Configuration:" +msgstr "" + +msgid "By default, all unauthorized requests will be redirected to the {project_name} login page unless your client is bearer-only. However, a confidential or public client may host both browsable and API endpoints. To prevent redirects on unauthenticated API requests and instead return an HTTP 401, you can override the redirectToLogin function." +msgstr "" + +msgid "For example, this override checks if the URL contains /api/ and disables login redirects:" +msgstr "" + +msgid "" +" Keycloak.prototype.redirectToLogin = function(req) {\n" +" const apiReqMatcher = /\\/api\\//i;\n" +" return !apiReqMatcher.test(req.originalUrl || req.url);\n" +" };" +msgstr "" + +msgid "Additional URLs" +msgstr "" + +msgid "Explicit user-triggered logout" +msgstr "" + +msgid "By default, the middleware catches calls to `/logout` to send the user through a {project_name}-centric logout workflow. This can be changed by specifying a `logout` configuration parameter to the `middleware()` call:" +msgstr "" + +msgid " app.use( keycloak.middleware( { logout: '/logoff' } ));" +msgstr "" + +msgid "When the user-triggered logout is invoked a query parameter `redirect_url` can be passed:" +msgstr "" + +msgid "https://example.com/logoff?redirect_url=https%3A%2F%2Fexample.com%3A3000%2Flogged%2Fout" +msgstr "" + +msgid "This parameter is then used as the redirect url of the OIDC logout endpoint and the user will be redirected to `\\https://example.com/logged/out`." +msgstr "" + +msgid "{project_name} Admin Callbacks" +msgstr "" + +msgid "Also, the middleware supports callbacks from the {project_name} console to log out a single session or all sessions. By default, these type of admin callbacks occur relative to the root URL of `/` but can be changed by providing an `admin` parameter to the `middleware()` call:" +msgstr "" + +msgid " app.use( keycloak.middleware( { admin: '/callbacks' } );" +msgstr "" + +msgid "Complete example" +msgstr "" + +msgid "A complete example using the Node.js adapter usage can be found in {quickstartRepo_link}/tree/latest/nodejs/resource-server[Keycloak quickstarts for Node.js]" +msgstr "" + +msgid "mod_auth_openidc Apache HTTPD Module" +msgstr "" + +msgid "The https://github.com/OpenIDC/mod_auth_openidc[mod_auth_openidc] is an Apache HTTP plugin for OpenID Connect. If your language/environment supports using Apache HTTPD as a proxy, then you can use _mod_auth_openidc_ to secure your web application with OpenID Connect. Configuration of this module is beyond the scope of this document. Please see the _mod_auth_openidc_ GitHub repo for more details on configuration." +msgstr "" + +msgid "To configure _mod_auth_openidc_ you'll need" +msgstr "" + +msgid "The client_id." +msgstr "" + +msgid "The client_secret." +msgstr "" + +msgid "The redirect_uri to your application." +msgstr "" + +msgid "The {project_name} openid-configuration url" +msgstr "" + +msgid "_mod_auth_openidc_ specific Apache HTTPD module config." +msgstr "" + +msgid "An example configuration would look like the following." +msgstr "" + +msgid "" +"LoadModule auth_openidc_module modules/mod_auth_openidc.so\n" +"\n" +"ServerName ${HOSTIP}\n" +"\n" +"\n" +"\n" +" ServerAdmin webmaster@localhost\n" +" DocumentRoot /var/www/html\n" +"\n" +" #this is required by mod_auth_openidc\n" +" OIDCCryptoPassphrase a-random-secret-used-by-apache-oidc-and-balancer\n" +"\n" +" OIDCProviderMetadataURL ${KC_ADDR}{kc_realms_path}/${KC_REALM}/.well-known/openid-configuration\n" +"\n" +" OIDCClientID ${CLIENT_ID}\n" +" OIDCClientSecret ${CLIENT_SECRET}\n" +" OIDCRedirectURI http://${HOSTIP}/${CLIENT_APP_NAME}/redirect_uri\n" +"\n" +" # maps the preferred_username claim to the REMOTE_USER environment variable\n" +" OIDCRemoteUserClaim preferred_username\n" +"\n" +" \n" +" AuthType openid-connect\n" +" Require valid-user\n" +" \n" +"" +msgstr "" + +msgid "Further information on how to configure mod_auth_openidc can be found on the https://github.com/OpenIDC/mod_auth_openidc[mod_auth_openidc] project page." +msgstr "" + +msgid "Financial-grade API (FAPI) Support" +msgstr "" + +msgid "{project_name} makes it easier for administrators to make sure that their clients are compliant with these specifications:" +msgstr "" + +msgid "https://openid.net/specs/openid-financial-api-part-1-1_0.html[Financial-grade API Security Profile 1.0 - Part 1: Baseline]" +msgstr "" + +msgid "https://openid.net/specs/openid-financial-api-part-2-1_0.html[Financial-grade API Security Profile 1.0 - Part 2: Advanced]" +msgstr "" + +msgid "https://openid.net/specs/openid-financial-api-ciba-ID1.html[Financial-grade API: Client Initiated Backchannel Authentication Profile] (FAPI CIBA)" +msgstr "" + +msgid "https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html[FAPI 2.0 Security Profile (Draft)]" +msgstr "" + +msgid "https://openid.bitbucket.io/fapi/fapi-2_0-message-signing.html[FAPI 2.0 Message Signing (Draft)]" +msgstr "" + +msgid "This compliance means that the {project_name} server will verify the requirements for the authorization server, which are mentioned in the specifications. {project_name} adapters do not have any specific support for the FAPI, hence the required validations on the client (application) side may need to be still done manually or through some other third-party solutions." +msgstr "" + +msgid "FAPI client profiles" +msgstr "" + +msgid "To make sure that your clients are FAPI compliant, you can configure Client Policies in your realm as described in the link:{adminguide_link}#_client_policies[{adminguide_name}] and link them to the global client profiles for FAPI support, which are automatically available in each realm. You can use either `fapi-1-baseline` or `fapi-1-advanced` profile based on which FAPI profile you need your clients to conform with. You can use also profiles `fapi-2-security-profile` or `fapi-2-message-signing` for the compliance with FAPI 2 Draft specifications." +msgstr "" + +msgid "In case you want to use link:{adminguide_link}#_oidc_clients[Pushed Authorization Request (PAR)], it is recommended that your client use both the `fapi-1-baseline` profile and `fapi-1-advanced` for PAR requests. Specifically, the `fapi-1-baseline` profile contains `pkce-enforcer` executor, which makes sure that client use PKCE with secured S256 algorithm. This is not required for FAPI Advanced clients unless they use PAR requests." +msgstr "" + +msgid "In case you want to use <<_backchannel_authentication_endpoint,CIBA>> in a FAPI compliant way, make sure that your clients use both `fapi-1-advanced` and `fapi-ciba` client profiles. There is a need to use the `fapi-1-advanced` profile, or other client profile containing the requested executors, as the `fapi-ciba` profile contains just CIBA-specific executors. When enforcing the requirements of the FAPI CIBA specification, there is a need for more requirements, such as enforcement of confidential clients or certificate-bound access tokens." +msgstr "" + +msgid "Open Finance Brasil Financial-grade API Security Profile" +msgstr "" + +msgid "{project_name} is compliant with the https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/82083996/EN+Open+Finance+Brasil+Financial-grade+API+Security+Profile+1.0+Implementers+Draft+3[Open Finance Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3]. This one is stricter in some requirements than the <<_fapi-support,FAPI 1 Advanced>> specification and hence it may be needed to configure link:{adminguide_link}#_client_policies[Client Policies] in the more strict way to enforce some of the requirements. Especially:" +msgstr "" + +msgid "If your client does not use PAR, make sure that it uses encrypted OIDC request objects. This can be achieved by using a client profile with the `secure-request-object` executor configured with `Encryption Required` enabled." +msgstr "" + +msgid "Make sure that for JWS, the client uses the `PS256` algorithm. For JWE, the client should use the `RSA-OAEP` with `A256GCM`. This may need to be set in all the link:{adminguide_link}#_oidc_clients[Client Settings] where these algorithms are applicable." +msgstr "" + +msgid "TLS considerations" +msgstr "" + +msgid "As confidential information is being exchanged, all interactions shall be encrypted with TLS (HTTPS). Moreover, there are some requirements in the FAPI specification for the cipher suites and TLS protocol versions used. To match these requirements, you can consider configure allowed ciphers. This configuration can be done by setting the `https-protocols` and `https-cipher-suites` options. {project_name} uses `TLSv1.3` by default and hence it is possibly not needed to change the default settings. However it may be needed to adjust ciphers if you need to fall back to lower TLS version for some reason. For more details, see https://www.keycloak.org/server/enabletls[Configuring TLS] {section}." +msgstr "" + +msgid "Recommendations" +msgstr "" + +msgid "This section describes some recommendations when securing your applications with {project_name}." +msgstr "" + +msgid "Validating access tokens" +msgstr "" + +msgid "If you need to manually validate access tokens issued by {project_name}, you can invoke the <<_token_introspection_endpoint,Introspection Endpoint>>. The downside to this approach is that you have to make a network invocation to the {project_name} server. This can be slow and possibly overload the server if you have too many validation requests going on at the same time. {project_name} issued access tokens are https://datatracker.ietf.org/doc/html/rfc7519[JSON Web Tokens (JWT)] digitally signed and encoded using https://datatracker.ietf.org/doc/html/rfc7515[JSON Web Signature (JWS)]. Because they are encoded in this way, you can locally validate access tokens using the public key of the issuing realm. You can either hard code the realm's public key in your validation code, or lookup and cache the public key using the <<_certificate_endpoint, certificate endpoint>> with the Key ID (KID) embedded within the JWS. Depending on what language you code in, many third party libraries exist and they can help you with JWS validation." +msgstr "" + +msgid "Redirect URIs" +msgstr "" + +msgid "When using the redirect based flows, be sure to use valid redirect uris for your clients. The redirect uris should be as specific as possible. This especially applies to client-side (public clients) applications. Failing to do so could result in:" +msgstr "" + +msgid "Open redirects - this can allow attackers to create spoof links that looks like they are coming from your domain" +msgstr "" + +msgid "Unauthorized entry - when users are already authenticated with {project_name}, an attacker can use a public client where redirect uris have not be configured correctly to gain access by redirecting the user without the users knowledge" +msgstr "" + +msgid "In production for web applications always use `https` for all redirect URIs. Do not allow redirects to http." +msgstr "" + +msgid "A few special redirect URIs also exist:" +msgstr "" + +msgid "`$$http://127.0.0.1$$`" +msgstr "" + +msgid "This redirect URI is useful for native applications and allows the native application to create a web server on a random port that can be used to obtain the authorization code. This redirect uri allows any port. Note that per https://datatracker.ietf.org/doc/html/rfc8252#section-8.3[OAuth 2.0 for Native Apps], the use of `localhost` is *not* recommended and the IP literal `127.0.0.1` should be used instead." +msgstr "" + +msgid "`urn:ietf:wg:oauth:2.0:oob`" +msgstr "" + +msgid "If you cannot start a web server in the client (or a browser is not available), you can use the special `urn:ietf:wg:oauth:2.0:oob` redirect uri. When this redirect uri is used, {project_name} displays a page with the code in the title and in a box on the page. The application can either detect that the browser title has changed, or the user can copy and paste the code manually to the application. With this redirect uri, a user can use a different device to obtain a code to paste back to the application." +msgstr "" + +msgid "Using SAML to secure applications and services" +msgstr "" + +msgid "This section describes how you can secure applications and services with SAML using either {project_name} client adapters or generic SAML provider libraries." +msgstr "" + +msgid "General Adapter Config" +msgstr "" + +msgid "Each SAML client adapter supported by {project_name} can be configured by a simple XML text file. This is what one might look like:" +msgstr "" + +msgid "" +"\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"" +msgstr "" + +msgid "Some of these configuration switches may be adapter specific and some are common across all adapters. For Java adapters you can use `${...}` enclosure as System property replacement. For example `${jboss.server.config.dir}`." +msgstr "" + +msgid "SP element" +msgstr "" + +msgid "Here is the explanation of the SP element attributes:" +msgstr "" + +msgid "" +"\n" +"\n" +"...\n" +"" +msgstr "" + +msgid "entityID" +msgstr "" + +msgid "This is the identifier for this client. The IdP needs this value to determine who the client is that is communicating with it. This setting is _REQUIRED_." +msgstr "" + +msgid "sslPolicy" +msgstr "" + +msgid "This is the SSL policy the adapter will enforce. Valid values are: `ALL`, `EXTERNAL`, and `NONE`. For `ALL`, all requests must come in via HTTPS. For `EXTERNAL`, only non-private IP addresses must come over the wire via HTTPS. For `NONE`, no requests are required to come over via HTTPS. This setting is _OPTIONAL_. Default value is `EXTERNAL`." +msgstr "" + +msgid "nameIDPolicyFormat" +msgstr "" + +msgid "SAML clients can request a specific NameID Subject format. Fill in this value if you want a specific format. It must be a standard SAML format identifier: `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`. This setting is _OPTIONAL_. By default, no special format is requested." +msgstr "" + +msgid "forceAuthentication" +msgstr "" + +msgid "SAML clients can request that a user is re-authenticated even if they are already logged in at the IdP. Set this to `true` to enable. This setting is _OPTIONAL_. Default value is `false`." +msgstr "" + +msgid "isPassive" +msgstr "" + +msgid "SAML clients can request that a user is never asked to authenticate even if they are not logged in at the IdP. Set this to `true` if you want this. Do not use together with `forceAuthentication` as they are opposite. This setting is _OPTIONAL_. Default value is `false`." +msgstr "" + +msgid "turnOffChangeSessionIdOnLogin" +msgstr "" + +msgid "The session ID is changed by default on a successful login on some platforms to plug a security attack vector. Change this to `true` to disable this. It is recommended you do not turn it off. Default value is `false`." +msgstr "" + +msgid "autodetectBearerOnly" +msgstr "" + +msgid "logoutPage" +msgstr "" + +msgid "This sets the page to display after logout. If the page is a full URL, such as `http://web.example.com/logout.html`, the user is redirected after logout to that page using the HTTP `302` status code. If a link without scheme part is specified, such as `/logout.jsp`, the page is displayed after logout, _regardless of whether it lies in a protected area according to `security-constraint` declarations in web.xml_, and the page is resolved relative to the deployment context root." +msgstr "" + +msgid "keepDOMAssertion" +msgstr "" + +msgid "This attribute should be set to __true__ to make the adapter store the DOM representation of the assertion in its original form inside the `SamlPrincipal` associated to the request. The assertion document can be retrieved using the method `getAssertionDocument` inside the principal. This is specially useful when re-playing a signed assertion. The returned document is the one that was generated parsing the SAML response received by the {project_name} server. This setting is _OPTIONAL_ and its default value is __false__ (the document is not saved inside the principal)." +msgstr "" + +msgid "Service Provider keys and key elements" +msgstr "" + +msgid "If the IdP requires that the client application (or SP) sign all of its requests and/or if the IdP will encrypt assertions, you must define the keys used to do this. For client-signed documents you must define both the private and public key or certificate that is used to sign documents. For encryption, you only have to define the private key that is used to decrypt it." +msgstr "" + +msgid "There are two ways to describe your keys. They can be stored within a Java KeyStore or you can copy/paste the keys directly within `keycloak-saml.xml` in the PEM format." +msgstr "" + +msgid "" +"\n" +" \n" +" \n" +" ...\n" +" \n" +" " +msgstr "" + +msgid "The `Key` element has two optional attributes `signing` and `encryption`. When set to true these tell the adapter what the key will be used for. If both attributes are set to true, then the key will be used for both signing documents and decrypting encrypted assertions. You must set at least one of these attributes to true." +msgstr "" + +msgid "KeyStore element" +msgstr "" + +msgid "Within the `Key` element you can load your keys and certificates from a Java Keystore. This is declared within a `KeyStore` element." +msgstr "" + +msgid "" +"\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" " +msgstr "" + +msgid "Here are the XML config attributes that are defined with the `KeyStore` element." +msgstr "" + +msgid "file" +msgstr "" + +msgid "File path to the key store. This option is _OPTIONAL_. The file or resource attribute must be set." +msgstr "" + +msgid "WAR resource path to the KeyStore. This is a path used in method call to ServletContext.getResourceAsStream(). This option is _OPTIONAL_. The file or resource attribute must be set." +msgstr "" + +msgid "password" +msgstr "" + +msgid "The password of the KeyStore. This option is _REQUIRED_." +msgstr "" + +msgid "If you are defining keys that the SP will use to sign document, you must also specify references to your private keys and certificates within the Java KeyStore. The `PrivateKey` and `Certificate` elements in the above example define an `alias` that points to the key or cert within the keystore. Keystores require an additional password to access private keys. In the `PrivateKey` element you must define this password within a `password` attribute." +msgstr "" + +msgid "Key PEMS" +msgstr "" + +msgid "Within the `Key` element you declare your keys and certificates directly using the sub elements `PrivateKeyPem`, `PublicKeyPem`, and `CertificatePem`. The values contained in these elements must conform to the PEM key format. You usually use this option if you are generating keys using `openssl` or similar command line tool." +msgstr "" + +msgid "" +"\n" +" \n" +" \n" +" 2341251234AB31234==231BB998311222423522334\n" +" \n" +" \n" +" 211111341251234AB31234==231BB998311222423522334\n" +" \n" +" \n" +"" +msgstr "" + +msgid "SP PrincipalNameMapping element" +msgstr "" + +msgid "This element is optional. When creating a Java Principal object that you obtain from methods such as `HttpServletRequest.getUserPrincipal()`, you can define what name is returned by the `Principal.getName()` method." +msgstr "" + +msgid "" +"\n" +" \n" +"\n" +"\n" +"\n" +" \n" +"\n" +msgstr "" + +msgid "The `policy` attribute defines the policy used to populate this value. The possible values for this attribute are:" +msgstr "" + +msgid "FROM_NAME_ID" +msgstr "" + +msgid "This policy just uses whatever the SAML subject value is. This is the default setting" +msgstr "" + +msgid "FROM_ATTRIBUTE" +msgstr "" + +msgid "This will pull the value from one of the attributes declared in the SAML assertion received from the server. You'll need to specify the name of the SAML assertion attribute to use within the `attribute` XML attribute." +msgstr "" + +msgid "RoleIdentifiers element" +msgstr "" + +msgid "The `RoleIdentifiers` element defines what SAML attributes within the assertion received from the user should be used as role identifiers within the Jakarta EE Security Context for the user." +msgstr "" + +msgid "" +"\n" +"\n" +" \n" +" \n" +" \n" +"" +msgstr "" + +msgid "By default `Role` attribute values are converted to Jakarta EE roles. Some IdPs send roles using a `member` or `memberOf` attribute assertion. You can define one or more `Attribute` elements to specify which SAML attributes must be converted into roles." +msgstr "" + +msgid "RoleMappingsProvider element" +msgstr "" + +msgid "The `RoleMappingsProvider` is an optional element that allows for the specification of the id and configuration of the `org.keycloak.adapters.saml.RoleMappingsProvider` SPI implementation that is to be used by the SAML adapter." +msgstr "" + +msgid "When {project_name} is used as the IDP, it is possible to use the built-in role mappers to map any roles before adding them to the SAML assertion. However, the SAML adapters can be used to send SAML requests to third party IDPs and in this case it might be necessary to map the roles extracted from the assertion into a different set of roles as required by the SP. The `RoleMappingsProvider` SPI allows for the configuration of pluggable role mappers that can be used to perform the necessary mappings." +msgstr "" + +msgid "The configuration of the provider looks as follows:" +msgstr "" + +msgid "" +"...\n" +"\n" +" ...\n" +"\n" +"\n" +" \n" +"\n" +"\n" +" ...\n" +"\n" +msgstr "" + +msgid "The `id` attribute identifies which of the installed providers is to be used. The `Property` sub-element can be used multiple times to specify configuration properties for the provider." +msgstr "" + +msgid "Properties Based role mappings provider" +msgstr "" + +msgid "{project_name} includes a `RoleMappingsProvider` implementation that performs the role mappings using a `properties` file. This provider is identified by the id `properties-based-role-mapper` and is implemented by the `org.keycloak.adapters.saml.PropertiesBasedRoleMapper` class." +msgstr "" + +msgid "This provider relies on two configuration properties that can be used to specify the location of the `properties` file that will be used. First, it checks if the `properties.file.location` property has been specified, using the configured value to locate the `properties` file in the filesystem. If the configured file is not located, the provider throws a `RuntimeException`. The following snippet shows an example of provider using the `properties.file.configuration` option to load the `roles.properties` file from the `/opt/mappers/` directory in the filesystem:" +msgstr "" + +msgid "" +" \n" +" \n" +" " +msgstr "" + +msgid "If the `properties.file.location` configuration has not been set, the provider checks the `properties.resource.location` property, using the configured value to load the `properties` file from the `WAR` resource. If this configuration property is also not present, the provider attempts to load the file from `/WEB-INF/role-mappings.properties` by default. Failure to load the file from the resource will result in the provider throwing a `RuntimeException`. The following snippet shows an example of provider using the `properties.resource.location` to load the `roles.properties` file from the application's `/WEB-INF/conf/` directory:" +msgstr "" + +msgid "" +" \n" +" \n" +" " +msgstr "" + +msgid "The `properties` file can contain both roles and principals as keys, and a list of zero or more roles separated by comma as values. When invoked, the implementation iterates through the set of roles that were extracted from the assertion and checks, for each role, if a mapping exists. If the role maps to an empty role, it is discarded. If it maps to a set of one or more different roles, then these roles are set in the result set. If no mapping is found for the role then it is included as is in the result set." +msgstr "" + +msgid "Once the roles have been processed, the implementation checks if the principal extracted from the assertion contains an entry `properties` file. If a mapping for the principal exists, any roles listed as value are added to the result set. This allows the assignment of extra roles to a principal." +msgstr "" + +msgid "As an example, let's assume the provider has been configured with the following properties file:" +msgstr "" + +msgid "" +"roleA=roleX,roleY\n" +"roleB=\n" +"\n" +"kc_user=roleZ\n" +msgstr "" + +msgid "If the principal `kc_user` is extracted from the assertion with roles `roleA`, `roleB` and `roleC`, the final set of roles assigned to the principal will be `roleC`, `roleX`, `roleY` and `roleZ` because `roleA` is being mapped into both `roleX` and `roleY`, `roleB` was mapped into an empty role - thus being discarded, `roleC` is used as is and finally an additional role was added to the `kc_user` principal (`roleZ`)." +msgstr "" + +msgid "Note: to use spaces in role names for mappings, use unicode replacements for space. For example, incoming 'role A' would appear as:" +msgstr "" + +msgid "role\\u0020A=roleX,roleY" +msgstr "" + +msgid "Adding your own role mappings provider" +msgstr "" + +msgid "To add a custom role mappings provider one simply needs to implement the `org.keycloak.adapters.saml.RoleMappingsProvider` SPI. For more details see the `SAML Role Mappings SPI` section in link:{developerguide_link}[{developerguide_name}]." +msgstr "" + +msgid "IDP Element" +msgstr "" + +msgid "Everything in the IDP element describes the settings for the identity provider (authentication server) the SP is communicating with." +msgstr "" + +msgid "" +"\n" +"...\n" +"" +msgstr "" + +msgid "Here are the attribute config options you can specify within the `IDP` element declaration." +msgstr "" + +msgid "This is the issuer ID of the IDP. This setting is _REQUIRED_." +msgstr "" + +msgid "signaturesRequired" +msgstr "" + +msgid "If set to `true`, the client adapter will sign every document it sends to the IDP. Also, the client will expect that the IDP will be signing any documents sent to it. This switch sets the default for all request and response types, but you will see later that you have some fine grain control over this. This setting is _OPTIONAL_ and will default to `false`." +msgstr "" + +msgid "signatureAlgorithm" +msgstr "" + +msgid " This is the signature algorithm that the IDP expects signed documents to use. Allowed values are: `RSA_SHA1`, `RSA_SHA256`, `RSA_SHA512`, and `DSA_SHA1`. This setting is _OPTIONAL_ and defaults to `RSA_SHA256`. Note that `SHA1` based algorithms are deprecated and can be removed in the future. We recommend the use of some more secure algorithm instead of `*_SHA1`. Also, with `*_SHA1` algorithms, verifying signatures do not work if the SAML server (usually {project_name}) runs on Java 17 or higher." +msgstr "" + +msgid "signatureCanonicalizationMethod" +msgstr "" + +msgid "This is the signature canonicalization method that the IDP expects signed documents to use. This setting is _OPTIONAL_. The default value is `\\http://www.w3.org/2001/10/xml-exc-c14n#` and should be good for most IDPs." +msgstr "" + +msgid "metadataUrl" +msgstr "" + +msgid "The URL used to retrieve the IDP metadata, currently this is only used to pick up signing and encryption keys periodically which allow cycling of these keys on the IDP without manual changes on the SP side." +msgstr "" + +msgid "IDP AllowedClockSkew sub element" +msgstr "" + +msgid "The `AllowedClockSkew` optional sub element defines the allowed clock skew between IDP and SP. The default value is 0." +msgstr "" + +msgid "3500" +msgstr "" + +msgid "unit" +msgstr "" + +msgid "It is possible to define the time unit attached to the value for this element. Allowed values are MICROSECONDS, MILLISECONDS, MINUTES, NANOSECONDS and SECONDS. This is _OPTIONAL_. The default value is `SECONDS`." +msgstr "" + +msgid "IDP SingleSignOnService sub element" +msgstr "" + +msgid "The `SingleSignOnService` sub element defines the login SAML endpoint of the IDP. The client adapter will send requests to the IDP formatted via the settings within this element when it wants to log in." +msgstr "" + +msgid "" +"\n" +"" +msgstr "" + +msgid "Here are the config attributes you can define on this element:" +msgstr "" + +msgid "signRequest" +msgstr "" + +msgid "Should the client sign authn requests? This setting is _OPTIONAL_. Defaults to whatever the IDP `signaturesRequired` element value is." +msgstr "" + +msgid "validateResponseSignature" +msgstr "" + +msgid "Should the client expect the IDP to sign the assertion response document sent back from an authn request? This setting _OPTIONAL_. Defaults to whatever the IDP `signaturesRequired` element value is." +msgstr "" + +msgid "requestBinding" +msgstr "" + +msgid "This is the SAML binding type used for communicating with the IDP. This setting is _OPTIONAL_. The default value is `POST`, but you can set it to `REDIRECT` as well." +msgstr "" + +msgid "responseBinding" +msgstr "" + +msgid "SAML allows the client to request what binding type it wants authn responses to use. The values of this can be `POST` or `REDIRECT`. This setting is _OPTIONAL_. The default is that the client will not request a specific binding type for responses." +msgstr "" + +msgid "assertionConsumerServiceUrl" +msgstr "" + +msgid "URL of the assertion consumer service (ACS) where the IDP login service should send responses to. This setting is _OPTIONAL_. By default it is unset, relying on the configuration in the IdP. When set, it must end in `/saml`, for example `\\http://sp.domain.com/my/endpoint/for/saml`. The value of this property is sent in `AssertionConsumerServiceURL` attribute of SAML `AuthnRequest` message. This property is typically accompanied by the `responseBinding` attribute." +msgstr "" + +msgid "bindingUrl" +msgstr "" + +msgid "This is the URL for the IDP login service that the client will send requests to. This setting is _REQUIRED_." +msgstr "" + +msgid "IDP SingleLogoutService sub element" +msgstr "" + +msgid "The `SingleLogoutService` sub element defines the logout SAML endpoint of the IDP. The client adapter will send requests to the IDP formatted via the settings within this element when it wants to log out." +msgstr "" + +msgid "" +"" +msgstr "" + +msgid "Should the client sign logout requests it makes to the IDP? This setting is _OPTIONAL_. Defaults to whatever the IDP `signaturesRequired` element value is." +msgstr "" + +msgid "signResponse" +msgstr "" + +msgid "Should the client sign logout responses it sends to the IDP requests? This setting is _OPTIONAL_. Defaults to whatever the IDP `signaturesRequired` element value is." +msgstr "" + +msgid "validateRequestSignature" +msgstr "" + +msgid "Should the client expect signed logout request documents from the IDP? This setting is _OPTIONAL_. Defaults to whatever the IDP `signaturesRequired` element value is." +msgstr "" + +msgid "Should the client expect signed logout response documents from the IDP? This setting is _OPTIONAL_. Defaults to whatever the IDP `signaturesRequired` element value is." +msgstr "" + +msgid "This is the SAML binding type used for communicating SAML requests to the IDP. This setting is _OPTIONAL_. The default value is `POST`, but you can set it to REDIRECT as well." +msgstr "" + +msgid "This is the SAML binding type used for communicating SAML responses to the IDP. The values of this can be `POST` or `REDIRECT`. This setting is _OPTIONAL_. The default value is `POST`, but you can set it to `REDIRECT` as well." +msgstr "" + +msgid "postBindingUrl" +msgstr "" + +msgid "This is the URL for the IDP's logout service when using the POST binding. This setting is _REQUIRED_ if using the `POST` binding." +msgstr "" + +msgid "redirectBindingUrl" +msgstr "" + +msgid "This is the URL for the IDP's logout service when using the REDIRECT binding. This setting is _REQUIRED_ if using the REDIRECT binding." +msgstr "" + +msgid "IDP Keys sub element" +msgstr "" + +msgid "The Keys sub element of IDP is only used to define the certificate or public key to use to verify documents signed by the IDP. It is defined in the same way as the <<_saml-sp-keys,SP's Keys element>>. But again, you only have to define one certificate or public key reference. Note that, if both IDP and SP are realized by {project_name} server and adapter, respectively, there is no need to specify the keys for signature validation, see below." +msgstr "" + +msgid "It is possible to configure SP to obtain public keys for IDP signature validation from published certificates automatically, provided both SP and IDP are implemented by {project_name}. This is done by removing all declarations of signature validation keys in Keys sub element. If the Keys sub element would then remain empty, it can be omitted completely. The keys are then automatically obtained by SP from SAML descriptor, location of which is derived from SAML endpoint URL specified in the <<_sp-idp-singlesignonservice,IDP SingleSignOnService sub element>>. Settings of the HTTP client that is used for SAML descriptor retrieval usually needs no additional configuration, however it can be configured in the <<_sp-idp-httpclient,IDP HttpClient sub element>>." +msgstr "" + +msgid "It is also possible to specify multiple keys for signature verification. This is done by declaring multiple Key elements within Keys sub element that have `signing` attribute set to `true`. This is useful for example in situation when the IDP signing keys are rotated: There is usually a transition period when new SAML protocol messages and assertions are signed with the new key but those signed by previous key should still be accepted." +msgstr "" + +msgid "It is not possible to configure {project_name} to both obtain the keys for signature verification automatically and define additional static signature verification keys." +msgstr "" + +msgid "" +" \n" +" ...\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" " +msgstr "" + +msgid "IDP HttpClient sub element" +msgstr "" + +msgid "The `HttpClient` optional sub element defines the properties of HTTP client used for automatic obtaining of certificates containing public keys for IDP signature verification via SAML descriptor of the IDP when <<_sp-idp-keys-automatic,enabled>>." +msgstr "" + +msgid "" +"" +msgstr "" + +msgid "connectionPoolSize" +msgstr "" + +msgid "This config option defines how many connections to the {project_name} server should be pooled. This is _OPTIONAL_. The default value is `10`." +msgstr "" + +msgid "disableTrustManager" +msgstr "" + +msgid "If the {project_name} server requires HTTPS and this config option is set to `true` you do not have to specify a truststore. This setting should only be used during development and *never* in production as it will disable verification of SSL certificates. This is _OPTIONAL_. The default value is `false`." +msgstr "" + +msgid "allowAnyHostname" +msgstr "" + +msgid "If the {project_name} server requires HTTPS and this config option is set to `true` the {project_name} server's certificate is validated via the truststore, but host name validation is not done. This setting should only be used during development and *never* in production as it will partly disable verification of SSL certificates. This setting may be useful in test environments. This is _OPTIONAL_. The default value is `false`." +msgstr "" + +msgid "The value is the file path to a truststore file. If you prefix the path with `classpath:`, then the truststore will be obtained from the deployment's classpath instead. Used for outgoing HTTPS communications to the {project_name} server. Client making HTTPS requests need a way to verify the host of the server they are talking to. This is what the truststore does. The keystore contains one or more trusted host certificates or certificate authorities. You can create this truststore by extracting the public certificate of the {project_name} server's SSL keystore. This is _REQUIRED_ unless `disableTrustManager` is `true`." +msgstr "" + +msgid "truststorePassword" +msgstr "" + +msgid "Password for the truststore. This is _REQUIRED_ if `truststore` is set and the truststore requires a password." +msgstr "" + +msgid "clientKeystore" +msgstr "" + +msgid "This is the file path to a keystore file. This keystore contains client certificate for two-way SSL when the adapter makes HTTPS requests to the {project_name} server. This is _OPTIONAL_." +msgstr "" + +msgid "clientKeystorePassword" +msgstr "" + +msgid "Password for the client keystore and for the client's key. This is _REQUIRED_ if `clientKeystore` is set." +msgstr "" + +msgid "proxyUrl" +msgstr "" + +msgid "URL to HTTP proxy to use for HTTP connections. This is _OPTIONAL_." +msgstr "" + +msgid "socketTimeout" +msgstr "" + +msgid "Timeout for socket waiting for data after establishing the connection in milliseconds. Maximum time of inactivity between two data packets. A timeout value of zero is interpreted as an infinite timeout. A negative value is interpreted as undefined (system default if applicable). The default value is `-1`. This is _OPTIONAL_." +msgstr "" + +msgid "connectionTimeout" +msgstr "" + +msgid "Timeout for establishing the connection with the remote host in milliseconds. A timeout value of zero is interpreted as an infinite timeout. A negative value is interpreted as undefined (system default if applicable). The default value is `-1`. This is _OPTIONAL_." +msgstr "" + +msgid "connectionTtl" +msgstr "" + +msgid "Connection time-to-live for client in milliseconds. A value less than or equal to zero is interpreted as an infinite value. The default value is `-1`. This is _OPTIONAL_." +msgstr "" + +msgid "To be able to secure WAR apps deployed on JBoss EAP or WildFly, you must install and configure the {project_name} SAML Adapter Subsystem." +msgstr "" + +msgid "You then provide a keycloak config, `/WEB-INF/keycloak-saml.xml` file in your WAR and change the auth-method to KEYCLOAK-SAML within web.xml." +msgstr "" + +msgid "Installing adapters from a Galleon feature pack" +msgstr "" + +msgid "For the WildFly 29 or newer, the SAML adapter is provided as a Galleon feature pack. More details about this is in the https://docs.wildfly.org/30/WildFly_Elytron_Security.html#Keycloak_SAML_Integration[WildFly documentation]. The same option will be provided for JBoss EAP 8 GA." +msgstr "" + +msgid "{project_name} provided adapter ZIP download in the past, but it is not provided anymore. For the older WildFly versions, it is recommended to upgrade to newer WildFly/EAP and use Galleon. Otherwise, you will need to stick with the older {project_name} adapters, but those are not maintained and officially supported. For JBoss EAP 7, it is possible to stick with the Red Hat Single Sign-On 7.6 adapters, which is still supported." +msgstr "" + +msgid "For more details on how to integrate {project_name} with JakartaEE applications running on latest Wildfly/EAP, take a look at the Jakarta EE quickstart in the {quickstartRepo_link}[Keycloak Quickstart GitHub Repository]." +msgstr "" + +msgid "Below are the details on how to configure the SAML adapter secured by Galleon." +msgstr "" + +msgid "Setting SameSite value for JSESSIONID cookie" +msgstr "" + +msgid "Browsers are planning to set the default value for the `SameSite` attribute for cookies to `Lax`. This setting means that cookies will be sent to applications only if the request originates in the same domain. This behavior can affect the SAML POST binding which may become non-functional. To preserve full functionality of the SAML adapter, we recommend setting the `SameSite` value to `None` for the `JSESSIONID` cookie created by your container. Not doing so may result in resetting the container's session with each request to {project_name}." +msgstr "" + +msgid "To avoid setting the `SameSite` attribute to `None`, consider switching to the REDIRECT binding if it is acceptable, or to OIDC protocol where this workaround is not necessary." +msgstr "" + +msgid "To set the `SameSite` value to `None` for the `JSESSIONID` cookie in Wildfly/EAP, add a file `undertow-handlers.conf` with the following content to the `WEB-INF` directory of your application." +msgstr "" + +msgid "samesite-cookie(mode=None, cookie-pattern=JSESSIONID)" +msgstr "" + +msgid "The support for this configuration is available in Wildfly from version 19.1.0." +msgstr "" + +msgid "The first thing you must do is create a `keycloak-saml.xml` adapter config file within the `WEB-INF` directory of your WAR. The format of this config file is described in the <<_saml-general-config,General Adapter Config>> section." +msgstr "" + +msgid "Next you must set the `auth-method` to `KEYCLOAK-SAML` in `web.xml`. You also have to use standard servlet security to specify role-base constraints on your URLs. Here's an example _web.xml_ file:" +msgstr "" + +msgid "" +"\n" +"\n" +"\n" +"\tcustomer-portal\n" +"\n" +" \n" +" \n" +" Admins\n" +" /admin/*\n" +" \n" +" \n" +" admin\n" +" \n" +" \n" +" CONFIDENTIAL\n" +" \n" +" \n" +" \n" +" \n" +" Customers\n" +" /customers/*\n" +" \n" +" \n" +" user\n" +" \n" +" \n" +" CONFIDENTIAL\n" +" \n" +" \n" +"\n" +" \n" +" KEYCLOAK-SAML\n" +" this is ignored currently\n" +" \n" +"\n" +" \n" +" admin\n" +" \n" +" \n" +" user\n" +" \n" +"" +msgstr "" + +msgid "All standard servlet settings except the `auth-method` setting." +msgstr "" + +msgid "Securing WARs using the {project_name} SAML Subsystem" +msgstr "" + +msgid "You do not have to open a WAR to secure it with {project_name}. Alternatively, you can externally secure it via the {project_name} SAML Adapter Subsystem. While you don't have to specify KEYCLOAK-SAML as an `auth-method`, you still have to define the `security-constraints` in `web.xml`. You do not, however, have to create a `WEB-INF/keycloak-saml.xml` file. This metadata is instead defined within the XML in your server's `domain.xml` or `standalone.xml` subsystem configuration section." +msgstr "" + +msgid "" +"\n" +"\n" +" \n" +"\n" +"\n" +"\n" +" \n" +" \n" +" \n" +" ...\n" +" \n" +" \n" +" \n" +"" +msgstr "" + +msgid "The `secure-deployment` `name` attribute identifies the WAR you want to secure. Its value is the `module-name` defined in `web.xml` with `.war` appended. The rest of the configuration uses the same XML syntax as `keycloak-saml.xml` configuration defined in <<_saml-general-config,General Adapter Config>>." +msgstr "" + +msgid "An example configuration:" +msgstr "" + +msgid "" +"\n" +"\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"" +msgstr "" + +msgid "Tomcat SAML adapters" +msgstr "" + +msgid "The {project_name} Tomcat SAML adapter is deprecated. We recommend that you use another client adapter if possible." +msgstr "" + +msgid "To be able to secure WAR apps deployed on Tomcat 8 or 9 you must install the Keycloak Tomcat SAML adapter into your Tomcat installation. You then have to provide some extra configuration in each WAR you deploy to Tomcat." +msgstr "" + +msgid "Download the adapter for the Tomcat version on your system from the link:https://www.keycloak.org/downloads[Keycloak Downloads] site:" +msgstr "" + +msgid "Install on the Tomcat version on your system:" +msgstr "" + +msgid "" +"$ cd $TOMCAT_HOME/lib\n" +"$ unzip keycloak-saml-tomcat-adapter-dist.zip" +msgstr "" + +msgid "Including the adapter's jars within your WEB-INF/lib directory will not work. The Keycloak SAML adapter is implemented as a Valve and valve code must reside in Tomcat's main lib/ directory." +msgstr "" + +msgid "Create a `META-INF/context.xml` file in your WAR package. This is a Tomcat specific config file and you must define a Keycloak specific Valve." +msgstr "" + +msgid "" +"\n" +" \n" +"" +msgstr "" + +msgid "Create a `keycloak-saml.xml` adapter config file within the `WEB-INF` directory of your WAR. The format of this config file is described in the <<_saml-general-config,General Adapter Config>> section." +msgstr "" + +msgid "If the `keycloak-saml.xml` does not explicitly set `assertionConsumerServiceUrl`, the SAML adapter will implicitly listen for SAML assertions at the location `/my-context-path/saml`. This has to match `Master SAML Processing URL` in the IDP realm/client settings, for example `\\http://sp.domain.com/my-context-path/saml`. If not, Tomcat will probably redirect infinitely to the IDP login service, as it does not receive the SAML assertion after the user logged in." +msgstr "" + +msgid "To set the `SameSite` value to `None` for `JSESSIONID` cookie in Tomcat add following configuration to the`context.xml` of your application. Note, this will set the `SameSite` value to `None` for all cookies created by Tomcat container." +msgstr "" + +msgid "" +msgstr "" + +msgid "It is not possible to set the `SameSite` attribute only to a subset of cookies, therefore all cookies created for your application will have this attribute set to `None`." +msgstr "" + +msgid "The support for this feature is available in Tomcat from versions 9.0.29 and 8.5.49." +msgstr "" + +msgid "Jetty SAML adapters" +msgstr "" + +msgid "The {project_name} Jetty SAML adapter is deprecated. We recommend that you use another client adapter if possible." +msgstr "" + +msgid "To be able to secure WAR apps deployed on Jetty you must install the {project_name} Jetty 9.4 SAML adapter into your Jetty installation. You then provide some extra configuration in each WAR you deploy to Jetty." +msgstr "" + +msgid "Use the following installation and configuration procedures." +msgstr "" + +msgid "Jetty 9 Installing the adapter" +msgstr "" + +msgid "{project_name} has a separate SAML adapter for Jetty 9.4. Adapters are no longer included with the appliance or war distribution. Each adapter is a separate download on the Keycloak download site. They are also available as a maven artifact." +msgstr "" + +msgid "Unzip the Jetty 9.4 distro into Jetty 9.4's root directory." +msgstr "" + +msgid "Including adapter's jars within your WEB-INF/lib directory will not work." +msgstr "" + +msgid "" +"$ cd $JETTY_HOME\n" +"$ unzip keycloak-saml-jetty94-adapter-dist.zip" +msgstr "" + +msgid "Enable the keycloak module for your jetty.base." +msgstr "" + +msgid "" +"$ cd your-base\n" +"$ java -jar $JETTY_HOME/start.jar --add-to-startd=keycloak" +msgstr "" + +msgid "Jetty 9 WAR Configuration" +msgstr "" + +msgid "Use this procedure to secure a WAR directly." +msgstr "" + +msgid "Create a `WEB-INF/jetty-web.xml` file in your WAR package. This is a Jetty specific config file and you must define a Keycloak specific authenticator within it." +msgstr "" + +msgid "" +"\n" +"\n" +"\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"" +msgstr "" + +msgid "Java Servlet filter adapter" +msgstr "" + +msgid "If you want to use SAML with a Java servlet application that doesn't have an adapter for that servlet platform, you can opt to use the servlet filter adapter that {project_name} has. This adapter works a little differently than the other adapters. You still have to specify a `/WEB-INF/keycloak-saml.xml` file as defined in the <<_saml-general-config,General Adapter Config>> section, but you do not define security constraints in _web.xml_. Instead you define a filter mapping using the {project_name} servlet filter adapter to secure the url patterns you want to secure." +msgstr "" + +msgid "Backchannel logout works a bit differently than the standard adapters. Instead of invalidating the http session it instead marks the session ID as logged out. There's just no way of arbitrarily invalidating an HTTP session based on a session ID." +msgstr "" + +msgid "Backchannel logout does not currently work when you have a clustered application that uses the SAML filter." +msgstr "" + +msgid "" +"\n" +"\n" +"\tcustomer-portal\n" +"\n" +" \n" +" Keycloak Filter\n" +" org.keycloak.adapters.saml.servlet.SamlFilter\n" +" \n" +" \n" +" Keycloak Filter\n" +" /*\n" +" \n" +"" +msgstr "" + +msgid "The {project_name} filter has the same configuration parameters available as the other adapters except you must define them as filter init params instead of context params." +msgstr "" + +msgid "You can define multiple filter mappings if you have various different secure and unsecure url patterns." +msgstr "" + +msgid "You must have a filter mapping that covers `/saml`. This mapping covers all server callbacks." +msgstr "" + +msgid "When registering SPs with an IdP, you must register `http[s]://hostname/{context-root}/saml` as your Assert Consumer Service URL and Single Logout Service URL." +msgstr "" + +msgid "" +"\n" +" org.keycloak\n" +" keycloak-saml-servlet-filter-adapter\n" +" {project_versionMvn}\n" +"" +msgstr "" + +msgid "In order to use <<_saml_multi_tenancy,Multi Tenancy>> the `keycloak.config.resolver` parameter should be passed as a filter parameter." +msgstr "" + +msgid "" +" \n" +" Keycloak Filter\n" +" org.keycloak.adapters.saml.servlet.SamlFilter\n" +" \n" +" keycloak.config.resolver\n" +" example.SamlMultiTenantResolver\n" +" \n" +" " +msgstr "" + +msgid "Registering with an Identity Provider" +msgstr "" + +msgid "For each servlet-based adapter, the endpoint you register for the assert consumer service URL and single logout service must be the base URL of your servlet application with `/saml` appended to it, that is, `$$https://example.com/contextPath/saml$$`." +msgstr "" + +msgid "There are multiple ways you can log out from a web application. For Jakarta EE servlet containers, you can call `HttpServletRequest.logout()`. For any other browser application, you can point the browser at any url of your web application that has a security constraint and pass in a query parameter GLO, i.e. `$$http://myapp?GLO=true$$`. This will log you out if you have an SSO session with your browser." +msgstr "" + +msgid "Logout in clustered environment" +msgstr "" + +msgid "Internally, the SAML adapter stores a mapping between the SAML session index, principal name (when known), and HTTP session ID. This mapping can be maintained in JBoss application server family (WildFly 10/11, EAP 6/7) across cluster for distributable applications. As a precondition, the HTTP sessions need to be distributed across cluster (i.e. application is marked with `` tag in application's `web.xml`)." +msgstr "" + +msgid "To enable the functionality, add the following section to your `/WEB_INF/web.xml` file:" +msgstr "" + +msgid "For EAP 7, WildFly 10/11:" +msgstr "" + +msgid "" +"\n" +" keycloak.sessionIdMapperUpdater.classes\n" +" org.keycloak.adapters.saml.wildfly.infinispan.InfinispanSessionCacheIdMapperUpdater\n" +"" +msgstr "" + +msgid "For EAP 6:" +msgstr "" + +msgid "" +"\n" +" keycloak.sessionIdMapperUpdater.classes\n" +" org.keycloak.adapters.saml.jbossweb.infinispan.InfinispanSessionCacheIdMapperUpdater\n" +"" +msgstr "" + +msgid "If the session cache of the deployment is named `_deployment-cache_`, the cache used for SAML mapping will be named as `_deployment-cache_.ssoCache`. The name of the cache can be overridden by a context parameter `keycloak.sessionIdMapperUpdater.infinispan.cacheName`. The cache container containing the cache will be the same as the one containing the deployment session cache, but can be overridden by a context parameter `keycloak.sessionIdMapperUpdater.infinispan.containerName`." +msgstr "" + +msgid "By default, the configuration of the SAML mapping cache will be derived from session cache. The configuration can be manually overridden in cache configuration section of the server just the same as other caches." +msgstr "" + +msgid "Currently, to provide reliable service, it is recommended to use replicated cache for the SAML session cache. Using distributed cache may lead to results where the SAML logout request would land to a node with no access to SAML session index to HTTP session mapping which would lead to unsuccessful logout." +msgstr "" + +msgid "Logout in cross-site scenario" +msgstr "" + +msgid "The cross-site scenario only applies to WildFly 10 and higher, and EAP 7 and higher." +msgstr "" + +msgid "Special handling is needed for handling sessions that span multiple data centers. Imagine the following scenario:" +msgstr "" + +msgid "Login requests are handled within cluster in data center 1." +msgstr "" + +msgid "Admin issues logout request for a particular SAML session, the request lands in data center 2." +msgstr "" + +msgid "The data center 2 has to log out all sessions that are present in data center 1 (and all other data centers that share HTTP sessions)." +msgstr "" + +msgid "To cover this case, the SAML session cache described <<_saml_logout_in_cluster,above>> needs to be replicated not only within individual clusters but across all the data centers for example https://access.redhat.com/documentation/en-us/red_hat_data_grid/6.6/html/administration_and_configuration_guide/chap-externalize_sessions#Externalize_HTTP_Session_from_JBoss_EAP_6.x_to_JBoss_Data_Grid[via standalone Infinispan/JDG server]:" +msgstr "" + +msgid "A cache has to be added to the standalone Infinispan/JDG server." +msgstr "" + +msgid "The cache from previous item has to be added as a remote store for the respective SAML session cache." +msgstr "" + +msgid "Once remote store is found to be present on SAML session cache during deployment, it is watched for changes and the local SAML session cache is updated accordingly." +msgstr "" + +msgid "Obtaining assertion attributes" +msgstr "" + +msgid "After a successful SAML login, your application code may want to obtain attribute values passed with the SAML assertion. `HttpServletRequest.getUserPrincipal()` returns a `Principal` object that you can typecast into a {project_name} specific class called `org.keycloak.adapters.saml.SamlPrincipal`. This object allows you to look at the raw assertion and also has convenience functions to look up attribute values." +msgstr "" + +msgid "" +"package org.keycloak.adapters.saml;\n" +"\n" +"public class SamlPrincipal implements Serializable, Principal {\n" +" /**\n" +" * Get full saml assertion\n" +" *\n" +" * @return\n" +" */\n" +" public AssertionType getAssertion() {\n" +" ...\n" +" }\n" +"\n" +" /**\n" +" * Get SAML subject sent in assertion\n" +" *\n" +" * @return\n" +" */\n" +" public String getSamlSubject() {\n" +" ...\n" +" }\n" +"\n" +" /**\n" +" * Subject nameID format\n" +" *\n" +" * @return\n" +" */\n" +" public String getNameIDFormat() {\n" +" ...\n" +" }\n" +"\n" +" @Override\n" +" public String getName() {\n" +" ...\n" +" }\n" +"\n" +" /**\n" +" * Convenience function that gets Attribute value by attribute name\n" +" *\n" +" * @param name\n" +" * @return\n" +" */\n" +" public List getAttributes(String name) {\n" +" ...\n" +"\n" +" }\n" +"\n" +" /**\n" +" * Convenience function that gets Attribute value by attribute friendly name\n" +" *\n" +" * @param friendlyName\n" +" * @return\n" +" */\n" +" public List getFriendlyAttributes(String friendlyName) {\n" +" ...\n" +" }\n" +"\n" +" /**\n" +" * Convenience function that gets first value of an attribute by attribute name\n" +" *\n" +" * @param name\n" +" * @return\n" +" */\n" +" public String getAttribute(String name) {\n" +" ...\n" +" }\n" +"\n" +" /**\n" +" * Convenience function that gets first value of an attribute by attribute name\n" +" *\n" +" *\n" +" * @param friendlyName\n" +" * @return\n" +" */\n" +" public String getFriendlyAttribute(String friendlyName) {\n" +" ...\n" +" }\n" +"\n" +" /**\n" +" * Get set of all assertion attribute names\n" +" *\n" +" * @return\n" +" */\n" +" public Set getAttributeNames() {\n" +" ...\n" +" }\n" +"\n" +" /**\n" +" * Get set of all assertion friendly attribute names\n" +" *\n" +" * @return\n" +" */\n" +" public Set getFriendlyNames() {\n" +" ...\n" +" }\n" +"}" +msgstr "" + +msgid "Error Handling" +msgstr "" + +msgid "{project_name} has some error handling facilities for servlet based client adapters. When an error is encountered in authentication, the client adapter will call `HttpServletResponse.sendError()`. You can set up an `error-page` within your `web.xml` file to handle the error however you want. The client adapter can throw 400, 401, 403, and 500 errors." +msgstr "" + +msgid "The client adapter also sets an `HttpServletRequest` attribute that you can retrieve. The attribute name is `org.keycloak.adapters.spi.AuthenticationError`. Typecast this object to: `org.keycloak.adapters.saml.SamlAuthenticationError`. This class can tell you exactly what happened. If this attribute is not set, then the adapter was not responsible for the error code." +msgstr "" + +msgid "" +"public class SamlAuthenticationError implements AuthenticationError {\n" +" public static enum Reason {\n" +" EXTRACTION_FAILURE,\n" +" INVALID_SIGNATURE,\n" +" ERROR_STATUS\n" +" }\n" +"\n" +" public Reason getReason() {\n" +" return reason;\n" +" }\n" +" public StatusResponseType getStatus() {\n" +" return status;\n" +" }\n" +"}" +msgstr "" + +msgid "Troubleshooting" +msgstr "" + +msgid "The best way to troubleshoot problems is to turn on debugging for SAML in both the client adapter and {project_name} Server. Using your logging framework, set the log level to `DEBUG` for the `org.keycloak.saml` package. Turning this on allows you to see the SAML requests and response documents being sent to and from the server." +msgstr "" + +msgid "SAML offers Multi Tenancy, meaning that a single target application (WAR) can be secured with multiple {project_name} realms. The realms can be located on the same {project_name} instance or on different instances." +msgstr "" + +msgid "To do this, the application must have multiple `keycloak-saml.xml` adapter configuration files." +msgstr "" + +msgid "While you could have multiple instances of your WAR with different adapter configuration files deployed to different context-paths, this may be inconvenient and you may also want to select the realm based on something other than context-path." +msgstr "" + +msgid "{project_name} makes it possible to have a custom config resolver, so you can choose which adapter config is used for each request. In SAML, the configuration is only interesting in the login processing; once the user is logged in, the session is authenticated and it does not matter if the `keycloak-saml.xml` returned is different. For that reason, returning the same configuration for the same session is the correct way to go." +msgstr "" + +msgid "To achieve this, create an implementation of `org.keycloak.adapters.saml.SamlConfigResolver`. The following example uses the `Host` header to locate the proper configuration and load it and the associated elements from the applications' Java classpath:" +msgstr "" + +msgid "" +"package example;\n" +"\n" +"import java.io.InputStream;\n" +"import org.keycloak.adapters.saml.SamlConfigResolver;\n" +"import org.keycloak.adapters.saml.SamlDeployment;\n" +"import org.keycloak.adapters.saml.config.parsers.DeploymentBuilder;\n" +"import org.keycloak.adapters.saml.config.parsers.ResourceLoader;\n" +"import org.keycloak.adapters.spi.HttpFacade;\n" +"import org.keycloak.saml.common.exceptions.ParsingException;\n" +"\n" +"public class SamlMultiTenantResolver implements SamlConfigResolver {\n" +"\n" +" @Override\n" +" public SamlDeployment resolve(HttpFacade.Request request) {\n" +" String host = request.getHeader(\"Host\");\n" +" String realm = null;\n" +" if (host.contains(\"tenant1\")) {\n" +" realm = \"tenant1\";\n" +" } else if (host.contains(\"tenant2\")) {\n" +" realm = \"tenant2\";\n" +" } else {\n" +" throw new IllegalStateException(\"Not able to guess the keycloak-saml.xml to load\");\n" +" }\n" +"\n" +" InputStream is = getClass().getResourceAsStream(\"/\" + realm + \"-keycloak-saml.xml\");\n" +" if (is == null) {\n" +" throw new IllegalStateException(\"Not able to find the file /\" + realm + \"-keycloak-saml.xml\");\n" +" }\n" +"\n" +" ResourceLoader loader = new ResourceLoader() {\n" +" @Override\n" +" public InputStream getResourceAsStream(String path) {\n" +" return getClass().getResourceAsStream(path);\n" +" }\n" +" };\n" +"\n" +" try {\n" +" return new DeploymentBuilder().build(is, loader);\n" +" } catch (ParsingException e) {\n" +" throw new IllegalStateException(\"Cannot load SAML deployment\", e);\n" +" }\n" +" }\n" +"}" +msgstr "" + +msgid "You must also configure which `SamlConfigResolver` implementation to use with the `keycloak.config.resolver` context-param in your `web.xml`:" +msgstr "" + +msgid "" +"\n" +" ...\n" +" \n" +" keycloak.config.resolver\n" +" example.SamlMultiTenantResolver\n" +" \n" +"" +msgstr "" + +msgid "Migration from older versions" +msgstr "" + +msgid "Migrating to 1.9.0" +msgstr "" + +msgid "SAML SP Client Adapter changes" +msgstr "" + +msgid "Keycloak SAML SP Client Adapter now requires a specific endpoint, `/saml` to be registered with your IdP. The SamlFilter must also be bound to /saml in addition to any other binding it has. This had to be done because SAML POST binding would eat the request input stream and this would be really bad for clients that relied on it." +msgstr "" + +msgid "mod_auth_mellon Apache HTTPD Module" +msgstr "" + +msgid "{project_name} does not provide any official support to mod_auth_mellon. The instructions below are best-effort and may not be up-to-date. We recommend that you stick to official mod_auth_mellon documentation for more details." +msgstr "" + +msgid "The https://github.com/latchset/mod_auth_mellon[mod_auth_mellon] module is an Apache HTTPD plugin for SAML. If your language/environment supports using Apache HTTPD as a proxy, then you can use mod_auth_mellon to secure your web application with SAML. For more details on this module see the _mod_auth_mellon_ GitHub repo." +msgstr "" + +msgid "To configure mod_auth_mellon you need:" +msgstr "" + +msgid "An Identity Provider (IdP) entity descriptor XML file, which describes the connection to {project_name} or another SAML IdP" +msgstr "" + +msgid "An SP entity descriptor XML file, which describes the SAML connections and configuration for the application you are securing." +msgstr "" + +msgid "A private key PEM file, which is a text file in the PEM format that defines the private key the application uses to sign documents." +msgstr "" + +msgid "A certificate PEM file, which is a text file that defines the certificate for your application." +msgstr "" + +msgid "mod_auth_mellon-specific Apache HTTPD module configuration." +msgstr "" + +msgid "If you have already defined and registered the client application within a realm on the {project_name} application server, {project_name} can generate all the files you need except the Apache HTTPD module configuration." +msgstr "" + +msgid "Perform the following procedure to generate the Apache HTTPD module configuration." +msgstr "" + +msgid "Go to the Installation page of your SAML client." +msgstr "" + +msgid "Select the *Mod Auth Mellon* files option." +msgstr "" + +msgid "mod_auth_mellon config download" +msgstr "" + +msgid "image:images/mod-auth-mellon-config-download.png[]" +msgstr "" + +msgid "Click *Download* to download a ZIP file that contains the XML descriptor and PEM files you need." +msgstr "" + +msgid "Configuring mod_auth_mellon with {project_name}" +msgstr "" + +msgid "There are two hosts involved:" +msgstr "" + +msgid "The host on which {project_name} is running, which will be referred to as $idp_host because {project_name} is a SAML identity provider (IdP)." +msgstr "" + +msgid "The host on which the web application is running, which will be referred to as $sp_host. In SAML an application using an IdP is called a service provider (SP)." +msgstr "" + +msgid "All of the following steps need to performed on $sp_host with root privileges." +msgstr "" + +msgid "Installing the packages" +msgstr "" + +msgid "To install the necessary packages, you will need:" +msgstr "" + +msgid "Apache Web Server (httpd)" +msgstr "" + +msgid "Mellon SAML SP add-on module for Apache" +msgstr "" + +msgid "Tools to create X509 certificates" +msgstr "" + +msgid "To install the necessary packages, run this command:" +msgstr "" + +msgid "yum install httpd mod_auth_mellon mod_ssl openssl" +msgstr "" + +msgid "Creating a configuration directory for Apache SAML" +msgstr "" + +msgid "It is advisable to keep configuration files related to Apache's use of SAML in one location." +msgstr "" + +msgid "Create a new directory named saml2 located under the Apache configuration root /etc/httpd:" +msgstr "" + +msgid "mkdir /etc/httpd/saml2" +msgstr "" + +msgid "Configuring the Mellon Service Provider" +msgstr "" + +msgid "Configuration files for Apache add-on modules are located in the /etc/httpd/conf.d directory and have a file name extension of .conf. You need to create the /etc/httpd/conf.d/mellon.conf file and place Mellon's configuration directives in it." +msgstr "" + +msgid "Mellon's configuration directives can roughly be broken down into two classes of information:" +msgstr "" + +msgid "Which URLs to protect with SAML authentication" +msgstr "" + +msgid "What SAML parameters will be used when a protected URL is referenced." +msgstr "" + +msgid "Apache configuration directives typically follow a hierarchical tree structure in the URL space, which are known as locations. You need to specify one or more URL locations for Mellon to protect. You have flexibility in how you add the configuration parameters that apply to each location. You can either add all the necessary parameters to the location block or you can add Mellon parameters to a common location high up in the URL location hierarchy that specific protected locations inherit (or some combination of the two). Since it is common for an SP to operate in the same way no matter which location triggers SAML actions, the example configuration used here places common Mellon configuration directives in the root of the hierarchy and then specific locations to be protected by Mellon can be defined with minimal directives. This strategy avoids duplicating the same parameters for each protected location." +msgstr "" + +msgid "This example has just one protected location: \\https://$sp_host/private." +msgstr "" + +msgid "To configure the Mellon service provider, perform the following procedure." +msgstr "" + +msgid "Create the file /etc/httpd/conf.d/mellon.conf with this content:" +msgstr "" + +msgid "" +" \n" +" MellonEnable info\n" +" MellonEndpointPath /mellon/\n" +" MellonSPMetadataFile /etc/httpd/saml2/mellon_metadata.xml\n" +" MellonSPPrivateKeyFile /etc/httpd/saml2/mellon.key\n" +" MellonSPCertFile /etc/httpd/saml2/mellon.crt\n" +" MellonIdPMetadataFile /etc/httpd/saml2/idp_metadata.xml\n" +" \n" +" \n" +" AuthType Mellon\n" +" MellonEnable auth\n" +" Require valid-user\n" +" " +msgstr "" + +msgid "Some of the files referenced in the code above are created in later steps." +msgstr "" + +msgid "Setting the SameSite value for the cookie used by mod_auth_mellon" +msgstr "" + +msgid "Browsers are planning to set the default value for the `SameSite` attribute for cookies to `Lax`. This setting means that cookies will be sent to applications only if the request originates in the same domain. This behavior can affect the SAML POST binding which may become non-functional. To preserve full functionality of the _mod_auth_mellon_ module, we recommend setting the `SameSite` value to `None` for the cookie created by _mod_auth_mellon_. Not doing so may result in an inability to login using {project_name}." +msgstr "" + +msgid "To set the `SameSite` value to `None`, add the following configuration to `` tag within your `mellon.conf` file." +msgstr "" + +msgid "" +"MellonSecureCookie On\n" +"MellonCookieSameSite none" +msgstr "" + +msgid "The support for this configuration is available in the _mod_auth_mellon_ module from version 0.16.0." +msgstr "" + +msgid "Creating the Service Provider metadata" +msgstr "" + +msgid "In SAML IdPs and SPs exchange SAML metadata, which is in XML format. The schema for the metadata is a standard, thus assuring participating SAML entities can consume each other's metadata. You need:" +msgstr "" + +msgid "Metadata for the IdP that the SP utilizes" +msgstr "" + +msgid "Metadata describing the SP provided to the IdP" +msgstr "" + +msgid "One of the components of SAML metadata is X509 certificates. These certificates are used for two purposes:" +msgstr "" + +msgid "Sign SAML messages so the receiving end can prove the message originated from the expected party." +msgstr "" + +msgid "Encrypt the message during transport (seldom used because SAML messages typically occur on TLS-protected transports)" +msgstr "" + +msgid "You can use your own certificates if you already have a Certificate Authority (CA) or you can generate a self-signed certificate. For simplicity in this example a self-signed certificate is used." +msgstr "" + +msgid "Because Mellon's SP metadata must reflect the capabilities of the installed version of mod_auth_mellon, must be valid SP metadata XML, and must contain an X509 certificate (whose creation can be obtuse unless you are familiar with X509 certificate generation) the most expedient way to produce the SP metadata is to use a tool included in the mod_auth_mellon package (mellon_create_metadata.sh). The generated metadata can always be edited later because it is a text file. The tool also creates your X509 key and certificate." +msgstr "" + +msgid "SAML IdPs and SPs identify themselves using a unique name known as an EntityID. To use the Mellon metadata creation tool you need:" +msgstr "" + +msgid "The EntityID, which is typically the URL of the SP, and often the URL of the SP where the SP metadata can be retrieved" +msgstr "" + +msgid "The URL where SAML messages for the SP will be consumed, which Mellon calls the MellonEndPointPath." +msgstr "" + +msgid "To create the SP metadata, perform the following procedure." +msgstr "" + +msgid "Create a few helper shell variables:" +msgstr "" + +msgid "" +"fqdn=`hostname`\n" +"mellon_endpoint_url=\"https://${fqdn}/mellon\"\n" +"mellon_entity_id=\"${mellon_endpoint_url}/metadata\"\n" +"file_prefix=\"$(echo \"$mellon_entity_id\" | sed 's/[^A-Za-z.]/_/g' | sed 's/__*/_/g')\"" +msgstr "" + +msgid "Invoke the Mellon metadata creation tool by running this command:" +msgstr "" + +msgid "/usr/libexec/mod_auth_mellon/mellon_create_metadata.sh $mellon_entity_id $mellon_endpoint_url" +msgstr "" + +msgid "Move the generated files to their destination (referenced in the /etc/httpd/conf.d/mellon.conf file created above):" +msgstr "" + +msgid "" +"mv ${file_prefix}.cert /etc/httpd/saml2/mellon.crt\n" +"mv ${file_prefix}.key /etc/httpd/saml2/mellon.key\n" +"mv ${file_prefix}.xml /etc/httpd/saml2/mellon_metadata.xml" +msgstr "" + +msgid "Adding the Mellon Service Provider to the {project_name} Identity Provider" +msgstr "" + +msgid "Assumption: The {project_name} IdP has already been installed on the $idp_host." +msgstr "" + +msgid "{project_name} supports multiple tenancy where all users, clients, and so on are grouped in what is called a realm. Each realm is independent of other realms. You can use an existing realm in your {project_name}, but this example shows how to create a new realm called test_realm and use that realm." +msgstr "" + +msgid "All these operations are performed using the {project_name} Admin Console. You must have the admin username and password for $idp_host to perform the following procedure." +msgstr "" + +msgid "Open the Admin Console and log on by entering the admin username and password." +msgstr "" + +msgid "After logging into the Admin Console, there will be an existing realm. When {project_name} is first set up a root realm, master, is created by default. Any previously created realms are listed in the upper left corner of the Admin Console in a drop-down list." +msgstr "" + +msgid "From the realm drop-down list select *Add realm*." +msgstr "" + +msgid "In the Name field type `test_realm` and click *Create*." +msgstr "" + +msgid "Adding the Mellon Service Provider as a client of the realm" +msgstr "" + +msgid "In {project_name} SAML SPs are known as clients. To add the SP we must be in the Clients section of the realm." +msgstr "" + +msgid "Click the Clients menu item on the left and click *Create* in the upper right corner to create a new client." +msgstr "" + +msgid "Adding the Mellon SP client" +msgstr "" + +msgid "To add the Mellon SP client, perform the following procedure." +msgstr "" + +msgid "Set the client protocol to SAML." +msgstr "" + +msgid "From the Client Protocol drop down list, select *saml*." +msgstr "" + +msgid "Provide the Mellon SP metadata file created above (/etc/httpd/saml2/mellon_metadata.xml)." +msgstr "" + +msgid "Depending on where your browser is running you might have to copy the SP metadata from $sp_host to the machine on which your browser is running so the browser can find the file." +msgstr "" + +msgid "Click *Save*." +msgstr "" + +msgid "Editing the Mellon SP client" +msgstr "" + +msgid "Use this procedure to set important client configuration parameters." +msgstr "" + +msgid "Ensure \"Force POST Binding\" is On." +msgstr "" + +msgid "Add paosResponse to the Valid Redirect URIs list:" +msgstr "" + +msgid "Copy the postResponse URL in \"Valid Redirect URIs\" and paste it into the empty add text fields just below the \"+\"." +msgstr "" + +msgid "Change \"postResponse\" to \"paosResponse\". (The paosResponse URL is needed for SAML ECP.)" +msgstr "" + +msgid "Click *Save* at the bottom." +msgstr "" + +msgid "Many SAML SPs determine authorization based on a user's membership in a group. The {project_name} IdP can manage user group information but it does not supply the user's groups unless the IdP is configured to supply it as a SAML attribute." +msgstr "" + +msgid "Perform the following procedure to configure the IdP to supply the user's groups as a SAML attribute." +msgstr "" + +msgid "Click the Mappers tab of the client." +msgstr "" + +msgid "In the upper right corner of the Mappers page, click *Create*." +msgstr "" + +msgid "From the Mapper Type drop-down list select *Group list*." +msgstr "" + +msgid "Set Name to \"group list\"." +msgstr "" + +msgid "Set the SAML attribute name to \"groups\"." +msgstr "" + +msgid "The remaining steps are performed on $sp_host." +msgstr "" + +msgid "Retrieving the Identity Provider metadata" +msgstr "" + +msgid "Now that you have created the realm on the IdP you need to retrieve the IdP metadata associated with it so the Mellon SP recognizes it. In the /etc/httpd/conf.d/mellon.conf file created previously, the MellonIdPMetadataFile is specified as /etc/httpd/saml2/idp_metadata.xml but until now that file has not existed on $sp_host." +msgstr "" + +msgid "Use this procedure to retrieve that file from the IdP." +msgstr "" + +msgid "Use this command, substituting with the correct value for $idp_host:" +msgstr "" + +msgid "" +"curl -k -o /etc/httpd/saml2/idp_metadata.xml \\\n" +"https://$idp_host{kc_realms_path}/test_realm/protocol/saml/descriptor" +msgstr "" + +msgid "Mellon is now fully configured." +msgstr "" + +msgid "To run a syntax check for Apache configuration files, use this command:" +msgstr "" + +msgid "apachectl configtest" +msgstr "" + +msgid "Configtest is equivalent to the -t argument to apachectl. If the configuration test shows any errors, correct them before proceeding." +msgstr "" + +msgid "Restart the Apache server:" +msgstr "" + +msgid "systemctl restart httpd.service" +msgstr "" + +msgid "You have now set up both {project_name} as a SAML IdP in the test_realm and mod_auth_mellon as SAML SP protecting the URL $sp_host/protected (and everything beneath it) by authenticating against the ``$idp_host`` IdP." +msgstr "" + +msgid "Configuring a Docker registry to use {project_name}" +msgstr "" + +msgid "Docker authentication is disabled by default. To enable see the https://www.keycloak.org/server/features[Enabling and disabling features] {section}." +msgstr "" + +msgid "This section describes how you can configure a Docker registry to use {project_name} as its authentication server." +msgstr "" + +msgid "For more information on how to set up and configure a Docker registry, see the link:https://distribution.github.io/distribution/about/configuration/[Docker Registry Configuration Guide]." +msgstr "" + +msgid "Docker registry configuration file installation" +msgstr "" + +msgid "For users with more advanced Docker registry configurations, it is generally recommended to provide your own registry configuration file. The {project_name} Docker provider supports this mechanism via the _Registry Config File_ Format Option. Choosing this option will generate output similar to the following:" +msgstr "" + +msgid "" +"auth:\n" +" token:\n" +" realm: http://localhost:8080{kc_realms_path}/master/protocol/docker-v2/auth\n" +" service: docker-test\n" +" issuer: http://localhost:8080{kc_realms_path}/master" +msgstr "" + +msgid "This output can then be copied into any existing registry config file. See the link:https://distribution.github.io/distribution/about/configuration/[registry config file specification] for more information on how the file should be set up, or start with link:https://github.com/distribution/distribution/blob/main/cmd/registry/config-example.yml[a basic example]." +msgstr "" + +msgid "Don't forget to configure the `rootcertbundle` field with the location of the {project_name} realm's public key. The auth configuration will not work without this argument." +msgstr "" + +msgid "Docker registry environment variable override installation" +msgstr "" + +msgid "Often times it is appropriate to use a simple environment variable override for develop or POC Docker registries. While this approach is usually not recommended for production use, it can be helpful when one requires quick-and-dirty way to stand up a registry. Simply use the _Variable Override_ Format Option from the client details, and an output should appear like the one below:" +msgstr "" + +msgid "" +"REGISTRY_AUTH_TOKEN_REALM: http://localhost:8080{kc_realms_path}/master/protocol/docker-v2/auth\n" +"REGISTRY_AUTH_TOKEN_SERVICE: docker-test\n" +"REGISTRY_AUTH_TOKEN_ISSUER: http://localhost:8080{kc_realms_path}/master" +msgstr "" + +msgid "Don't forget to configure the `REGISTRY_AUTH_TOKEN_ROOTCERTBUNDLE` override with the location of the {project_name} realm's public key. The auth configuration will not work without this argument." +msgstr "" + +msgid "Docker Compose YAML File" +msgstr "" + +msgid "This installation method is meant to be an easy way to get a docker registry authenticating against a {project_name} server. It is intended for development purposes only and should never be used in a production or production-like environment." +msgstr "" + +msgid "The zip file installation mechanism provides a quickstart for developers who want to understand how the {project_name} server can interact with the Docker registry. In order to configure:" +msgstr "" + +msgid "From the desired realm, create a client configuration. At this point you will not have a Docker registry - the quickstart will take care of that part." +msgstr "" + +msgid "Choose the \"Docker Compose YAML\" option from the from _Action_ menu and select the *Download adapter config* option to download the ZIP file." +msgstr "" + +msgid "Unzip the archive to the desired location, and open the directory." +msgstr "" + +msgid "Start the Docker registry with `docker-compose up`" +msgstr "" + +msgid "it is recommended that you configure the Docker registry client in a realm other than 'master', since the HTTP Basic auth flow will not present forms." +msgstr "" + +msgid "Once the above configuration has taken place, and the keycloak server and Docker registry are running, docker authentication should be successful:" +msgstr "" + +msgid "" +"[user ~]# docker login localhost:5000 -u $username\n" +"Password: *******\n" +"Login Succeeded" +msgstr "" + +msgid "Using the client registration service" +msgstr "" + +msgid "In order for an application or service to utilize {project_name} it has to register a client in {project_name}. An admin can do this through the admin console (or admin REST endpoints), but clients can also register themselves through the {project_name} client registration service." +msgstr "" + +msgid "The Client Registration Service provides built-in support for {project_name} Client Representations, OpenID Connect Client Meta Data and SAML Entity Descriptors. The Client Registration Service endpoint is `{kc_realms_path}//clients-registrations/`." +msgstr "" + +msgid "The built-in supported `providers` are:" +msgstr "" + +msgid "default - {project_name} Client Representation (JSON)" +msgstr "" + +msgid "install - {project_name} Adapter Configuration (JSON)" +msgstr "" + +msgid "openid-connect - OpenID Connect Client Metadata Description (JSON)" +msgstr "" + +msgid "saml2-entity-descriptor - SAML Entity Descriptor (XML)" +msgstr "" + +msgid "The following sections will describe how to use the different providers." +msgstr "" + +msgid "Authentication" +msgstr "" + +msgid "To invoke the Client Registration Services you usually need a token. The token can be a bearer token, an initial access token or a registration access token. There is an alternative to register new client without any token as well, but then you need to configure Client Registration Policies (see below)." +msgstr "" + +msgid "Bearer token" +msgstr "" + +msgid "The bearer token can be issued on behalf of a user or a Service Account. The following permissions are required to invoke the endpoints (see link:{adminguide_link}[{adminguide_name}] for more details):" +msgstr "" + +msgid "create-client or manage-client - To create clients" +msgstr "" + +msgid "view-client or manage-client - To view clients" +msgstr "" + +msgid "manage-client - To update or delete client" +msgstr "" + +msgid "If you are using a bearer token to create clients it's recommend to use a token from a Service Account with only the `create-client` role (see link:{adminguide_link}[{adminguide_name}] for more details)." +msgstr "" + +msgid "Initial Access Token" +msgstr "" + +msgid "The recommended approach to registering new clients is by using initial access tokens. An initial access token can only be used to create clients and has a configurable expiration as well as a configurable limit on how many clients can be created." +msgstr "" + +msgid "An initial access token can be created through the admin console. To create a new initial access token first select the realm in the admin console, then click on `Client` in the menu on the left, followed by `Initial access token` in the tabs displayed in the page." +msgstr "" + +msgid "You will now be able to see any existing initial access tokens. If you have access you can delete tokens that are no longer required. You can only retrieve the value of the token when you are creating it. To create a new token click on `Create`. You can now optionally add how long the token should be valid, also how many clients can be created using the token. After you click on `Save` the token value is displayed." +msgstr "" + +msgid "It is important that you copy/paste this token now as you won't be able to retrieve it later. If you forget to copy/paste it, then delete the token and create another one." +msgstr "" + +msgid "The token value is used as a standard bearer token when invoking the Client Registration Services, by adding it to the Authorization header in the request. For example:" +msgstr "" + +msgid "Authorization: bearer eyJhbGciOiJSUz..." +msgstr "" + +msgid "Registration Access Token" +msgstr "" + +msgid "When you create a client through the Client Registration Service the response will include a registration access token. The registration access token provides access to retrieve the client configuration later, but also to update or delete the client. The registration access token is included with the request in the same way as a bearer token or initial access token." +msgstr "" + +msgid "By default, registration access token rotation is enabled. This means a registration access token is only valid once. When the token is used, the response will include a new token. Note that registration access token rotation can be disabled by using link:{adminguide_link}#_client_policies[Client Policies]." +msgstr "" + +msgid "If a client was created outside of the Client Registration Service it won't have a registration access token associated with it. You can create one through the admin console. This can also be useful if you lose the token for a particular client. To create a new token find the client in the admin console and click on `Credentials`. Then click on `Generate registration access token`." +msgstr "" + +msgid "{project_name} Representations" +msgstr "" + +msgid "The `default` client registration provider can be used to create, retrieve, update and delete a client. It uses {project_name} Client Representation format which provides support for configuring clients exactly as they can be configured through the admin console, including for example configuring protocol mappers." +msgstr "" + +msgid "To create a client create a Client Representation (JSON) then perform an HTTP POST request to `{kc_realms_path}//clients-registrations/default`." +msgstr "" + +msgid "It will return a Client Representation that also includes the registration access token. You should save the registration access token somewhere if you want to retrieve the config, update or delete the client later." +msgstr "" + +msgid "To retrieve the Client Representation perform an HTTP GET request to `{kc_realms_path}//clients-registrations/default/`." +msgstr "" + +msgid "It will also return a new registration access token." +msgstr "" + +msgid "To update the Client Representation perform an HTTP PUT request with the updated Client Representation to: `{kc_realms_path}//clients-registrations/default/`." +msgstr "" + +msgid "To delete the Client Representation perform an HTTP DELETE request to: `{kc_realms_path}//clients-registrations/default/`" +msgstr "" + +msgid "{project_name} adapter configuration" +msgstr "" + +msgid "The `installation` client registration provider can be used to retrieve the adapter configuration for a client. In addition to token authentication you can also authenticate with client credentials using HTTP basic authentication. To do this include the following header in the request:" +msgstr "" + +msgid "Authorization: basic BASE64(client-id + ':' + client-secret)" +msgstr "" + +msgid "To retrieve the Adapter Configuration then perform an HTTP GET request to `{kc_realms_path}//clients-registrations/install/`." +msgstr "" + +msgid "No authentication is required for public clients. This means that for the JavaScript adapter you can load the client configuration directly from {project_name} using the above URL." +msgstr "" + +msgid "OpenID Connect Dynamic Client Registration" +msgstr "" + +msgid "{project_name} implements https://openid.net/specs/openid-connect-registration-1_0.html[OpenID Connect Dynamic Client Registration], which extends https://datatracker.ietf.org/doc/html/rfc7591[OAuth 2.0 Dynamic Client Registration Protocol] and https://datatracker.ietf.org/doc/html/rfc7592[OAuth 2.0 Dynamic Client Registration Management Protocol]." +msgstr "" + +msgid "The endpoint to use these specifications to register clients in {project_name} is `{kc_realms_path}//clients-registrations/openid-connect[/]`." +msgstr "" + +msgid "This endpoint can also be found in the OpenID Connect Discovery endpoint for the realm, `{kc_realms_path}//.well-known/openid-configuration`." +msgstr "" + +msgid "SAML Entity Descriptors" +msgstr "" + +msgid "The SAML Entity Descriptor endpoint only supports using SAML v2 Entity Descriptors to create clients. It doesn't support retrieving, updating or deleting clients. For those operations the {project_name} representation endpoints should be used. When creating a client a {project_name} Client Representation is returned with details about the created client, including a registration access token." +msgstr "" + +msgid "To create a client perform an HTTP POST request with the SAML Entity Descriptor to `{kc_realms_path}//clients-registrations/saml2-entity-descriptor`." +msgstr "" + +msgid "The following example creates a client with the clientId `myclient` using CURL. You need to replace `eyJhbGciOiJSUz...` with a proper initial access token or bearer token." +msgstr "" + +msgid "" +"curl -X POST \\\n" +" -d '{ \"clientId\": \"myclient\" }' \\\n" +" -H \"Content-Type:application/json\" \\\n" +" -H \"Authorization: bearer eyJhbGciOiJSUz...\" \\\n" +" http://localhost:8080{kc_realms_path}/master/clients-registrations/default" +msgstr "" + +msgid "Example using Java Client Registration API" +msgstr "" + +msgid "The Client Registration Java API makes it easy to use the Client Registration Service using Java. To use include the dependency `org.keycloak:keycloak-client-registration-api:>VERSION<` from Maven." +msgstr "" + +msgid "For full instructions on using the Client Registration refer to the JavaDocs. Below is an example of creating a client. You need to replace `eyJhbGciOiJSUz...` with a proper initial access token or bearer token." +msgstr "" + +msgid "" +"String token = \"eyJhbGciOiJSUz...\";\n" +"\n" +"ClientRepresentation client = new ClientRepresentation();\n" +"client.setClientId(CLIENT_ID);\n" +"\n" +"ClientRegistration reg = ClientRegistration.create()\n" +" .url(\"http://localhost:8080{kc_base_path}\", \"myrealm\")\n" +" .build();\n" +"\n" +"reg.auth(Auth.token(token));\n" +"\n" +"client = reg.create(client);\n" +"\n" +"String registrationAccessToken = client.getRegistrationAccessToken();" +msgstr "" + +msgid "Client Registration Policies" +msgstr "" + +msgid "The current plans are for the Client Registration Policies to be removed in favor of the Client Policies described in the link:{adminguide_link}#_client_policies[{adminguide_name}]. Client Policies are more flexible and support more use cases." +msgstr "" + +msgid "{project_name} currently supports two ways how new clients can be registered through Client Registration Service." +msgstr "" + +msgid "Authenticated requests - Request to register new client must contain either `Initial Access Token` or `Bearer Token` as mentioned above." +msgstr "" + +msgid "Anonymous requests - Request to register new client doesn't need to contain any token at all" +msgstr "" + +msgid "Anonymous client registration requests are very interesting and powerful feature, however you usually don't want that anyone is able to register new client without any limitations. Hence we have `Client Registration Policy SPI`, which provide a way to limit who can register new clients and under which conditions." +msgstr "" + +msgid "In {project_name} admin console, you can click to `Client Registration` tab and then `Client Registration Policies` sub-tab. Here you will see what policies are configured by default for anonymous requests and what policies are configured for authenticated requests." +msgstr "" + +msgid "The anonymous requests (requests without any token) are allowed just for creating (registration) of new clients. So when you register new client through anonymous request, the response will contain Registration Access Token, which must be used for Read, Update or Delete request of particular client. However using this Registration Access Token from anonymous registration will be then subject to Anonymous Policy too! This means that for example request for update client also needs to come from Trusted Host if you have `Trusted Hosts` policy. Also for example it won't be allowed to disable `Consent Required` when updating client and when `Consent Required` policy is present etc." +msgstr "" + +msgid "Currently we have these policy implementations:" +msgstr "" + +msgid "Trusted Hosts Policy - You can configure list of trusted hosts and trusted domains. Request to Client Registration Service can be sent just from those hosts or domains. Request sent from some untrusted IP will be rejected. URLs of newly registered client must also use just those trusted hosts or domains. For example it won't be allowed to set `Redirect URI` of client pointing to some untrusted host. By default, there is not any whitelisted host, so anonymous client registration is de-facto disabled." +msgstr "" + +msgid "Consent Required Policy - Newly registered clients will have `Consent Allowed` switch enabled. So after successful authentication, user will always see consent screen when he needs to approve permissions (client scopes). It means that client won't have access to any personal info or permission of user unless user approves it." +msgstr "" + +msgid "Protocol Mappers Policy - Allows to configure list of whitelisted protocol mapper implementations. New client can't be registered or updated if it contains some non-whitelisted protocol mapper. Note that this policy is used for authenticated requests as well, so even for authenticated request there are some limitations which protocol mappers can be used." +msgstr "" + +msgid "Client Scope Policy - Allow to whitelist `Client Scopes`, which can be used with newly registered or updated clients. There are no whitelisted scopes by default; only the client scopes, which are defined as `Realm Default Client Scopes` are whitelisted by default." +msgstr "" + +msgid "Full Scope Policy - Newly registered clients will have `Full Scope Allowed` switch disabled. This means they won't have any scoped realm roles or client roles of other clients." +msgstr "" + +msgid "Max Clients Policy - Rejects registration if current number of clients in the realm is same or bigger than specified limit. It's 200 by default for anonymous registrations." +msgstr "" + +msgid "Client Disabled Policy - Newly registered client will be disabled. This means that admin needs to manually approve and enable all newly registered clients. This policy is not used by default even for anonymous registration." +msgstr "" + +msgid "Automating Client Registration with the CLI" +msgstr "" + +msgid "The Client Registration CLI is a command-line interface (CLI) tool for application developers to configure new clients in a self-service manner when integrating with {project_name}. It is specifically designed to interact with {project_name} Client Registration REST endpoints." +msgstr "" + +msgid "It is necessary to create or obtain a client configuration for any application to be able to use {project_name}. You usually configure a new client for each new application hosted on a unique host name. When an application interacts with {project_name}, the application identifies itself with a client ID so {project_name} can provide a login page, single sign-on (SSO) session management, and other services." +msgstr "" + +msgid "You can configure application clients from a command line with the Client Registration CLI, and you can use it in shell scripts." +msgstr "" + +msgid "To allow a particular user to use `Client Registration CLI` the {project_name} administrator typically uses the Admin Console to configure a new user with proper roles or to configure a new client and client secret to grant access to the Client Registration REST API." +msgstr "" + +msgid "Configuring a new regular user for use with Client Registration CLI" +msgstr "" + +msgid "Log in to the Admin Console (for example, http://localhost:8080{kc_admins_path}) as [command]`admin`." +msgstr "" + +msgid "Select a realm to administer." +msgstr "" + +msgid "If you want to use an existing user, select that user to edit; otherwise, create a new user." +msgstr "" + +msgid "Select *Role Mappings > Client Roles > realm-management*. If you are in the master realm, select *NAME-realm*, where `NAME` is the name of the target realm. You can grant access to any other realm to users in the master realm." +msgstr "" + +msgid "Select *Available Roles > manage-client* to grant a full set of client management permissions. Another option is to choose *view-clients* for read-only or *create-client* to create new clients." +msgstr "" + +msgid "These permissions grant the user the capability to perform operations without the use of <<_initial_access_token,Initial Access Token>> or <<_registration_access_token,Registration Access Token>>." +msgstr "" + +msgid "It is possible to not assign any [command]`realm-management` roles to a user. In that case, a user can still log in with the Client Registration CLI but cannot use it without an Initial Access Token. Trying to perform any operations without a token results in a *403 Forbidden* error." +msgstr "" + +msgid "The Administrator can issue Initial Access Tokens from the Admin Console through the *Realm Settings > Client Registration > Initial Access Token* menu." +msgstr "" + +msgid "Configuring a client for use with the Client Registration CLI" +msgstr "" + +msgid "By default, the server recognizes the Client Registration CLI as the [filename]`admin-cli` client, which is configured automatically for every new realm. No additional client configuration is necessary when logging in with a user name." +msgstr "" + +msgid "Create a client (for example, [filename]`reg-cli`) if you want to use a separate client configuration for the Client Registration CLI." +msgstr "" + +msgid "Toggle the *Standard Flow Enabled* setting it to *Off*." +msgstr "" + +msgid "Strengthen the security by configuring the client [filename]`Access Type` as [filename]`Confidential` and selecting *Credentials > ClientId and Secret*." +msgstr "" + +msgid "You can configure either [filename]`Client Id and Secret` or [filename]`Signed JWT` under the *Credentials* tab ." +msgstr "" + +msgid "Enable service accounts if you want to use a service account associated with the client by selecting a client to edit in the *Clients* section of the `Admin Console`." +msgstr "" + +msgid "Under *Settings*, change the *Access Type* to *Confidential*, toggle the *Service Accounts Enabled* setting to *On*, and click *Save*." +msgstr "" + +msgid "Click *Service Account Roles* and select desired roles to configure the access for the service account. For the details on what roles to select, see <<_configuring_a_user_for_client_registration_cli>>." +msgstr "" + +msgid "Toggle the *Direct Access Grants Enabled* setting it to *On* if you want to use a regular user account instead of a service account." +msgstr "" + +msgid "If the client is configured as [filename]`Confidential`, provide the configured secret when running [command]`kcreg config credentials` by using the [command]`--secret` option." +msgstr "" + +msgid "Specify which [filename]`clientId` to use (for example, [command]`--client reg-cli`) when running [command]`kcreg config credentials`." +msgstr "" + +msgid "With the service account enabled, you can omit specifying the user when running [command]`kcreg config credentials` and only provide the client secret or keystore information." +msgstr "" + +msgid "Installing the Client Registration CLI" +msgstr "" + +msgid "The Client Registration CLI is packaged inside the {project_name} Server distribution. You can find execution scripts inside the [filename]`bin` directory. The Linux script is called [filename]`kcreg.sh`, and the Windows script is called [filename]`kcreg.bat`." +msgstr "" + +msgid "Add the {project_name} server directory to your [filename]`PATH` when setting up the client for use from any location on the file system." +msgstr "" + +msgid "For example, on:" +msgstr "" + +msgid "Linux:" +msgstr "" + +msgid "" +"$ export PATH=$PATH:$KEYCLOAK_HOME/bin\n" +"$ kcreg.sh" +msgstr "" + +msgid "Windows:" +msgstr "" + +msgid "" +"c:\\> set PATH=%PATH%;%KEYCLOAK_HOME%\\bin\n" +"c:\\> kcreg" +msgstr "" + +msgid "[filename]`KEYCLOAK_HOME` refers to a directory where the {project_name} Server distribution was unpacked." +msgstr "" + +msgid "Using the Client Registration CLI" +msgstr "" + +msgid "Start an authenticated session by logging in with your credentials." +msgstr "" + +msgid "Run commands on the [filename]`Client Registration REST` endpoint." +msgstr "" + +msgid "" +"$ kcreg.sh config credentials --server http://localhost:8080{kc_base_path} --realm demo --user user --client reg-cli\n" +"$ kcreg.sh create -s clientId=my_client -s 'redirectUris=[\"http://localhost:8980/myapp/*\"]'\n" +"$ kcreg.sh get my_client" +msgstr "" + +msgid "" +"c:\\> kcreg config credentials --server http://localhost:8080{kc_base_path} --realm demo --user user --client reg-cli\n" +"c:\\> kcreg create -s clientId=my_client -s \"redirectUris=[\\\"http://localhost:8980/myapp/*\\\"]\"\n" +"c:\\> kcreg get my_client" +msgstr "" + +msgid "In a production environment, {project_name} has to be accessed with [filename]`https:` to avoid exposing tokens to network sniffers." +msgstr "" + +msgid "If a server's certificate is not issued by one of the trusted certificate authorities (CAs) that are included in Java's default certificate truststore, prepare a [filename]`truststore.jks` file and instruct the Client Registration CLI to use it." +msgstr "" + +msgid "$ kcreg.sh config truststore --trustpass $PASSWORD ~/.keycloak/truststore.jks" +msgstr "" + +msgid "c:\\> kcreg config truststore --trustpass %PASSWORD% %HOMEPATH%\\.keycloak\\truststore.jks" +msgstr "" + +msgid "Logging in" +msgstr "" + +msgid "Specify a server endpoint URL and a realm when you log in with the Client Registration CLI." +msgstr "" + +msgid "Specify a user name or a client id, which results in a special service account being used. When using a user name, you must use a password for the specified user. When using a client ID, you use a client secret or a [filename]`Signed JWT` instead of a password." +msgstr "" + +msgid "Regardless of the login method, the account that logs in needs proper permissions to be able to perform client registration operations. Keep in mind that any account in a non-master realm can only have permissions to manage clients within the same realm. If you need to manage different realms, you can either configure multiple users in different realms, or you can create a single user in the [filename]`master` realm and add roles for managing clients in different realms." +msgstr "" + +msgid "You cannot configure users with the Client Registration CLI. Use the Admin Console web interface or the Admin Client CLI to configure users. See link:{adminguide_link}[{adminguide_name}] for more details." +msgstr "" + +msgid "When [filename]`kcreg` successfully logs in, it receives authorization tokens and saves them in a private configuration file so the tokens can be used for subsequent invocations. See <<_working_with_alternative_configurations>> for more information on configuration files." +msgstr "" + +msgid "See the built-in help for more information on using the Client Registration CLI." +msgstr "" + +msgid "$ kcreg.sh help" +msgstr "" + +msgid "c:\\> kcreg help" +msgstr "" + +msgid "See [filename]`kcreg config credentials --help` for more information about starting an authenticated session." +msgstr "" + +msgid "Working with alternative configurations" +msgstr "" + +msgid "By default, the Client Registration CLI automatically maintains a configuration file at a default location, [filename]`./.keycloak/kcreg.config`, under the user's home directory. You can use the [command]`--config` option to point to a different file or location to maintain multiple authenticated sessions in parallel. It is the safest way to perform operations tied to a single configuration file from a single thread." +msgstr "" + +msgid "Do not make the configuration file visible to other users on the system. The configuration file contains access tokens and secrets that should be kept private." +msgstr "" + +msgid "You might want to avoid storing secrets inside a configuration file by using the [command]`--no-config` option with all of your commands, even though it is less convenient and requires more token requests to do so. Specify all authentication information with each [command]`kcreg` invocation." +msgstr "" + +msgid "Initial Access and Registration Access Tokens" +msgstr "" + +msgid "Developers who do not have an account configured at the {project_name} server they want to use can use the Client Registration CLI. This is possible only when the realm administrator issues a developer an Initial Access Token. It is up to the realm administrator to decide how and when to issue and distribute these tokens. The realm administrator can limit the maximum age of the Initial Access Token and the total number of clients that can be created with it." +msgstr "" + +msgid "Once a developer has an Initial Access Token, the developer can use it to create new clients without authenticating with [command]`kcreg config credentials`. The Initial Access Token can be stored in the configuration file or specified as part of the [command]`kcreg create` command." +msgstr "" + +msgid "" +"$ kcreg.sh config initial-token $TOKEN\n" +"$ kcreg.sh create -s clientId=myclient" +msgstr "" + +msgid "or" +msgstr "" + +msgid "$ kcreg.sh create -s clientId=myclient -t $TOKEN" +msgstr "" + +msgid "" +"c:\\> kcreg config initial-token %TOKEN%\n" +"c:\\> kcreg create -s clientId=myclient" +msgstr "" + +msgid "c:\\> kcreg create -s clientId=myclient -t %TOKEN%" +msgstr "" + +msgid "When using an Initial Access Token, the server response includes a newly issued Registration Access Token. Any subsequent operation for that client needs to be performed by authenticating with that token, which is only valid for that client." +msgstr "" + +msgid "The Client Registration CLI automatically uses its private configuration file to save and use this token with its associated client. As long as the same configuration file is used for all client operations, the developer does not need to authenticate to read, update, or delete a client that was created this way." +msgstr "" + +msgid "See <<_client_registration, Client Registration>> for more information about Initial Access and Registration Access Tokens." +msgstr "" + +msgid "Run the [command]`kcreg config initial-token --help` and [command]`kcreg config registration-token --help` commands for more information on how to configure tokens with the Client Registration CLI." +msgstr "" + +msgid "Creating a client configuration" +msgstr "" + +msgid "The first task after authenticating with credentials or configuring an Initial Access Token is usually to create a new client. Often you might want to use a prepared JSON file as a template and set or override some of the attributes." +msgstr "" + +msgid "The following example shows how to read a JSON file, override any client id it may contain, set any other attributes, and print the configuration to a standard output after successful creation." +msgstr "" + +msgid "$ kcreg.sh create -f client-template.json -s clientId=myclient -s baseUrl=/myclient -s 'redirectUris=[\"/myclient/*\"]' -o" +msgstr "" + +msgid "C:\\> kcreg create -f client-template.json -s clientId=myclient -s baseUrl=/myclient -s \"redirectUris=[\\\"/myclient/*\\\"]\" -o" +msgstr "" + +msgid "Run the [command]`kcreg create --help` for more information about the [command]`kcreg create` command." +msgstr "" + +msgid "You can use [command]`kcreg attrs` to list available attributes. Keep in mind that many configuration attributes are not checked for validity or consistency. It is up to you to specify proper values. Remember that you should not have any id fields in your template and should not specify them as arguments to the [command]`kcreg create` command." +msgstr "" + +msgid "Retrieving a client configuration" +msgstr "" + +msgid "You can retrieve an existing client by using the [command]`kcreg get` command." +msgstr "" + +msgid "$ kcreg.sh get myclient" +msgstr "" + +msgid "C:\\> kcreg get myclient" +msgstr "" + +msgid "You can also retrieve the client configuration as an adapter configuration file, which you can package with your web application." +msgstr "" + +msgid "$ kcreg.sh get myclient -e install > keycloak.json" +msgstr "" + +msgid "C:\\> kcreg get myclient -e install > keycloak.json" +msgstr "" + +msgid "Run the [command]`kcreg get --help` command for more information about the [command]`kcreg get` command." +msgstr "" + +msgid "Modifying a client configuration" +msgstr "" + +msgid "There are two methods for updating a client configuration." +msgstr "" + +msgid "One method is to submit a complete new state to the server after getting the current configuration, saving it to a file, editing it, and posting it back to the server." +msgstr "" + +msgid "" +"$ kcreg.sh get myclient > myclient.json\n" +"$ vi myclient.json\n" +"$ kcreg.sh update myclient -f myclient.json" +msgstr "" + +msgid "" +"C:\\> kcreg get myclient > myclient.json\n" +"C:\\> notepad myclient.json\n" +"C:\\> kcreg update myclient -f myclient.json" +msgstr "" + +msgid "The second method fetches the current client, sets or deletes fields on it, and posts it back in one step." +msgstr "" + +msgid "$ kcreg.sh update myclient -s enabled=false -d redirectUris" +msgstr "" + +msgid "C:\\> kcreg update myclient -s enabled=false -d redirectUris" +msgstr "" + +msgid "You can also use a file that contains only changes to be applied so you do not have to specify too many values as arguments. In this case, specify [command]`--merge` to tell the Client Registration CLI that rather than treating the JSON file as a full, new configuration, it should treat it as a set of attributes to be applied over the existing configuration." +msgstr "" + +msgid "$ kcreg.sh update myclient --merge -d redirectUris -f mychanges.json" +msgstr "" + +msgid "C:\\> kcreg update myclient --merge -d redirectUris -f mychanges.json" +msgstr "" + +msgid "Run the [command]`kcreg update --help` command for more information about the [command]`kcreg update` command." +msgstr "" + +msgid "Deleting a client configuration" +msgstr "" + +msgid "Use the following example to delete a client." +msgstr "" + +msgid "$ kcreg.sh delete myclient" +msgstr "" + +msgid "C:\\> kcreg delete myclient" +msgstr "" + +msgid "Run the [command]`kcreg delete --help` command for more information about the [command]`kcreg delete` command." +msgstr "" + +msgid "Refreshing invalid Registration Access Tokens" +msgstr "" + +msgid "When performing a create, read, update, and delete (CRUD) operation using the [command]`--no-config` mode, the Client Registration CLI cannot handle Registration Access Tokens for you. In that case, it is possible to lose track of the most recently issued Registration Access Token for a client, which makes it impossible to perform any further CRUD operations on that client without authenticating with an account that has *manage-clients* permissions." +msgstr "" + +msgid "If you have permissions, you can issue a new Registration Access Token for the client and have it printed to a standard output or saved to a configuration file of your choice. Otherwise, you have to ask the realm administrator to issue a new Registration Access Token for your client and send it to you. You can then pass it to any CRUD command via the [command]`--token` option. You can also use the [command]`kcreg config registration-token` command to save the new token in a configuration file and have the Client Registration CLI automatically handle it for you from that point on." +msgstr "" + +msgid "Run the [command]`kcreg update-token --help` command for more information about the [command]`kcreg update-token` command." +msgstr "" + +msgid "Q: When logging in, I get an error: *Parameter client_assertion_type is missing [invalid_client]*." +msgstr "" + +msgid "A: This error means your client is configured with [filename]`Signed JWT` token credentials, which means you have to use the [command]`--keystore` parameter when logging in." +msgstr "" + +msgid "Using token exchange" +msgstr "" + +msgid "{tech_feature_name} is *Technology Preview* and is not fully supported. This feature is disabled by default." +msgstr "" + +msgid "To enable start the server with `--features=preview` or `--features={tech_feature_id}`" +msgstr "" + +msgid "To use more than the <<_internal-token-to-internal-token-exchange,Internal Token to Internal Token Exchange>> flow, also enable the `admin-fine-grained-authz` feature. For details, see the https://www.keycloak.org/server/features[Enabling and disabling features] {section}." +msgstr "" + +msgid "How token exchange works" +msgstr "" + +msgid "In {project_name}, token exchange is the process of using a set of credentials or token to obtain an entirely different token. A client may want to invoke on a less trusted application so it may want to downgrade the current token it has. A client may want to exchange a {project_name} token for a token stored for a linked social provider account. You may want to trust external tokens minted by other {project_name} realms or foreign IDPs. A client may have a need to impersonate a user. Here's a short summary of the current capabilities of {project_name} around token exchange." +msgstr "" + +msgid "A client can exchange an existing {project_name} token created for a specific client for a new token targeted to a different client" +msgstr "" + +msgid "A client can exchange an existing {project_name} token for an external token, i.e. a linked Facebook account" +msgstr "" + +msgid "A client can exchange an external token for a {project_name} token." +msgstr "" + +msgid "A client can impersonate a user" +msgstr "" + +msgid "Token exchange in {project_name} is a very loose implementation of the link:https://datatracker.ietf.org/doc/html/rfc8693[OAuth Token Exchange] specification at the IETF. We have extended it a little, ignored some of it, and loosely interpreted other parts of the specification. It is a simple grant type invocation on a realm's OpenID Connect token endpoint." +msgstr "" + +msgid "{kc_realms_path}/{realm}/protocol/openid-connect/token" +msgstr "" + +msgid "It accepts form parameters (`application/x-www-form-urlencoded`) as input and the output depends on the type of token you requested an exchange for. Token exchange is a client endpoint so requests must provide authentication information for the calling client. Public clients specify their client identifier as a form parameter. Confidential clients can also use form parameters to pass their client id and secret, Basic Auth, or however your admin has configured the client authentication flow in your realm." +msgstr "" + +msgid "Form parameters" +msgstr "" + +msgid "client_id" +msgstr "" + +msgid "_REQUIRED MAYBE._ This parameter is required for clients using form parameters for authentication. If you are using Basic Auth, a client JWT token, or client cert authentication, then do not specify this parameter." +msgstr "" + +msgid "client_secret" +msgstr "" + +msgid "_REQUIRED MAYBE_. This parameter is required for clients using form parameters for authentication and using a client secret as a credential. Do not specify this parameter if client invocations in your realm are authenticated by a different means." +msgstr "" + +msgid "grant_type" +msgstr "" + +msgid "_REQUIRED._ The value of the parameter must be `urn:ietf:params:oauth:grant-type:token-exchange`." +msgstr "" + +msgid "subject_token" +msgstr "" + +msgid "_OPTIONAL._ A security token that represents the identity of the party on behalf of whom the request is being made. It is required if you are exchanging an existing token for a new one." +msgstr "" + +msgid "subject_issuer" +msgstr "" + +msgid "_OPTIONAL._ Identifies the issuer of the `subject_token`. It can be left blank if the token comes from the current realm or if the issuer can be determined from the `subject_token_type`. Otherwise it is required to be specified. Valid values are the alias of an `Identity Provider` configured for your realm. Or an issuer claim identifier configured by a specific `Identity Provider`." +msgstr "" + +msgid "subject_token_type" +msgstr "" + +msgid "_OPTIONAL._ This parameter is the type of the token passed with the `subject_token` parameter. This defaults to `urn:ietf:params:oauth:token-type:access_token` if the `subject_token` comes from the realm and is an access token. If it is an external token, this parameter may or may not have to be specified depending on the requirements of the `subject_issuer`." +msgstr "" + +msgid "requested_token_type" +msgstr "" + +msgid "_OPTIONAL._ This parameter represents the type of token the client wants to exchange for. Currently only oauth and OpenID Connect token types are supported. The default value for this depends on whether it is `urn:ietf:params:oauth:token-type:refresh_token` in which case you will be returned both an access token and refresh token within the response. Other appropriate values are `urn:ietf:params:oauth:token-type:access_token` and `urn:ietf:params:oauth:token-type:id_token`" +msgstr "" + +msgid "audience" +msgstr "" + +msgid "_OPTIONAL._ This parameter specifies the target client you want the new token minted for." +msgstr "" + +msgid "requested_issuer" +msgstr "" + +msgid "_OPTIONAL._ This parameter specifies that the client wants a token minted by an external provider. It must be the alias of an `Identity Provider` configured within the realm." +msgstr "" + +msgid "requested_subject" +msgstr "" + +msgid "_OPTIONAL._ This specifies a username or user id if your client wants to impersonate a different user." +msgstr "" + +msgid "scope" +msgstr "" + +msgid "_NOT IMPLEMENTED._ This parameter represents the target set of OAuth and OpenID Connect scopes the client is requesting. It is not implemented at this time but will be once {project_name} has better support for scopes in general." +msgstr "" + +msgid "We currently only support OpenID Connect and OAuth exchanges. Support for SAML based clients and identity providers may be added in the future depending on user demand." +msgstr "" + +msgid "Responses from a token exchange request" +msgstr "" + +msgid "A successful response from an exchange invocation will return the HTTP 200 response code with a content type that depends on the `requested-token-type` and `requested_issuer` the client asks for. OAuth requested token types will return a JSON document as described in the link:https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-16[OAuth Token Exchange] specification." +msgstr "" + +msgid "" +"{\n" +" \"access_token\" : \".....\",\n" +" \"refresh_token\" : \".....\",\n" +" \"expires_in\" : \"....\"\n" +" }" +msgstr "" + +msgid "Clients requesting a refresh token will get back both an access and refresh token in the response. Clients requesting only access token type will only get an access token in the response. Expiration information may or may not be included for clients requesting an external issuer through the `requested_issuer` parameter." +msgstr "" + +msgid "Error responses generally fall under the 400 HTTP response code category, but other error status codes may be returned depending on the severity of the error. Error responses may include content depending on the `requested_issuer`. OAuth based exchanges may return a JSON document as follows:" +msgstr "" + +msgid "" +"{\n" +" \"error\" : \"....\"\n" +" \"error_description\" : \"....\"\n" +"}" +msgstr "" + +msgid "Additional error claims may be returned depending on the exchange type. For example, OAuth Identity Providers may include an additional `account-link-url` claim if the user does not have a link to an identity provider. This link can be used for a client initiated link request." +msgstr "" + +msgid "Token exchange setup requires knowledge of fine grain admin permissions (See the link:{adminguide_link}[{adminguide_name}] for more information). You will need to grant clients permission to exchange. This is discussed more later in this chapter." +msgstr "" + +msgid "The rest of this chapter discusses the setup requirements and provides examples for different exchange scenarios. For simplicity's sake, let's call a token minted by the current realm as an _internal_ token and a token minted by an external realm or identity provider as an _external_ token." +msgstr "" + +msgid "Internal token to internal token exchange" +msgstr "" + +msgid "With an internal token to token exchange you have an existing token minted to a specific client and you want to exchange this token for a new one minted for a different target client. Why would you want to do this? This generally happens when a client has a token minted for itself, and needs to make additional requests to other applications that require different claims and permissions within the access token. Other reasons this type of exchange might be required is if you need to perform a \"permission downgrade\" where your app needs to invoke on a less trusted app and you don't want to propagate your current access token." +msgstr "" + +msgid "Granting permission for the exchange" +msgstr "" + +msgid "Clients that want to exchange tokens for a different client need to be authorized in the Admin Console. You need to define a `token-exchange` fine grain permission in the target client you want permission to exchange to." +msgstr "" + +msgid "Target Client Permission" +msgstr "" + +msgid "image:images/exchange-target-client-permission-unset.png[Target Client Permission]" +msgstr "" + +msgid "Toggle *Permissions Enabled* to *On*." +msgstr "" + +msgid "image:images/exchange-target-client-permission-set.png[Target Client Exchange Permission Set]" +msgstr "" + +msgid "That page displays a *token-exchange* link." +msgstr "" + +msgid "Click that link to start defining the permission." +msgstr "" + +msgid "This setup page displays." +msgstr "" + +msgid "Target Client Exchange Permission Setup" +msgstr "" + +msgid "image:images/exchange-target-client-permission-setup.png[Target Client Exchange Permission Setup]" +msgstr "" + +msgid "Click *Client details* in the breadcrumbs at the top of the screen." +msgstr "" + +msgid "Define a policy for this permission." +msgstr "" + +msgid "Click *Authorization* in the breadcrumbs at the top of the screen." +msgstr "" + +msgid "Click the *Policies* tab." +msgstr "" + +msgid "Create a *Client* Policy by clicking *Create policy* button." +msgstr "" + +msgid "Client Policy Creation" +msgstr "" + +msgid "image:images/exchange-target-client-policy.png[Client Policy Creation]" +msgstr "" + +msgid "Enter in the starting client that is the authenticated client that is requesting a token exchange." +msgstr "" + +msgid "After you create this policy, go back to the target client's *token-exchange* permission and add the client policy you just defined." +msgstr "" + +msgid "Apply Client Policy" +msgstr "" + +msgid "image:images/exchange-target-client-exchange-apply-policy.png[Apply Client Policy]" +msgstr "" + +msgid "Your client now has permission to invoke. If you do not do this correctly, you will get a 403 Forbidden response if you try to make an exchange." +msgstr "" + +msgid "Making the request" +msgstr "" + +msgid "When your client is exchanging an existing token for a token targeting another client, you use the `audience` parameter. This parameter must be the client identifier for the target client that you configured in the Admin Console." +msgstr "" + +msgid "" +"curl -X POST \\\n" +" -d \"client_id=starting-client\" \\\n" +" -d \"client_secret=the client secret\" \\\n" +" --data-urlencode \"grant_type=urn:ietf:params:oauth:grant-type:token-exchange\" \\\n" +" -d \"subject_token=....\" \\\n" +" --data-urlencode \"requested_token_type=urn:ietf:params:oauth:token-type:refresh_token\" \\\n" +" -d \"audience=target-client\" \\\n" +" http://localhost:8080{kc_realms_path}/myrealm/protocol/openid-connect/token" +msgstr "" + +msgid "The `subject_token` parameter must be an access token for the target realm. If your `requested_token_type` parameter is a refresh token type, then the response will contain both an access token, refresh token, and expiration. Here's an example JSON response you get back from this call." +msgstr "" + +msgid "When the `audience` parameter is not set, the value of the parameter defaults to the client making the token exchange request." +msgstr "" + +msgid "Unlike with confidential clients, public clients are not allowed to perform token exchanges using tokens from other clients. If you are passing a `subject_token`, the (confidential) client that was issued the token should either match the client making the request or, if issued to a different client, the client making the request should be among the audiences set to the token." +msgstr "" + +msgid "If you are explicitly setting a target `audience` (with a client different from the client making the request), you should also make sure that the `token-exchange` scope permission is configured for the client set to the `audience` parameter to allow the client making the request to successfully complete the exchange." +msgstr "" + +msgid "" +"{\n" +" \"access_token\" : \"....\",\n" +" \"refresh_token\" : \"....\",\n" +" \"expires_in\" : 3600\n" +"}" +msgstr "" + +msgid "Internal token to external token exchange" +msgstr "" + +msgid "You can exchange a realm token for an external token minted by an external identity provider. This external identity provider must be configured within the `Identity Provider` section of the Admin Console. Currently only OAuth/OpenID Connect based external identity providers are supported, this includes all social providers. {project_name} does not perform a backchannel exchange to the external provider. So if the account is not linked, you will not be able to get the external token. To be able to obtain an external token one of these conditions must be met:" +msgstr "" + +msgid "The user must have logged in with the external identity provider at least once" +msgstr "" + +msgid "The user must have linked with the external identity provider through the User Account Service" +msgstr "" + +msgid "The user account was linked through the external identity provider using link:{developerguide_link}[Client Initiated Account Linking] API." +msgstr "" + +msgid "Finally, the external identity provider must have been configured to store tokens, or, one of the above actions must have been performed with the same user session as the internal token you are exchanging." +msgstr "" + +msgid "If the account is not linked, the exchange response will contain a link you can use to establish it. This is discussed more in the <<_internal_external_making_request, Making the Request>> section." +msgstr "" + +msgid "Internal to external token exchange requests will be denied with a 403, Forbidden response until you grant permission for the calling client to exchange tokens with the external identity provider. To grant permission to the client, you go to the identity provider's configuration page to the *Permissions* tab." +msgstr "" + +msgid "Identity Provider Permission" +msgstr "" + +msgid "image:images/exchange-idp-permission-unset.png[Identity Provider Exchange Permission]" +msgstr "" + +msgid "image:images/exchange-idp-permission-set.png[Identity Provider Exchange Permission Set]" +msgstr "" + +msgid "The page displays *token-exchange* link." +msgstr "" + +msgid "Click the link to start defining the permission." +msgstr "" + +msgid "This setup page appears." +msgstr "" + +msgid "Identity Provider Exchange Permission Setup" +msgstr "" + +msgid "image:images/exchange-idp-permission-setup.png[Identity Provider Exchange Permission Setup]" +msgstr "" + +msgid "Click *Policies* tab to create a client policy." +msgstr "" + +msgid "image:images/exchange-idp-client-policy.png[Client Policy Creation]" +msgstr "" + +msgid "Enter the starting client that is the authenticated client that is requesting a token exchange." +msgstr "" + +msgid "Return to the identity provider's *token-exchange* permission and add the client policy you just defined." +msgstr "" + +msgid "image:images/exchange-idp-apply-policy.png[Apply Client Policy]" +msgstr "" + +msgid "When your client is exchanging an existing internal token to an external one, you provide the `requested_issuer` parameter. The parameter must be the alias of a configured identity provider." +msgstr "" + +msgid "" +"curl -X POST \\\n" +" -d \"client_id=starting-client\" \\\n" +" -d \"client_secret=the client secret\" \\\n" +" --data-urlencode \"grant_type=urn:ietf:params:oauth:grant-type:token-exchange\" \\\n" +" -d \"subject_token=....\" \\\n" +" --data-urlencode \"requested_token_type=urn:ietf:params:oauth:token-type:access_token\" \\\n" +" -d \"requested_issuer=google\" \\\n" +" http://localhost:8080{kc_realms_path}/myrealm/protocol/openid-connect/token" +msgstr "" + +msgid "The `subject_token` parameter must be an access token for the target realm. The `requested_token_type` parameter must be `urn:ietf:params:oauth:token-type:access_token` or left blank. No other requested token type is supported at this time. Here's an example successful JSON response you get back from this call." +msgstr "" + +msgid "" +"{\n" +" \"access_token\" : \"....\",\n" +" \"expires_in\" : 3600\n" +" \"account-link-url\" : \"https://....\"\n" +"}" +msgstr "" + +msgid "If the external identity provider is not linked for whatever reason, you will get an HTTP 400 response code with this JSON document:" +msgstr "" + +msgid "" +"{\n" +" \"error\" : \"....\",\n" +" \"error_description\" : \"...\"\n" +" \"account-link-url\" : \"https://....\"\n" +"}" +msgstr "" + +msgid "The `error` claim will be either `token_expired` or `not_linked`. The `account-link-url` claim is provided so that the client can perform link:{developerguide_link}[Client Initiated Account Linking]. Most, if not all, providers require linking through browser OAuth protocol. With the `account-link-url` just add a `redirect_uri` query parameter to it and you can forward browsers to perform the link." +msgstr "" + +msgid "External token to internal token exchange" +msgstr "" + +msgid "You can trust and exchange external tokens minted by external identity providers for internal tokens. This can be used to bridge between realms or just to trust tokens from your social provider. It works similarly to an identity provider browser login in that a new user is imported into your realm if it doesn't exist." +msgstr "" + +msgid "The current limitation on external token exchanges is that if the external token maps to an existing user an exchange will not be allowed unless the existing user already has an account link to the external identity provider." +msgstr "" + +msgid "When the exchange is complete, a user session will be created within the realm, and you will receive an access and or refresh token depending on the `requested_token_type` parameter value. You should note that this new user session will remain active until it times out or until you call the logout endpoint of the realm passing this new access token." +msgstr "" + +msgid "These types of changes required a configured identity provider in the Admin Console." +msgstr "" + +msgid "SAML identity providers are not supported at this time. Twitter tokens cannot be exchanged either." +msgstr "" + +msgid "Before external token exchanges can be done, you grant permission for the calling client to make the exchange. This permission is granted in the same manner as <<_grant_permission_external_exchange, internal to external permission is granted>>." +msgstr "" + +msgid "If you also provide an `audience` parameter whose value points to a different client other than the calling one, you must also grant the calling client permission to exchange to the target client specific in the `audience` parameter. How to do this is <<_client_to_client_permission, discussed earlier>> in this section." +msgstr "" + +msgid "The `subject_token_type` must either be `urn:ietf:params:oauth:token-type:access_token` or `urn:ietf:params:oauth:token-type:jwt`. If the type is `urn:ietf:params:oauth:token-type:access_token` you specify the `subject_issuer` parameter and it must be the alias of the configured identity provider. If the type is `urn:ietf:params:oauth:token-type:jwt`, the provider will be matched via the `issuer` claim within the JWT which must be the alias of the provider, or a registered issuer within the providers configuration." +msgstr "" + +msgid "For validation, if the token is an access token, the provider's user info service will be invoked to validate the token. A successful call will mean that the access token is valid. If the subject token is a JWT and if the provider has signature validation enabled, that will be attempted, otherwise, it will default to also invoking on the user info service to validate the token." +msgstr "" + +msgid "By default, the internal token minted will use the calling client to determine what's in the token using the protocol mappers defined for the calling client. Alternatively, you can specify a different target client using the `audience` parameter." +msgstr "" + +msgid "" +"curl -X POST \\\n" +" -d \"client_id=starting-client\" \\\n" +" -d \"client_secret=the client secret\" \\\n" +" --data-urlencode \"grant_type=urn:ietf:params:oauth:grant-type:token-exchange\" \\\n" +" -d \"subject_token=....\" \\\n" +" -d \"subject_issuer=myOidcProvider\" \\\n" +" --data-urlencode \"subject_token_type=urn:ietf:params:oauth:token-type:access_token\" \\\n" +" -d \"audience=target-client\" \\\n" +" http://localhost:8080{kc_realms_path}/myrealm/protocol/openid-connect/token" +msgstr "" + +msgid "If your `requested_token_type` parameter is a refresh token type, then the response will contain both an access token, refresh token, and expiration. Here's an example JSON response you get back from this call." +msgstr "" + +msgid "Impersonation" +msgstr "" + +msgid "For internal and external token exchanges, the client can request on behalf of a user to impersonate a different user. For example, you may have an admin application that needs to impersonate a user so that a support engineer can debug a problem." +msgstr "" + +msgid "The user that the subject token represents must have permission to impersonate other users. See the link:{adminguide_link}[{adminguide_name}] on how to enable this permission. It can be done through a role or through fine grain admin permissions." +msgstr "" + +msgid "Make the request as described in other chapters except additionally specify the `requested_subject` parameter. The value of this parameter must be a username or user id." +msgstr "" + +msgid "" +"curl -X POST \\\n" +" -d \"client_id=starting-client\" \\\n" +" -d \"client_secret=the client secret\" \\\n" +" --data-urlencode \"grant_type=urn:ietf:params:oauth:grant-type:token-exchange\" \\\n" +" -d \"subject_token=....\" \\\n" +" --data-urlencode \"requested_token_type=urn:ietf:params:oauth:token-type:access_token\" \\\n" +" -d \"audience=target-client\" \\\n" +" -d \"requested_subject=wburke\" \\\n" +" http://localhost:8080{kc_realms_path}/myrealm/protocol/openid-connect/token" +msgstr "" + +msgid "Direct Naked Impersonation" +msgstr "" + +msgid "You can make an internal token exchange request without providing a `subject_token`. This is called a direct naked impersonation because it places a lot of trust in a client as that client can impersonate any user in the realm. You might need this to bridge for applications where it is impossible to obtain a subject token to exchange. For example, you may be integrating a legacy application that performs login directly with LDAP. In that case, the legacy app is able to authenticate users itself, but not able to obtain a token." +msgstr "" + +msgid "It is very risky to enable direct naked impersonation for a client. If the client's credentials are ever stolen, that client can impersonate any user in the system." +msgstr "" + +msgid "If the `audience` parameter is provided, then the calling client must have permission to exchange to the client. How to set this up is discussed earlier in this chapter." +msgstr "" + +msgid "Additionally, the calling client must be granted permission to impersonate users." +msgstr "" + +msgid "Click *Users* in the menu." +msgstr "" + +msgid "Click the *Permissions* tab." +msgstr "" + +msgid "User Permissions" +msgstr "" + +msgid "image:images/exchange-users-permission-unset.png[User Permissions]" +msgstr "" + +msgid "image:images/exchange-users-permission-set.png[Users Impersonation Permission Set]" +msgstr "" + +msgid "The page displays an *impersonate* link." +msgstr "" + +msgid "Users Impersonation Permission Setup" +msgstr "" + +msgid "image:images/exchange-users-permission-setup.png[Users Impersonation Permission Setup]" +msgstr "" + +msgid "Go to the *Policies* tab and create a client policy." +msgstr "" + +msgid "image:images/exchange-users-client-policy.png[Client Policy Creation]" +msgstr "" + +msgid "Return to the users' *impersonation* permission and add the client policy you just defined." +msgstr "" + +msgid "image:images/exchange-users-apply-policy.png[Apply Client Policy]" +msgstr "" + +msgid "Your client now has permission to impersonate users. If you do not do this correctly, you will get a 403 Forbidden response if you try to make this type of exchange." +msgstr "" + +msgid "Public clients are not allowed to do direct naked impersonations." +msgstr "" + +msgid "To make the request, simply specify the `requested_subject` parameter. This must be the username or user id of a valid user. You can also specify an `audience` parameter if you wish." +msgstr "" + +msgid "" +"curl -X POST \\\n" +" -d \"client_id=starting-client\" \\\n" +" -d \"client_secret=the client secret\" \\\n" +" --data-urlencode \"grant_type=urn:ietf:params:oauth:grant-type:token-exchange\" \\\n" +" -d \"requested_subject=wburke\" \\\n" +" http://localhost:8080{kc_realms_path}/myrealm/protocol/openid-connect/token" +msgstr "" + +msgid "Expand permission model with service accounts" +msgstr "" + +msgid "When granting clients permission to exchange, you don't necessarily manually enable those permissions for each and every client. If the client has a service account associated with it, you can use a role to group permissions together and assign exchange permissions by assigning a role to the client's service account. For example, you might define a `naked-exchange` role and any service account that has that role can do a naked exchange." +msgstr "" + +msgid "Exchange vulnerabilities" +msgstr "" + +msgid "When you start allowing token exchanges, there are various things you have to both be aware of and careful of." +msgstr "" + +msgid "The first is public clients. Public clients do not have or require a client credential in order to perform an exchange. Anybody that has a valid token will be able to __impersonate__ the public client and perform the exchanges that public client is allowed to perform. If there are any untrustworthy clients that are managed by your realm, public clients may open up vulnerabilities in your permission models. This is why direct naked exchanges do not allow public clients and will abort with an error if the calling client is public." +msgstr "" + +msgid "It is possible to exchange social tokens provided by Facebook, Google, etc. for a realm token. Be careful and vigilante on what the exchange token is allowed to do as it's not hard to create fake accounts on these social websites. Use default roles, groups, and identity provider mappers to control what attributes and roles are assigned to the external social user." +msgstr "" + +msgid "Direct naked exchanges are quite dangerous. You are putting a lot of trust in the calling client that it will never leak out its client credentials. If those credentials are leaked, then the thief can impersonate anybody in your system. This is in direct contrast to confidential clients that have existing tokens. You have two factors of authentication, the access token and the client credentials, and you're only dealing with one user. So use direct naked exchanges sparingly." +msgstr "" diff --git a/src/23.0/server_admin.po b/src/23.0/server_admin.po new file mode 100644 index 000000000..4b0b1b30b --- /dev/null +++ b/src/23.0/server_admin.po @@ -0,0 +1,13092 @@ +msgid "" +msgstr "" +"Content-Type: text/plain; charset=UTF-8\n" + +msgid "{adminguide_name}" +msgstr "" + +msgid "*{release_header_guide}* icon:angle-down[]" +msgstr "" + +msgid "{gettingstarted_link}[{gettingstarted_name_short}]" +msgstr "" + +msgid "{adapterguide_link}[{adapterguide_name_short}]" +msgstr "" + +msgid "{developerguide_link}[{developerguide_name_short}]" +msgstr "" + +msgid "{authorizationguide_link}[{authorizationguide_name_short}]" +msgstr "" + +msgid "{upgradingguide_link}[{upgradingguide_name_short}]" +msgstr "" + +msgid "{releasenotes_link}[{releasenotes_name_short}]" +msgstr "" + +msgid "Version *{project_version}*" +msgstr "" + +msgid "{project_name} features and concepts" +msgstr "" + +msgid "{project_name} is a single sign on solution for web apps and RESTful web services. The goal of {project_name} is to make security simple so that it is easy for application developers to secure the apps and services they have deployed in their organization. Security features that developers normally have to write for themselves are provided out of the box and are easily tailorable to the individual requirements of your organization. {project_name} provides customizable user interfaces for login, registration, administration, and account management. You can also use {project_name} as an integration platform to hook it into existing LDAP and Active Directory servers. You can also delegate authentication to third party identity providers like Facebook and Google." +msgstr "" + +msgid "Features" +msgstr "" + +msgid "{project_name} provides the following features:" +msgstr "" + +msgid "Single-Sign On and Single-Sign Out for browser applications." +msgstr "" + +msgid "OpenID Connect support." +msgstr "" + +msgid "OAuth 2.0 support." +msgstr "" + +msgid "SAML support." +msgstr "" + +msgid "Identity Brokering - Authenticate with external OpenID Connect or SAML Identity Providers." +msgstr "" + +msgid "Social Login - Enable login with Google, GitHub, Facebook, Twitter, and other social networks." +msgstr "" + +msgid "User Federation - Sync users from LDAP and Active Directory servers." +msgstr "" + +msgid "Kerberos bridge - Automatically authenticate users that are logged-in to a Kerberos server." +msgstr "" + +msgid "Admin Console for central management of users, roles, role mappings, clients and configuration." +msgstr "" + +msgid "Account Management console that allows users to centrally manage their account." +msgstr "" + +msgid "Theme support - Customize all user facing pages to integrate with your applications and branding." +msgstr "" + +msgid "Two-factor Authentication - Support for TOTP/HOTP via Google Authenticator or FreeOTP." +msgstr "" + +msgid "Login flows - optional user self-registration, recover password, verify email, require password update, etc." +msgstr "" + +msgid "Session management - Admins and users themselves can view and manage user sessions." +msgstr "" + +msgid "Token mappers - Map user attributes, roles, etc. how you want into tokens and statements." +msgstr "" + +msgid "Not-before revocation policies per realm, application and user." +msgstr "" + +msgid "CORS support - Client adapters have built-in support for CORS." +msgstr "" + +msgid "Service Provider Interfaces (SPI) - A number of SPIs to enable customizing various aspects of the server. Authentication flows, user federation providers, protocol mappers and many more." +msgstr "" + +msgid "Client adapters for JavaScript applications, WildFly, JBoss EAP, Tomcat, Jetty, Spring, etc." +msgstr "" + +msgid "Supports any platform/language that has an OpenID Connect Relying Party library or SAML 2.0 Service Provider library." +msgstr "" + +msgid "Basic {project_name} operations" +msgstr "" + +msgid "{project_name} is a separate server that you manage on your network. Applications are configured to point to and be secured by this server. {project_name} uses open protocol standards like link:https://openid.net/developers/how-connect-works/[OpenID Connect] or link:https://saml.xml.org/saml-specifications[SAML 2.0] to secure your applications. Browser applications redirect a user's browser from the application to the {project_name} authentication server where they enter their credentials. This redirection is important because users are completely isolated from applications and applications never see a user's credentials. Applications instead are given an identity token or assertion that is cryptographically signed. These tokens can have identity information like username, address, email, and other profile data. They can also hold permission data so that applications can make authorization decisions. These tokens can also be used to make secure invocations on REST-based services." +msgstr "" + +msgid "Core concepts and terms" +msgstr "" + +msgid "Consider these core concepts and terms before attempting to use {project_name} to secure your web applications and REST services." +msgstr "" + +msgid "users" +msgstr "" + +msgid "Users are entities that are able to log into your system. They can have attributes associated with themselves like email, username, address, phone number, and birthday. They can be assigned group membership and have specific roles assigned to them." +msgstr "" + +msgid "authentication" +msgstr "" + +msgid "The process of identifying and validating a user." +msgstr "" + +msgid "authorization" +msgstr "" + +msgid "The process of granting access to a user." +msgstr "" + +msgid "credentials" +msgstr "" + +msgid "Credentials are pieces of data that {project_name} uses to verify the identity of a user. Some examples are passwords, one-time-passwords, digital certificates, or even fingerprints." +msgstr "" + +msgid "roles" +msgstr "" + +msgid "Roles identify a type or category of user. `Admin`, `user`, `manager`, and `employee` are all typical roles that may exist in an organization. Applications often assign access and permissions to specific roles rather than individual users as dealing with users can be too fine-grained and hard to manage." +msgstr "" + +msgid "user role mapping" +msgstr "" + +msgid "A user role mapping defines a mapping between a role and a user. A user can be associated with zero or more roles. This role mapping information can be encapsulated into tokens and assertions so that applications can decide access permissions on various resources they manage." +msgstr "" + +msgid "composite roles" +msgstr "" + +msgid "A composite role is a role that can be associated with other roles. For example a `superuser` composite role could be associated with the `sales-admin` and `order-entry-admin` roles. If a user is mapped to the `superuser` role they also inherit the `sales-admin` and `order-entry-admin` roles." +msgstr "" + +msgid "groups" +msgstr "" + +msgid "Groups manage groups of users. Attributes can be defined for a group. You can map roles to a group as well. Users that become members of a group inherit the attributes and role mappings that group defines." +msgstr "" + +msgid "realms" +msgstr "" + +msgid "A realm manages a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another and can only manage and authenticate the users that they control." +msgstr "" + +msgid "clients" +msgstr "" + +msgid "Clients are entities that can request {project_name} to authenticate a user. Most often, clients are applications and services that want to use {project_name} to secure themselves and provide a single sign-on solution. Clients can also be entities that just want to request identity information or an access token so that they can securely invoke other services on the network that are secured by {project_name}." +msgstr "" + +msgid "client adapters" +msgstr "" + +msgid "Client adapters are plugins that you install into your application environment to be able to communicate and be secured by {project_name}. {project_name} has a number of adapters for different platforms that you can download. There are also third-party adapters you can get for environments that we don't cover." +msgstr "" + +msgid "consent" +msgstr "" + +msgid "Consent is when you as an admin want a user to give permission to a client before that client can participate in the authentication process. After a user provides their credentials, {project_name} will pop up a screen identifying the client requesting a login and what identity information is requested of the user. User can decide whether or not to grant the request." +msgstr "" + +msgid "client scopes" +msgstr "" + +msgid "When a client is registered, you must define protocol mappers and role scope mappings for that client. It is often useful to store a client scope, to make creating new clients easier by sharing some common settings. This is also useful for requesting some claims or roles to be conditionally based on the value of `scope` parameter. {project_name} provides the concept of a client scope for this." +msgstr "" + +msgid "client role" +msgstr "" + +msgid "Clients can define roles that are specific to them. This is basically a role namespace dedicated to the client." +msgstr "" + +msgid "identity token" +msgstr "" + +msgid "A token that provides identity information about the user. Part of the OpenID Connect specification." +msgstr "" + +msgid "access token" +msgstr "" + +msgid "A token that can be provided as part of an HTTP request that grants access to the service being invoked on. This is part of the OpenID Connect and OAuth 2.0 specification." +msgstr "" + +msgid "assertion" +msgstr "" + +msgid "Information about a user. This usually pertains to an XML blob that is included in a SAML authentication response that provided identity metadata about an authenticated user." +msgstr "" + +msgid "service account" +msgstr "" + +msgid "Each client has a built-in service account which allows it to obtain an access token." +msgstr "" + +msgid "direct grant" +msgstr "" + +msgid "A way for a client to obtain an access token on behalf of a user via a REST invocation." +msgstr "" + +msgid "protocol mappers" +msgstr "" + +msgid "For each client you can tailor what claims and assertions are stored in the OIDC token or SAML assertion. You do this per client by creating and configuring protocol mappers." +msgstr "" + +msgid "session" +msgstr "" + +msgid "When a user logs in, a session is created to manage the login session. A session contains information like when the user logged in and what applications have participated within single-sign on during that session. Both admins and users can view session information." +msgstr "" + +msgid "user federation provider" +msgstr "" + +msgid "{project_name} can store and manage users. Often, companies already have LDAP or Active Directory services that store user and credential information. You can point {project_name} to validate credentials from those external stores and pull in identity information." +msgstr "" + +msgid "identity provider" +msgstr "" + +msgid "An identity provider (IDP) is a service that can authenticate a user. {project_name} is an IDP." +msgstr "" + +msgid "identity provider federation" +msgstr "" + +msgid "{project_name} can be configured to delegate authentication to one or more IDPs. Social login via Facebook or Google+ is an example of identity provider federation. You can also hook {project_name} to delegate authentication to any other OpenID Connect or SAML 2.0 IDP." +msgstr "" + +msgid "identity provider mappers" +msgstr "" + +msgid "When doing IDP federation you can map incoming tokens and assertions to user and session attributes. This helps you propagate identity information from the external IDP to your client requesting authentication." +msgstr "" + +msgid "required actions" +msgstr "" + +msgid "Required actions are actions a user must perform during the authentication process. A user will not be able to complete the authentication process until these actions are complete. For example, an admin may schedule users to reset their passwords every month. An `update password` required action would be set for all these users." +msgstr "" + +msgid "authentication flows" +msgstr "" + +msgid "Authentication flows are work flows a user must perform when interacting with certain aspects of the system. A login flow can define what credential types are required. A registration flow defines what profile information a user must enter and whether something like reCAPTCHA must be used to filter out bots. Credential reset flow defines what actions a user must do before they can reset their password." +msgstr "" + +msgid "events" +msgstr "" + +msgid "Events are audit streams that admins can view and hook into." +msgstr "" + +msgid "themes" +msgstr "" + +msgid "Every screen provided by {project_name} is backed by a theme. Themes define HTML templates and stylesheets which you can override as needed." +msgstr "" + +msgid "Creating the first administrator" +msgstr "" + +msgid "After installing {project_name}, you need an administrator account that can act as a _super_ admin with full permissions to manage {project_name}. With this account, you can log in to the {project_name} Admin Console where you create realms and users and register applications that are secured by {project_name}." +msgstr "" + +msgid "Creating the account on the local host" +msgstr "" + +msgid "If your server is accessible from `localhost`, perform these steps." +msgstr "" + +msgid "Procedure" +msgstr "" + +msgid "In a web browser, go to the http://localhost:8080{kc_base_path} URL." +msgstr "" + +msgid "Supply a username and password that you can recall." +msgstr "" + +msgid "Welcome page" +msgstr "" + +msgid "image:images/initial-welcome-page.png[Welcome page]" +msgstr "" + +msgid "Creating the account remotely" +msgstr "" + +msgid "If you cannot access the server from a `localhost` address or just want to start {project_name} from the command line, use the `KEYCLOAK_ADMIN` and `KEYCLOAK_ADMIN_PASSWORD` environment variables to create an initial admin account." +msgstr "" + +msgid "For example:" +msgstr "" + +msgid "" +"export KEYCLOAK_ADMIN=\n" +"export KEYCLOAK_ADMIN_PASSWORD=\n" +"\n" +"bin/kc.[sh|bat] start" +msgstr "" + +msgid "Configuring realms" +msgstr "" + +msgid "Once you have an administrative account for the Admin Console, you can configure realms. A realm is a space where you manage objects, including users, applications, roles, and groups. A user belongs to and logs into a realm. One {project_name} deployment can define, store, and manage as many realms as there is space for in the database." +msgstr "" + +msgid "Using the Admin Console" +msgstr "" + +msgid "You configure realms and perform most administrative tasks in the {project_name} Admin Console." +msgstr "" + +msgid "Prerequisites" +msgstr "" + +msgid "You need an administrator account. See xref:creating-first-admin_{context}[Creating the first administrator]." +msgstr "" + +msgid "Go to the URL for the Admin Console." +msgstr "" + +msgid "For example, for localhost, use this URL: http://localhost:8080{kc_admins_path}/" +msgstr "" + +msgid "Login page" +msgstr "" + +msgid "image:images/login-page.png[Login page]" +msgstr "" + +msgid "Enter the username and password you created on the Welcome Page or through environment variables as per https://www.keycloak.org/server/configuration#_creating_the_initial_admin_user[Creating the initial admin user] guide. This action displays the Admin Console." +msgstr "" + +msgid "Admin Console" +msgstr "" + +msgid "image:images/admin-console.png[Admin Console]" +msgstr "" + +msgid "Note the menus and other options that you can use:" +msgstr "" + +msgid "Click the menu labeled *Master* to pick a realm you want to manage or to create a new one." +msgstr "" + +msgid "Click the top right list to view your account or log out." +msgstr "" + +msgid "Hover over a question mark *?* icon to show a tooltip text that describes that field. The image above shows the tooltip in action." +msgstr "" + +msgid "Click a question mark *?* icon to show a tooltip text that describes that field. The image above shows the tooltip in action." +msgstr "" + +msgid "Export files from the Admin Console are not suitable for backups or data transfer between servers. Only boot-time exports are suitable for backups or data transfer between servers." +msgstr "" + +msgid "The master realm" +msgstr "" + +msgid "In the Admin Console, two types of realms exist:" +msgstr "" + +msgid "`Master realm` - This realm was created for you when you first started {project_name}. It contains the administrator account you created at the first login. Use the _master_ realm only to create and manage the realms in your system." +msgstr "" + +msgid "`Other realms` - These realms are created by the administrator in the master realm. In these realms, administrators manage the users in your organization and the applications they need. The applications are owned by the users." +msgstr "" + +msgid "Realms and applications" +msgstr "" + +msgid "image:images/master_realm.png[Realms and applications]" +msgstr "" + +msgid "Realms are isolated from one another and can only manage and authenticate the users that they control. Following this security model helps prevent accidental changes and follows the tradition of permitting user accounts access to only those privileges and powers necessary for the successful completion of their current task." +msgstr "" + +msgid "Additional resources" +msgstr "" + +msgid "See <<_per_realm_admin_permissions, Dedicated Realm Admin Consoles>> if you want to disable the _master_ realm and define administrator accounts within any new realm you create. Each realm has its own dedicated Admin Console that you can log into with local accounts." +msgstr "" + +msgid "Creating a realm" +msgstr "" + +msgid "You create a realm to provide a management space where you can create users and give them permissions to use applications. At first login, you are typically in the _master_ realm, the top-level realm from which you create other realms." +msgstr "" + +msgid "When deciding what realms you need, consider the kind of isolation you want to have for your users and applications. For example, you might create a realm for the employees of your company and a separate realm for your customers. Your employees would log into the employee realm and only be able to visit internal company applications. Customers would log into the customer realm and only be able to interact with customer-facing apps." +msgstr "" + +msgid "Point to the top of the left pane." +msgstr "" + +msgid "Click *Create Realm*." +msgstr "" + +msgid "Add realm menu" +msgstr "" + +msgid "image:images/add-realm-menu.png[Add realm menu]" +msgstr "" + +msgid "Enter a name for the realm." +msgstr "" + +msgid "Click *Create*." +msgstr "" + +msgid "Create realm" +msgstr "" + +msgid "image:images/create-realm.png[Create realm]" +msgstr "" + +msgid "The current realm is now set to the realm you just created. You can switch between realms by clicking the realm name in the menu." +msgstr "" + +msgid "Configuring SSL for a realm" +msgstr "" + +msgid "Each realm has an associated SSL Mode, which defines the SSL/HTTPS requirements for interacting with the realm. Browsers and applications that interact with the realm honor the SSL/HTTPS requirements defined by the SSL Mode or they cannot interact with the server." +msgstr "" + +msgid "Click *Realm settings* in the menu." +msgstr "" + +msgid "Click the *General* tab." +msgstr "" + +msgid "General tab" +msgstr "" + +msgid "image:images/general-tab.png[General Tab]" +msgstr "" + +msgid "Set *Require SSL* to one of the following SSL modes:" +msgstr "" + +msgid "*External requests* Users can interact with {project_name} without SSL so long as they stick to private IP addresses such as `localhost`, `127.0.0.1`, `10.x.x.x`, `192.168.x.x`, and `172.16.x.x`. If you try to access {project_name} without SSL from a non-private IP address, you will get an error." +msgstr "" + +msgid "*None* {project_name} does not require SSL. This choice applies only in development when you are experimenting and do not plan to support this deployment." +msgstr "" + +msgid "*All requests* {project_name} requires SSL for all IP addresses." +msgstr "" + +msgid "Configuring email for a realm" +msgstr "" + +msgid "{project_name} sends emails to users to verify their email addresses, when they forget their passwords, or when an administrator needs to receive notifications about a server event. To enable {project_name} to send emails, you provide {project_name} with your SMTP server settings." +msgstr "" + +msgid "Click the *Email* tab." +msgstr "" + +msgid "Email tab" +msgstr "" + +msgid "image:images/email-tab.png[Email Tab]" +msgstr "" + +msgid "Fill in the fields and toggle the switches as needed." +msgstr "" + +msgid "Template" +msgstr "" + +msgid "From" +msgstr "" + +msgid "*From* denotes the address used for the *From* SMTP-Header for the emails sent." +msgstr "" + +msgid "From display name" +msgstr "" + +msgid "*From display name* allows to configure a user-friendly email address aliases (optional). If not set the plain *From* email address will be displayed in email clients." +msgstr "" + +msgid "Reply to" +msgstr "" + +msgid "*Reply to* denotes the address used for the *Reply-To* SMTP-Header for the mails sent (optional). If not set the plain *From* email address will be used." +msgstr "" + +msgid "Reply to display name" +msgstr "" + +msgid "*Reply to display name* allows to configure a user-friendly email address aliases (optional). If not set the plain *Reply To* email address will be displayed." +msgstr "" + +msgid "Envelope from" +msgstr "" + +msgid "*Envelope from* denotes the https://en.wikipedia.org/wiki/Bounce_address[Bounce Address] used for the *Return-Path* SMTP-Header for the mails sent (optional)." +msgstr "" + +msgid "Connection & Authentication" +msgstr "" + +msgid "Host" +msgstr "" + +msgid "*Host* denotes the SMTP server hostname used for sending emails." +msgstr "" + +msgid "Port" +msgstr "" + +msgid "*Port* denotes the SMTP server port." +msgstr "" + +msgid "Encryption" +msgstr "" + +msgid "Tick one of these checkboxes to support sending emails for recovering usernames and passwords, especially if the SMTP server is on an external network. You will most likely need to change the *Port* to 465, the default port for SSL/TLS." +msgstr "" + +msgid "Authentication" +msgstr "" + +msgid "Set this switch to *ON* if your SMTP server requires authentication. When prompted, supply the *Username* and *Password*. The value of the *Password* field can refer a value from an external <<_vault-administration,vault>>." +msgstr "" + +msgid "Configuring themes" +msgstr "" + +msgid "For a given realm, you can change the appearance of any UI in {project_name} by using themes." +msgstr "" + +msgid "Click *Realm setting* in the menu." +msgstr "" + +msgid "Click the *Themes* tab." +msgstr "" + +msgid "Themes tab" +msgstr "" + +msgid "image:images/themes-tab.png[Themes tab]" +msgstr "" + +msgid "Pick the theme you want for each UI category and click *Save*." +msgstr "" + +msgid "Login theme" +msgstr "" + +msgid "Username password entry, OTP entry, new user registration, and other similar screens related to login." +msgstr "" + +msgid "Account theme" +msgstr "" + +msgid "Each user has a User Account Management UI." +msgstr "" + +msgid "Admin console theme" +msgstr "" + +msgid "The skin of the {project_name} Admin Console." +msgstr "" + +msgid "Email theme" +msgstr "" + +msgid "Whenever {project_name} has to send out an email, it uses templates defined in this theme to craft the email." +msgstr "" + +msgid "The link:{developerguide_link}[{developerguide_name}] describes how to create a new theme or modify existing ones." +msgstr "" + +msgid "Enabling internationalization" +msgstr "" + +msgid "Every UI screen is internationalized in {project_name}. The default language is English, but you can choose which locales you want to support and what the default locale will be." +msgstr "" + +msgid "Click *Realm Settings* in the menu." +msgstr "" + +msgid "Click the *Localization* tab." +msgstr "" + +msgid "Enable *Internationalization*." +msgstr "" + +msgid "Select the languages you will support." +msgstr "" + +msgid "Localization tab" +msgstr "" + +msgid "image:images/localization.png[Localization tab]" +msgstr "" + +msgid "The next time a user logs in, that user can choose a language on the login page to use for the login screens, Account Console, and Admin Console." +msgstr "" + +msgid "The link:{developerguide_link}[{developerguide_name}] explains how you can offer additional languages. All internationalized texts which are provided by the theme can be overwritten by realm-specific texts on the *Localization* tab." +msgstr "" + +msgid "User locale selection" +msgstr "" + +msgid "A locale selector provider suggests the best locale on the information available. However, it is often unknown who the user is. For this reason, the previously authenticated user's locale is remembered in a persisted cookie." +msgstr "" + +msgid "The logic for selecting the locale uses the first of the following that is available:" +msgstr "" + +msgid "User selected - when the user has selected a locale using the drop-down locale selector" +msgstr "" + +msgid "User profile - when there is an authenticated user and the user has a preferred locale set" +msgstr "" + +msgid "Client selected - passed by the client using for example ui_locales parameter" +msgstr "" + +msgid "Cookie - last locale selected on the browser" +msgstr "" + +msgid "Accepted language - locale from *Accept-Language* header" +msgstr "" + +msgid "Realm default" +msgstr "" + +msgid "If none of the above, fall back to English" +msgstr "" + +msgid "When a user is authenticated an action is triggered to update the locale in the persisted cookie mentioned earlier. If the user has actively switched the locale through the locale selector on the login pages the users locale is also updated at this point." +msgstr "" + +msgid "If you want to change the logic for selecting the locale, you have an option to create custom `LocaleSelectorProvider`. For details, please refer to the link:{developerguide_link}#_locale_selector[{developerguide_name}]." +msgstr "" + +msgid "Controlling login options" +msgstr "" + +msgid "{project_name} includes several built-in login page features." +msgstr "" + +msgid "Enabling forgot password" +msgstr "" + +msgid "If you enable `Forgot password`, users can reset their login credentials if they forget their passwords or lose their OTP generator." +msgstr "" + +msgid "Click the *Login* tab." +msgstr "" + +msgid "Login tab" +msgstr "" + +msgid "image:images/login-tab.png[Login Tab]" +msgstr "" + +msgid "Toggle *Forgot password* to *ON*." +msgstr "" + +msgid "A `Forgot Password?` link displays in your login pages." +msgstr "" + +msgid "Forgot password link" +msgstr "" + +msgid "image:images/forgot-password-link.png[Forgot Password Link]" +msgstr "" + +msgid "Specify `Host` and `From` in the *Email* tab in order for Keycloak to be able to send the reset email." +msgstr "" + +msgid "Click this link to bring users where they can enter their username or email address and receive an email with a link to reset their credentials." +msgstr "" + +msgid "Forgot password page" +msgstr "" + +msgid "image:images/forgot-password-page.png[Forgot Password Page]" +msgstr "" + +msgid "The text sent in the email is configurable. See link:{developerguide_link}[{developerguide_name}] for more information." +msgstr "" + +msgid "When users click the email link, {project_name} asks them to update their password, and if they have set up an OTP generator, {project_name} asks them to reconfigure the OTP generator. Depending on security requirements of your organization, you may not want users to reset their OTP generator through email." +msgstr "" + +msgid "To change this behavior, perform these steps:" +msgstr "" + +msgid "Click *Authentication* in the menu." +msgstr "" + +msgid "Click the *Flows* tab." +msgstr "" + +msgid "Select the *Reset Credentials* flow." +msgstr "" + +msgid "Reset credentials flow" +msgstr "" + +msgid "image:images/reset-credentials-flow.png[Reset Credentials Flow]" +msgstr "" + +msgid "If you do not want to reset the OTP, set the `Reset OTP` requirement to *Disabled*." +msgstr "" + +msgid "Click the *Required actions* tab." +msgstr "" + +msgid "Ensure *Update Password* is enabled." +msgstr "" + +msgid "Required Actions" +msgstr "" + +msgid "image:images/reset-credentials-required-actions.png[Required Actions]" +msgstr "" + +msgid "Enabling Remember Me" +msgstr "" + +msgid "A logged-in user closing their browser destroys their session, and that user must log in again. You can set {project_name} to keep the user's login session open if that user clicks the _Remember Me_ checkbox upon login. This action turns the login cookie from a session-only cookie to a persistence cookie." +msgstr "" + +msgid "Toggle the *Remember Me* switch to *On*." +msgstr "" + +msgid "image:images/login-tab-remember-me.png[Login Tab Remember Me]" +msgstr "" + +msgid "When you save this setting, a `remember me` checkbox displays on the realm's login page." +msgstr "" + +msgid "Remember Me" +msgstr "" + +msgid "image:images/remember-me.png[Remember Me]" +msgstr "" + +msgid "ACR to Level of Authentication (LoA) Mapping" +msgstr "" + +msgid "In the login settings of a realm, you can define which `Authentication Context Class Reference (ACR)` value is mapped to which `Level of Authentication (LoA)`. The ACR can be any value, whereas the LoA must be numeric. The acr claim can be requested in the `claims` or `acr_values` parameter sent in the OIDC request and it is also included in the access token and ID token. The mapped number is used in the authentication flow conditions." +msgstr "" + +msgid "Mapping can be also specified at the client level in case that particular client needs to use different values than realm. However, a best practice is to stick to realm mappings." +msgstr "" + +msgid "image:images/realm-oidc-map-acr-to-loa.png[alt=\"ACR to LoA mapping\"]" +msgstr "" + +msgid "For further details see <<_step-up-flow,Step-up Authentication>> and https://openid.net/specs/openid-connect-core-1_0.html#acrSemantics[the official OIDC specification]." +msgstr "" + +msgid "Update Email Workflow (UpdateEmail)" +msgstr "" + +msgid "With this workflow, users will have to use an UPDATE_EMAIL action to change their own email address." +msgstr "" + +msgid "The action is associated with a single email input form. If the realm has email verification disabled, this action will allow to update the email without verification. If the realm has email verification enabled, the action will send an email update action token to the new email address without changing the account email. Only the action token triggering will complete the email update." +msgstr "" + +msgid "Applications are able to send their users to the email update form by leveraging UPDATE_EMAIL as an AIA (Application Initiated Action)." +msgstr "" + +msgid "Please note that Update Email Workflow support is in development. Use this feature experimentally." +msgstr "" + +msgid "If you enable this feature and you are migrating from a previous version, enable the *Update Email* required action in your realms. Otherwise, users cannot update their email addresses." +msgstr "" + +msgid "Configuring realm keys" +msgstr "" + +msgid "The authentication protocols that are used by {project_name} require cryptographic signatures and sometimes encryption. {project_name} uses asymmetric key pairs, a private and public key, to accomplish this." +msgstr "" + +msgid "{project_name} has a single active key pair at a time, but can have several passive keys as well. The active key pair is used to create new signatures, while the passive key pair can be used to verify previous signatures. This makes it possible to regularly rotate the keys without any downtime or interruption to users." +msgstr "" + +msgid "When a realm is created, a key pair and a self-signed certificate is automatically generated." +msgstr "" + +msgid "Click *Keys*." +msgstr "" + +msgid "Select *Passive keys* from the filter dropdown to view passive keys." +msgstr "" + +msgid "Select *Disabled keys* from the filter dropdown to view disabled keys." +msgstr "" + +msgid "A key pair can have the status `Active`, but still not be selected as the currently active key pair for the realm. The selected active pair which is used for signatures is selected based on the first key provider sorted by priority that is able to provide an active key pair." +msgstr "" + +msgid "Rotating keys" +msgstr "" + +msgid "We recommend that you regularly rotate keys. Start by creating new keys with a higher priority than the existing active keys. You can instead create new keys with the same priority and making the previous keys passive." +msgstr "" + +msgid "Once new keys are available, all new tokens and cookies will be signed with the new keys. When a user authenticates to an application, the SSO cookie is updated with the new signature. When OpenID Connect tokens are refreshed new tokens are signed with the new keys. Eventually, all cookies and tokens use the new keys and after a while the old keys can be removed." +msgstr "" + +msgid "The frequency of deleting old keys is a tradeoff between security and making sure all cookies and tokens are updated. Consider creating new keys every three to six months and deleting old keys one to two months after you create the new keys. If a user was inactive in the period between the new keys being added and the old keys being removed, that user will have to re-authenticate." +msgstr "" + +msgid "Rotating keys also applies to offline tokens. To make sure they are updated, the applications need to refresh the tokens before the old keys are removed." +msgstr "" + +msgid "Adding a generated key pair" +msgstr "" + +msgid "Use this procedure to generate a key pair including a self-signed certificate." +msgstr "" + +msgid "Select the realm in the Admin Console." +msgstr "" + +msgid "Click the *Keys* tab." +msgstr "" + +msgid "Click the *Providers* tab." +msgstr "" + +msgid "Click *Add provider* and select *rsa-generated*." +msgstr "" + +msgid "Enter a number in the *Priority* field. This number determines if the new key pair becomes the active key pair. The highest number makes the key pair active." +msgstr "" + +msgid "Select a value for *AES Key size*." +msgstr "" + +msgid "Click *Save*." +msgstr "" + +msgid "Changing the priority for a provider will not cause the keys to be re-generated, but if you want to change the keysize you can edit the provider and new keys will be generated." +msgstr "" + +msgid "Rotating keys by extracting a certificate" +msgstr "" + +msgid "You can rotate keys by extracting a certificate from an RSA generated key pair and using that certificate in a new keystore." +msgstr "" + +msgid "A generated key pair" +msgstr "" + +msgid "Click *Realm Settings*." +msgstr "" + +msgid "A list of *Active* keys appears." +msgstr "" + +msgid "On a row with an RSA key, click *Certificate* under *Public Keys*." +msgstr "" + +msgid "The certificate appears in text form." +msgstr "" + +msgid "Save the certificate to a file and enclose it in these lines." +msgstr "" + +msgid "" +"----Begin Certificate----\n" +"\n" +"----End Certificate----" +msgstr "" + +msgid "Use the *keytool* command to convert the key file to PEM Format." +msgstr "" + +msgid "Remove the current RSA public key certificate from the keystore." +msgstr "" + +msgid "keytool -delete -keystore .jks -storepass -alias " +msgstr "" + +msgid "Import the new certificate into the keystore" +msgstr "" + +msgid "keytool -importcert -file domain.crt -keystore .jks -storepass -alias " +msgstr "" + +msgid "Rebuild the application." +msgstr "" + +msgid "mvn clean install wildfly:deploy" +msgstr "" + +msgid "Adding an existing key pair and certificate" +msgstr "" + +msgid "To add a key pair and certificate obtained elsewhere select `Providers` and choose `rsa` from the dropdown. You can change the priority to make sure the new key pair becomes the active key pair." +msgstr "" + +msgid "A private key file. The file must be PEM formatted." +msgstr "" + +msgid "Click *Realm settings*." +msgstr "" + +msgid "Click *Add provider* and select *rsa*." +msgstr "" + +msgid "Enter a number in the *Priority* field. This number determines if the new key pair becomes the active key pair." +msgstr "" + +msgid "Click *Browse...* beside *Private RSA Key* to upload the private key file." +msgstr "" + +msgid "If you have a signed certificate for your private key, click *Browse...* beside *X509 Certificate* to upload the certificate file. {project_name} automatically generates a self-signed certificate if you do not upload a certificate." +msgstr "" + +msgid "Loading keys from a Java Keystore" +msgstr "" + +msgid "To add a key pair and certificate stored in a Java Keystore file on the host select `Providers` and choose `java-keystore` from the dropdown. You can change the priority to make sure the new key pair becomes the active key pair." +msgstr "" + +msgid "For the associated certificate chain to be loaded it must be imported to the Java Keystore file with the same `Key Alias` used to load the key pair." +msgstr "" + +msgid "Click *Add provider* and select *java-keystore*." +msgstr "" + +msgid "Enter a value for *Keystore*." +msgstr "" + +msgid "Enter a value for *Keystore Password*." +msgstr "" + +msgid "Enter a value for *Key Alias*." +msgstr "" + +msgid "Enter a value for *Key Password*." +msgstr "" + +msgid "Making keys passive" +msgstr "" + +msgid "Click the provider of the key you want to make passive." +msgstr "" + +msgid "Toggle *Active* to *Off*." +msgstr "" + +msgid "Disabling keys" +msgstr "" + +msgid "Toggle *Enabled* to *Off*." +msgstr "" + +msgid "Compromised keys" +msgstr "" + +msgid "{project_name} has the signing keys stored just locally and they are never shared with the client applications, users or other entities. However, if you think that your realm signing key was compromised, you should first generate new key pair as described above and then immediately remove the compromised key pair." +msgstr "" + +msgid "Alternatively, you can delete the provider from the `Providers` table." +msgstr "" + +msgid "Click *Clients* in the menu." +msgstr "" + +msgid "Click *security-admin-console*." +msgstr "" + +msgid "Scroll down to the *Access settings* section." +msgstr "" + +msgid "Fill in the *Admin URL* field." +msgstr "" + +msgid "Click the *Advanced* tab." +msgstr "" + +msgid "Click *Set to now* in the *Revocation* section." +msgstr "" + +msgid "Click *Push*." +msgstr "" + +msgid "Pushing the not-before policy ensures that client applications do not accept the existing tokens signed by the compromised key. The client application is forced to download new key pairs from {project_name} also so the tokens signed by the compromised key will be invalid." +msgstr "" + +msgid "REST and confidential clients must set *Admin URL* so {project_name} can send clients the pushed not-before policy request." +msgstr "" + +msgid "Using external storage" +msgstr "" + +msgid "Organizations can have databases containing information, passwords, and other credentials. Typically, you cannot migrate existing data storage to a {project_name} deployment so {project_name} can federate existing external user databases. {project_name} supports LDAP and Active Directory, but you can also code extensions for any custom user database by using the {project_name} User Storage SPI." +msgstr "" + +msgid "When a user attempts to log in, {project_name} examines that user's storage to find that user. If {project_name} does not find the user, {project_name} iterates over each User Storage provider for the realm until it finds a match. Data from the external data storage then maps into a standard user model the {project_name} runtime consumes. This user model then maps to OIDC token claims and SAML assertion attributes." +msgstr "" + +msgid "External user databases rarely have the data necessary to support all the features of {project_name}, so the User Storage Provider can opt to store items locally in {project_name} user data storage. Providers can import users locally and sync periodically with external data storage. This approach depends on the capabilities of the provider and the configuration of the provider. For example, your external user data storage may not support OTP. The OTP can be handled and stored by {project_name}, depending on the provider." +msgstr "" + +msgid "Adding a provider" +msgstr "" + +msgid "To add a storage provider, perform the following procedure:" +msgstr "" + +msgid "Click *User Federation* in the menu." +msgstr "" + +msgid "User federation" +msgstr "" + +msgid "image:images/user-federation.png[User federation]" +msgstr "" + +msgid "Select the provider type card from the listed cards." +msgstr "" + +msgid "{project_name} brings you to that provider's configuration page." +msgstr "" + +msgid "Dealing with provider failures" +msgstr "" + +msgid "If a User Storage Provider fails, you may not be able to log in and view users in the Admin Console. {project_name} does not detect failures when using a Storage Provider to look up a user, so it cancels the invocation. If you have a Storage Provider with a high priority that fails during user lookup, the login or user query fails with an exception and will not fail over to the next configured provider." +msgstr "" + +msgid "{project_name} searches the local {project_name} user database first to resolve users before any LDAP or custom User Storage Provider. Consider creating an administrator account stored in the local {project_name} user database in case of problems connecting to your LDAP and back ends." +msgstr "" + +msgid "Each LDAP and custom User Storage Provider has an `enable` toggle on its Admin Console page. Disabling the User Storage Provider skips the provider when performing queries, so you can view and log in with user accounts in a different provider with lower priority. If your provider uses an `import` strategy and is disabled, imported users are still available for lookup in read-only mode." +msgstr "" + +msgid "When a Storage Provider lookup fails, {project_name} does not fail over because user databases often have duplicate usernames or duplicate emails between them. Duplicate usernames and emails can cause problems because the user loads from one external data store when the admin expects them to load from another data store." +msgstr "" + +msgid "Lightweight Directory Access Protocol (LDAP) and Active Directory" +msgstr "" + +msgid "{project_name} includes an LDAP/AD provider. You can federate multiple different LDAP servers in one {project_name} realm and map LDAP user attributes into the {project_name} common user model." +msgstr "" + +msgid "By default, {project_name} maps the username, email, first name, and last name of the user account, but you can also configure additional <<_ldap_mappers,mappings>>. {project_name}'s LDAP/AD provider supports password validation using LDAP/AD protocols and storage, edit, and synchronization modes." +msgstr "" + +msgid "Configuring federated LDAP storage" +msgstr "" + +msgid "Click *Add LDAP providers*." +msgstr "" + +msgid "{project_name} brings you to the LDAP configuration page." +msgstr "" + +msgid "Storage mode" +msgstr "" + +msgid "{project_name} imports users from LDAP into the local {project_name} user database. This copy of the user database synchronizes on-demand or through a periodic background task. An exception exists for synchronizing passwords. {project_name} never imports passwords. Password validation always occurs on the LDAP server." +msgstr "" + +msgid "The advantage of synchronization is that all {project_name} features work efficiently because any required extra per-user data is stored locally. The disadvantage is that each time {project_name} queries a specific user for the first time, {project_name} performs a corresponding database insert." +msgstr "" + +msgid "You can synchronize the import with your LDAP server. Import synchronization is unnecessary when LDAP mappers always read particular attributes from the LDAP rather than the database." +msgstr "" + +msgid "You can use LDAP with {project_name} without importing users into the {project_name} user database. The LDAP server backs up the common user model that the {project_name} runtime uses. If LDAP does not support data that a {project_name} feature requires, that feature will not work. The advantage of this approach is that you do not have the resource usage of importing and synchronizing copies of LDAP users into the {project_name} user database." +msgstr "" + +msgid "The *Import Users* switch on the LDAP configuration page controls this storage mode. To import users, toggle this switch to *ON*." +msgstr "" + +msgid "If you disable *Import Users*, you cannot save user profile attributes into the {project_name} database. Also, you cannot save metadata except for user profile metadata mapped to the LDAP. This metadata can include role mappings, group mappings, and other metadata based on the LDAP mappers' configuration." +msgstr "" + +msgid "When you attempt to change the non-LDAP mapped user data, the user update is not possible. For example, you cannot disable the LDAP mapped user unless the user's `enabled` flag maps to an LDAP attribute." +msgstr "" + +msgid "Edit mode" +msgstr "" + +msgid "Users and admins can modify user metadata, users through the <<_account-service, Account Console>>, and administrators through the Admin Console. The `Edit Mode` configuration on the LDAP configuration page defines the user's LDAP update privileges." +msgstr "" + +msgid "READONLY" +msgstr "" + +msgid "You cannot change the username, email, first name, last name, and other mapped attributes. {project_name} shows an error anytime a user attempts to update these fields. Password updates are not supported." +msgstr "" + +msgid "WRITABLE" +msgstr "" + +msgid "You can change the username, email, first name, last name, and other mapped attributes and passwords and synchronize them automatically with the LDAP store." +msgstr "" + +msgid "UNSYNCED" +msgstr "" + +msgid "{project_name} stores changes to the username, email, first name, last name, and passwords in {project_name} local storage, so the administrator must synchronize this data back to LDAP. In this mode, {project_name} deployments can update user metadata on read-only LDAP servers. This option also applies when importing users from LDAP into the local {project_name} user database." +msgstr "" + +msgid "When {project_name} creates the LDAP provider, {project_name} also creates a set of initial <<_ldap_mappers,LDAP mappers>>. {project_name} configures these mappers based on a combination of the *Vendor*, *Edit Mode*, and *Import Users* switches. For example, when edit mode is UNSYNCED, {project_name} configures the mappers to read a particular user attribute from the database and not from the LDAP server. However, if you later change the edit mode, the mapper's configuration does not change because it is impossible to detect if the configuration changes changed in UNSYNCED mode. Decide the *Edit Mode* when creating the LDAP provider. This note applies to *Import Users* switch also." +msgstr "" + +msgid "Other configuration options" +msgstr "" + +msgid "Console Display Name" +msgstr "" + +msgid "The name of the provider to display in the admin console." +msgstr "" + +msgid "Priority" +msgstr "" + +msgid "The priority of the provider when looking up users or adding a user." +msgstr "" + +msgid "Sync Registrations" +msgstr "" + +msgid "Toggle this switch to *ON* if you want new users created by {project_name} added to LDAP." +msgstr "" + +msgid "Allow Kerberos authentication" +msgstr "" + +msgid "Enable Kerberos/SPNEGO authentication in the realm with user data provisioned from LDAP. For more information, see the <<_kerberos,Kerberos section>>." +msgstr "" + +msgid "Other options" +msgstr "" + +msgid "Hover the mouse pointer over the tooltips in the Admin Console to see more details about these options." +msgstr "" + +msgid "Connecting to LDAP over SSL" +msgstr "" + +msgid "When you configure a secure connection URL to your LDAP store (for example,`ldaps://myhost.com:636`), {project_name} uses SSL to communicate with the LDAP server. Configure a truststore on the {project_name} server side so that {project_name} can trust the SSL connection to LDAP." +msgstr "" + +msgid "Configure the global truststore for {project_name} with the Truststore SPI. For more information about configuring the global truststore, see the https://www.keycloak.org/server/keycloak-truststore[Configuring a Truststore] {section}. If you do not configure the Truststore SPI, the truststore falls back to the default mechanism provided by Java, which can be the file supplied by the `javax.net.ssl.trustStore` system property or the cacerts file from the JDK if the system property is unset." +msgstr "" + +msgid "The `Use Truststore SPI` configuration property, in the LDAP federation provider configuration, controls the truststore SPI. By default, {project_name} sets the property to `Always`, which is adequate for most deployments. {project_name} uses the Truststore SPI if the connection URL to LDAP starts with `ldaps` only." +msgstr "" + +msgid "Synchronizing LDAP users to {project_name}" +msgstr "" + +msgid "If you set the *Import Users* option, the LDAP Provider handles importing LDAP users into the {project_name} local database. The first time a user logs in or is returned as part of a user query (e.g. using the search field in the admin console), the LDAP provider imports the LDAP user into the {project_name} database. During authentication, the LDAP password is validated." +msgstr "" + +msgid "If you want to sync all LDAP users into the {project_name} database, configure and enable the *Sync Settings* on the LDAP provider configuration page." +msgstr "" + +msgid "Two types of synchronization exist:" +msgstr "" + +msgid "Periodic Full sync" +msgstr "" + +msgid "This type synchronizes all LDAP users into the {project_name} database. The LDAP users already in {project_name}, but different in LDAP, directly update in the {project_name} database." +msgstr "" + +msgid "Periodic Changed users sync" +msgstr "" + +msgid "When synchronizing, {project_name} creates or updates users created or updated after the last sync only." +msgstr "" + +msgid "The best way to synchronize is to click *Synchronize all users* when you first create the LDAP provider, then set up periodic synchronization of changed users." +msgstr "" + +msgid "LDAP mappers" +msgstr "" + +msgid "LDAP mappers are `listeners` triggered by the LDAP Provider. They provide another extension point to LDAP integration. LDAP mappers are triggered when:" +msgstr "" + +msgid "Users log in by using LDAP." +msgstr "" + +msgid "Users initially register." +msgstr "" + +msgid "The Admin Console queries a user." +msgstr "" + +msgid "When you create an LDAP Federation provider, {project_name} automatically provides a set of `mappers` for this provider. This set is changeable by users, who can also develop mappers or update/delete existing ones." +msgstr "" + +msgid "User Attribute Mapper" +msgstr "" + +msgid "This mapper specifies which LDAP attribute maps to the attribute of the {project_name} user. For example, you can configure the `mail` LDAP attribute to the `email` attribute in the {project_name} database. For this mapper implementation, a one-to-one mapping always exists." +msgstr "" + +msgid "FullName Mapper" +msgstr "" + +msgid "This mapper specifies the full name of the user. {project_name} saves the name in an LDAP attribute (usually `cn`) and maps the name to the `firstName` and `lastname` attributes in the {project_name} database. Having `cn` to contain the full name of the user is common for LDAP deployments." +msgstr "" + +msgid "When you register new users in {project_name} and `Sync Registrations` is ON for the LDAP provider, the fullName mapper permits falling back to the username. This fallback is useful when using Microsoft Active Directory (MSAD). The common setup for MSAD is to configure the `cn` LDAP attribute as fullName and, at the same time, use the `cn` LDAP attribute as the `RDN LDAP Attribute` in the LDAP provider configuration. With this setup, {project_name} falls back to the username. For example, if you create {project_name} user \"john123\" and leave firstName and lastName empty, then the fullname mapper saves \"john123\" as the value of the `cn` in LDAP. When you enter \"John Doe\" for firstName and lastName later, the fullname mapper updates LDAP `cn` to the \"John Doe\" value as falling back to the username is unnecessary." +msgstr "" + +msgid "Hardcoded Attribute Mapper" +msgstr "" + +msgid "This mapper adds a hardcoded attribute value to each {project_name} user linked with LDAP. This mapper can also force values for the `enabled` or `emailVerified` user properties." +msgstr "" + +msgid "Role Mapper" +msgstr "" + +msgid "This mapper configures role mappings from LDAP into {project_name} role mappings. A single role mapper can map LDAP roles (usually groups from a particular branch of the LDAP tree) into roles corresponding to a specified client's realm roles or client roles. You can configure more Role mappers for the same LDAP provider. For example, you can specify that role mappings from groups under `ou=main,dc=example,dc=org` map to realm role mappings, and role mappings from groups under `ou=finance,dc=example,dc=org` map to client role mappings of client `finance`." +msgstr "" + +msgid "Hardcoded Role Mapper" +msgstr "" + +msgid "This mapper grants a specified {project_name} role to each {project_name} user from the LDAP provider." +msgstr "" + +msgid "Group Mapper" +msgstr "" + +msgid "This mapper maps LDAP groups from a branch of an LDAP tree into groups within {project_name}. This mapper also propagates user-group mappings from LDAP into user-group mappings in {project_name}." +msgstr "" + +msgid "MSAD User Account Mapper" +msgstr "" + +msgid "This mapper is specific to Microsoft Active Directory (MSAD). It can integrate the MSAD user account state into the {project_name} account state, such as enabled account or expired password. This mapper uses the `userAccountControl`, and `pwdLastSet` LDAP attributes, specific to MSAD and are not the LDAP standard. For example, if the value of `pwdLastSet` is `0`, the {project_name} user must update their password. The result is an UPDATE_PASSWORD required action added to the user. If the value of `userAccountControl` is `514` (disabled account), the {project_name} user is disabled." +msgstr "" + +msgid "Certificate Mapper" +msgstr "" + +msgid "This mapper maps X.509 certificates. {project_name} uses it in conjunction with X.509 authentication and `Full certificate in PEM format` as an identity source. This mapper behaves similarly to the `User Attribute Mapper`, but {project_name} can filter for an LDAP attribute storing a PEM or DER format certificate. Enable `Always Read Value From LDAP` with this mapper." +msgstr "" + +msgid "User Attribute mappers that map basic {project_name} user attributes, such as username, firstname, lastname, and email, to corresponding LDAP attributes. You can extend these and provide your own additional attribute mappings. The Admin Console provides tooltips to help with configuring the corresponding mappers." +msgstr "" + +msgid "Password hashing" +msgstr "" + +msgid "When {project_name} updates a password, {project_name} sends the password in plain-text format. This action is different from updating the password in the built-in {project_name} database, where {project_name} hashes and salts the password before sending it to the database. For LDAP, {project_name} relies on the LDAP server to hash and salt the password." +msgstr "" + +msgid "By default, LDAP servers such as MSAD, RHDS, or FreeIPA hash and salt passwords. Other LDAP servers such as OpenLDAP or ApacheDS store the passwords in plain-text unless you use the _LDAPv3 Password Modify Extended Operation_ as described in https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3[RFC3062]. Enable the LDAPv3 Password Modify Extended Operation in the LDAP configuration page. See the documentation of your LDAP server for more details." +msgstr "" + +msgid "Always verify that user passwords are properly hashed and not stored as plaintext by inspecting a changed directory entry using `ldapsearch` and base64 decode the `userPassword` attribute value." +msgstr "" + +msgid "Troubleshooting" +msgstr "" + +msgid "It is useful to increase the logging level to TRACE for the category `org.keycloak.storage.ldap`. With this setting, many logging messages are sent to the server log in the `TRACE` level, including the logging for all queries to the LDAP server and the parameters, which were used to send the queries. When you are creating any LDAP question on user forum or JIRA, consider attaching the server log with enabled TRACE logging. If it is too big, the good alternative is to include just the snippet from server log with the messages, which were added to the log during the operation, which causes the issues to you." +msgstr "" + +msgid "When you create an LDAP provider, a message appears in the server log in the INFO level starting with:" +msgstr "" + +msgid "Creating new LDAP Store for the LDAP storage provider: ..." +msgstr "" + +msgid "It shows the configuration of your LDAP provider. Before you are asking the questions or reporting bugs, it will be nice to include this message to show your LDAP configuration. Eventually feel free to replace some config changes, which you do not want to include, with some placeholder values. One example is `bindDn=some-placeholder` . For `connectionUrl`, feel free to replace it as well, but it is generally useful to include at least the protocol, which was used (`ldap` vs `ldaps`)`. Similarly it can be useful to include the details for configuration of your LDAP mappers, which are displayed with the message like this at the DEBUG level:" +msgstr "" + +msgid "Mapper for provider: XXX, Mapper name: YYY, Provider: ZZZ ..." +msgstr "" + +msgid "Note those messages are displayed just with the enabled DEBUG logging." +msgstr "" + +msgid "For tracking the performance or connection pooling issues, consider setting the value of property `Connection Pool Debug Level` of the LDAP provider to value `all`. This will add lots of additional messages to server log with the included logging for the LDAP connection pooling. This can be used to track the issues related to connection pooling or performance." +msgstr "" + +msgid "After changing the configuration of connection pooling, you may need to restart the Keycloak server to enforce re-initialization of the LDAP provider connection." +msgstr "" + +msgid "If no more messages appear for connection pooling even after server restart, it can indicate that connection pooling does not work with your LDAP server." +msgstr "" + +msgid "For the case of reporting LDAP issue, you may consider to attach some part of your LDAP tree with the target data, which causes issues in your environment. For example if login of some user takes lot of time, you can consider attach his LDAP entry showing count of `member` attributes of various \"group\" entries. In this case, it might be useful to add if those group entries are mapped to some Group LDAP mapper (or Role LDAP Mapper) in {project_name} etc." +msgstr "" + +msgid "SSSD and FreeIPA Identity Management integration" +msgstr "" + +msgid "{project_name} includes the https://fedoraproject.org/wiki/Features/SSSD[System Security Services Daemon (SSSD)] plugin. SSSD is part of the Fedora and Red Hat Enterprise Linux (RHEL), and it provides access to multiple identities and authentication providers. SSSD also provides benefits such as failover and offline support. For more information, see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/sssd[the Red Hat Enterprise Linux Identity Management documentation]." +msgstr "" + +msgid "SSSD integrates with the FreeIPA identity management (IdM) server, providing authentication and access control. With this integration, {project_name} can authenticate against privileged access management (PAM) services and retrieve user data from SSSD. For more information about using Red Hat Identity Management in Linux environments, see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/index[the Red Hat Enterprise Linux Identity Management documentation]." +msgstr "" + +msgid "image:images/keycloak-sssd-freeipa-integration-overview.png[]" +msgstr "" + +msgid "{project_name} and SSSD communicate through read-only D-Bus interfaces. For this reason, the way to provision and update users is to use the FreeIPA/IdM administration interface. By default, the interface imports the username, email, first name, and last name." +msgstr "" + +msgid "{project_name} registers groups and roles automatically but does not synchronize them. Any changes made by the {project_name} administrator in {project_name} do not synchronize with SSSD." +msgstr "" + +msgid "FreeIPA/IdM server" +msgstr "" + +msgid "The https://quay.io/repository/freeipa/freeipa-server?tab=tags/[FreeIPA Container image] is available at https://quay.io/[Quay.io]. To set up the FreeIPA server, see the https://www.freeipa.org/page/Quick_Start_Guide[FreeIPA documentation]." +msgstr "" + +msgid "Run your FreeIPA server using this command:" +msgstr "" + +msgid "" +" docker run --name freeipa-server-container -it \\\n" +" -h server.freeipa.local -e PASSWORD=YOUR_PASSWORD \\\n" +" -v /sys/fs/cgroup:/sys/fs/cgroup:ro \\\n" +" -v /var/lib/ipa-data:/data:Z freeipa/freeipa-server" +msgstr "" + +msgid "The parameter `-h` with `server.freeipa.local` represents the FreeIPA/IdM server hostname. Change `YOUR_PASSWORD` to a password of your own." +msgstr "" + +msgid "After the container starts, change the `/etc/hosts` file to include:" +msgstr "" + +msgid "x.x.x.x server.freeipa.local" +msgstr "" + +msgid "If you do not make this change, you must set up a DNS server." +msgstr "" + +msgid "Use the following command to enroll your Linux server in the IPA domain so that the SSSD federation provider starts and runs on {project_name}:" +msgstr "" + +msgid " ipa-client-install --mkhomedir -p admin -w password" +msgstr "" + +msgid "Run the following command on the client to verify the installation is working:" +msgstr "" + +msgid " kinit admin" +msgstr "" + +msgid "Enter your password." +msgstr "" + +msgid "Add users to the IPA server using this command:" +msgstr "" + +msgid "$ ipa user-add --first= --last= --email= --phone= --street= --city= --state= --postalcode= --password" +msgstr "" + +msgid "Force set the user's password using kinit." +msgstr "" + +msgid " kinit " +msgstr "" + +msgid "Enter the following to restore normal IPA operation:" +msgstr "" + +msgid "" +"kdestroy -A\n" +"kinit admin" +msgstr "" + +msgid "SSSD and D-Bus" +msgstr "" + +msgid "The federation provider obtains the data from SSSD using D-BUS. It authenticates the data using PAM." +msgstr "" + +msgid "Install the sssd-dbus RPM." +msgstr "" + +msgid "$ sudo yum install sssd-dbus" +msgstr "" + +msgid "Run the following provisioning script:" +msgstr "" + +msgid "$ bin/federation-sssd-setup.sh" +msgstr "" + +msgid "The script can also be used as a guide to configure SSSD and PAM for {project_name}. It makes the following changes to `/etc/sssd/sssd.conf`:" +msgstr "" + +msgid "" +" [domain/your-hostname.local]\n" +" ...\n" +" ldap_user_extra_attrs = mail:mail, sn:sn, givenname:givenname, telephoneNumber:telephoneNumber\n" +" ...\n" +" [sssd]\n" +" services = nss, sudo, pam, ssh, ifp\n" +" ...\n" +" [ifp]\n" +" allowed_uids = root, yourOSUsername\n" +" user_attributes = +mail, +telephoneNumber, +givenname, +sn" +msgstr "" + +msgid "The `ifp` service is added to SSSD and configured to allow the OS user to interrogate the IPA server through this interface." +msgstr "" + +msgid "The script also creates a new PAM service `/etc/pam.d/keycloak` to authenticate users via SSSD:" +msgstr "" + +msgid "" +"auth required pam_sss.so\n" +"account required pam_sss.so" +msgstr "" + +msgid "Run `dbus-send` to ensure the setup is successful." +msgstr "" + +msgid "" +"dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string: array:string:mail,givenname,sn,telephoneNumber\n" +"\n" +"dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups string:" +msgstr "" + +msgid "If the setup is successful, each command displays the user's attributes and groups respectively. If there is a timeout or an error, the federation provider running on {project_name} cannot retrieve any data. This error usually happens because the server is not enrolled in the FreeIPA IdM server, or does not have permission to access the SSSD service." +msgstr "" + +msgid "If you do not have permission to access the SSSD service, ensure that the user running the {project_name} server is in the `/etc/sssd/sssd.conf` file in the following section:" +msgstr "" + +msgid "" +"[ifp]\n" +"allowed_uids = root, yourOSUsername" +msgstr "" + +msgid "And the `ipaapi` system user is created inside the host. This user is necessary for the `ifp` service. Check the user is created in the system." +msgstr "" + +msgid "" +"grep ipaapi /etc/passwd\n" +"ipaapi:x:992:988:IPA Framework User:/:/sbin/nologin" +msgstr "" + +msgid "Enabling the SSSD federation provider" +msgstr "" + +msgid "{project_name} uses https://github.com/hypfvieh/dbus-java[DBus-Java] project to communicate at a low level with D-Bus and https://github.com/java-native-access/jna[JNA] to authenticate via Operating System Pluggable Authentication Modules (PAM)." +msgstr "" + +msgid "Although now {project_name} contains all the needed libraries to run the `SSSD` provider, JDK version 17 is needed. Therefore the `SSSD` provider will only be displayed when the host configuration is correct and JDK 17 is used to run {project_name}." +msgstr "" + +msgid "Configuring a federated SSSD store" +msgstr "" + +msgid "After the installation, configure a federated SSSD store." +msgstr "" + +msgid "If everything is setup successfully the *Add Sssd providers* button will be displayed in the page. Click on it." +msgstr "" + +msgid "Assign a name to the new provider." +msgstr "" + +msgid "You can now authenticate against {project_name} using a FreeIPA/IdM user and credentials." +msgstr "" + +msgid "Custom providers" +msgstr "" + +msgid "{project_name} does have a Service Provider Interface (SPI) for User Storage Federation to develop custom providers. You can find documentation on developing customer providers in the link:{developerguide_link}[{developerguide_name}]." +msgstr "" + +msgid "Managing users" +msgstr "" + +msgid "From the Admin Console, you have a wide range of actions you can perform to manage users." +msgstr "" + +msgid "Creating users" +msgstr "" + +msgid "You create users in the realm where you intend to have applications needed by those users. Avoid creating users in the master realm, which is only intended for creating other realms." +msgstr "" + +msgid "Prerequisite" +msgstr "" + +msgid "You are in a realm other than the master realm." +msgstr "" + +msgid "Click *Users* in the menu." +msgstr "" + +msgid "Click *Add User*." +msgstr "" + +msgid "Enter the details for the new user." +msgstr "" + +msgid "*Username* is the only required field." +msgstr "" + +msgid "Click *Save*. After saving the details, the *Management* page for the new user is displayed." +msgstr "" + +msgid "Defining user credentials" +msgstr "" + +msgid "You can manage credentials of a user in the *Credentials* tab." +msgstr "" + +msgid "Credential management" +msgstr "" + +msgid "image:images/user-credentials.png[user credentials]" +msgstr "" + +msgid "You change the priority of credentials by dragging and dropping rows. The new order determines the priority of the credentials for that user. The topmost credential has the highest priority. The priority determines which credential is displayed first after a user logs in." +msgstr "" + +msgid "Type" +msgstr "" + +msgid "This column displays the type of credential, for example *password* or *OTP*." +msgstr "" + +msgid "User Label" +msgstr "" + +msgid "This is an assignable label to recognize the credential when presented as a selection option during login. It can be set to any value to describe the credential." +msgstr "" + +msgid "Data" +msgstr "" + +msgid "This is the non-confidential technical information about the credential. It is hidden, by default. You can click *Show data...* to display the data for a credential." +msgstr "" + +msgid "Actions" +msgstr "" + +msgid "Click *Reset password* to change the password for the user and *Delete* to remove the credential." +msgstr "" + +msgid "You cannot configure other types of credentials for a specific user in the Admin Console; that task is the user's responsibility." +msgstr "" + +msgid "You can delete the credentials of a user in the event a user loses an OTP device or if credentials have been compromised. You can only delete credentials of a user in the *Credentials* tab." +msgstr "" + +msgid "Setting a password for a user" +msgstr "" + +msgid "If a user does not have a password, or if the password has been deleted, the *Set Password* section is displayed." +msgstr "" + +msgid "If a user already has a password, it can be reset in the *Reset Password* section." +msgstr "" + +msgid "Click *Users* in the menu. The *Users* page is displayed." +msgstr "" + +msgid "Select a user." +msgstr "" + +msgid "Click the *Credentials* tab." +msgstr "" + +msgid "Type a new password in the *Set Password* section." +msgstr "" + +msgid "Click *Set Password*." +msgstr "" + +msgid "If *Temporary* is *ON*, the user must change the password at the first login. To allow users to keep the password supplied, set *Temporary* to *OFF.* The user must click *Set Password* to change the password." +msgstr "" + +msgid "Requesting a user reset a password" +msgstr "" + +msgid "You can also request that the user reset the password." +msgstr "" + +msgid "Click *Credential Reset*." +msgstr "" + +msgid "Select *Update Password* from the list." +msgstr "" + +msgid "Click *Send Email*. The sent email contains a link that directs the user to the *Update Password* window." +msgstr "" + +msgid "Optionally, you can set the validity of the email link. This is set to the default preset in the *Tokens* tab in *Realm Settings*." +msgstr "" + +msgid "Creating an OTP" +msgstr "" + +msgid "If OTP is conditional in your realm, the user must navigate to {project_name} Account Console to reconfigure a new OTP generator. If OTP is required, then the user must reconfigure a new OTP generator when logging in." +msgstr "" + +msgid "Alternatively, you can send an email to the user that requests the user reset the OTP generator. The following procedure also applies if the user already has an OTP credential." +msgstr "" + +msgid "You are logged in to the appropriate realm." +msgstr "" + +msgid "Click *Users* in the main menu. The *Users* page is displayed." +msgstr "" + +msgid "Set *Reset Actions* to *Configure OTP*." +msgstr "" + +msgid "Click *Send Email*. The sent email contains a link that directs the user to the *OTP setup page*." +msgstr "" + +msgid "Configuring user attributes" +msgstr "" + +msgid "User attributes provide a customized experience for each user. You can create a personalized identity for each user in the console by configuring user attributes." +msgstr "" + +msgid "Users" +msgstr "" + +msgid "image:images/user-attributes.png[]" +msgstr "" + +msgid "You are in the realm where the user exists." +msgstr "" + +msgid "Select a user to manage." +msgstr "" + +msgid "Click the *Attributes* tab." +msgstr "" + +msgid "Enter the attribute name in the *Key* field." +msgstr "" + +msgid "Enter the attribute value in the *Value* field." +msgstr "" + +msgid "Some read-only attributes are not supposed to be updated by the administrators. This includes attributes that are read-only by design like for example `LDAP_ID`, which is filled automatically by the LDAP provider. Some other attributes should be read-only for typical user administrators due to security reasons. See the details in the xref:read_only_user_attributes[Mitigating security threats] chapter." +msgstr "" + +msgid "Allowing users to self-register" +msgstr "" + +msgid "You can use {project_name} as a third-party authorization server to manage application users, including users who self-register. If you enable self-registration, the login page displays a registration link so that user can create an account." +msgstr "" + +msgid "Registration link" +msgstr "" + +msgid "image:images/registration-link.png[]" +msgstr "" + +msgid "A user must add profile information to the registration form to complete registration. The registration form can be customized by removing or adding the fields that must be completed by a user." +msgstr "" + +msgid "Clarification on identity brokering and admin API" +msgstr "" + +msgid "Even when self-registrations is disabled, new users can be still added to {project_name} by either:" +msgstr "" + +msgid "Administrator can add new users with the usage of admin console (or admin REST API)" +msgstr "" + +msgid "When identity brokering is enabled, new users authenticated by identity provider may be automatically added/registered in {project_name} storage. See the <<_identity_broker_first_login, First login flow section in the Identity Brokering chapter>> for more information." +msgstr "" + +msgid "Also users coming from the <<_user-storage-federation, 3rd-party user storage>> (for example LDAP) are automatically available in {project_name} when the particular user storage is enabled" +msgstr "" + +msgid "For more information on customizing user registration, see the link:{developerguide_link}[{developerguide_name}]." +msgstr "" + +msgid "Enabling user registration" +msgstr "" + +msgid "Enable users to self-register." +msgstr "" + +msgid "Click *Realm Settings* in the main menu." +msgstr "" + +msgid "Toggle *User Registration* to *ON*." +msgstr "" + +msgid "After you enable this setting, a *Register* link displays on the login page of the Admin Console." +msgstr "" + +msgid "Registering as a new user" +msgstr "" + +msgid "As a new user, you must complete a registration form to log in for the first time. You add profile information and a password to register." +msgstr "" + +msgid "Registration form" +msgstr "" + +msgid "image:images/registration-form.png[]" +msgstr "" + +msgid "User registration is enabled." +msgstr "" + +msgid "Click the *Register* link on the login page. The registration page is displayed." +msgstr "" + +msgid "Enter the user profile information." +msgstr "" + +msgid "Enter the new password." +msgstr "" + +msgid "Click *Register*." +msgstr "" + +msgid "Requiring user to agree to terms and conditions during registration" +msgstr "" + +msgid "For a user to register, you can require agreement to your terms and conditions." +msgstr "" + +msgid "Registration form with required terms and conditions agreement" +msgstr "" + +msgid "image:images/registration-form-with-required-tac.png[]" +msgstr "" + +msgid "Terms and conditions required action is enabled." +msgstr "" + +msgid "Click *Authentication* in the menu. Click the *Flows* tab." +msgstr "" + +msgid "Click the *registration* flow." +msgstr "" + +msgid "Select *Required* on the *Terms and Conditions* row." +msgstr "" + +msgid "Make the terms and conditions agreement required at registration" +msgstr "" + +msgid "image:images/require-tac-agreement-at-registration.png[]" +msgstr "" + +msgid "Defining actions required at login" +msgstr "" + +msgid "You can set the actions that a user must perform at the first login. These actions are required after the user provides credentials. After the first login, these actions are no longer required. You add required actions on the *Details* tab of that user." +msgstr "" + +msgid "The following are examples of required action types:" +msgstr "" + +msgid "Update Password" +msgstr "" + +msgid "The user must change their password." +msgstr "" + +msgid "Configure OTP" +msgstr "" + +msgid "The user must configure a one-time password generator on their mobile device using either the Free OTP or Google Authenticator application." +msgstr "" + +msgid "Verify Email" +msgstr "" + +msgid "The user must verify their email account. An email will be sent to the user with a validation link that they must click. Once this workflow is successfully completed, the user will be allowed to log in." +msgstr "" + +msgid "Update Profile" +msgstr "" + +msgid "The user must update profile information, such as name, address, email, and phone number." +msgstr "" + +msgid "Setting required actions for one user" +msgstr "" + +msgid "You can set the actions that are required for any user." +msgstr "" + +msgid "Select a user from the list." +msgstr "" + +msgid "Navigate to the *Required User Actions* list." +msgstr "" + +msgid "image:images/user-required-action.png[]" +msgstr "" + +msgid "Select all the actions you want to add to the account." +msgstr "" + +msgid "Click the *X* next to the action name to remove it." +msgstr "" + +msgid "Click *Save* after you select which actions to add." +msgstr "" + +msgid "Setting required actions for all users" +msgstr "" + +msgid "You can specify what actions are required before the first login of all new users. The requirements apply to a user created by the *Add User* button on the *Users* page or the *Register* link on the login page." +msgstr "" + +msgid "Click the *Required Actions* tab." +msgstr "" + +msgid "Click the checkbox in the *Set as default action* column for one or more required actions. When a new user logs in for the first time, the selected actions must be executed." +msgstr "" + +msgid "Enabling terms and conditions as a required action" +msgstr "" + +msgid "You can enable a required action that new users must accept the terms and conditions before logging in to {project_name} for the first time." +msgstr "" + +msgid "Enable the *Terms and Conditions* action." +msgstr "" + +msgid "Edit the `terms.ftl` file in the base login theme." +msgstr "" + +msgid "For more information on extending and creating themes, see the link:{developerguide_link}[{developerguide_name}]." +msgstr "" + +msgid "Searching for a user" +msgstr "" + +msgid "Search for a user to view detailed information about the user, such as the user's groups and roles." +msgstr "" + +msgid "Click *Users* in the main menu. This *Users* page is displayed." +msgstr "" + +msgid "Type the full name, last name, first name, or email address of the user you want to search for in the search box. The search returns all users that match your criteria." +msgstr "" + +msgid "The criteria used to match users depends on the syntax used on the search box:" +msgstr "" + +msgid "`\"somevalue\"` -> performs exact search of the string `\"somevalue\"`;" +msgstr "" + +msgid "`\\*somevalue*` -> performs infix search, akin to a `LIKE '%somevalue%'` DB query;" +msgstr "" + +msgid "`somevalue*` or `somevalue` -> performs prefix search, akin to a `LIKE 'somevalue%'` DB query." +msgstr "" + +msgid "Searches performed in the *Users* page encompasses searching both {project_name}'s database and configured user federated backends, such as LDAP. Users found in federated backends will be imported into {project_name}'s database if they don't already exist there." +msgstr "" + +msgid "For more information on user federation, see <<_user-storage-federation,User Federation>>." +msgstr "" + +msgid "Deleting a user" +msgstr "" + +msgid "You can delete a user, who no longer needs access to applications. If a user is deleted, the user profile and data is also deleted." +msgstr "" + +msgid "Click *View all users* to find a user to delete." +msgstr "" + +msgid "Alternatively, you can use the search bar to find a user." +msgstr "" + +msgid "Click *Delete* from the action menu next to the user you want to remove and confirm deletion." +msgstr "" + +msgid "Enabling account deletion by users" +msgstr "" + +msgid "End users and applications can delete their accounts in the Account Console if you enable this capability in the Admin Console. Once you enable this capability, you can give that capability to specific users." +msgstr "" + +msgid "Enabling the Delete Account Capability" +msgstr "" + +msgid "You enable this capability on the *Required Actions* tab." +msgstr "" + +msgid "Select *Enabled* on the *Delete Account* row." +msgstr "" + +msgid "Delete account on required actions tab" +msgstr "" + +msgid "image:images/enable-delete-account-action.png[]" +msgstr "" + +msgid "Giving a user the *delete-account* role" +msgstr "" + +msgid "You can give specific users a role that allows account deletion." +msgstr "" + +msgid "Click the *Role Mappings* tab." +msgstr "" + +msgid "Click the *Assign role* button." +msgstr "" + +msgid "Click *account delete-account*." +msgstr "" + +msgid "Click *Assign*." +msgstr "" + +msgid "Delete-account role" +msgstr "" + +msgid "image:images/delete-account-client-role.png[delete-account role]" +msgstr "" + +msgid "Deleting your account" +msgstr "" + +msgid "Once you have the *delete-account* role, you can delete your own account." +msgstr "" + +msgid "Log into the Account Console." +msgstr "" + +msgid "At the bottom of the *Personal Info* page, click *Delete Account*." +msgstr "" + +msgid "Delete account page" +msgstr "" + +msgid "image:images/delete-account-page.png[Delete account page]" +msgstr "" + +msgid "Enter your credentials and confirm the deletion." +msgstr "" + +msgid "Delete confirmation" +msgstr "" + +msgid "image:images/delete-account-confirm.png[]" +msgstr "" + +msgid "This action is irreversible. All your data in {project_name} will be removed." +msgstr "" + +msgid "Impersonating a user" +msgstr "" + +msgid "An administrator with the appropriate permissions can impersonate a user. For example, if a user experiences a bug in an application, an administrator can impersonate the user to investigate or duplicate the issue." +msgstr "" + +msgid "Any user with the `impersonation` role in the realm can impersonate a user." +msgstr "" + +msgid "Click a user to impersonate." +msgstr "" + +msgid "From the *Actions* list, select *Impersonate*." +msgstr "" + +msgid "image:images/user-details.png[]" +msgstr "" + +msgid "If the administrator and the user are in the same realm, then the administrator will be logged out and automatically logged in as the user being impersonated." +msgstr "" + +msgid "If the administrator and user are in different realms, the administrator will remain logged in, and additionally will be logged in as the user in that user's realm." +msgstr "" + +msgid "In both instances, the *User Account Management* page of the impersonated user is displayed." +msgstr "" + +msgid "For more information on assigning administration permissions, see the <<_admin_permissions,Admin Console Access Control>> chapter." +msgstr "" + +msgid "Enabling reCAPTCHA" +msgstr "" + +msgid "To safeguard registration against bots, {project_name} has integration with Google reCAPTCHA." +msgstr "" + +msgid "Once reCAPTCHA is enabled, you can edit `register.ftl` in your login theme to configure the placement and styling of the reCAPTCHA button on the registration page." +msgstr "" + +msgid "Enter the following URL in a browser:" +msgstr "" + +msgid "https://developers.google.com/recaptcha/" +msgstr "" + +msgid "Create an API key to get your reCAPTCHA site key and secret. Note the reCAPTCHA site key and secret for future use in this procedure." +msgstr "" + +msgid "The localhost works by default. You do not have to specify a domain." +msgstr "" + +msgid "Navigate to the {project_name} admin console." +msgstr "" + +msgid "Select *Registration* from the list." +msgstr "" + +msgid "Set the *reCAPTCHA* requirement to *Required*. This enables reCAPTCHA." +msgstr "" + +msgid "Click the *gear icon* ⚙️ on the *reCAPTCHA* row." +msgstr "" + +msgid "Click the *Config* link." +msgstr "" + +msgid "Recaptcha config page" +msgstr "" + +msgid "image:images/recaptcha-config.png[]" +msgstr "" + +msgid "Enter the *Recaptcha Site Key* generated from the Google reCAPTCHA website." +msgstr "" + +msgid "Enter the *Recaptcha Secret* generated from the Google reCAPTCHA website." +msgstr "" + +msgid "Authorize Google to use the registration page as an iframe." +msgstr "" + +msgid "In {project_name}, websites cannot include a login page dialog in an iframe. This restriction is to prevent clickjacking attacks. You need to change the default HTTP response headers that is set in {project_name}." +msgstr "" + +msgid "Click the *Security Defenses* tab." +msgstr "" + +msgid "Enter `https://www.google.com` in the field for the *X-Frame-Options* header." +msgstr "" + +msgid "Enter `https://www.google.com` in the field for the *Content-Security-Policy* header." +msgstr "" + +msgid "Defining a user profile" +msgstr "" + +msgid "In {project_name} a user is associated with a set of attributes. These attributes are used to better describe and identify users within {project_name} as well as to pass over additional information about them to applications." +msgstr "" + +msgid "A user profile defines a well-defined schema for representing user attributes and how they are managed within a realm. By providing a consistent view over user information, it allows administrators to control the different aspects on how attributes are managed as well as to make it much easier to extend {project_name} to support additional attributes." +msgstr "" + +msgid "Among other capabilities, user profile enables administrators to:" +msgstr "" + +msgid "Define a schema for user attributes" +msgstr "" + +msgid "Define whether an attribute is required based on contextual information (e.g.: if required only for users, or admins, or both, or depending on the scope being requested.)" +msgstr "" + +msgid "Define specific permissions for viewing and editing user attributes, making possible to adhere to strong privacy requirements where some attributes can not be seen or be changed by third-parties (including administrators)" +msgstr "" + +msgid "Dynamically enforce user profile compliance so that user information is always updated and in compliance with the metadata and rules associated with attributes" +msgstr "" + +msgid "Define validation rules on a per-attribute basis by leveraging the built-in validators or writing custom ones" +msgstr "" + +msgid "Dynamically render forms that users interact with like registration, update profile, brokering, and personal information in the account console, according to the attribute definitions and without any need to manually change themes." +msgstr "" + +msgid "The User Profile capabilities are backed by the User Profile SPI. By default, these capabilities are disabled and realms are configured to use a default configuration that keeps backward compatibility with the legacy behavior." +msgstr "" + +msgid "The legacy behavior is about keeping the default constraints used by {project_name} when managing users root attributes such as username, email, first and last name, without any restriction on how custom attributes are managed. Regarding user flows such as registration, profile update, brokering, and managing accounts through the account console, users are restricted to use the attributes aforementioned with the possibility to change theme templates to support additional attributes." +msgstr "" + +msgid "If you are already using {project_name}, the legacy behavior is what you have been using so far." +msgstr "" + +msgid "Differently than the legacy behavior, the declarative provider gives you a lot more flexibility to define the user profile configuration to a realm through the administration console and a well-defined JSON schema." +msgstr "" + +msgid "In the next sections, we'll be looking at how to use the declarative provider to define your own user profile configuration." +msgstr "" + +msgid "In the future, the legacy behavior will no longer be supported in {project_name}. Ideally, you should start looking at the new capabilities provided by the User Profile and migrate your realms accordingly." +msgstr "" + +msgid "Enabling the User Profile" +msgstr "" + +msgid "{tech_feature_name} is *Technology Preview* and is not fully supported. This feature is disabled by default." +msgstr "" + +msgid "To enable start the server with `--features=preview` or `--features={tech_feature_id}`" +msgstr "" + +msgid "In addition to enabling the `declarative_user_profile` feature, you should enable User Profile for a realm. To do that, click on the `Realm Settings` link on the left side menu and turn on the `User Profile Enabled` switch." +msgstr "" + +msgid "image:images/user-profile-enabling.png[]" +msgstr "" + +msgid "Once you enable it and click on the `Save` button, you can access the `User Profile` tab from where you can manage the configuration for user attributes." +msgstr "" + +msgid "By enabling the user profile for a realm, {project_name} is going to impose additional constraints on how attributes are managed based on the user profile configuration. In summary, here is the list of what you should expect when the feature is enabled:" +msgstr "" + +msgid "From an administration point of view, the `Attributes` tab at the user details page will only show the attributes defined in the user profile configuration. The conditions defined on a per-attribute basis will also be taken into account when managing attributes." +msgstr "" + +msgid "User facing forms like registration, update profile, brokering, and personal info in the account console, are going to be rendered dynamically based on the user profile configuration. For that, {project_name} is going to rely on different templates to render these forms dynamically." +msgstr "" + +msgid "In the next topics, we'll be exploring how to manage the user profile configuration and how it affects your realm." +msgstr "" + +msgid "Managing the User Profile" +msgstr "" + +msgid "The user profile configuration is managed on a per-realm basis. For that, click on the `Realm Settings` link on the left side menu and then click on the `User Profile` tab." +msgstr "" + +msgid "User Profile Tab" +msgstr "" + +msgid "image:images/user-profile-tab.png[]" +msgstr "" + +msgid "In the `Attributes` sub-tab you have a list of the attributes currently associated with the user profile. By default, the configuration is created based on the user root attributes and each attribute is configured with some defaults in terms of validation and permissioning." +msgstr "" + +msgid "In the `Attribute Groups` sub-tab you can manage attribute groups. An attribute group allows you to correlate attributes so that they are displayed together when rendering user facing forms." +msgstr "" + +msgid "For now, attribute groups are only used for rendering purposes but in the future they should also enable defining top-level configurations to the attributes they are linked to." +msgstr "" + +msgid "In the `JSON Editor` sub-tab you can view and edit the configuration using a well-defined JSON schema. Any change you make when at any other tab are reflected in the JSON configuration shown at this tab." +msgstr "" + +msgid "In the next section, you are going to learn how to manage the configuration from the `Attributes` sub-tab." +msgstr "" + +msgid "Managing Attributes" +msgstr "" + +msgid "At the `Attributes` sub-tab you can create, edit, and delete the attributes associated with the user profile." +msgstr "" + +msgid "To define a new attribute and associate it with the user profile, click on the *Create attribute* button at the top the attribute listing." +msgstr "" + +msgid "Attribute Configuration" +msgstr "" + +msgid "image:images/user-profile-create-attribute.png[]" +msgstr "" + +msgid "When configuring the attribute you can define the following settings:" +msgstr "" + +msgid "Name" +msgstr "" + +msgid "The name of the attribute." +msgstr "" + +msgid "Display name" +msgstr "" + +msgid "A user-friendly name for the attribute, mainly used when rendering user-facing forms. It supports internationalization so that values can be loaded from message bundles." +msgstr "" + +msgid "Attribute Group" +msgstr "" + +msgid "The attribute group to which the attribute belongs to, if any." +msgstr "" + +msgid "Enabled when scope" +msgstr "" + +msgid "Allows you to define a list of scopes to dynamically enable an attribute. If not set, the attribute is always enabled and its constraints are always enforced when managing user profiles as well as when rendering user-facing forms. Otherwise, the same constraints only apply when any of the scopes in the list is requested by clients." +msgstr "" + +msgid "Required" +msgstr "" + +msgid "Set the attribute as required. If not enabled, the attribute is optional. Otherwise, the attribute must be provided by users and administrators with the possibility to also make the attribute required only for users or administrators as well as based on the scopes requested by clients." +msgstr "" + +msgid "Permission" +msgstr "" + +msgid "In this section, you can define read and write permissions for users and administrators." +msgstr "" + +msgid "Validation" +msgstr "" + +msgid "In this section, you can define the validations that will be performed when managing the attribute value. {project_name} provides a set of built-in validators you can choose from with the possibility to add your own." +msgstr "" + +msgid "Annotation" +msgstr "" + +msgid "In this section, you can associate annotations to the attribute. Annotations are mainly useful to pass over additional metadata to frontends for rendering purposes." +msgstr "" + +msgid "Managing Permissions" +msgstr "" + +msgid "In the `Permission` section, you can define the level of access users and administrators have to read and write to an attribute." +msgstr "" + +msgid "Attribute Permission" +msgstr "" + +msgid "image:images/user-profile-permission.png[]" +msgstr "" + +msgid "For that, you can use the following settings:" +msgstr "" + +msgid "Can user view?" +msgstr "" + +msgid "If enabled, users can view the attribute. Otherwise, users don't have access to the attribute." +msgstr "" + +msgid "Can user edit?" +msgstr "" + +msgid "If enabled, users can view and edit the attribute. Otherwise, users don't have access to write to the attribute." +msgstr "" + +msgid "Can admin view?" +msgstr "" + +msgid "If enabled, administrators can view the attribute. Otherwise, administrators don't have access to the attribute." +msgstr "" + +msgid "Can admin edit?" +msgstr "" + +msgid "If enabled, administrators can view and edit the attribute. Otherwise, administrators don't have access to write to the attribute." +msgstr "" + +msgid "When you create an attribute, no permission is set to the attribute. Effectively, the attribute won't be accessible by either users or administrators. Once you create the attribute, make sure to set the permissions accordingly to that the attribute is only visible by the target audience." +msgstr "" + +msgid "Permissioning has a direct impact on how and who can manage the attribute, as well as on how the attribute is rendered in user-facing forms." +msgstr "" + +msgid "For instance, by marking an attribute as only viewable by users, the administrators won't have access to the attribute when managing users through the administration console (neither from the User API). Also, users won't be able to change the attribute when updating their profiles. An interesting configuration if user attributes are fetched from an existing identity store (federation) and you just want to make attributes visible to users without any possibility to update the attribute other than through the source identity store." +msgstr "" + +msgid "Similarly, you can also mark an attribute as writable only for administrators with read-only access for users. In this case, only administrators are going to be allowed to manage the attribute." +msgstr "" + +msgid "Depending on your privacy requirements, you might also want attributes inaccessible to administrators but with read-write permissions for users." +msgstr "" + +msgid "Make sure to set the correct permissions whenever you add a new attribute to the user profile configuration." +msgstr "" + +msgid "Managing validations" +msgstr "" + +msgid "In the `Validation` section, you can choose from different forms of validation to make sure the attribute value conforms to specific rules." +msgstr "" + +msgid "Attribute Validation" +msgstr "" + +msgid "image:images/user-profile-validation.png[]" +msgstr "" + +msgid "{project_name} provides different validators out of the box:" +msgstr "" + +msgid "Description" +msgstr "" + +msgid "Configuration" +msgstr "" + +msgid "length" +msgstr "" + +msgid "Check the length of a string value based on a minimum and maximum length." +msgstr "" + +msgid "" +"*min*: an integer to define the minimum allowed length.\n" +"\n" +"*max*: an integer to define the maximum allowed length.\n" +"\n" +"*trim-disabled*: a boolean to define whether the value is trimmed prior to validation." +msgstr "" + +msgid "integer" +msgstr "" + +msgid "Check if the value is an integer and within a lower and/or upper range. If no range is defined, the validator only checks whether the value is a valid number." +msgstr "" + +msgid "" +"*min*: an integer to define the lower range.\n" +"\n" +"*max*: an integer to define the upper range." +msgstr "" + +msgid "double" +msgstr "" + +msgid "Check if the value is a double and within a lower and/or upper range. If no range is defined, the validator only checks whether the value is a valid number." +msgstr "" + +msgid "uri" +msgstr "" + +msgid "Check if the value is a valid URI." +msgstr "" + +msgid "None" +msgstr "" + +msgid "pattern" +msgstr "" + +msgid "Check if the value matches a specific RegEx pattern." +msgstr "" + +msgid "" +"*pattern*: the RegEx pattern to use when validating values.\n" +"\n" +"*error-message*: the key of the error message in i18n bundle. If not set a generic message is used." +msgstr "" + +msgid "email" +msgstr "" + +msgid "Check if the value has a valid e-mail format." +msgstr "" + +msgid "*max-local-length*: an integer to define the maximum length for the local part of the email. It defaults to 64 per specification." +msgstr "" + +msgid "local-date" +msgstr "" + +msgid "Check if the value has a valid format based on the realm and/or user locale." +msgstr "" + +msgid "person-name-prohibited-characters" +msgstr "" + +msgid "Check if the value is a valid person name as an additional barrier for attacks such as script injection. The validation is based on a default RegEx pattern that blocks characters not common in person names." +msgstr "" + +msgid "*error-message*: the key of the error message in i18n bundle. If not set a generic message is used." +msgstr "" + +msgid "username-prohibited-characters" +msgstr "" + +msgid "Check if the value is a valid username as an additional barrier for attacks such as script injection. The validation is based on a default RegEx pattern that blocks characters not common in usernames." +msgstr "" + +msgid "options" +msgstr "" + +msgid "Check if the value is from the defined set of allowed values. Useful to validate values entered through select and multiselect fields." +msgstr "" + +msgid "*options*: array of strings containing allowed values." +msgstr "" + +msgid "Managing annotations" +msgstr "" + +msgid "In order to pass additional information to frontends, attributes can be decorated with annotations to dictate how attributes are rendered. This capability is mainly useful when extending {project_name} themes to render pages dynamically based on the annotations associated with attributes. This mechanism is used for example to link:#_configuring_form_input_field_for_attribute[configure Form input filed for attribute]." +msgstr "" + +msgid "Attribute Annotation" +msgstr "" + +msgid "image:images/user-profile-annotation.png[]" +msgstr "" + +msgid "Managing Attribute Groups" +msgstr "" + +msgid "At the `Attribute Groups` sub-tab you can create, edit, and delete attribute groups. An attribute group allows you to define a container for correlated attributes so that they are rendered together when at the user-facing forms." +msgstr "" + +msgid "Attribute Group List" +msgstr "" + +msgid "image:images/user-profile-attribute-group-list.png[]" +msgstr "" + +msgid "You can't delete attribute groups that are bound to attributes. For that, you should first update the attributes to remove the binding." +msgstr "" + +msgid "To create a new group, click on the *Create attributes group* button on the top of the attribute groups listing." +msgstr "" + +msgid "Attribute Group Configuration" +msgstr "" + +msgid "image:images/user-profile-create-attribute-group.png[]" +msgstr "" + +msgid "When configuring the group you can define the following settings:" +msgstr "" + +msgid "The name of the group." +msgstr "" + +msgid "A user-friendly name for the group, mainly used when rendering user-facing forms. It supports internationalization so that values can be loaded from message bundles." +msgstr "" + +msgid "Display description" +msgstr "" + +msgid "A user-friendly text that will be displayed as a tooltip when rendering user-facing forms." +msgstr "" + +msgid "Using the JSON configuration" +msgstr "" + +msgid "The user profile configuration is stored using a well-defined JSON schema. You can choose from editing the user profile configuration directly by clicking on the `JSON Editor` sub-tab." +msgstr "" + +msgid "JSON Configuration" +msgstr "" + +msgid "image:images/user-profile-json-config.png[]" +msgstr "" + +msgid "The JSON schema is defined as follows:" +msgstr "" + +msgid "" +"{\n" +" \"attributes\": [\n" +" {\n" +" \"name\": \"myattribute\",\n" +" \"required\": {\n" +" \"roles\": [ \"user\", \"admin\" ],\n" +" \"scopes\": [ \"foo\", \"bar\" ]\n" +" },\n" +" \"permissions\": {\n" +" \"view\": [ \"admin\", \"user\" ],\n" +" \"edit\": [ \"admin\", \"user\" ]\n" +" },\n" +" \"validations\": {\n" +" \"email\": {\n" +" \"max-local-length\": 64\n" +" },\n" +" \"length\": {\n" +" \"max\": 255\n" +" }\n" +" },\n" +" \"annotations\": {\n" +" \"myannotation\": \"myannotation-value\"\n" +" }\n" +" }\n" +" ],\n" +" \"groups\": [\n" +" {\n" +" \"name\": \"personalInfo\",\n" +" \"displayHeader\": \"Personal Information\"\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "The schema supports as many attributes as you need." +msgstr "" + +msgid "For each attribute you should define a `name` and, optionally, the `required`, `permission`, and the `annotations` settings." +msgstr "" + +msgid "Required property" +msgstr "" + +msgid "The `required` setting defines whether an attribute is required. {project_name} allows you to set an attribute as required based on different conditions." +msgstr "" + +msgid "When the `required` setting is defined as an empty object, the attribute is always required." +msgstr "" + +msgid "" +"{\n" +" \"attributes\": [\n" +" {\n" +" \"name\": \"myattribute\",\n" +" \"required\": {}\n" +" ]\n" +"}" +msgstr "" + +msgid "On the other hand, you can choose to make the attribute required only for users, or administrators, or both. As well as mark the attribute as required only in case a specific scope is requested when the user is authenticating in {project_name}." +msgstr "" + +msgid "To mark an attribute as required for a user and/or administrator, set the `roles` property as follows:" +msgstr "" + +msgid "" +"{\n" +" \"attributes\": [\n" +" {\n" +" \"name\": \"myattribute\",\n" +" \"required\": {\n" +" \"roles\": [\"user\"]\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "The `roles` property expects an array whose values can be either `user` or `admin`, depending on whether the attribute is required by the user or the administrator, respectively." +msgstr "" + +msgid "Similarly, you can choose to make the attribute required when a set of one or more scopes is requested by a client when authenticating a user. For that, you can use the `scopes` property as follows:" +msgstr "" + +msgid "" +"{\n" +" \"attributes\": [\n" +" {\n" +" \"name\": \"myattribute\",\n" +" \"required\": {\n" +" \"scopes\": [\"foo\"]\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "The `scopes` property is an array whose values can be any string representing a client scope." +msgstr "" + +msgid "Permissions property" +msgstr "" + +msgid "The attribute-level `permissions` property can be used to define the read and write permissions to an attribute. The permissions are set based on whether these operations can be performed on the attribute by a user, or administrator, or both." +msgstr "" + +msgid "" +"{\n" +" \"attributes\": [\n" +" {\n" +" \"name\": \"myattribute\",\n" +" \"permissions\": {\n" +" \"view\": [\"admin\"],\n" +" \"edit\": [\"user\"]\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "Both `view` and `edit` properties expect an array whose values can be either `user` or `admin`, depending on whether the attribute is viewable or editable by the user or the administrator, respectively." +msgstr "" + +msgid "When the `edit` permission is granted, the `view` permission is implicitly granted." +msgstr "" + +msgid "Annotations property" +msgstr "" + +msgid "The attribute-level `annotation` property can be used to associate additional metadata to attributes. Annotations are mainly useful for passing over additional information about attributes to frontends rendering user attributes based on the user profile configuration. Each annotation is a key/value pair." +msgstr "" + +msgid "" +"{\n" +" \"attributes\": [\n" +" {\n" +" \"name\": \"myattribute\",\n" +" \"annotations\": {\n" +" \"foo\": [\"foo-value\"],\n" +" \"bar\": [\"bar-value\"]\n" +" }\n" +" ]\n" +"}" +msgstr "" + +msgid "Using dynamic forms" +msgstr "" + +msgid "One of the main capabilities of User Profile is the possibility to dynamically render user-facing forms based on attributes metadata. When you have the feature enabled to your realm, forms like registration and update profile are rendered using specific theme templates to dynamically render pages based on the user profile configuration." +msgstr "" + +msgid "That said, you shouldn't need to customize templates at all if the default rendering mechanisms serves to your needs. In case you still need customizations to themes, here are the templates you should be looking at:" +msgstr "" + +msgid "base/login/update-user-profile.ftl" +msgstr "" + +msgid "The template that renders the update profile page." +msgstr "" + +msgid "base/login/register-user-profile.ftl" +msgstr "" + +msgid "The template that renders the registration page." +msgstr "" + +msgid "base/login/idp-review-user-profile.ftl" +msgstr "" + +msgid "The template that renders the page to review/update the user profile when federating users through brokering." +msgstr "" + +msgid "base/login/user-profile-commons.ftl" +msgstr "" + +msgid "The template that renders input fields in forms based on attributes configuration. Used from all three page templates described above. New input types can be implemented here." +msgstr "" + +msgid "The default rendering mechanism provides the following capabilities:" +msgstr "" + +msgid "Dynamically display fields based on the permissions set to attributes." +msgstr "" + +msgid "Dynamically render markers for required fields based on the constraints set to the attributes." +msgstr "" + +msgid "Dynamically render field input type (text, date, number, select, multiselect) set to an attribute." +msgstr "" + +msgid "Dynamically render read-only fields depending on the permissions set to an attribute." +msgstr "" + +msgid "Dynamically order fields depending on the order set to the attributes." +msgstr "" + +msgid "Dynamically group fields that belong to a same attribute group." +msgstr "" + +msgid "Ordering attributes" +msgstr "" + +msgid "The attributes order is set by dragging and dropping the attribute rows on the attribute listing page." +msgstr "" + +msgid "Ordering Attributes" +msgstr "" + +msgid "image:images/user-profile-attribute-list-order.png[]" +msgstr "" + +msgid "The order you set in this page is respected when fields are rendered in dynamic forms." +msgstr "" + +msgid "Grouping attributes" +msgstr "" + +msgid "When dynamic forms are rendered, they will try to group together attributes that belong to a same attribute group." +msgstr "" + +msgid "Dynamic Update Profile Form" +msgstr "" + +msgid "image:images/user-profile-update-profile.png[]" +msgstr "" + +msgid "When attributes are linked to an attribute group, the attribute order is also important to make sure attributes within the same group are close together, within a same group header. Otherwise, if attributes within a group do not have a sequential order you might have the same group header rendered multiple times in the dynamic form." +msgstr "" + +msgid "Configuring Form input filed for Attributes" +msgstr "" + +msgid "{project_name} provides built-in annotations to configure which input type will be used for the attribute in dynamic forms and other aspects of it's visualization." +msgstr "" + +msgid "Available annotations are:" +msgstr "" + +msgid "inputType" +msgstr "" + +msgid "Type of the form input field. Available types are described in a table below." +msgstr "" + +msgid "inputHelperTextBefore" +msgstr "" + +msgid "" +"Helper text rendered before (above) the input field. Direct text or internationalization pattern (like `${i18n.key}`) can be used here.\n" +"Text is NOT html escaped when rendered into the page, so you can use html tags here to format the text, but you also have to correctly escape html control characters." +msgstr "" + +msgid "inputHelperTextAfter" +msgstr "" + +msgid "" +"Helper text rendered after (under) the input field. Direct text or internationalization pattern (like `${i18n.key}`) can be used here.\n" +"Text is NOT html escaped when rendered into the page, so you can use html tags here to format the text, but you also have to correctly escape html control characters." +msgstr "" + +msgid "inputOptionsFromValidation" +msgstr "" + +msgid "Annotation for select and multiselect types. Optional name of custom attribute validation to get input options from. See link:#_managing_options_for_select_fields[detailed description] below." +msgstr "" + +msgid "inputOptionLabelsI18nPrefix" +msgstr "" + +msgid "Annotation for select and multiselect types. Internationalization key prefix to render options in UI. See link:#_managing_options_for_select_fields[detailed description] below." +msgstr "" + +msgid "inputOptionLabels" +msgstr "" + +msgid "Annotation for select and multiselect types. Optional map to define UI labels for options (directly or using internationalization). See link:#_managing_options_for_select_fields[detailed description] below." +msgstr "" + +msgid "inputTypePlaceholder" +msgstr "" + +msgid "" +"HTML input `placeholder` attribute applied to the field - specifies a short hint that describes the expected value of an input field (e.g. a sample value\n" +"or a short description of the expected format). The short hint is displayed in the input field before the user enters a value." +msgstr "" + +msgid "inputTypeSize" +msgstr "" + +msgid "" +"HTML input `size` attribute applied to the field - specifies the width, in characters, of a single line input field. For fields based on HTML `select` type\n" +"it specifies number of rows with options shown. May not work, depending on css in used theme!" +msgstr "" + +msgid "inputTypeCols" +msgstr "" + +msgid "HTML input `cols` attribute applied to the field - specifies the width, in characters, for `textarea` type. May not work, depending on css in used theme!" +msgstr "" + +msgid "inputTypeRows" +msgstr "" + +msgid "" +"HTML input `rows` attribute applied to the field - specifies the height, in characters, for `textarea` type. For select fields it specifies number\n" +"of rows with options shown. May not work, depending on css in used theme!" +msgstr "" + +msgid "inputTypePattern" +msgstr "" + +msgid "" +"HTML input `pattern` attribute applied to the field providing client side validation - specifies a regular expression that an input field's value\n" +"is checked against. Useful for single line inputs." +msgstr "" + +msgid "inputTypeMaxLength" +msgstr "" + +msgid "" +"HTML input `maxlength` attribute applied to the field providing client side validation - maximal length of the text which can be entered into the input\n" +"field. Useful for text fields." +msgstr "" + +msgid "inputTypeMinLength" +msgstr "" + +msgid "" +"HTML input `minlength` attribute applied to the field providing client side validation - minimal length of the text which can be entered into the input\n" +"field. Useful for text fields." +msgstr "" + +msgid "inputTypeMax" +msgstr "" + +msgid "" +"HTML input `max` attribute applied to the field providing client side validation - maximal value which can be entered into the input field.\n" +"Useful for numeric fields." +msgstr "" + +msgid "inputTypeMin" +msgstr "" + +msgid "" +"HTML input `min` attribute applied to the field providing client side validation - minimal value which can be entered into the input field.\n" +"Useful for numeric fields." +msgstr "" + +msgid "inputTypeStep" +msgstr "" + +msgid "HTML input `step` attribute applied to the field - Specifies the interval between legal numbers in an input field. Useful for numeric fields." +msgstr "" + +msgid "Field types use HTML form field tags and attributes applied to them - they behave based on the HTML specifications and browser support for them." +msgstr "" + +msgid "Visual rendering also depends on css styles applied in the used theme." +msgstr "" + +msgid "Available `inputType` annotation values:" +msgstr "" + +msgid "HTML tag used" +msgstr "" + +msgid "text" +msgstr "" + +msgid "Single line text input." +msgstr "" + +msgid "input" +msgstr "" + +msgid "textarea" +msgstr "" + +msgid "Multiple line text input." +msgstr "" + +msgid "select" +msgstr "" + +msgid "Common single select input. See link:#_managing_options_for_select_fields[description how to configure options] below." +msgstr "" + +msgid "select-radiobuttons" +msgstr "" + +msgid "Single select input through group of radio buttons. See link:#_managing_options_for_select_fields[description how to configure options] below." +msgstr "" + +msgid "group of input" +msgstr "" + +msgid "multiselect" +msgstr "" + +msgid "Common multiselect input. See link:#_managing_options_for_select_fields[description how to configure options] below." +msgstr "" + +msgid "multiselect-checkboxes" +msgstr "" + +msgid "Multiselect input through group of checkboxes. See link:#_managing_options_for_select_fields[description how to configure options] below." +msgstr "" + +msgid "html5-email" +msgstr "" + +msgid "Single line text input for email address based on HTML 5 spec." +msgstr "" + +msgid "html5-tel" +msgstr "" + +msgid "Single line text input for phone number based on HTML 5 spec." +msgstr "" + +msgid "html5-url" +msgstr "" + +msgid "Single line text input for URL based on HTML 5 spec." +msgstr "" + +msgid "html5-number" +msgstr "" + +msgid "Single line input for number (integer or float depending on `step`) based on HTML 5 spec." +msgstr "" + +msgid "html5-range" +msgstr "" + +msgid "Slider for number entering based on HTML 5 spec." +msgstr "" + +msgid "html5-datetime-local" +msgstr "" + +msgid "Date Time input based on HTML 5 spec." +msgstr "" + +msgid "html5-date" +msgstr "" + +msgid "Date input based on HTML 5 spec." +msgstr "" + +msgid "html5-month" +msgstr "" + +msgid "Month input based on HTML 5 spec." +msgstr "" + +msgid "html5-week" +msgstr "" + +msgid "Week input based on HTML 5 spec." +msgstr "" + +msgid "html5-time" +msgstr "" + +msgid "Time input based on HTML 5 spec." +msgstr "" + +msgid "Defining options for select and multiselect fields" +msgstr "" + +msgid "Options for select and multiselect fields are taken from validation applied to the attribute to be sure validation and field options presented in UI are always consistent. By default, options are taken from built-in `options` validation." +msgstr "" + +msgid "You can use various ways to provide nice human-readable labels for select and multiselect options. The simplest case is when attribute values are same as UI labels. No extra configuration is necessary in this case." +msgstr "" + +msgid "Option values same as UI labels" +msgstr "" + +msgid "image:images/user-profile-select-options-simple.png[]" +msgstr "" + +msgid "When attribute value is kind of ID not suitable for UI, you can use simple internationalization support provided by `inputOptionLabelsI18nPrefix` annotation. It defines prefix for internationalization keys, option value is dot appended to this prefix." +msgstr "" + +msgid "Simple internationalization for UI labels using i18n key prefix" +msgstr "" + +msgid "image:images/user-profile-select-options-simple-i18n.png[]" +msgstr "" + +msgid "Localized UI label texts for option value have to be provided by `userprofile.jobtitle.sweng` and `userprofile.jobtitle.swarch` keys then, using common localization mechanism." +msgstr "" + +msgid "You can also use `inputOptionLabels` annotation to provide labels for individual options. It contains map of labels for option - key in the map is option value (defined in validation), and value in the map is UI label text itself or its internationalization pattern (like `${i18n.key}`) for that option." +msgstr "" + +msgid "You have to use User Profile `JSON Editor` to enter map as `inputOptionLabels` annotation value." +msgstr "" + +msgid "Example of directly entered labels for individual options without internationalization:" +msgstr "" + +msgid "" +"\"attributes\": [\n" +"<...\n" +"{\n" +" \"name\": \"jobTitle\",\n" +" \"validations\": {\n" +" \"options\": {\n" +" \"options\":[\n" +" \"sweng\",\n" +" \"swarch\"\n" +" ]\n" +" }\n" +" },\n" +" \"annotations\": {\n" +" \"inputType\": \"select\",\n" +" \"inputOptionLabels\": {\n" +" \"sweng\": \"Software Engineer\",\n" +" \"swarch\": \"Software Architect\"\n" +" }\n" +" }\n" +"}\n" +"...\n" +"]" +msgstr "" + +msgid "Example of the internationalized labels for individual options:" +msgstr "" + +msgid "" +"\"attributes\": [\n" +"...\n" +"{\n" +" \"name\": \"jobTitle\",\n" +" \"validations\": {\n" +" \"options\": {\n" +" \"options\":[\n" +" \"sweng\",\n" +" \"swarch\"\n" +" ]\n" +" }\n" +" },\n" +" \"annotations\": {\n" +" \"inputType\": \"select-radiobuttons\",\n" +" \"inputOptionLabels\": {\n" +" \"sweng\": \"${jobtitle.swengineer}\",\n" +" \"swarch\": \"${jobtitle.swarchitect}\"\n" +" }\n" +" }\n" +"}\n" +"...\n" +"]" +msgstr "" + +msgid "Localized texts have to be provided by `jobtitle.swengineer` and `jobtitle.swarchitect` keys then, using common localization mechanism." +msgstr "" + +msgid "Custom validator can be used to provide options thanks to `inputOptionsFromValidation` attribute annotation. This validation have to have `options` config providing array of options. Internationalization works the same way as for options provided by built-in `options` validation." +msgstr "" + +msgid "Options provided by custom validator" +msgstr "" + +msgid "image:images/user-profile-select-options-custom-validator.png[]" +msgstr "" + +msgid "Forcing User Profile compliance" +msgstr "" + +msgid "In order to make sure user profiles are in compliance with the configuration, administrators may use the `VerifyProfile` required action to eventually force users to update their profiles when authenticating to {project_name}." +msgstr "" + +msgid "The `VerifyProfile` action is similar to the `UpdateProfile` action. However, it leverages all the capabilities provided by the user profile to automatically enforce compliance with the user profile configuration." +msgstr "" + +msgid "When enabled, the `VerifyProfile` action is going to perform the following steps when the user is authenticating:" +msgstr "" + +msgid "Check whether the user profile is fully compliant with the user profile configuration set to the realm." +msgstr "" + +msgid "If not, perform an additional step during the authentication so that the user can update any missing or invalid attribute." +msgstr "" + +msgid "If the user profile is compliant with the configuration, no additional step is performed, and the user continues with the authentication process." +msgstr "" + +msgid "By default, the `VerifyProfile` action is disabled. To enabled it, click on the `Authentication` link on the left side menu and then click on the `Required Actions` tab. At this tab, select the *Enabled* switch of the `VerifyProfile` action." +msgstr "" + +msgid "Registering the VerifyProfile Required Action" +msgstr "" + +msgid "image:images/user-profile-register-verify-profile-action.png[]" +msgstr "" + +msgid "Migrating to User Profile" +msgstr "" + +msgid "Before enabling the User Profile capabilities to a realm, there are some important considerations you should be aware of. By providing a single place to manage attribute metadata, the feature is very strict about the attributes that can be set to users and how they are managed." +msgstr "" + +msgid "In terms of user management, administrators are able to manage only the attributes defined in the user profile configuration. Any other attribute set to the user and not yet defined in the user profile configuration won't be accessible. It is recommended to update your user profile configuration with all the user attributes you want to expose either to users or administrators." +msgstr "" + +msgid "The same recommendation applies for those accessing the User REST API to query user information." +msgstr "" + +msgid "In regards to {project_name} internal user attributes such as `LDAP_ID`, `LDAP_ENTRY_DN`, or `KERBEROS_PRINCIPAL`, if you want to be able to access those attributes you should have them as attributes in your user profile configuration. The recommendation is to mark these attributes as viewable only to administrators so that you can look at them when managing the user attributes through the administration console or querying users via User API." +msgstr "" + +msgid "In regards to theming, if you already have customizations to the legacy templates (those hardcoded with user root attributes) your custom templates won't be used when rendering user-facing forms but the new templates that render these forms dynamically. Ideally, you should avoid having any customizations to templates and try to stick with the behavior provided by these new templates to dynamically render forms for you. If they are still not enough to address your requirements, you can either customize them or provide us with any feedback so that we discuss whether it makes sense to enhance the new templates." +msgstr "" + +msgid "Personal data collected by {project_name}" +msgstr "" + +msgid "By default, {project_name} collects the following data:" +msgstr "" + +msgid "Basic user profile data, such as the user email, first name, and last name." +msgstr "" + +msgid "Basic user profile data used for social accounts and references to the social account when using a social login." +msgstr "" + +msgid "Device information collected for audit and security purposes, such as the IP address, operating system name, and the browser name." +msgstr "" + +msgid "The information collected in {project_name} is highly customizable. The following guidelines apply when making customizations:" +msgstr "" + +msgid "Registration and account forms can contain custom fields, such as birthday, gender, and nationality. An administrator can configure {project_name} to retrieve data from a social provider or a user storage provider such as LDAP." +msgstr "" + +msgid "{project_name} collects user credentials, such as password, OTP codes, and WebAuthn public keys. This information is encrypted and saved in a database, so it is not visible to {project_name} administrators. Each type of credential can include non-confidential metadata that is visible to administrators such as the algorithm that is used to hash the password and the number of hash iterations used to hash the password." +msgstr "" + +msgid "With authorization services and UMA support enabled, {project_name} can hold information about some objects for which a particular user is the owner." +msgstr "" + +msgid "Managing user sessions" +msgstr "" + +msgid "When users log into realms, {project_name} maintains a user session for each user and remembers each client visited by the user within the session. Realm administrators can perform multiple actions on each user session:" +msgstr "" + +msgid "View login statistics for the realm." +msgstr "" + +msgid "View active users and where they logged in." +msgstr "" + +msgid "Log a user out of their session." +msgstr "" + +msgid "Revoke tokens." +msgstr "" + +msgid "Set up token timeouts." +msgstr "" + +msgid "Set up session timeouts." +msgstr "" + +msgid "Administering sessions" +msgstr "" + +msgid "To see a top-level view of the active clients and sessions in {project_name}, click *Sessions* from the menu." +msgstr "" + +msgid "Sessions" +msgstr "" + +msgid "image:images/sessions.png[Sessions tab]" +msgstr "" + +msgid "Signing out all active sessions" +msgstr "" + +msgid "You can sign out all users in the realm. From the *Action* list, select *Sign out all active sessions*. All SSO cookies become invalid. {project_name} notifies clients by using the {project_name} OIDC client adapter of the logout event. Clients requesting authentication within active browser sessions must log in again. Client types such as SAML do not receive a back-channel logout request." +msgstr "" + +msgid "Clicking *Sign out all active sessions* does not revoke outstanding access tokens. Outstanding tokens must expire naturally. For clients using the {project_name} OIDC client adapter, you can push a <<_revocation-policy, revocation policy>> to revoke the token, but this does not work for other adapters." +msgstr "" + +msgid "Viewing client sessions" +msgstr "" + +msgid "Click the *Sessions* tab." +msgstr "" + +msgid "Click a client to see that client's sessions." +msgstr "" + +msgid "Client sessions" +msgstr "" + +msgid "image:images/client-sessions.png[Client sessions]" +msgstr "" + +msgid "Viewing user sessions" +msgstr "" + +msgid "Click a user to see that user's sessions." +msgstr "" + +msgid "User sessions" +msgstr "" + +msgid "image:images/user-sessions.png[User sessions]" +msgstr "" + +msgid "Revoking active sessions" +msgstr "" + +msgid "If your system is compromised, you can revoke all active sessions and access tokens." +msgstr "" + +msgid "Click *Sessions* in the menu." +msgstr "" + +msgid "From the *Actions* list, select *Revocation*." +msgstr "" + +msgid "Revocation" +msgstr "" + +msgid "image:images/revocation.png[Revocation]" +msgstr "" + +msgid "Specify a time and date where sessions or tokens issued before that time and date are invalid using this console." +msgstr "" + +msgid "Click *Set to now* to set the policy to the current time and date." +msgstr "" + +msgid "Click *Push* to push this revocation policy to any registered OIDC client with the {project_name} OIDC client adapter." +msgstr "" + +msgid "Session and token timeouts" +msgstr "" + +msgid "{project_name} includes control of the session, cookie, and token timeouts through the *Sessions* and *Tokens* tabs in the *Realm settings* menu." +msgstr "" + +msgid "Sessions tab" +msgstr "" + +msgid "image:images/sessions-tab.png[Sessions Tab]" +msgstr "" + +msgid "SSO Session Idle" +msgstr "" + +msgid "This setting is for OIDC clients only. If a user is inactive for longer than this timeout, the user session is invalidated. This timeout value resets when clients request authentication or send a refresh token request. {project_name} adds a window of time to the idle timeout before the session invalidation takes effect. See the <<_idle_timeouts_note, note>> later in this section." +msgstr "" + +msgid "SSO Session Max" +msgstr "" + +msgid "The maximum time before a user session expires." +msgstr "" + +msgid "SSO Session Idle Remember Me" +msgstr "" + +msgid "This setting is similar to the standard SSO Session Idle configuration but specific to logins with *Remember Me* enabled. Users can specify longer session idle timeouts when they click *Remember Me* when logging in. This setting is an optional configuration and, if its value is not greater than zero, it uses the same idle timeout as the SSO Session Idle configuration." +msgstr "" + +msgid "SSO Session Max Remember Me" +msgstr "" + +msgid "This setting is similar to the standard SSO Session Max but specific to *Remember Me* logins. Users can specify longer sessions when they click *Remember Me* when logging in. This setting is an optional configuration and, if its value is not greater than zero, it uses the same session lifespan as the SSO Session Max configuration." +msgstr "" + +msgid "Client Session Idle" +msgstr "" + +msgid "Idle timeout for the client session. If the user is inactive for longer than this timeout, the client session is invalidated and the refresh token requests bump the idle timeout. This setting never affects the general SSO user session, which is unique. Note the SSO user session is the parent of zero or more client sessions, one client session is created for every different client app the user logs in. This value should specify a shorter idle timeout than the *SSO Session Idle*. Users can override it for individual clients in the *Advanced Settings* client tab. This setting is an optional configuration and, when set to zero, uses the same idle timeout in the SSO Session Idle configuration." +msgstr "" + +msgid "Client Session Max" +msgstr "" + +msgid "" +"The maximum time for a client session and before a refresh token expires and invalidates. As in the previous option, this setting never affects the SSO user session and should specify a shorter value than the *SSO Session Max*. Users can override it for individual clients in the *Advanced Settings* client tab. This setting is an optional configuration and, when set to zero, uses the same max timeout in the SSO Session Max configuration.\n" +"\n" +"[[_offline-session-idle]]" +msgstr "" + +msgid "Offline Session Idle" +msgstr "" + +msgid "" +"This setting is for <<_offline-access, offline access>>. The amount of time the session remains idle before {project_name} revokes its offline token. {project_name} adds a window of time to the idle timeout before the session invalidation takes effect. See the <<_idle_timeouts_note, note>> later in this section.\n" +"\n" +"[[_offline-session-max-limited]]" +msgstr "" + +msgid "Offline Session Max Limited" +msgstr "" + +msgid "" +"This setting is for <<_offline-access, offline access>>. If this flag is *Enabled*, Offline Session Max can control the maximum time the offline token remains active, regardless of user activity. If the flag is *Disabled*, offline sessions never expire by lifespan, only by idle. Once this option is activated, the <<_offline-session-max, Offline Session Max>> (global option at realm level) and *Client Offline Session Max* (specific client level option in the *Advanced Settings* tab) can be configured.\n" +"\n" +"[[_offline-session-max]]" +msgstr "" + +msgid "Offline Session Max" +msgstr "" + +msgid "This setting is for <<_offline-access, offline access>>, and it is the maximum time before {project_name} revokes the corresponding offline token. This option controls the maximum amount of time the offline token remains active, regardless of user activity." +msgstr "" + +msgid "Login timeout" +msgstr "" + +msgid "The total time a logging in must take. If authentication takes longer than this time, the user must start the authentication process again." +msgstr "" + +msgid "Login action timeout" +msgstr "" + +msgid "The Maximum time users can spend on any one page during the authentication process." +msgstr "" + +msgid "Tokens tab" +msgstr "" + +msgid "image:images/tokens-tab.png[Tokens Tab]" +msgstr "" + +msgid "Default Signature Algorithm" +msgstr "" + +msgid "" +"The default algorithm used to assign tokens for the realm.\n" +"\n" +"[[_revoke-refresh-token]]" +msgstr "" + +msgid "Revoke Refresh Token" +msgstr "" + +msgid "When *Enabled*, {project_name} revokes refresh tokens and issues another token that the client must use. This action applies to OIDC clients performing the refresh token flow." +msgstr "" + +msgid "Access Token Lifespan" +msgstr "" + +msgid "When {project_name} creates an OIDC access token, this value controls the lifetime of the token." +msgstr "" + +msgid "Access Token Lifespan For Implicit Flow" +msgstr "" + +msgid "With the Implicit Flow, {project_name} does not provide a refresh token. A separate timeout exists for access tokens created by the Implicit Flow." +msgstr "" + +msgid "Client login timeout" +msgstr "" + +msgid "The maximum time before clients must finish the Authorization Code Flow in OIDC." +msgstr "" + +msgid "User-Initiated Action Lifespan" +msgstr "" + +msgid "The maximum time before a user's action permission expires. Keep this value short because users generally react to self-created actions quickly." +msgstr "" + +msgid "Default Admin-Initiated Action Lifespan" +msgstr "" + +msgid "The maximum time before an action permission sent to a user by an administrator expires. Keep this value long to allow administrators to send e-mails to offline users. An administrator can override the default timeout before issuing the token." +msgstr "" + +msgid "Email Verification" +msgstr "" + +msgid "Specifies independent timeout for email verification." +msgstr "" + +msgid "IdP account email verification" +msgstr "" + +msgid "Specifies independent timeout for IdP account email verification." +msgstr "" + +msgid "Forgot password" +msgstr "" + +msgid "Specifies independent timeout for forgot password." +msgstr "" + +msgid "Execute actions" +msgstr "" + +msgid "Specifies independent timeout for execute actions." +msgstr "" + +msgid "For idle timeouts, a two-minute window of time exists that the session is active. For example, when you have the timeout set to 30 minutes, it will be 32 minutes before the session expires." +msgstr "" + +msgid "This action is necessary for some scenarios in cluster and cross-data center environments where the token refreshes on one cluster node a short time before the expiration and the other cluster nodes incorrectly consider the session as expired because they have not yet received the message about a successful refresh from the refreshing node." +msgstr "" + +msgid "Offline access" +msgstr "" + +msgid "During https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess[offline access] logins, the client application requests an offline token instead of a refresh token. The client application saves this offline token and can use it for future logins if the user logs out. This action is useful if your application needs to perform offline actions on behalf of the user even when the user is not online. For example, a regular data backup." +msgstr "" + +msgid "The client application is responsible for persisting the offline token in storage and then using it to retrieve new access tokens from the {project_name} server." +msgstr "" + +msgid "The difference between a refresh token and an offline token is that an offline token never expires and is not subject to the `SSO Session Idle` timeout and `SSO Session Max` lifespan. The offline token is valid after a user logout or server restart. You must use the offline token for a refresh token action at least once per thirty days or for the value of the <<_offline-session-idle, Offline Session Idle>>." +msgstr "" + +msgid "If you enable <<_offline-session-max-limited, Offline Session Max Limited>>, offline tokens expire after 60 days even if you use the offline token for a refresh token action. You can change this value, <<_offline-session-max, Offline Session Max>>, in the Admin Console." +msgstr "" + +msgid "When using offline access, client idle and max timeouts can be overridden at the <<_client_advanced_settings_oidc,client level>>. The options *Client Offline Session Idle* and *Client Offline Session Max*, in the client *Advanced Settings* tab, allow you to have a shorter offline timeouts for a specific application. Note that client session values also control the refresh token expiration but they never affect the global offline user SSO session. The option *Client Offline Session Max* is only evaluated in the client if <<_offline-session-max-limited, Offline Session Max Limited>> is *Enabled* at the realm level." +msgstr "" + +msgid "If you enable the <<_revoke-refresh-token, Revoke Refresh Token>> option, you can use each offline token once only. After refresh, you must store the new offline token from the refresh response instead of the previous one." +msgstr "" + +msgid "Users can view and revoke offline tokens that {project_name} grants them in the <<_account-service, User Account Console>>. Administrators can revoke offline tokens for individual users in the Admin Console in the `Consents` tab. Administrators can view all offline tokens issued in the `Offline Access` tab of each client. Administrators can revoke offline tokens by setting a <<_revocation-policy, revocation policy>>." +msgstr "" + +msgid "To issue an offline token, users must have the role mapping for the realm-level `offline_access` role. Clients must also have that role in their scope. Clients must add an `offline_access` client scope as an `Optional client scope` to the role, which is done by default." +msgstr "" + +msgid "Clients can request an offline token by adding the parameter `scope=offline_access` when sending their authorization request to {project_name}. The {project_name} OIDC client adapter automatically adds this parameter when you use it to access your application's secured URL (such as, $$http://localhost:8080/customer-portal/secured?scope=offline_access$$). The Direct Access Grant and Service Accounts support offline tokens if you include `scope=offline_access` in the authentication request body." +msgstr "" + +msgid "Offline sessions are besides the Infinispan caches stored also in the database. Whenever the {project_name} server is restarted or an offline session is evicted from the Infinispan cache, it is still available in the database. Any following attempt to access the offline session will load the session from the database, and also import it to the Infinispan cache. To reduce memory requirements, we introduced a configuration option to shorten lifespan for imported offline sessions. Such sessions will be evicted from the Infinispan caches after the specified lifespan, but still available in the database. This will lower memory consumption, especially for deployments with a large number of offline sessions. Currently, the offline session lifespan override is disabled by default. To specify the lifespan override for offline user sessions, start {project_name} server with the following parameter:" +msgstr "" + +msgid "--spi-user-sessions-infinispan-offline-session-cache-entry-lifespan-override=" +msgstr "" + +msgid "Similarly for offline client sessions:" +msgstr "" + +msgid "--spi-user-sessions-infinispan-offline-client-session-cache-entry-lifespan-override=" +msgstr "" + +msgid "Offline sessions preloading" +msgstr "" + +msgid "In addition to Infinispan caches, offline sessions are stored in a database which means they will be available even after server restart. By default, the offline sessions are not preloaded from the database into the Infinispan caches during the server startup, because this approach has a drawback if there are many offline sessions to be preloaded. It can significantly slow down the server startup time. Therefore, the offline sessions are lazily fetched from the database by default." +msgstr "" + +msgid "However, {project_name} can be configured to preload the offline sessions from the database into the Infinispan caches during the server startup. It can be achieved by setting `preloadOfflineSessionsFromDatabase` property in the `userSessions` SPI to `true`." +msgstr "" + +msgid "The following example shows how to configure offline sessions preloading." +msgstr "" + +msgid "bin/kc.[sh|bat] start --spi-user-sessions-infinispan-preload-offline-sessions-from-database=true" +msgstr "" + +msgid "Transient sessions" +msgstr "" + +msgid "You can conduct transient sessions in {project_name}. When using transient sessions, {project_name} does not create a user session after successful authentication. {project_name} creates a temporary, transient session for the scope of the current request that successfully authenticates the user. {project_name} can run <<_protocol-mappers, protocol mappers>> using transient sessions after authentication." +msgstr "" + +msgid "The `sid` and `session_state` of the tokens are usually empty when the token is issued with transient sessions. So during transient sessions, the client application cannot refresh tokens or validate a specific session. Sometimes these actions are unnecessary, so you can avoid the additional resource use of persisting user sessions. This session saves performance, memory, and network communication (in cluster and cross-data center environments) resources." +msgstr "" + +msgid "At this moment, transient sessions are automatically used just during <<_service_accounts, service account authentication>> with disabled token refresh. Note that token refresh is automatically disabled during service account authentication unless explicitly enabled by client switch `Use refresh tokens for client credentials grant`." +msgstr "" + +msgid "Assigning permissions using roles and groups" +msgstr "" + +msgid "Roles and groups have a similar purpose, which is to give users access and permissions to use applications. Groups are a collection of users to which you apply roles and attributes. Roles define specific applications permissions and access control." +msgstr "" + +msgid "A role typically applies to one type of user. For example, an organization may include `admin`, `user`, `manager`, and `employee` roles. An application can assign access and permissions to a role and then assign multiple users to that role so the users have the same access and permissions. For example, the Admin Console has roles that give permission to users to access different parts of the Admin Console." +msgstr "" + +msgid "There is a global namespace for roles and each client also has its own dedicated namespace where roles can be defined." +msgstr "" + +msgid "Creating a realm role" +msgstr "" + +msgid "Realm-level roles are a namespace for defining your roles. To see the list of roles, click *Realm Roles* in the menu." +msgstr "" + +msgid "image:images/roles.png[]" +msgstr "" + +msgid "Click *Create Role*." +msgstr "" + +msgid "Enter a *Role Name*." +msgstr "" + +msgid "Enter a *Description*." +msgstr "" + +msgid "Add role" +msgstr "" + +msgid "image:images/role.png[Add role]" +msgstr "" + +msgid "The *description* field can be localized by specifying a substitution variable with `$\\{var-name}` strings. The localized value is configured to your theme within the themes property files. See the link:{developerguide_link}[{developerguide_name}] for more details." +msgstr "" + +msgid "Client roles" +msgstr "" + +msgid "Client roles are namespaces dedicated to clients. Each client gets its own namespace. Client roles are managed under the *Roles* tab for each client. You interact with this UI the same way you do for realm-level roles." +msgstr "" + +msgid "Converting a role to a composite role" +msgstr "" + +msgid "Any realm or client level role can become a _composite role_. A _composite role_ is a role that has one or more additional roles associated with it. When a composite role is mapped to a user, the user gains the roles associated with the composite role. This inheritance is recursive so users also inherit any composite of composites. However, we recommend that composite roles are not overused." +msgstr "" + +msgid "Click *Realm Roles* in the menu." +msgstr "" + +msgid "Click the role that you want to convert." +msgstr "" + +msgid "From the *Action* list, select *Add associated roles*." +msgstr "" + +msgid "Composite role" +msgstr "" + +msgid "image:images/composite-role.png[Composite role]" +msgstr "" + +msgid "The role selection UI is displayed on the page and you can associate realm level and client level roles to the composite role you are creating." +msgstr "" + +msgid "In this example, the *employee* realm-level role is associated with the *developer* composite role. Any user with the *developer* role also inherits the *employee* role." +msgstr "" + +msgid "When creating tokens and SAML assertions, any composite also has its associated roles added to the claims and assertions of the authentication response sent back to the client." +msgstr "" + +msgid "Assigning role mappings" +msgstr "" + +msgid "You can assign role mappings to a user through the *Role Mappings* tab for that user." +msgstr "" + +msgid "Click the user that you want to perform a role mapping on." +msgstr "" + +msgid "Click the *Role mappings* tab." +msgstr "" + +msgid "Click *Assign role*." +msgstr "" + +msgid "Select the role you want to assign to the user from the dialog." +msgstr "" + +msgid "Role mappings" +msgstr "" + +msgid "image:images/user-role-mappings.png[Role mappings]" +msgstr "" + +msgid "In the preceding example, we are assigning the composite role *developer* to a user. That role was created in the <<_composite-roles, Composite Roles>> topic." +msgstr "" + +msgid "Effective role mappings" +msgstr "" + +msgid "image:images/effective-role-mappings.png[Effective role mappings]" +msgstr "" + +msgid "When the *developer* role is assigned, the *employee* role associated with the *developer* composite is displayed with *Inherited* \"True\". *Inherited* roles are the roles explicitly assigned to users and roles that are inherited from composites." +msgstr "" + +msgid "Using default roles" +msgstr "" + +msgid "Use default roles to automatically assign user role mappings when a user is created or imported through <<_identity_broker, Identity Brokering>>." +msgstr "" + +msgid "Click the *User registration* tab." +msgstr "" + +msgid "Default roles" +msgstr "" + +msgid "image:images/default-roles.png[Default roles]" +msgstr "" + +msgid "This screenshot shows that some _default roles_ already exist." +msgstr "" + +msgid "Role scope mappings" +msgstr "" + +msgid "On creation of an OIDC access token or SAML assertion, the user role mappings become claims within the token or assertion. Applications use these claims to make access decisions on the resources controlled by the application. {project_name} digitally signs access tokens and applications re-use them to invoke remotely secured REST services. However, these tokens have an associated risk. An attacker can obtain these tokens and use their permissions to compromise your networks. To prevent this situation, use _Role Scope Mappings_." +msgstr "" + +msgid "_Role Scope Mappings_ limit the roles declared inside an access token. When a client requests a user authentication, the access token they receive contains only the role mappings that are explicitly specified for the client's scope. The result is that you limit the permissions of each individual access token instead of giving the client access to all the users permissions." +msgstr "" + +msgid "By default, each client gets all the role mappings of the user. You can view the role mappings for a client." +msgstr "" + +msgid "Click the client to go to the details." +msgstr "" + +msgid "Click the *Client scopes* tab." +msgstr "" + +msgid "Click the link in the row with _Dedicated scope and mappers for this client_" +msgstr "" + +msgid "Click the *Scope* tab." +msgstr "" + +msgid "Full scope" +msgstr "" + +msgid "image:images/full-client-scope.png[Full scope]" +msgstr "" + +msgid "By default, the effective roles of scopes are every declared role in the realm. To change this default behavior, toggle *Full Scope Allowed* to *OFF* and declare the specific roles you want in each client. You can also use <<_client_scopes, client scopes>> to define the same role scope mappings for a set of clients." +msgstr "" + +msgid "Partial scope" +msgstr "" + +msgid "image:images/client-scope.png[Partial scope]" +msgstr "" + +msgid "Groups" +msgstr "" + +msgid "Groups in {project_name} manage a common set of attributes and role mappings for each user. Users can be members of any number of groups and inherit the attributes and role mappings assigned to each group." +msgstr "" + +msgid "To manage groups, click *Groups* in the menu." +msgstr "" + +msgid "image:images/groups.png[]" +msgstr "" + +msgid "Groups are hierarchical. A group can have multiple subgroups but a group can have only one parent. Subgroups inherit the attributes and role mappings from their parent. Users inherit the attributes and role mappings from their parent as well." +msgstr "" + +msgid "If you have a parent group and a child group, and a user that belongs only to the child group, the user in the child group inherits the attributes and role mappings of both the parent group and the child group." +msgstr "" + +msgid "The following example includes a top-level *Sales* group and a child *North America* subgroup." +msgstr "" + +msgid "To add a group:" +msgstr "" + +msgid "Click the group." +msgstr "" + +msgid "Click *Create group*." +msgstr "" + +msgid "Enter a group name." +msgstr "" + +msgid "Click the group name." +msgstr "" + +msgid "The group management page is displayed." +msgstr "" + +msgid "Group" +msgstr "" + +msgid "image:images/group.png[]" +msgstr "" + +msgid "Attributes and role mappings you define are inherited by the groups and users that are members of the group." +msgstr "" + +msgid "To add a user to a group:" +msgstr "" + +msgid "Click the user that you want to perform a role mapping on. If the user is not displayed, click *View all users*." +msgstr "" + +msgid "Click *Groups*." +msgstr "" + +msgid "User groups" +msgstr "" + +msgid "image:images/user-groups.png[]" +msgstr "" + +msgid "Click *Join Group*." +msgstr "" + +msgid "Select a group from the dialog." +msgstr "" + +msgid "Select a group from the *Available Groups* tree." +msgstr "" + +msgid "Click *Join*." +msgstr "" + +msgid "To remove a group from a user:" +msgstr "" + +msgid "Click the user to be removed from the group." +msgstr "" + +msgid "Click *Leave* on the group table row." +msgstr "" + +msgid "In this example, the user _jimlincoln_ is in the _North America_ group. You can see _jimlincoln_ displayed under the *Members* tab for the group." +msgstr "" + +msgid "Group membership" +msgstr "" + +msgid "image:images/group-membership.png[]" +msgstr "" + +msgid "Groups compared to roles" +msgstr "" + +msgid "Groups and roles have some similarities and differences. In {project_name}, groups are a collection of users to which you apply roles and attributes. Roles define types of users and applications assign permissions and access control to roles." +msgstr "" + +msgid "<<_composite-roles,Composite Roles>> are similar to Groups as they provide the same functionality. The difference between them is conceptual. Composite roles apply the permission model to a set of services and applications. Use composite roles to manage applications and services." +msgstr "" + +msgid "Groups focus on collections of users and their roles in an organization. Use groups to manage users." +msgstr "" + +msgid "Using default groups" +msgstr "" + +msgid "To automatically assign group membership to any users who is created or who is imported through <<_identity_broker, Identity Brokering>>, you use default groups." +msgstr "" + +msgid "Click the *Default Groups* tab." +msgstr "" + +msgid "Default groups" +msgstr "" + +msgid "image:images/default-groups.png[Default groups]" +msgstr "" + +msgid "This screenshot shows that some _default groups_ already exist." +msgstr "" + +msgid "Configuring authentication" +msgstr "" + +msgid "This chapter covers several authentication topics. These topics include:" +msgstr "" + +msgid "Enforcing strict password and One Time Password (OTP) policies." +msgstr "" + +msgid "Managing different credential types." +msgstr "" + +msgid "Logging in with Kerberos." +msgstr "" + +msgid "Disabling and enabling built-in credential types." +msgstr "" + +msgid "Password policies" +msgstr "" + +msgid "When {project_name} creates a realm, it does not associate password policies with the realm. You can set a simple password with no restrictions on its length, security, or complexity. Simple passwords are unacceptable in production environments. {project_name} has a set of password policies available through the Admin Console." +msgstr "" + +msgid "Click the *Policies* tab." +msgstr "" + +msgid "Select the policy to add in the *Add policy* drop-down box." +msgstr "" + +msgid "Enter a value that applies to the policy chosen." +msgstr "" + +msgid "Password policy image:images/password-policy.png[Password Policy]" +msgstr "" + +msgid "After saving the policy, {project_name} enforces the policy for new users." +msgstr "" + +msgid "The new policy will not be effective for existing users. Therefore, make sure that you set the password policy from the beginning of the realm creation or add \"Update password\" to existing users or use \"Expire password\" to make sure that users update their passwords in next \"N\" days, which will actually adjust to new password policies." +msgstr "" + +msgid "Password policy types" +msgstr "" + +msgid "HashAlgorithm" +msgstr "" + +msgid "Passwords are not stored in cleartext. Before storage or validation, {project_name} hashes passwords using standard hashing algorithms. PBKDF2 is the only built-in and default algorithm available. See the link:{developerguide_link}[{developerguide_name}] on how to add your own hashing algorithm." +msgstr "" + +msgid "If you change the hashing algorithm, password hashes in storage will not change until the user logs in." +msgstr "" + +msgid "Hashing iterations" +msgstr "" + +msgid "Specifies the number of times {project_name} hashes passwords before storage or verification. The default value is 27,500." +msgstr "" + +msgid "{project_name} hashes passwords to ensure that hostile actors with access to the password database cannot read passwords through reverse engineering." +msgstr "" + +msgid "A high hashing iteration value can impact performance as it requires higher CPU power." +msgstr "" + +msgid "Digits" +msgstr "" + +msgid "The number of numerical digits required in the password string." +msgstr "" + +msgid "Lowercase characters" +msgstr "" + +msgid "The number of lower case letters required in the password string." +msgstr "" + +msgid "Uppercase characters" +msgstr "" + +msgid "The number of upper case letters required in the password string." +msgstr "" + +msgid "Special characters" +msgstr "" + +msgid "The number of special characters required in the password string." +msgstr "" + +msgid "Not username" +msgstr "" + +msgid "The password cannot be the same as the username." +msgstr "" + +msgid "Not email" +msgstr "" + +msgid "The password cannot be the same as the email address of the user." +msgstr "" + +msgid "Regular expression" +msgstr "" + +msgid "Password must match one or more defined Java regular expression patterns. See https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/regex/Pattern.html[Java's regular expression documentation] for the syntax of those expressions." +msgstr "" + +msgid "Expire password" +msgstr "" + +msgid "The number of days the password is valid. When the number of days has expired, the user must change their password." +msgstr "" + +msgid "Not recently used" +msgstr "" + +msgid "Password cannot be already used by the user. {project_name} stores a history of used passwords. The number of old passwords stored is configurable in {project_name}." +msgstr "" + +msgid "Password blacklist" +msgstr "" + +msgid "Password must not be in a blacklist file." +msgstr "" + +msgid "Blacklist files are UTF-8 plain-text files with Unix line endings. Every line represents a blacklisted password." +msgstr "" + +msgid "{project_name} compares passwords in a case-insensitive manner. All passwords in the blacklist must be lowercase." +msgstr "" + +msgid "The value of the blacklist file must be the name of the blacklist file, for example, `100k_passwords.txt`." +msgstr "" + +msgid "Blacklist files resolve against `+${kc.home.dir}/data/password-blacklists/+` by default. Customize this path using:" +msgstr "" + +msgid "The `keycloak.password.blacklists.path` system property." +msgstr "" + +msgid "The `blacklistsPath` property of the `passwordBlacklist` policy SPI configuration. To configure the blacklist folder using the CLI, use `--spi-password-policy-password-blacklist-blacklists-path=/path/to/blacklistsFolder`." +msgstr "" + +msgid "A note about False Positives" +msgstr "" + +msgid "The current implementation uses a BloomFilter for fast and memory efficient containment checks, such as whether a given password is contained in a blacklist, with the possibility for false positives." +msgstr "" + +msgid "By default a false positive probability of `0.01%` is used." +msgstr "" + +msgid "To change the false positive probability by CLI configuration, use `--spi-password-policy-password-blacklist-false-positive-probability=0.00001`." +msgstr "" + +msgid "Maximum Authentication Age" +msgstr "" + +msgid "Specifies the maximum age of a user authentication in seconds with which the user can update a password without re-authentication. A value of `0` indicates that the user has to always re-authenticate with their current password before they can update the password." +msgstr "" + +msgid "One Time Password (OTP) policies" +msgstr "" + +msgid "{project_name} has several policies for setting up a FreeOTP or Google Authenticator One-Time Password generator." +msgstr "" + +msgid "Click the *Policy* tab." +msgstr "" + +msgid "Click the *OTP Policy* tab." +msgstr "" + +msgid "Otp Policy" +msgstr "" + +msgid "image:images/otp-policy.png[OTP Policy]" +msgstr "" + +msgid "{project_name} generates a QR code on the OTP set-up page, based on information configured in the *OTP Policy* tab. FreeOTP and Google Authenticator scan the QR code when configuring OTP." +msgstr "" + +msgid "Time-based or counter-based one time passwords" +msgstr "" + +msgid "The algorithms available in {project_name} for your OTP generators are time-based and counter-based." +msgstr "" + +msgid "With Time-Based One Time Passwords (TOTP), the token generator will hash the current time and a shared secret. The server validates the OTP by comparing the hashes within a window of time to the submitted value. TOTPs are valid for a short window of time." +msgstr "" + +msgid "With Counter-Based One Time Passwords (HOTP), {project_name} uses a shared counter rather than the current time. The {project_name} server increments the counter with each successful OTP login. Valid OTPs change after a successful login." +msgstr "" + +msgid "TOTP is more secure than HOTP because the matchable OTP is valid for a short window of time, while the OTP for HOTP is valid for an indeterminate amount of time. HOTP is more user-friendly than TOTP because no time limit exists to enter the OTP." +msgstr "" + +msgid "HOTP requires a database update every time the server increments the counter. This update is a performance drain on the authentication server during heavy load. To increase efficiency, TOTP does not remember passwords used, so there is no need to perform database updates. The drawback is that it is possible to re-use TOTPs in the valid time interval." +msgstr "" + +msgid "TOTP configuration options" +msgstr "" + +msgid "OTP hash algorithm" +msgstr "" + +msgid "The default algorithm is SHA1. The other, more secure options are SHA256 and SHA512." +msgstr "" + +msgid "Number of digits" +msgstr "" + +msgid "The length of the OTP. Short OTP's are user-friendly, easier to type, and easier to remember. Longer OTP's are more secure than shorter OTP's." +msgstr "" + +msgid "Look around window" +msgstr "" + +msgid "The number of intervals the server attempts to match the hash. This option is present in {project_name} if the clock of the TOTP generator or authentication server becomes out-of-sync. The default value of 1 is adequate. For example, if the time interval for a token is 30 seconds, the default value of 1 means it will accept valid tokens in the 90-second window (time interval 30 seconds + look ahead 30 seconds + look behind 30 seconds). Every increment of this value increases the valid window by 60 seconds (look ahead 30 seconds + look behind 30 seconds)." +msgstr "" + +msgid "OTP token period" +msgstr "" + +msgid "The time interval in seconds the server matches a hash. Each time the interval passes, the token generator generates a TOTP." +msgstr "" + +msgid "Reusable code" +msgstr "" + +msgid "Determine whether OTP tokens can be reused in the authentication process or user needs to wait for the next token. Users cannot reuse those tokens by default, and the administrator needs to explicitly specify that those tokens can be reused." +msgstr "" + +msgid "HOTP configuration options" +msgstr "" + +msgid "The length of the OTP. Short OTPs are user-friendly, easier to type, and easier to remember. Longer OTPs are more secure than shorter OTPs." +msgstr "" + +msgid "The number of previous and following intervals the server attempts to match the hash. This option is present in {project_name} if the clock of the TOTP generator or authentication server become out-of-sync. The default value of 1 is adequate. This option is present in {project_name} to cover when the user's counter gets ahead of the server." +msgstr "" + +msgid "Initial counter" +msgstr "" + +msgid "The value of the initial counter." +msgstr "" + +msgid "Authentication flows" +msgstr "" + +msgid "An _authentication flow_ is a container of authentications, screens, and actions, during log in, registration, and other {project_name} workflows." +msgstr "" + +msgid "Built-in flows" +msgstr "" + +msgid "{project_name} has several built-in flows. You cannot modify these flows, but you can alter the flow's requirements to suit your needs." +msgstr "" + +msgid "Click on the _Browser_ item in the list to see the details." +msgstr "" + +msgid "Browser flow" +msgstr "" + +msgid "image:images/browser-flow.png[Browser Flow]" +msgstr "" + +msgid "Auth type" +msgstr "" + +msgid "The name of the authentication or the action to execute. If an authentication is indented, it is in a sub-flow. It may or may not be executed, depending on the behavior of its parent." +msgstr "" + +msgid "Cookie" +msgstr "" + +msgid "The first time a user logs in successfully, {project_name} sets a session cookie. If the cookie is already set, this authentication type is successful. Since the cookie provider returned success and each execution at this level of the flow is _alternative_, {project_name} does not perform any other execution. This results in a successful login." +msgstr "" + +msgid "Kerberos" +msgstr "" + +msgid "This authenticator is disabled by default and is skipped during the Browser Flow." +msgstr "" + +msgid "Identity Provider Redirector" +msgstr "" + +msgid "This action is configured through the *Actions* > *Config* link. It redirects to another IdP for <<_identity_broker, identity brokering>>." +msgstr "" + +msgid "Forms" +msgstr "" + +msgid "Since this sub-flow is marked as _alternative_, it will not be executed if the *Cookie* authentication type passed. This sub-flow contains an additional authentication type that needs to be executed. {project_name} loads the executions for this sub-flow and processes them." +msgstr "" + +msgid "The first execution is the *Username Password Form*, an authentication type that renders the username and password page. It is marked as _required_, so the user must enter a valid username and password." +msgstr "" + +msgid "The second execution is the *Browser - Conditional OTP* sub-flow. This sub-flow is _conditional_ and executes depending on the result of the *Condition - User Configured* execution. If the result is true, {project_name} loads the executions for this sub-flow and processes them." +msgstr "" + +msgid "The next execution is the *Condition - User Configured* authentication. This authentication checks if {project_name} has configured other executions in the flow for the user. The *Browser - Conditional OTP* sub-flow executes only when the user has a configured OTP credential." +msgstr "" + +msgid "The final execution is the *OTP Form*. {project_name} marks this execution as _required_ but it runs only when the user has an OTP credential set up because of the setup in the _conditional_ sub-flow. If not, the user does not see an OTP form." +msgstr "" + +msgid "Requirement" +msgstr "" + +msgid "A set of radio buttons that control the execution of an action executes." +msgstr "" + +msgid "All _Required_ elements in the flow must be successfully sequentially executed. The flow terminates if a required element fails." +msgstr "" + +msgid "Alternative" +msgstr "" + +msgid "Only a single element must successfully execute for the flow to evaluate as successful. Because the _Required_ flow elements are sufficient to mark a flow as successful, any _Alternative_ flow element within a flow containing _Required_ flow elements will not execute." +msgstr "" + +msgid "Disabled" +msgstr "" + +msgid "The element does not count to mark a flow as successful." +msgstr "" + +msgid "Conditional" +msgstr "" + +msgid "This requirement type is only set on sub-flows." +msgstr "" + +msgid "A _Conditional_ sub-flow contains executions. These executions must evaluate to logical statements." +msgstr "" + +msgid "If all executions evaluate as _true_, the _Conditional_ sub-flow acts as _Required_." +msgstr "" + +msgid "If any executions evaluate as _false_, the _Conditional_ sub-flow acts as _Disabled_." +msgstr "" + +msgid "If you do not set an execution, the _Conditional_ sub-flow acts as _Disabled_." +msgstr "" + +msgid "If a flow contains executions and the flow is not set to _Conditional_, {project_name} does not evaluate the executions, and the executions are considered functionally _Disabled_." +msgstr "" + +msgid "Creating flows" +msgstr "" + +msgid "Important functionality and security considerations apply when you design a flow." +msgstr "" + +msgid "To create a flow, perform the following:" +msgstr "" + +msgid "Click *Create flow*." +msgstr "" + +msgid "You can copy and then modify an existing flow. Click the \"Action list\" (the three dots at the end of the row), click *Duplicate*, and enter a name for the new flow." +msgstr "" + +msgid "When creating a new flow, you must create a top-level flow first with the following options:" +msgstr "" + +msgid "The name of the flow." +msgstr "" + +msgid "The description you can set to the flow." +msgstr "" + +msgid "Top-Level Flow Type" +msgstr "" + +msgid "The type of flow. The type *client* is used only for the authentication of clients (applications). For all other cases, choose *basic*." +msgstr "" + +msgid "Create a top-level flow" +msgstr "" + +msgid "image:images/Create-top-level-flow.png[Top Level Flow]" +msgstr "" + +msgid "When {project_name} has created the flow, {project_name} displays the *Add step*, and *Add sub-flow* buttons." +msgstr "" + +msgid "An empty new flow" +msgstr "" + +msgid "image:images/New-flow.png[New Flow]" +msgstr "" + +msgid "Three factors determine the behavior of flows and sub-flows." +msgstr "" + +msgid "The structure of the flow and sub-flows." +msgstr "" + +msgid "The executions within the flows" +msgstr "" + +msgid "The requirements set within the sub-flows and the executions." +msgstr "" + +msgid "Executions have a wide variety of actions, from sending a reset email to validating an OTP. Add executions with the *Add step* button." +msgstr "" + +msgid "Adding an authentication execution" +msgstr "" + +msgid "image:images/Create-authentication-execution.png[Adding an Authentication Execution]" +msgstr "" + +msgid "Two types of executions exist, _automatic executions_ and _interactive executions_. _Automatic executions_ are similar to the *Cookie* execution and will automatically perform their action in the flow. _Interactive executions_ halt the flow to get input. Executions executing successfully set their status to _success_. For a flow to complete, it needs at least one execution with a status of _success_." +msgstr "" + +msgid "You can add sub-flows to top-level flows with the *Add sub-flow* button. The *Add sub-flow* button displays the *Create Execution Flow* page. This page is similar to the *Create Top Level Form* page. The difference is that the *Flow Type* can be *basic* (default) or *form*. The *form* type constructs a sub-flow that generates a form for the user, similar to the built-in *Registration* flow. Sub-flows success depends on how their executions evaluate, including their contained sub-flows. See the <<_execution-requirements, execution requirements section>> for an in-depth explanation of how sub-flows work." +msgstr "" + +msgid "After adding an execution, check the requirement has the correct value." +msgstr "" + +msgid "All elements in a flow have a *Delete* option next to the element. Some executions have a *⚙️* menu item (the gear icon) to configure the execution. It is also possible to add executions and sub-flows to sub-flows with the *Add step* and *Add sub-flow* links." +msgstr "" + +msgid "Since the order of execution is important, you can move executions and sub-flows up and down by dragging their names." +msgstr "" + +msgid "Make sure to properly test your configuration when you configure the authentication flow to confirm that no security holes exist in your setup. We recommend that you test various corner cases. For example, consider testing the authentication behavior for a user when you remove various credentials from the user's account before authentication." +msgstr "" + +msgid "As an example, when 2nd-factor authenticators, such as OTP Form or WebAuthn Authenticator, are configured in the flow as REQUIRED and the user does not have credential of particular type, the user will be able to set up the particular credential during authentication itself. This situation means that the user does not authenticate with this credential as he set up it right during the authentication. So for browser authentication, make sure to configure your authentication flow with some 1st-factor credentials such as Password or WebAuthn Passwordless Authenticator." +msgstr "" + +msgid "Creating a password-less browser login flow" +msgstr "" + +msgid "To illustrate the creation of flows, this section describes creating an advanced browser login flow. The purpose of this flow is to allow a user a choice between logging in using a password-less manner with xref:webauthn_{context}[WebAuthn], or two-factor authentication with a password and OTP." +msgstr "" + +msgid "Enter `Browser Password-less` as a name." +msgstr "" + +msgid "Click *Add execution*." +msgstr "" + +msgid "Select *Cookie* from the list." +msgstr "" + +msgid "Click *Add*." +msgstr "" + +msgid "Select *Alternative* for the *Cookie* authentication type to set its requirement to alternative." +msgstr "" + +msgid "Click *Add step*." +msgstr "" + +msgid "Select *Kerberos* from the list." +msgstr "" + +msgid "Select *Identity Provider Redirector* from the list." +msgstr "" + +msgid "Select *Alternative* for the *Identity Provider Redirector* authentication type to set its requirement to alternative." +msgstr "" + +msgid "Click *Add sub-flow*." +msgstr "" + +msgid "Enter *Forms* as a name." +msgstr "" + +msgid "Select *Alternative* for the *Forms* authentication type to set its requirement to alternative." +msgstr "" + +msgid "The common part with the browser flow" +msgstr "" + +msgid "image:images/Passwordless-browser-login-common.png[Passwordless browser login]" +msgstr "" + +msgid "Click *+* menu of the *Forms* execution." +msgstr "" + +msgid "Select *Add step*." +msgstr "" + +msgid "Select *Username Form* from the list." +msgstr "" + +msgid "At this stage, the form requires a username but no password. We must enable password authentication to avoid security risks." +msgstr "" + +msgid "Click *+* menu of the *Forms* sub-flow." +msgstr "" + +msgid "Enter `Authentication` as name." +msgstr "" + +msgid "Select *Required* for the *Authentication* authentication type to set its requirement to required." +msgstr "" + +msgid "Click *+* menu of the *Authentication* sub-flow." +msgstr "" + +msgid "Select *WebAuthn Passwordless Authenticator* from the list." +msgstr "" + +msgid "Select *Alternative* for the *Webauthn Passwordless Authenticator* authentication type to set its requirement to alternative." +msgstr "" + +msgid "Enter `Password with OTP` as name." +msgstr "" + +msgid "Select *Alternative* for the *Password with OTP* authentication type to set its requirement to alternative." +msgstr "" + +msgid "Click *+* menu of the *Password with OTP* sub-flow." +msgstr "" + +msgid "Select *Password Form* from the list." +msgstr "" + +msgid "Select *Required* for the *Password Form* authentication type to set its requirement to required." +msgstr "" + +msgid "Select *OTP Form* from the list." +msgstr "" + +msgid "Click *Required* for the *OTP Form* authentication type to set its requirement to required." +msgstr "" + +msgid "Finally, change the bindings." +msgstr "" + +msgid "Click the *Action* menu at the top of the screen." +msgstr "" + +msgid "Select *Bind flow* from the menu." +msgstr "" + +msgid "Click the *Browser Flow* drop-down list." +msgstr "" + +msgid "A password-less browser login" +msgstr "" + +msgid "image:images/Passwordless-browser-login.png[Passwordless browser login]" +msgstr "" + +msgid "After entering the username, the flow works as follows:" +msgstr "" + +msgid "If users have WebAuthn passwordless credentials recorded, they can use these credentials to log in directly. This is the password-less login. The user can also select *Password with OTP* because the `WebAuthn Passwordless` execution and the `Password with OTP` flow are set to *Alternative*. If they are set to *Required*, the user has to enter WebAuthn, password, and OTP." +msgstr "" + +msgid "If the user selects the *Try another way* link with `WebAuthn passwordless` authentication, the user can choose between `Password` and `Security Key` (WebAuthn passwordless). When selecting the password, the user will need to continue and log in with the assigned OTP. If the user has no WebAuthn credentials, the user must enter the password and then the OTP. If the user has no OTP credential, they will be asked to record one." +msgstr "" + +msgid "Since the WebAuthn Passwordless execution is set to *Alternative* rather than *Required*, this flow will never ask the user to register a WebAuthn credential. For a user to have a Webauthn credential, an administrator must add a required action to the user. Do this by:" +msgstr "" + +msgid "Enabling the *Webauthn Register Passwordless* required action in the realm (see the xref:webauthn_{context}[WebAuthn] documentation)." +msgstr "" + +msgid "Setting the required action using the *Credential Reset* part of a user's xref:ref-user-credentials_{context}[Credentials] management menu." +msgstr "" + +msgid "Creating an advanced flow such as this can have side effects. For example, if you enable the ability to reset the password for users, this would be accessible from the password form. In the default `Reset Credentials` flow, users must enter their username. Since the user has already entered a username earlier in the `Browser Password-less` flow, this action is unnecessary for {project_name} and suboptimal for user experience. To correct this problem, you can:" +msgstr "" + +msgid "Duplicate the `Reset Credentials` flow. Set its name to `Reset Credentials for password-less`, for example." +msgstr "" + +msgid "Click *Delete* (trash icon) of the *Choose user* step." +msgstr "" + +msgid "In the *Action* menu, select *Bind flow* and select *Reset credentials flow* from the dropdown and click *Save*" +msgstr "" + +msgid "Creating a browser login flow with step-up mechanism" +msgstr "" + +msgid "This section describes how to create advanced browser login flow using the step-up mechanism. The purpose of step-up authentication is to allow access to clients or resources based on a specific authentication level of a user." +msgstr "" + +msgid "Enter `Browser Incl Step up Mechanism` as a name." +msgstr "" + +msgid "Enter *Auth Flow* as a name." +msgstr "" + +msgid "Click *Alternative* for the *Auth Flow* authentication type to set its requirement to alternative." +msgstr "" + +msgid "Now you configure the flow for the first authentication level." +msgstr "" + +msgid "Click *+* menu of the *Auth Flow*." +msgstr "" + +msgid "Enter `1st Condition Flow` as a name." +msgstr "" + +msgid "Click *Conditional* for the *1st Condition Flow* authentication type to set its requirement to conditional." +msgstr "" + +msgid "Click *+* menu of the *1st Condition Flow*." +msgstr "" + +msgid "Click *Add condition*." +msgstr "" + +msgid "Select *Conditional - Level Of Authentication* from the list." +msgstr "" + +msgid "Click *Required* for the *Conditional - Level Of Authentication* authentication type to set its requirement to required." +msgstr "" + +msgid "Click *⚙️* (gear icon)." +msgstr "" + +msgid "Enter `Level 1` as an alias." +msgstr "" + +msgid "Enter `1` for the Level of Authentication (LoA)." +msgstr "" + +msgid "Set Max Age to *36000*. This value is in seconds and it is equivalent to 10 hours, which is the default `SSO Session Max` timeout set in the realm. As a result, when a user authenticates with this level, subsequent SSO logins can re-use this level and the user does not need to authenticate with this level until the end of the user session, which is 10 hours by default." +msgstr "" + +msgid "Click *Save*" +msgstr "" + +msgid "Configure the condition for the first authentication level" +msgstr "" + +msgid "image:images/authentication-step-up-condition-1.png[Authentication step up condition 1]" +msgstr "" + +msgid "Select *Username Password Form* from the list." +msgstr "" + +msgid "Now you configure the flow for the second authentication level." +msgstr "" + +msgid "Enter `2nd Condition Flow` as an alias." +msgstr "" + +msgid "Click *Conditional* for the *2nd Condition Flow* authentication type to set its requirement to conditional." +msgstr "" + +msgid "Click *+* menu of the *2nd Condition Flow*." +msgstr "" + +msgid "Select *Conditional - Level Of Authentication* from the item list." +msgstr "" + +msgid "Enter `Level 2` as an alias." +msgstr "" + +msgid "Enter `2` for the Level of Authentication (LoA)." +msgstr "" + +msgid "Set Max Age to *0*. As a result, when a user authenticates, this level is valid just for the current authentication, but not any subsequent SSO authentications. So the user will always need to authenticate again with this level when this level is requested." +msgstr "" + +msgid "Configure the condition for the second authentication level" +msgstr "" + +msgid "image:images/authentication-step-up-condition-2.png[Autehtnication step up condition 2]" +msgstr "" + +msgid "Select *Bind flow* from the list." +msgstr "" + +msgid "Select *Browser Flow* in the dropdown." +msgstr "" + +msgid "Browser login with step-up mechanism" +msgstr "" + +msgid "image:images/authentication-step-up-flow.png[Authentication step up flow]" +msgstr "" + +msgid "Request a certain authentication level" +msgstr "" + +msgid "To use the step-up mechanism, you specify a requested level of authentication (LoA) in your authentication request. The `claims` parameter is used for this purpose:" +msgstr "" + +msgid "https://{DOMAIN}{kc_realms_path}/{REALMNAME}/protocol/openid-connect/auth?client_id={CLIENT-ID}&redirect_uri={REDIRECT-URI}&scope=openid&response_type=code&response_mode=query&nonce=exg16fxdjcu&claims=%7B%22id_token%22%3A%7B%22acr%22%3A%7B%22essential%22%3Atrue%2C%22values%22%3A%5B%22gold%22%5D%7D%7D%7D" +msgstr "" + +msgid "The `claims` parameter is specified in a JSON representation:" +msgstr "" + +msgid "" +"claims= {\n" +" \"id_token\": {\n" +" \"acr\": {\n" +" \"essential\": true,\n" +" \"values\": [\"gold\"]\n" +" }\n" +" }\n" +" }" +msgstr "" + +msgid "The {project_name} javascript adapter has support for easy construct of this JSON and sending it in the login request. See link:{adapterguide_link_js_adapter}[Javascript adapter documentation] for more details." +msgstr "" + +msgid "You can also use simpler parameter `acr_values` instead of `claims` parameter to request particular levels as non-essential. This is mentioned in the OIDC specification." +msgstr "" + +msgid "You can also configure the default level for the particular client, which is used when the parameter `acr_values` or the parameter `claims` with the `acr` claim is not present. For further details, see <<_mapping-acr-to-loa-client,Client ACR configuration>>)." +msgstr "" + +msgid "To request the acr_values as text (such as `gold`) instead of a numeric value, you configure the mapping between the ACR and the LoA. It is possible to configure it at the realm level (recommended) or at the client level. For configuration see <<_mapping-acr-to-loa-realm,ACR to LoA Mapping>>." +msgstr "" + +msgid "For more details see the https://openid.net/specs/openid-connect-core-1_0.html#acrSemantics[official OIDC specification]." +msgstr "" + +msgid "*Flow logic*" +msgstr "" + +msgid "" +"The logic for the previous configured authentication flow is as follows: +\n" +"If a client request a high authentication level, meaning Level of Authentication 2 (LoA 2), a user has to perform full 2-factor authentication: Username/Password + OTP. However, if a user already has a session in Keycloak, that was logged in with username and password (LoA 1), the user is only asked for the second authentication factor (OTP)." +msgstr "" + +msgid "The option *Max Age* in the condition determines how long (how much seconds) the subsequent authentication level is valid. This setting helps to decide whether the user will be asked to present the authentication factor again during a subsequent authentication. If the particular level X is requested by the `claims` or `acr_values` parameter and user already authenticated with level X, but it is expired (for example max age is configured to 300 and user authenticated before 310 seconds) then the user will be asked to re-authenticate again with the particular level. However if the level is not yet expired, the user will be automatically considered as authenticated with that level." +msgstr "" + +msgid "Using *Max Age* with the value 0 means, that particular level is valid just for this single authentication. Hence every re-authentication requesting that level will need to authenticate again with that level. This is useful for operations that require higher security in the application (e.g. send payment) and always require authentication with the specific level." +msgstr "" + +msgid "Note that parameters such as `claims` or `acr_values` might be changed by the user in the URL when the login request is sent from the client to the {project_name} via the user's browser. This situation can be mitigated if client uses PAR (Pushed authorization request), a request object, or other mechanisms that prevents the user from rewrite the parameters in the URL. Hence after the authentication, clients are encouraged to check the ID Token to double-check that `acr` in the token corresponds to the expected level." +msgstr "" + +msgid "If no explicit level is requested by parameters, the {project_name} will require the authentication with the first LoA condition found in the authentication flow, such as the Username/Password in the preceding example. When a user was already authenticated with that level and that level expired, the user is not required to re-authenticate, but `acr` in the token will have the value 0. This result is considered as authentication based solely on `long-lived browser cookie` as mentioned in the section 2 of OIDC Core 1.0 specification." +msgstr "" + +msgid "A conflict situation may arise when an admin specifies several flows, sets different LoA levels to each, and assigns the flows to different clients. However, the rule is always the same: if a user has a certain level, it needs only have that level to connect to a client. It's up to the admin to make sure that the LoA is coherent." +msgstr "" + +msgid "*Example scenario*" +msgstr "" + +msgid "Max Age is configured as 300 seconds for level 1 condition." +msgstr "" + +msgid "Login request is sent without requesting any acr. Level 1 will be used and the user needs to authenticate with username and password. The token will have `acr=1`." +msgstr "" + +msgid "Another login request is sent after 100 seconds. The user is automatically authenticated due to the SSO and the token will return `acr=1`." +msgstr "" + +msgid "Another login request is sent after another 201 seconds (301 seconds since authentication in point 2). The user is automatically authenticated due to the SSO, but the token will return `acr=0` due the level 1 is considered expired." +msgstr "" + +msgid "Another login request is sent, but now it will explicitly request ACR of level 1 in the `claims` parameter. User will be asked to re-authenticate with username/password and then `acr=1` will be returned in the token." +msgstr "" + +msgid "*ACR claim in the token*" +msgstr "" + +msgid "ACR claim is added to the token by the `acr loa level` protocol mapper defined in the `acr` client scope. This client scope is the realm default client scope and hence will be added to all newly created clients in the realm." +msgstr "" + +msgid "In case you do not want `acr` claim inside tokens or you need some custom logic for adding it, you can remove the client scope from your client." +msgstr "" + +msgid "Note when the login request initiates a request with the `claims` parameter requesting `acr` as `essential` claim, then {project_name} will always return one of the specified levels. If it is not able to return one of the specified levels (For example if the requested level is unknown or bigger than configured conditions in the authentication flow), then {project_name} will throw an error." +msgstr "" + +msgid "User session limits" +msgstr "" + +msgid "Limits on the number of session that a user can have can be configured. Sessions can be limited per realm or per client." +msgstr "" + +msgid "To add session limits to a flow, perform the following steps." +msgstr "" + +msgid "Click *Add step* for the flow." +msgstr "" + +msgid "Select *User session count limiter* from the item list." +msgstr "" + +msgid "Click *Required* for the *User Session Count Limiter* authentication type to set its requirement to required." +msgstr "" + +msgid "Click *⚙️* (gear icon) for the *User Session Count Limiter*." +msgstr "" + +msgid "Enter an alias for this config." +msgstr "" + +msgid "Enter the required maximum number of sessions that a user can have in this realm. For example, if 2 is the value, 2 SSO sessions is the maximum that each user can have in this realm. If 0 is the value, this check is disabled." +msgstr "" + +msgid "Enter the required maximum number of sessions a user can have for the client. For example, if 2 is the value, then 2 SSO sessions is the maximum in this realm for each client. So when a user is trying to authenticate to client `foo`, but that user has already authenticated in 2 SSO sessions to client `foo`, either the authentication will be denied or an existing sessions will be killed based on the behavior configured. If a value of 0 is used, this check is disabled. If both session limits and client session limits are enabled, it makes sense to have client session limits to be always lower than session limits. The limit per client can never exceed the limit of all SSO sessions of this user." +msgstr "" + +msgid "Select the behavior that is required when the user tries to create a session after the limit is reached. Available behaviors are:" +msgstr "" + +msgid "*Deny new session* - when a new session is requested and the session limit is reached, no new sessions can be created." +msgstr "" + +msgid "*Terminate oldest session* - when a new session is requested and the session limit has been reached, the oldest session will be removed and the new session created." +msgstr "" + +msgid "Optionally, add a custom error message to be displayed when the limit is reached." +msgstr "" + +msgid "Note that the user session limits should be added to your bound *Browser flow*, *Direct grant flow*, *Reset credentials* and also to any *Post broker login flow*. The authenticator should be added at the point when the user is already known during authentication (usually at the end of the authentication flow) and should be typically REQUIRED. Note that it is not possible to have ALTERNATIVE and REQUIRED executions at the same level." +msgstr "" + +msgid "For most of authenticators like `Direct grant flow`, `Reset credentials` or `Post broker login flow`, it is recommended to add the authenticator as REQUIRED at the end of the authentication flow. Here is an example for the `Reset credentials` flow:" +msgstr "" + +msgid "image:images/authentication-user-session-limits-resetcred.png[Authentication User Session Limits Reset Credentials Flow]" +msgstr "" + +msgid "For `Browser` flow, consider not adding the Session Limits authenticator at the top level flow. This recommendation is due to the `Cookie` authenticator, which automatically re-authenticates users based on SSO cookie. It is at the top level and it is better to not check session limits during SSO re-authentication because a user session already exists. So instead, consider adding a separate ALTERNATIVE subflow, such as the following `authenticate-user-with-session-limit` example at the same level like `Cookie`. Then you can add a REQUIRED subflow, in the following `real-authentication-subflow`example, as a nested subflow of `authenticate-user-with-session-limit` and add a `User Session Limit` at the same level as well. Inside the `real-authentication-subflow`, you can add real authenticators in a similar fashion to the default browser flow. The following example flow allows to users to authenticate with an identity provider or with password and OTP:" +msgstr "" + +msgid "image:images/authentication-user-session-limits-browser.png[Authentication User Session Limits Browser Flow]" +msgstr "" + +msgid "Regarding `Post Broker login flow`, you can add the `User Session Limits` as the only authenticator in the authentication flow as long as you have no other authenticators that you trigger after authentication with your identity provider. However, make sure that this flow is configured as `Post Broker Flow` at your identity providers. This requirement exists needed so that the authentication with Identity providers also participates in the session limits." +msgstr "" + +msgid "Currently, the administrator is responsible for maintaining consistency between the different configurations. So make sure that all your flows use same the configuration of `User Session Limits`." +msgstr "" + +msgid "User session limit feature is not available for CIBA." +msgstr "" + +msgid "Script Authenticator" +msgstr "" + +msgid "Ability to upload scripts through the Admin Console and REST endpoints is deprecated." +msgstr "" + +msgid "For more details see link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}]." +msgstr "" + +msgid "{project_name} supports login with a Kerberos ticket through the Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) protocol. SPNEGO authenticates transparently through the web browser after the user authenticates the session. For non-web cases, or when a ticket is not available during login, {project_name} supports login with Kerberos username and password." +msgstr "" + +msgid "A typical use case for web authentication is the following:" +msgstr "" + +msgid "The user logs into the desktop." +msgstr "" + +msgid "The user accesses a web application secured by {project_name} using a browser." +msgstr "" + +msgid "The application redirects to {project_name} login." +msgstr "" + +msgid "{project_name} renders the HTML login screen with status 401 and HTTP header `WWW-Authenticate: Negotiate`" +msgstr "" + +msgid "If the browser has a Kerberos ticket from desktop login, the browser transfers the desktop sign-on information to {project_name} in header `Authorization: Negotiate 'spnego-token'`. Otherwise, it displays the standard login screen, and the user enters the login credentials." +msgstr "" + +msgid "{project_name} validates the token from the browser and authenticates the user." +msgstr "" + +msgid "If using LDAPFederationProvider with Kerberos authentication support, {project_name} provisions user data from LDAP. If using KerberosFederationProvider, {project_name} lets the user update the profile and pre-fill login data." +msgstr "" + +msgid "{project_name} returns to the application. {project_name} and the application communicate through OpenID Connect or SAML messages. {project_name} acts as a broker to Kerberos/SPNEGO login. Therefore {project_name} authenticating through Kerberos is hidden from the application." +msgstr "" + +msgid "The https://www.ietf.org/rfc/rfc4559.txt[Negotiate] www-authenticate scheme allows NTLM as a fallback to Kerberos and on some web browsers in Windows NTLM is supported by default. If a www-authenticate challenge comes from a server outside a browsers permitted list, users may encounter an NTLM dialog prompt. A user would need to click the cancel button on the dialog to continue as Keycloak does not support this mechanism. This situation can happen if Intranet web browsers are not strictly configured or if Keycloak serves users in both the Intranet and Internet. A https://github.com/keycloak/keycloak/issues/8989[custom authenticator] can be used to restrict Negotiate challenges to a whitelist of hosts." +msgstr "" + +msgid "Perform the following steps to set up Kerberos authentication:" +msgstr "" + +msgid "The setup and configuration of the Kerberos server (KDC)." +msgstr "" + +msgid "The setup and configuration of the {project_name} server." +msgstr "" + +msgid "The setup and configuration of the client machines." +msgstr "" + +msgid "Setup of Kerberos server" +msgstr "" + +msgid "The steps to set up a Kerberos server depends on the operating system (OS) and the Kerberos vendor. Consult Windows Active Directory, MIT Kerberos, and your OS documentation for instructions on setting up and configuring a Kerberos server." +msgstr "" + +msgid "During setup, perform these steps:" +msgstr "" + +msgid "Add some user principals to your Kerberos database. You can also integrate your Kerberos with LDAP, so user accounts provision from the LDAP server." +msgstr "" + +msgid "Add service principal for \"HTTP\" service. For example, if the {project_name} server runs on `www.mydomain.org`, add the service principal `HTTP/www.mydomain.org@`." +msgstr "" + +msgid "On MIT Kerberos, you run a \"kadmin\" session. On a machine with MIT Kerberos, you can use the command:" +msgstr "" + +msgid "sudo kadmin.local" +msgstr "" + +msgid "Then, add HTTP principal and export its key to a keytab file with commands such as:" +msgstr "" + +msgid "" +"addprinc -randkey HTTP/www.mydomain.org@MYDOMAIN.ORG\n" +"ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG" +msgstr "" + +msgid "Ensure the keytab file `/tmp/http.keytab` is accessible on the host where {project_name} is running." +msgstr "" + +msgid "Setup and configuration of {project_name} server" +msgstr "" + +msgid "Install a Kerberos client on your machine." +msgstr "" + +msgid "Install a Kerberos client. If your machine runs Fedora, Ubuntu, or RHEL, install the link:https://www.freeipa.org/page/Downloads[freeipa-client] package, containing a Kerberos client and other utilities." +msgstr "" + +msgid "Configure the Kerberos client (on Linux, the configuration settings are in the link:https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html[/etc/krb5.conf] file )." +msgstr "" + +msgid "Add your Kerberos realm to the configuration and configure the HTTP domains your server runs on." +msgstr "" + +msgid "For example, for the MYDOMAIN.ORG realm, you can configure the `domain_realm` section like this:" +msgstr "" + +msgid "" +"[domain_realm]\n" +" .mydomain.org = MYDOMAIN.ORG\n" +" mydomain.org = MYDOMAIN.ORG" +msgstr "" + +msgid "Export the keytab file with the HTTP principal and ensure the file is accessible to the process running the {project_name} server. For production, ensure that the file is readable by this process only." +msgstr "" + +msgid "For the MIT Kerberos example above, we exported keytab to the `/tmp/http.keytab` file. If your _Key Distribution Centre (KDC)_ and {project_name} run on the same host, the file is already available." +msgstr "" + +msgid "Enabling SPNEGO processing" +msgstr "" + +msgid "By default, {project_name} disables SPNEGO protocol support. To enable it, go to the <<_authentication-flows, browser flow>> and enable *Kerberos*." +msgstr "" + +msgid "Set the *Kerberos* requirement from _disabled_ to _alternative_ (Kerberos is optional) or _required_ (browser must have Kerberos enabled). If you have not configured the browser to work with SPNEGO or Kerberos, {project_name} falls back to the regular login screen." +msgstr "" + +msgid "Configure Kerberos user storage federation providers" +msgstr "" + +msgid "You must now use <<_user-storage-federation,User Storage Federation>> to configure how {project_name} interprets Kerberos tickets. Two different federation providers exist with Kerberos authentication support." +msgstr "" + +msgid "To authenticate with Kerberos backed by an LDAP server, configure the <<_ldap, LDAP Federation Provider>>." +msgstr "" + +msgid "Go to the configuration page for your LDAP provider." +msgstr "" + +msgid "Ldap kerberos integration" +msgstr "" + +msgid "image:images/ldap-kerberos.png[LDAP Kerberos Integration]" +msgstr "" + +msgid "Toggle *Allow Kerberos authentication* to *ON*" +msgstr "" + +msgid "*Allow Kerberos authentication* makes {project_name} use the Kerberos principal access user information so information can import into the {project_name} environment." +msgstr "" + +msgid "If an LDAP server is not backing up your Kerberos solution, use the *Kerberos* User Storage Federation Provider." +msgstr "" + +msgid "Select *Kerberos* from the *Add provider* select box." +msgstr "" + +msgid "Kerberos user storage provider" +msgstr "" + +msgid "image:images/kerberos-provider.png[Kerberos User Storage Provider]" +msgstr "" + +msgid "The *Kerberos* provider parses the Kerberos ticket for simple principal information and imports the information into the local {project_name} database. User profile information, such as first name, last name, and email, are not provisioned." +msgstr "" + +msgid "Setup and configuration of client machines" +msgstr "" + +msgid "Client machines must have a Kerberos client and set up the `krb5.conf` as described <<_server_setup, above>>. The client machines must also enable SPNEGO login support in their browser. See link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/configuring_applications_for_sso[configuring Firefox for Kerberos] if you are using the Firefox browser." +msgstr "" + +msgid "The `.mydomain.org` URI must be in the `network.negotiate-auth.trusted-uris` configuration option." +msgstr "" + +msgid "In Windows domains, clients do not need to adjust their configuration. Internet Explorer and Edge can already participate in SPNEGO authentication." +msgstr "" + +msgid "Example setups" +msgstr "" + +msgid "{Project_name} and FreeIPA docker image" +msgstr "" + +msgid "When you install https://www.docker.com/[docker], run a docker image with the FreeIPA server installed. FreeIPA provides an integrated security solution with MIT Kerberos and 389 LDAP server. The image also contains a {project_name} server configured with an LDAP Federation provider and enabled SPNEGO/Kerberos authentication against the FreeIPA server. See details https://github.com/mposolda/keycloak-freeipa-docker/blob/master/README.md[here]." +msgstr "" + +msgid "ApacheDS testing Kerberos server" +msgstr "" + +msgid "For quick testing and unit tests, use a simple https://directory.apache.org/apacheds/[ApacheDS] Kerberos server. You must build {project_name} from the source and then run the Kerberos server with the maven-exec-plugin from our test suite. See details https://github.com/keycloak/keycloak/blob/main/docs/tests.md#kerberos-server[here]." +msgstr "" + +msgid "Credential delegation" +msgstr "" + +msgid "Kerberos supports the credential delegation. Applications may need access to the Kerberos ticket so they can re-use it to interact with other services secured by Kerberos. Because the {project_name} server processed the SPNEGO protocol, you must propagate the GSS credential to your application within the OpenID Connect token claim or a SAML assertion attribute. {project_name} transmits this to your application from the {project_name} server. To insert this claim into the token or assertion, each application must enable the built-in protocol mapper `gss delegation credential`. This mapper is available in the *Mappers* tab of the application's client page. See <<_protocol-mappers, Protocol Mappers>> chapter for more details." +msgstr "" + +msgid "Applications must deserialize the claim it receives from {project_name} before using it to make GSS calls against other services. When you deserialize the credential from the access token to the GSSCredential object, create the GSSContext with this credential passed to the `GSSManager.createContext` method. For example:" +msgstr "" + +msgid "" +"// Obtain accessToken in your application.\n" +"KeycloakPrincipal keycloakPrincipal = (KeycloakPrincipal) servletReq.getUserPrincipal();\n" +"AccessToken accessToken = keycloakPrincipal.getKeycloakSecurityContext().getToken();\n" +"\n" +"// Retrieve Kerberos credential from accessToken and deserialize it\n" +"String serializedGssCredential = (String) accessToken.getOtherClaims().\n" +" get(org.keycloak.common.constants.KerberosConstants.GSS_DELEGATION_CREDENTIAL);\n" +"\n" +"GSSCredential deserializedGssCredential = org.keycloak.common.util.KerberosSerializationUtils.\n" +" deserializeCredential(serializedGssCredential);\n" +"\n" +"// Create GSSContext to call other Kerberos-secured services\n" +"GSSContext context = gssManager.createContext(serviceName, krb5Oid,\n" +" deserializedGssCredential, GSSContext.DEFAULT_LIFETIME);" +msgstr "" + +msgid "Examples of this code exist in `examples/kerberos` in the {project_name} example distribution or demo distribution download. You can also check the example sources directly https://github.com/keycloak/keycloak/tree/main/examples/kerberos[here]." +msgstr "" + +msgid "Configure `forwardable` Kerberos tickets in `krb5.conf` file and add support for delegated credentials to your browser." +msgstr "" + +msgid "Credential delegation has security implications, so use it only if necessary and only with HTTPS. See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/configuring_applications_for_sso[this article] for more details and an example." +msgstr "" + +msgid "Cross-realm trust" +msgstr "" + +msgid "In the Kerberos protocol, the `realm` is a set of Kerberos principals. The definition of these principals exists in the Kerberos database, which is typically an LDAP server." +msgstr "" + +msgid "The Kerberos protocol allows cross-realm trust. For example, if 2 Kerberos realms, A and B, exist, then cross-realm trust will allow the users from realm A to access realm B's resources. Realm B trusts realm A." +msgstr "" + +msgid "Kerberos cross-realm trust" +msgstr "" + +msgid "image:images/kerberos-trust-basic.png[]" +msgstr "" + +msgid "The {project_name} server supports cross-realm trust. To implement this, perform the following:" +msgstr "" + +msgid "Configure the Kerberos servers for the cross-realm trust. Implementing this step depends on the Kerberos server implementations. This step is necessary to add the Kerberos principal `krbtgt/B@A` to the Kerberos databases of realm A and B. This principal must have the same keys on both Kerberos realms. The principals must have the same password, key version numbers, and ciphers in both realms. Consult the Kerberos server documentation for more details." +msgstr "" + +msgid "The cross-realm trust is unidirectional by default. You must add the principal `krbtgt/A@B` to both Kerberos databases for bidirectional trust between realm A and realm B. However, trust is transitive by default. If realm B trusts realm A and realm C trusts realm B, then realm C trusts realm A without the principal, `krbtgt/C@A`, available. Additional configuration (for example, `capaths`) may be necessary on the Kerberos client-side so clients can find the trust path. Consult the Kerberos documentation for more details." +msgstr "" + +msgid "Configure {project_name} server" +msgstr "" + +msgid "When using an LDAP storage provider with Kerberos support, configure the server principal for realm B, as in this example: `HTTP/mydomain.com@B`. The LDAP server must find the users from realm A if users from realm A are to successfully authenticate to {project_name}, because {project_name} must perform the SPNEGO flow and then find the users." +msgstr "" + +msgid "Finding users is based on the LDAP storage provider option `Kerberos principal attribute`. When this is configured for instance with value like `userPrincipalName`, then after SPNEGO authentication of user `john@A`, {project_name} will try to lookup LDAP user with attribute `userPrincipalName` equivalent to `john@A`. If `Kerberos principal attribute` is left empty, then {project_name} will lookup the LDAP user based on the prefix of his kerberos principal with the realm omitted. For example, Kerberos principal user `john@A` must be available in the LDAP under username `john`, so typically under an LDAP DN such as `uid=john,ou=People,dc=example,dc=com`. If you want users from realm A and B to authenticate, ensure that LDAP can find users from both realms A and B." +msgstr "" + +msgid "When using a Kerberos user storage provider (typically, Kerberos without LDAP integration), configure the server principal as `HTTP/mydomain.com@B`, and users from Kerberos realms A and B must be able to authenticate." +msgstr "" + +msgid "Users from multiple Kerberos realms are allowed to authenticate as every user would have attribute `KERBEROS_PRINCIPAL` referring to the kerberos principal used for authentication and this is used for further lookups of this user. To avoid conflicts when there is user `john` in both kerberos realms `A` and `B`, the username of the {project_name} user might contain the kerberos realm lowercased. For instance username would be `john@a`. Just in case when realm matches with the configured `Kerberos realm`, the realm suffix might be omitted from the generated username. For instance username would be `john` for the Kerberos principal `john@A` as long as the `Kerberos realm` is configured on the Kerberos provider is `A`." +msgstr "" + +msgid "If you have issues, enable additional logging to debug the problem:" +msgstr "" + +msgid "Enable `Debug` flag in the Admin Console for Kerberos or LDAP federation providers" +msgstr "" + +msgid "Enable TRACE logging for category `org.keycloak` to receive more information in server logs" +msgstr "" + +msgid "Add system properties `-Dsun.security.krb5.debug=true` and `-Dsun.security.spnego.debug=true`" +msgstr "" + +msgid "X.509 client certificate user authentication" +msgstr "" + +msgid "{project_name} supports logging in with an X.509 client certificate if you have configured the server to use mutual SSL authentication." +msgstr "" + +msgid "A typical workflow:" +msgstr "" + +msgid "A client sends an authentication request over SSL/TLS channel." +msgstr "" + +msgid "During the SSL/TLS handshake, the server and the client exchange their x.509/v3 certificates." +msgstr "" + +msgid "The container ({appserver_name}) validates the certificate PKIX path and the certificate expiration date." +msgstr "" + +msgid "The x.509 client certificate authenticator validates the client certificate by using the following methods:" +msgstr "" + +msgid "Checks the certificate revocation status by using CRL or CRL Distribution Points." +msgstr "" + +msgid "Checks the Certificate revocation status by using OCSP (Online Certificate Status Protocol)." +msgstr "" + +msgid "Validates whether the key in the certificate matches the expected key." +msgstr "" + +msgid "Validates whether the extended key in the certificate matches the expected extended key." +msgstr "" + +msgid "If any of the these checks fail, the x.509 authentication fails. Otherwise, the authenticator extracts the certificate identity and maps it to an existing user." +msgstr "" + +msgid "When the certificate maps to an existing user, the behavior diverges depending on the authentication flow:" +msgstr "" + +msgid "In the Browser Flow, the server prompts users to confirm their identity or sign in with a username and password." +msgstr "" + +msgid "In the Direct Grant Flow, the server signs in the user." +msgstr "" + +msgid "Note that it is the responsibility of the web container to validate certificate PKIX path. X.509 authenticator on the {project_name} side provides just the additional support for check the certificate expiration, certificate revocation status and key usage. If you are using {project_name} deployed behind reverse proxy, make sure that your reverse proxy is configured to validate PKIX path. If you do not use reverse proxy and users directly access the {appserver_name}, you should be fine as {appserver_name} makes sure that PKIX path is validated as long as it is configured as described below." +msgstr "" + +msgid "Supported Certificate Identity Sources:" +msgstr "" + +msgid "Match SubjectDN by using regular expressions" +msgstr "" + +msgid "X500 Subject's email attribute" +msgstr "" + +msgid "X500 Subject's email from Subject Alternative Name Extension (RFC822Name General Name)" +msgstr "" + +msgid "X500 Subject's other name from Subject Alternative Name Extension. This other name is the User Principal Name (UPN), typically." +msgstr "" + +msgid "X500 Subject's Common Name attribute" +msgstr "" + +msgid "Match IssuerDN by using regular expressions" +msgstr "" + +msgid "Certificate Serial Number" +msgstr "" + +msgid "Certificate Serial Number and IssuerDN" +msgstr "" + +msgid "SHA-256 Certificate thumbprint" +msgstr "" + +msgid "Full certificate in PEM format" +msgstr "" + +msgid "Regular expressions" +msgstr "" + +msgid "{project_name} extracts the certificate identity from Subject DN or Issuer DN by using a regular expression as a filter. For example, this regular expression matches the email attribute:" +msgstr "" + +msgid "emailAddress=(.*?)(?:,|$)" +msgstr "" + +msgid "The regular expression filtering applies if the `Identity Source` is set to either `Match SubjectDN using regular expression` or `Match IssuerDN using regular expression`." +msgstr "" + +msgid "Mapping certificate identity to an existing user" +msgstr "" + +msgid "The certificate identity mapping can map the extracted user identity to an existing user's username, email, or a custom attribute whose value matches the certificate identity. For example, setting `Identity source` to _Subject's email_ or `User mapping method` to _Username or email_ makes the X.509 client certificate authenticator use the email attribute in the certificate's Subject DN as the search criteria when searching for an existing user by username or by email." +msgstr "" + +msgid "If you disable *Login with email* at realm settings, the same rules apply to certificate authentication. Users are unable to log in by using the email attribute." +msgstr "" + +msgid "Using `Certificate Serial Number and IssuerDN` as an identity source requires two custom attributes for the serial number and the IssuerDN." +msgstr "" + +msgid "`SHA-256 Certificate thumbprint` is the lowercase hexadecimal representation of SHA-256 certificate thumbprint." +msgstr "" + +msgid "Using `Full certificate in PEM format` as an identity source is limited to the custom attributes mapped to external federation sources, such as LDAP. {project_name} cannot store certificates in its database due to length limitations, so in the case of LDAP, you must enable `Always Read Value From LDAP`." +msgstr "" + +msgid "Extended certificate validation" +msgstr "" + +msgid "Revocation status checking using CRL." +msgstr "" + +msgid "Revocation status checking using CRL/Distribution Point." +msgstr "" + +msgid "Revocation status checking using OCSP/Responder URI." +msgstr "" + +msgid "Certificate KeyUsage validation." +msgstr "" + +msgid "Certificate ExtendedKeyUsage validation." +msgstr "" + +msgid "Adding X.509 client certificate authentication to browser flows" +msgstr "" + +msgid "Click the *Browser* flow." +msgstr "" + +msgid "From the *Action* list, select *Duplicate*." +msgstr "" + +msgid "Enter a name for the copy." +msgstr "" + +msgid "Click *Duplicate*." +msgstr "" + +msgid "Click \"X509/Validate Username Form\"." +msgstr "" + +msgid "X509 execution" +msgstr "" + +msgid "image:images/x509-execution.png[X509 Execution]" +msgstr "" + +msgid "Click and drag the \"X509/Validate Username Form\" over the \"Browser Forms\" execution." +msgstr "" + +msgid "Set the requirement to \"ALTERNATIVE\"." +msgstr "" + +msgid "X509 browser flow" +msgstr "" + +msgid "image:images/x509-browser-flow.png[X509 Browser Flow]" +msgstr "" + +msgid "Click the *Action* menu." +msgstr "" + +msgid "Click the *Bind flow*." +msgstr "" + +msgid "Click the *Browser flow* from the drop-down list." +msgstr "" + +msgid "X509 browser flow bindings" +msgstr "" + +msgid "image:images/x509-browser-flow-bindings.png[X509 Browser Flow Bindings]" +msgstr "" + +msgid "Configuring X.509 client certificate authentication" +msgstr "" + +msgid "X509 configuration" +msgstr "" + +msgid "image:images/x509-configuration.png[X509 Configuration]" +msgstr "" + +msgid "*User Identity Source*" +msgstr "" + +msgid "Defines the method for extracting the user identity from a client certificate." +msgstr "" + +msgid "*Canonical DN representation enabled*" +msgstr "" + +msgid "Defines whether to use canonical format to determine a distinguished name. The official link:https://docs.oracle.com/javase/8/docs/api/javax/security/auth/x500/X500Principal.html#getName-java.lang.String-[Java API documentation] describes the format. This option affects the two User Identity Sources _Match SubjectDN using regular expression_ and _Match IssuerDN using regular expression_ only. Enable this option when you set up a new {project_name} instance. Disable this option to retain backward compatibility with existing {project_name} instances." +msgstr "" + +msgid "*Enable Serial Number hexadecimal representation*" +msgstr "" + +msgid "Represent the link:https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.2[serial number] as hexadecimal. The serial number with the sign bit set to 1 must be left padded with 00 octet. For example, a serial number with decimal value _161_, or _a1_ in hexadecimal representation is encoded as _00a1_, according to RFC5280. See link:https://datatracker.ietf.org/doc/html/rfc5280#appendix-B[RFC5280, appendix-B] for more details." +msgstr "" + +msgid "*A regular expression*" +msgstr "" + +msgid "A regular expression to use as a filter for extracting the certificate identity. The expression must contain a single group." +msgstr "" + +msgid "*User Mapping Method*" +msgstr "" + +msgid "Defines the method to match the certificate identity with an existing user. _Username or email_ searches for existing users by username or email. _Custom Attribute Mapper_ searches for existing users with a custom attribute that matches the certificate identity. The name of the custom attribute is configurable." +msgstr "" + +msgid "*A name of user attribute*" +msgstr "" + +msgid "A custom attribute whose value matches against the certificate identity. Use multiple custom attributes when attribute mapping is related to multiple values, For example, 'Certificate Serial Number and IssuerDN'." +msgstr "" + +msgid "*CRL Checking Enabled*" +msgstr "" + +msgid "Check the revocation status of the certificate by using the Certificate Revocation List. The location of the list is defined in the *CRL file path* attribute." +msgstr "" + +msgid "*Enable CRL Distribution Point to check certificate revocation status*" +msgstr "" + +msgid "Use CDP to check the certificate revocation status. Most PKI authorities include CDP in their certificates." +msgstr "" + +msgid "*CRL file path*" +msgstr "" + +msgid "The path to a file containing a CRL list. The value must be a path to a valid file if the *CRL Checking Enabled* option is enabled." +msgstr "" + +msgid "*OCSP Checking Enabled*" +msgstr "" + +msgid "Checks the certificate revocation status by using Online Certificate Status Protocol." +msgstr "" + +msgid "*OCSP Fail-Open Behavior*" +msgstr "" + +msgid "By default the OCSP check must return a positive response in order to continue with a successful authentication. Sometimes however this check can be inconclusive: for example, the OCSP server could be unreachable, overloaded, or the client certificate may not contain an OCSP responder URI. When this setting is turned ON, authentication will be denied only if an explicit negative response is received by the OCSP responder and the certificate is definitely revoked. If a valid OCSP response is not available the authentication attempt will be accepted." +msgstr "" + +msgid "*OCSP Responder URI*" +msgstr "" + +msgid "Override the value of the OCSP responder URI in the certificate." +msgstr "" + +msgid "*Validate Key Usage*" +msgstr "" + +msgid "Verifies the certificate's KeyUsage extension bits are set. For example, \"digitalSignature,KeyEncipherment\" verifies if bits 0 and 2 in the KeyUsage extension are set. Leave this parameter empty to disable the Key Usage validation. See link:https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3[RFC5280, Section-4.2.1.3] for more information. {project_name} raises an error when a key usage mismatch occurs." +msgstr "" + +msgid "*Validate Extended Key Usage*" +msgstr "" + +msgid "Verifies one or more purposes defined in the Extended Key Usage extension. See link:https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12[RFC5280, Section-4.2.1.12] for more information. Leave this parameter empty to disable the Extended Key Usage validation. {project_name} raises an error when flagged as critical by the issuing CA and a key usage extension mismatch occurs." +msgstr "" + +msgid "*Validate Certificate Policy*" +msgstr "" + +msgid "Verifies one or more policy OIDs as defined in the Certificate Policy extension. See link:https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4[RFC5280, Section-4.2.1.4]. Leave the parameter empty to disable the Certificate Policy validation. Multiple policies should be separated using a comma." +msgstr "" + +msgid "*Certificate Policy Validation Mode*" +msgstr "" + +msgid "When more than one policy is specified in the `Validate Certificate Policy` setting, it decides whether the matching should check for all requested policies to be present, or one match is enough for a successful authentication. Default value is `All`, meaning that all requested policies should be present in the client certificate." +msgstr "" + +msgid "*Bypass identity confirmation*" +msgstr "" + +msgid "If enabled, X.509 client certificate authentication does not prompt the user to confirm the certificate identity. {project_name} signs in the user upon successful authentication." +msgstr "" + +msgid "*Revalidate client certificate*" +msgstr "" + +msgid "If set, the client certificate trust chain will be always verified at the application level using the certificates present in the configured trust store. This can be useful if the underlying web server does not enforce client certificate chain validation, for example because it is behind a non-validating load balancer or reverse proxy, or when the number of allowed CAs is too large for the mutual SSL negotiation (most browsers cap the maximum SSL negotiation packet size at 32767 bytes, which corresponds to about 200 advertised CAs). By default this option is off." +msgstr "" + +msgid "Adding X.509 Client Certificate Authentication to a Direct Grant Flow" +msgstr "" + +msgid "Select *Duplicate* from the \"Action list\" to make a copy of the built-in \"Direct grant\" flow." +msgstr "" + +msgid "Click the created flow." +msgstr "" + +msgid "Click the trash can icon 🗑️ of the \"Username Validation\" and click *Delete*." +msgstr "" + +msgid "Click the trash can icon 🗑️ of the \"Password\" and click *Delete*." +msgstr "" + +msgid "Click \"X509/Validate Username\"." +msgstr "" + +msgid "X509 direct grant execution" +msgstr "" + +msgid "image:images/x509-directgrant-execution.png[X509 Direct Grant Execution]" +msgstr "" + +msgid "Set up the x509 authentication configuration by following the steps described in the <<_browser_flow, x509 Browser Flow>> section." +msgstr "" + +msgid "Click the *Bindings* tab." +msgstr "" + +msgid "Click the *Direct Grant Flow* drop-down list." +msgstr "" + +msgid "Click the newly created \"x509 Direct Grant\" flow." +msgstr "" + +msgid "X509 direct grant flow bindings" +msgstr "" + +msgid "image:images/x509-directgrant-flow-bindings.png[X509 Direct Grant Flow Bindings]" +msgstr "" + +msgid "W3C Web Authentication (WebAuthn)" +msgstr "" + +msgid "{project_name} provides support for https://www.w3.org/TR/webauthn/[W3C Web Authentication (WebAuthn)]. {project_name} works as a WebAuthn's https://www.w3.org/TR/webauthn/#webauthn-relying-party[Relying Party (RP)]." +msgstr "" + +msgid "WebAuthn's operations success depends on the user's WebAuthn supporting authenticator, browser, and platform. Make sure your authenticator, browser, and platform support the WebAuthn specification." +msgstr "" + +msgid "Setup" +msgstr "" + +msgid "The setup procedure of WebAuthn support for 2FA is the following:" +msgstr "" + +msgid "Enable WebAuthn authenticator registration" +msgstr "" + +msgid "Toggle the *Webauthn Register* switch to *ON*." +msgstr "" + +msgid "Toggle the *Default Action* switch to *ON* if you want all new users to be required to register their WebAuthn credentials." +msgstr "" + +msgid "Adding WebAuthn authentication to a browser flow" +msgstr "" + +msgid "Select *Duplicate* from the \"Action list\" to make a copy of the built-in *Browser* flow." +msgstr "" + +msgid "Enter \"WebAuthn Browser\" as the name of the copy." +msgstr "" + +msgid "Click the name to go to the details" +msgstr "" + +msgid "Click the trash can icon 🗑️ of the \"WebAuthn Browser Browser - Conditional OTP\" and click *Delete*." +msgstr "" + +msgid "If you require WebAuthn for all users:" +msgstr "" + +msgid "Click *+* menu of the *WebAuthn Browser Forms*." +msgstr "" + +msgid "Click *WebAuthn Authenticator*." +msgstr "" + +msgid "Select *Required* for the *WebAuthn Authenticator* authentication type to set its requirement to required." +msgstr "" + +msgid "image:images/webauthn-browser-flow-required.png[Webauthn browser flow required]" +msgstr "" + +msgid "Select *Bind flow* from the drop-down list." +msgstr "" + +msgid "Select *Browser* from the drop-down list." +msgstr "" + +msgid "If a user does not have WebAuthn credentials, the user must register WebAuthn credentials." +msgstr "" + +msgid "Users can log in with WebAuthn if they have a WebAuthn credential registered only. So instead of adding the *WebAuthn Authenticator* execution, you can:" +msgstr "" + +msgid "Click *+* menu of the *WebAuthn Browser Forms* row." +msgstr "" + +msgid "Enter \"Conditional 2FA\" for the _name_ field." +msgstr "" + +msgid "Select *Conditional* for the *Conditional 2FA* to set its requirement to conditional." +msgstr "" + +msgid "On the *Conditional 2FA* row, click the plus sign + and select *Add condition*." +msgstr "" + +msgid "Select *Condition - User Configured*." +msgstr "" + +msgid "Select *Required* for the *Condition - User Configured* to set its requirement to required." +msgstr "" + +msgid "Drag and drop *WebAuthn Authenticator* into the *Conditional 2FA* flow" +msgstr "" + +msgid "Select *Alternative* for the *WebAuthn Authenticator* to set its requirement to alternative." +msgstr "" + +msgid "image:images/webauthn-browser-flow-conditional.png[Webauthn browser flow conditional]" +msgstr "" + +msgid "The user can choose between using WebAuthn and OTP for the second factor:" +msgstr "" + +msgid "On the *Conditional 2FA* row, click the plus sign + and select *Add step*." +msgstr "" + +msgid "Select *Alternative* for the *OTP Form* to set its requirement to alternative." +msgstr "" + +msgid "image:images/webauthn-browser-flow-conditional-with-OTP.png[WebAuthn browser flow conditional with OTP]" +msgstr "" + +msgid "Authenticate with WebAuthn authenticator" +msgstr "" + +msgid "After registering a WebAuthn authenticator, the user carries out the following operations:" +msgstr "" + +msgid "Open the login form. The user must authenticate with a username and password." +msgstr "" + +msgid "The user's browser asks the user to authenticate by using their WebAuthn authenticator." +msgstr "" + +msgid "Managing WebAuthn as an administrator" +msgstr "" + +msgid "Managing credentials" +msgstr "" + +msgid "{project_name} manages WebAuthn credentials similarly to other credentials from xref:ref-user-credentials_{context}[User credential management]:" +msgstr "" + +msgid "{project_name} assigns users a required action to create a WebAuthn credential from the *Reset Actions* list and select *Webauthn Register*." +msgstr "" + +msgid "Administrators can delete a WebAuthn credential by clicking *Delete*." +msgstr "" + +msgid "Administrators can view the credential's data, such as the AAGUID, by selecting *Show data...*." +msgstr "" + +msgid "Administrators can set a label for the credential by setting a value in the *User Label* field and saving the data." +msgstr "" + +msgid "Managing policy" +msgstr "" + +msgid "Administrators can configure WebAuthn related operations as *WebAuthn Policy* per realm." +msgstr "" + +msgid "Click the *WebAuthn Policy* tab." +msgstr "" + +msgid "Configure the items within the policy (see description below)." +msgstr "" + +msgid "The configurable items and their description are as follows:" +msgstr "" + +msgid "Relying Party Entity Name" +msgstr "" + +msgid "The readable server name as a WebAuthn Relying Party. This item is mandatory and applies to the registration of the WebAuthn authenticator. The default setting is \"keycloak\". For more details, see https://www.w3.org/TR/webauthn/#dictionary-pkcredentialentity[WebAuthn Specification]." +msgstr "" + +msgid "Signature Algorithms" +msgstr "" + +msgid "The algorithms telling the WebAuthn authenticator which signature algorithms to use for the https://www.w3.org/TR/webauthn/#iface-pkcredential[Public Key Credential]. {project_name} uses the Public Key Credential to sign and verify https://www.w3.org/TR/webauthn/#authentication-assertion[Authentication Assertions]. If no algorithms exist, the default https://datatracker.ietf.org/doc/html/rfc8152#section-8.1[ES256] is adapted. ES256 is an optional configuration item applying to the registration of WebAuthn authenticators. For more details, see https://www.w3.org/TR/webauthn/#dictdef-publickeycredentialparameters[WebAuthn Specification]." +msgstr "" + +msgid "Relying Party ID" +msgstr "" + +msgid "The ID of a WebAuthn Relying Party that determines the scope of https://www.w3.org/TR/webauthn/#public-key-credential[Public Key Credentials]. The ID must be the origin's effective domain. This ID is an optional configuration item applied to the registration of WebAuthn authenticators. If this entry is blank, {project_name} adapts the host part of {project_name}'s base URL. For more details, see https://www.w3.org/TR/webauthn/[WebAuthn Specification]." +msgstr "" + +msgid "Attestation Conveyance Preference" +msgstr "" + +msgid "The WebAuthn API implementation on the browser (https://www.w3.org/TR/webauthn/#webauthn-client[WebAuthn Client]) is the preferential method to generate Attestation statements. This preference is an optional configuration item applying to the registration of the WebAuthn authenticator. If no option exists, its behavior is the same as selecting \"none\". For more details, see https://www.w3.org/TR/webauthn/[WebAuthn Specification]." +msgstr "" + +msgid "Authenticator Attachment" +msgstr "" + +msgid "The acceptable attachment pattern of a WebAuthn authenticator for the WebAuthn Client. This pattern is an optional configuration item applying to the registration of the WebAuthn authenticator. For more details, see https://www.w3.org/TR/webauthn/#enumdef-authenticatorattachment[WebAuthn Specification]." +msgstr "" + +msgid "Require Resident Key" +msgstr "" + +msgid "The option requiring that the WebAuthn authenticator generates the Public Key Credential as https://www.w3.org/TR/webauthn/[Client-side-resident Public Key Credential Source]. This option applies to the registration of the WebAuthn authenticator. If left blank, its behavior is the same as selecting \"No\". For more details, see https://www.w3.org/TR/webauthn/#dom-authenticatorselectioncriteria-requireresidentkey[WebAuthn Specification]." +msgstr "" + +msgid "User Verification Requirement" +msgstr "" + +msgid "The option requiring that the WebAuthn authenticator confirms the verification of a user. This is an optional configuration item applying to the registration of a WebAuthn authenticator and the authentication of a user by a WebAuthn authenticator. If no option exists, its behavior is the same as selecting \"preferred\". For more details, see https://www.w3.org/TR/webauthn/#dom-authenticatorselectioncriteria-userverification[WebAuthn Specification for registering a WebAuthn authenticator] and https://www.w3.org/TR/webauthn/#dom-publickeycredentialrequestoptions-userverification[WebAuthn Specification for authenticating the user by a WebAuthn authenticator]." +msgstr "" + +msgid "Timeout" +msgstr "" + +msgid "The timeout value, in seconds, for registering a WebAuthn authenticator and authenticating the user by using a WebAuthn authenticator. If set to zero, its behavior depends on the WebAuthn authenticator's implementation. The default value is 0. For more details, see https://www.w3.org/TR/webauthn/#dom-publickeycredentialcreationoptions-timeout[WebAuthn Specification for registering a WebAuthn authenticator] and https://www.w3.org/TR/webauthn/#dom-publickeycredentialrequestoptions-timeout[WebAuthn Specification for authenticating the user by a WebAuthn authenticator]." +msgstr "" + +msgid "Avoid Same Authenticator Registration" +msgstr "" + +msgid "If enabled, {project_name} cannot re-register an already registered WebAuthn authenticator." +msgstr "" + +msgid "Acceptable AAGUIDs" +msgstr "" + +msgid "The white list of AAGUIDs which a WebAuthn authenticator must register against." +msgstr "" + +msgid "Attestation statement verification" +msgstr "" + +msgid "When registering a WebAuthn authenticator, {project_name} verifies the trustworthiness of the attestation statement generated by the WebAuthn authenticator. {project_name} requires the trust anchor's certificates imported into the https://www.keycloak.org/server/keycloak-truststore[truststore]." +msgstr "" + +msgid "To omit this validation, disable this truststore or set the WebAuthn policy's configuration item \"Attestation Conveyance Preference\" to \"none\"." +msgstr "" + +msgid "Managing WebAuthn credentials as a user" +msgstr "" + +msgid "Register WebAuthn authenticator" +msgstr "" + +msgid "The appropriate method to register a WebAuthn authenticator depends on whether the user has already registered an account on {project_name}." +msgstr "" + +msgid "New user" +msgstr "" + +msgid "If the *WebAuthn Register* required action is *Default Action* in a realm, new users must set up the WebAuthn security key after their first login." +msgstr "" + +msgid "Open the login form." +msgstr "" + +msgid "Fill in the items on the form." +msgstr "" + +msgid "After successfully registering, the browser asks the user to enter the text of their WebAuthn authenticator's label." +msgstr "" + +msgid "Existing user" +msgstr "" + +msgid "If `WebAuthn Authenticator` is set up as required as shown in the first example, then when existing users try to log in, they are required to register their WebAuthn authenticator automatically:" +msgstr "" + +msgid "Enter the items on the form." +msgstr "" + +msgid "Click *Login*." +msgstr "" + +msgid "After successful registration, the user's browser asks the user to enter the text of their WebAuthn authenticator's label." +msgstr "" + +msgid "Passwordless WebAuthn together with Two-Factor" +msgstr "" + +msgid "{project_name} uses WebAuthn for two-factor authentication, but you can use WebAuthn as the first-factor authentication. In this case, users with `passwordless` WebAuthn credentials can authenticate to {project_name} without a password. {project_name} can use WebAuthn as both the passwordless and two-factor authentication mechanism in the context of a realm and a single authentication flow." +msgstr "" + +msgid "An administrator typically requires that Security Keys registered by users for the WebAuthn passwordless authentication meet different requirements. For example, the security keys may require users to authenticate to the security key using a PIN, or the security key attests with a stronger certificate authority." +msgstr "" + +msgid "Because of this, {project_name} permits administrators to configure a separate `WebAuthn Passwordless Policy`. There is a required `Webauthn Register Passwordless` action of type and separate authenticator of type `WebAuthn Passwordless Authenticator`." +msgstr "" + +msgid "Set up WebAuthn passwordless support as follows:" +msgstr "" + +msgid "(if not already present) Register a new required action for WebAuthn passwordless support. Use the steps described in <<_webauthn-register, Enable WebAuthn Authenticator Registration>>. Register the `Webauthn Register Passwordless` action." +msgstr "" + +msgid "Configure the policy. You can use the steps and configuration options described in <<_webauthn-policy, Managing Policy>>. Perform the configuration in the Admin Console in the tab *WebAuthn Passwordless Policy*. Typically the requirements for the security key will be stronger than for the two-factor policy. For example, you can set the *User Verification Requirement* to *Required* when you configure the passwordless policy." +msgstr "" + +msgid "Configure the authentication flow. Use the *WebAuthn Browser* flow described in <<_webauthn-authenticator-setup, Adding WebAuthn Authentication to a Browser Flow>>. Configure the flow as follows:" +msgstr "" + +msgid "The *WebAuthn Browser Forms* subflow contains *Username Form* as the first authenticator. Delete the default *Username Password Form* authenticator and add the *Username Form* authenticator. This action requires the user to provide a username as the first step." +msgstr "" + +msgid "There will be a required subflow, which can be named *Passwordless Or Two-factor*, for example. This subflow indicates the user can authenticate with Passwordless WebAuthn credential or with Two-factor authentication." +msgstr "" + +msgid "The flow contains *WebAuthn Passwordless Authenticator* as the first alternative." +msgstr "" + +msgid "The second alternative will be a subflow named *Password And Two-factor Webauthn*, for example. This subflow contains a *Password Form* and a *WebAuthn Authenticator*." +msgstr "" + +msgid "The final configuration of the flow looks similar to this:" +msgstr "" + +msgid "PasswordLess flow" +msgstr "" + +msgid "image:images/webauthn-passwordless-flow.png[PasswordLess flow]" +msgstr "" + +msgid "You can now add *WebAuthn Register Passwordless* as the required action to a user, already known to {project_name}, to test this. During the first authentication, the user must use the password and second-factor WebAuthn credential. The user does not need to provide the password and second-factor WebAuthn credential if they use the WebAuthn Passwordless credential." +msgstr "" + +msgid "LoginLess WebAuthn" +msgstr "" + +msgid "{project_name} uses WebAuthn for two-factor authentication, but you can use WebAuthn as the first-factor authentication. In this case, users with `passwordless` WebAuthn credentials can authenticate to {project_name} without submitting a login or a password. {project_name} can use WebAuthn as both the loginless/passwordless and two-factor authentication mechanism in the context of a realm." +msgstr "" + +msgid "An administrator typically requires that Security Keys registered by users for the WebAuthn loginless authentication meet different requirements. Loginless authentication requires users to authenticate to the security key (for example by using a PIN code or a fingerprint) and that the cryptographic keys associated with the loginless credential are stored physically on the security key. Not all security keys meet that kind of requirements. Check with your security key vendor if your device supports 'user verification' and 'resident key'. See <<_webauthn-supported-keys, Supported Security Keys>>." +msgstr "" + +msgid "{project_name} permits administrators to configure the `WebAuthn Passwordless Policy` in a way that allows loginless authentication. Note that loginless authentication can only be configured with `WebAuthn Passwordless Policy` and with `WebAuthn Passwordless` credentials. WebAuthn loginless authentication and WebAuthn passwordless authentication can be configured on the same realm but will share the same policy `WebAuthn Passwordless Policy`." +msgstr "" + +msgid "Set up WebAuthn Loginless support as follows:" +msgstr "" + +msgid "Configure the `WebAuthn Passwordless Policy`. Perform the configuration in the Admin Console, `Authentication` section, in the tab `Policies` -> `WebAuthn Passwordless Policy`. You have to set *User Verification Requirement* to *required* and *Require Resident Key* to *Yes* when you configure the policy for loginless scenario. Note that since there isn't a dedicated Loginless policy it won't be possible to mix authentication scenarios with user verification=no/resident key=no and loginless scenarios (user verification=yes/resident key=yes). Storage capacity is usually very limited on security keys meaning that you won't be able to store many resident keys on your security key." +msgstr "" + +msgid "Configure the authentication flow. Create a new authentication flow, add the \"WebAuthn Passwordless\" execution and set the Requirement setting of the execution to *Required*" +msgstr "" + +msgid "LoginLess flow" +msgstr "" + +msgid "image:images/webauthn-loginless-flow.png[LoginLess flow]" +msgstr "" + +msgid "You can now add the required action `WebAuthn Register Passwordless` to a user, already known to {project_name}, to test this. The user with the required action configured will have to authenticate (with a username/password for example) and will then be prompted to register a security key to be used for loginless authentication." +msgstr "" + +msgid "Vendor specific remarks" +msgstr "" + +msgid "Compatibility check list" +msgstr "" + +msgid "Loginless authentication with {project_name} requires the security key to meet the following features" +msgstr "" + +msgid "FIDO2 compliance: not to be confused with FIDO/U2F" +msgstr "" + +msgid "User verification: the ability for the security key to authenticate the user (prevents someone finding your security key to be able to authenticate loginless and passwordless)" +msgstr "" + +msgid "Resident key: the ability for the security key to store the login and the cryptographic keys associated with the client application" +msgstr "" + +msgid "Windows Hello" +msgstr "" + +msgid "To use Windows Hello based credentials to authenticate against {project_name}, configure the *Signature Algorithms* setting of the `WebAuthn Passwordless Policy` to include the *RS256* value. Note that some browsers don't allow access to platform security key (like Windows Hello) inside private windows." +msgstr "" + +msgid "Supported security keys" +msgstr "" + +msgid "The following security keys have been successfully tested for loginless authentication with {project_name}:" +msgstr "" + +msgid "Windows Hello (Windows 10 21H1/21H2)" +msgstr "" + +msgid "Yubico Yubikey 5 NFC" +msgstr "" + +msgid "Feitian ePass FIDO-NFC" +msgstr "" + +msgid "Recovery Codes (RecoveryCodes)" +msgstr "" + +msgid "You can configure Recovery codes for two-factor authentication by adding 'Recovery Authentication Code Form' as a two-factor authenticator to your authentication flow. For an example of configuring this authenticator, see xref:webauthn_{context}[WebAuthn]." +msgstr "" + +msgid "Please note that Recovery Codes support is in development. Use this feature experimentally." +msgstr "" + +msgid "Conditions in conditional flows" +msgstr "" + +msgid "As was mentioned in <<_execution-requirements, Execution requirements>>, _Condition_ executions can be only contained in _Conditional_ subflow. If all _Condition_ executions evaluate as true, then the _Conditional_ sub-flow acts as _Required_. You can process the next execution in the _Conditional_ sub-flow. If some executions included in the _Conditional_ sub-flow evaluate as false, then the whole sub-flow is considered as _Disabled_." +msgstr "" + +msgid "Available conditions" +msgstr "" + +msgid "`Condition - User Role`" +msgstr "" + +msgid "This execution has the ability to determine if the user has a role defined by _User role_ field. If the user has the required role, the execution is considered as true and other executions are evaluated. The administrator has to define the following fields:" +msgstr "" + +msgid "Alias" +msgstr "" + +msgid "Describes a name of the execution, which will be shown in the authentication flow." +msgstr "" + +msgid "User role" +msgstr "" + +msgid "Role the user should have to execute this flow. To specify an application role the syntax is `appname.approle` (for example `myapp.myrole`)." +msgstr "" + +msgid "`Condition - User Configured`" +msgstr "" + +msgid "This checks if the other executions in the flow are configured for the user. The Execution requirements section includes an example of the OTP form." +msgstr "" + +msgid "`Condition - User Attribute`" +msgstr "" + +msgid "This checks if the user has set up the required attribute: optionally, the check can also evaluate the group attributes. There is a possibility to negate output, which means the user should not have the attribute. The xref:proc-configuring-user-attributes_{context}[User Attributes] section shows how to add a custom attribute. You can provide these fields:" +msgstr "" + +msgid "Attribute name" +msgstr "" + +msgid "Name of the attribute to check." +msgstr "" + +msgid "Expected attribute value" +msgstr "" + +msgid "Expected value in the attribute." +msgstr "" + +msgid "Include group attributes" +msgstr "" + +msgid "If On, the condition checks if any of the joined group has one attribute matching the configured name and value: this option can affect performance" +msgstr "" + +msgid "Negate output" +msgstr "" + +msgid "You can negate the output. In other words, the attribute should not be present." +msgstr "" + +msgid "Explicitly deny/allow access in conditional flows" +msgstr "" + +msgid "You can allow or deny access to resources in a conditional flow. The two authenticators `Deny Access` and `Allow Access` control access to the resources by conditions." +msgstr "" + +msgid "`Allow Access`" +msgstr "" + +msgid "Authenticator will always successfully authenticate. This authenticator is not configurable." +msgstr "" + +msgid "`Deny Access`" +msgstr "" + +msgid "Access will always be denied. You can define an error message, which will be shown to the user. You can provide these fields:" +msgstr "" + +msgid "Error message" +msgstr "" + +msgid "Error message which will be shown to the user. The error message could be provided as a particular message or as a property in order to use it with localization. (i.e. \"_You do not have the role 'admin'._\", _my-property-deny_ in messages properties) Leave blank for the default message defined as property `access-denied`." +msgstr "" + +msgid "Here is an example how to deny access to all users who do not have the role `role1` and show an error message defined by a property `deny-role1`. This example includes `Condition - User Role` and `Deny Access` executions." +msgstr "" + +msgid "image:images/deny-access-flow.png[Deny access flow]" +msgstr "" + +msgid "Condition - user role configuration" +msgstr "" + +msgid "image:images/deny-access-role-condition.png[Deny access role settings]" +msgstr "" + +msgid "Configuration of the `Deny Access` is really easy. You can specify an arbitrary Alias and required message like this:" +msgstr "" + +msgid "image:images/deny-access-execution-cond.png[Deny access execution settings]" +msgstr "" + +msgid "The last thing is defining the property with an error message in the login theme `messages_en.properties` (for English):" +msgstr "" + +msgid "deny-role1 = You do not have required role!" +msgstr "" + +msgid "Passkeys" +msgstr "" + +msgid "{project_name} provides preview support for https://fidoalliance.org/passkeys/[Passkeys]. {project_name} works as a Passkeys Relying Party (RP)." +msgstr "" + +msgid "Passkey registration and authentication are realized by the features of xref:webauthn_{context}[WebAuthn]. Therefore, users of {project_name} can do passkey registration and authentication by existing xref:webauthn_{context}[WebAuthn registraton and authentication]." +msgstr "" + +msgid "Both synced passkeys and device-bound passkeys can be used for both Same-Device and Cross-Device Authentication (CDA). However, passkeys operations success depends on the user's environment. Make sure which operations can succeed in https://passkeys.dev/device-support/[the environment]." +msgstr "" + +msgid "Integrating identity providers" +msgstr "" + +msgid "An Identity Broker is an intermediary service connecting service providers with identity providers. The identity broker creates a relationship with an external identity provider to use the provider's identities to access the internal services the service provider exposes." +msgstr "" + +msgid "From a user perspective, identity brokers provide a user-centric, centralized way to manage identities for security domains and realms. You can link an account with one or more identities from identity providers or create an account based on the identity information from them." +msgstr "" + +msgid "An identity provider derives from a specific protocol used to authenticate and send authentication and authorization information to users. It can be:" +msgstr "" + +msgid "A social provider such as Facebook, Google, or Twitter." +msgstr "" + +msgid "A business partner whose users need to access your services." +msgstr "" + +msgid "A cloud-based identity service you want to integrate." +msgstr "" + +msgid "Typically, {project_name} bases identity providers on the following protocols:" +msgstr "" + +msgid "`SAML v2.0`" +msgstr "" + +msgid "`OpenID Connect v1.0`" +msgstr "" + +msgid "`OAuth v2.0`" +msgstr "" + +msgid "Brokering overview" +msgstr "" + +msgid "When using {project_name} as an identity broker, {project_name} does not force users to provide their credentials to authenticate in a specific realm. {project_name} displays a list of identity providers from which they can authenticate." +msgstr "" + +msgid "If you configure a default identity provider, {project_name} redirects users to the default provider." +msgstr "" + +msgid "Different protocols may require different authentication flows. All the identity providers supported by {project_name} use the following flow." +msgstr "" + +msgid "Identity broker flow" +msgstr "" + +msgid "image:images/identity_broker_flow.png[Identity broker flow]" +msgstr "" + +msgid "The unauthenticated user requests a protected resource in a client application." +msgstr "" + +msgid "The client application redirects the user to {project_name} to authenticate." +msgstr "" + +msgid "{project_name} displays the login page with a list of identity providers configured in a realm." +msgstr "" + +msgid "The user selects one of the identity providers by clicking its button or link." +msgstr "" + +msgid "{project_name} issues an authentication request to the target identity provider requesting authentication and redirects the user to the identity provider's login page. The administrator has already set the connection properties and other configuration options for the Admin Console's identity provider." +msgstr "" + +msgid "The user provides credentials or consents to authenticate with the identity provider." +msgstr "" + +msgid "Upon successful authentication by the identity provider, the user redirects back to {project_name} with an authentication response. Usually, the response contains a security token used by {project_name} to trust the identity provider's authentication and retrieve user information." +msgstr "" + +msgid "{project_name} checks if the response from the identity provider is valid. If valid, {project_name} imports and creates a user if the user does not already exist. {project_name} may ask the identity provider for further user information if the token does not contain that information. This behavior is _identity federation_. If the user already exists, {project_name} may ask the user to link the identity returned from the identity provider with the existing account. This behavior is _account linking_. With {project_name}, you can configure _Account linking_ and specify it in the <<_identity_broker_first_login,First Login Flow>>. At this step, {project_name} authenticates the user and issues its token to access the requested resource in the service provider." +msgstr "" + +msgid "When the user authenticates, {project_name} redirects the user to the service provider by sending the token previously issued during the local authentication." +msgstr "" + +msgid "The service provider receives the token from {project_name} and permits access to the protected resource." +msgstr "" + +msgid "Variations of this flow are possible. For example, the client application can request a specific identity provider rather than displaying a list of them, or you can set {project_name} to force users to provide additional information before federating their identity." +msgstr "" + +msgid "At the end of the authentication process, {project_name} issues its token to client applications. Client applications are separate from the external identity providers, so they cannot see the client application's protocol or how they validate the user's identity. The provider only needs to know about {project_name}." +msgstr "" + +msgid "Default Identity Provider" +msgstr "" + +msgid "{project_name} can redirect to an identity provider rather than displaying the login form. To enable this redirection:" +msgstr "" + +msgid "Click the gear icon *⚙️* on the *Identity Provider Redirector* row." +msgstr "" + +msgid "Set *Default Identity Provider* to the identity provider you want to redirect users to." +msgstr "" + +msgid "If {project_name} does not find the configured default identity provider, the login form is displayed." +msgstr "" + +msgid "This authenticator is responsible for processing the `kc_idp_hint` query parameter. See the <<_client_suggested_idp, client suggested identity provider>> section for more information." +msgstr "" + +msgid "General configuration" +msgstr "" + +msgid "The foundations of the identity broker configuration are identity providers (IDPs). {project_name} creates identity providers for each realm and enables them for every application by default. Users from a realm can use any of the registered identity providers when signing in to an application." +msgstr "" + +msgid "Click *Identity Providers* in the menu." +msgstr "" + +msgid "Identity Providers" +msgstr "" + +msgid "image:images/identity-providers.png[Identity Providers]" +msgstr "" + +msgid "Select an identity provider. {project_name} displays the configuration page for the identity provider you selected." +msgstr "" + +msgid "Add Facebook identity Provider" +msgstr "" + +msgid "image:images/add-identity-provider.png[Add Facebook Identity Provider]" +msgstr "" + +msgid "When you configure an identity provider, the identity provider appears on the {project_name} login page as an option. You can place custom icons on the login screen for each identity provider. See link:{developerguide_link}#custom-identity-providers-icons[custom icons] for more information." +msgstr "" + +msgid "IDP login page" +msgstr "" + +msgid "image:images/identity-provider-login-page.png[]" +msgstr "" + +msgid "Social" +msgstr "" + +msgid "Social providers enable social authentication in your realm. With {project_name}, users can log in to your application using a social network account. Supported providers include Twitter, Facebook, Google, LinkedIn, Instagram, Microsoft, PayPal, Openshift v3, GitHub, GitLab, Bitbucket, and Stack Overflow." +msgstr "" + +msgid "Protocol-based" +msgstr "" + +msgid "Protocol-based providers rely on specific protocols to authenticate and authorize users. Using these providers, you can connect to any identity provider compliant with a specific protocol. {project_name} provides support for SAML v2.0 and OpenID Connect v1.0 protocols. You can configure and broker any identity provider based on these open standards." +msgstr "" + +msgid "Although each type of identity provider has its configuration options, all share a common configuration. The following configuration options available:" +msgstr "" + +msgid "Common Configuration" +msgstr "" + +msgid "The alias is a unique identifier for an identity provider and references an internal identity provider. {project_name} uses the alias to build redirect URIs for OpenID Connect protocols that require a redirect URI or callback URL to communicate with an identity provider. All identity providers must have an alias. Alias examples include `facebook`, `google`, and `idp.acme.com`." +msgstr "" + +msgid "Enabled" +msgstr "" + +msgid "Toggles the provider ON or OFF." +msgstr "" + +msgid "Hide on Login Page" +msgstr "" + +msgid "When *ON*, {project_name} does not display this provider as a login option on the login page. Clients can request this provider by using the 'kc_idp_hint' parameter in the URL to request a login." +msgstr "" + +msgid "Account Linking Only" +msgstr "" + +msgid "When *ON*, {project_name} links existing accounts with this provider. This provider cannot log users in, and {project_name} does not display this provider as an option on the login page." +msgstr "" + +msgid "Store Tokens" +msgstr "" + +msgid "When *ON*, {project_name} stores tokens from the identity provider." +msgstr "" + +msgid "Stored Tokens Readable" +msgstr "" + +msgid "When *ON*, users can retrieve the stored identity provider token. This action also applies to the _broker_ client-level role _read token_." +msgstr "" + +msgid "Trust Email" +msgstr "" + +msgid "When *ON*, {project_name} trusts email addresses from the identity provider. If the realm requires email validation, users that log in from this identity provider do not need to perform the email verification process." +msgstr "" + +msgid "GUI Order" +msgstr "" + +msgid "The sort order of the available identity providers on the login page." +msgstr "" + +msgid "Verify essential claim" +msgstr "" + +msgid "When *ON*, ID tokens issued by the identity provider must have a specific claim, otherwise, the user can not authenticate through this broker" +msgstr "" + +msgid "Essential claim" +msgstr "" + +msgid "When *Verify essential claim* is *ON*, the name of the JWT token claim to filter (match is case sensitive)" +msgstr "" + +msgid "Essential claim value" +msgstr "" + +msgid "When *Verify essential claim* is *ON*, the value of the JWT token claim to match (supports regular expression format)" +msgstr "" + +msgid "First Login Flow" +msgstr "" + +msgid "The authentication flow {project_name} triggers when users use this identity provider to log into {project_name} for the first time." +msgstr "" + +msgid "Post Login Flow" +msgstr "" + +msgid "The authentication flow {project_name} triggers when a user finishes logging in with the external identity provider." +msgstr "" + +msgid "Sync Mode" +msgstr "" + +msgid "Strategy to update user information from the identity provider through mappers. When choosing *legacy*, {project_name} used the current behavior. *Import* does not update user data and *force* updates user data when possible. See <<_mappers, Identity Provider Mappers>> for more information." +msgstr "" + +msgid "Social Identity Providers" +msgstr "" + +msgid "A social identity provider can delegate authentication to a trusted, respected social media account. {project_name} includes support for social networks such as Google, Facebook, Twitter, GitHub, LinkedIn, Microsoft, and Stack Overflow." +msgstr "" + +msgid "Bitbucket" +msgstr "" + +msgid "To log in with Bitbucket, perform the following procedure." +msgstr "" + +msgid "From the *Add provider* list, select *Bitbucket*." +msgstr "" + +msgid "Add identity provider" +msgstr "" + +msgid "image:images/bitbucket-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "Copy the value of *Redirect URI* to your clipboard." +msgstr "" + +msgid "In a separate browser tab, perform the https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/[OAuth on Bitbucket Cloud] process. When you click *Add Consumer*:" +msgstr "" + +msgid "Paste the value of *Redirect URI* into the *Callback URL* field." +msgstr "" + +msgid "Ensure you select *Email* and *Read* in the *Account* section to permit your application to read email." +msgstr "" + +msgid "Note the *Key* and *Secret* values Bitbucket displays when you create your consumer." +msgstr "" + +msgid "In {project_name}, paste the value of the `Key` into the *Client ID* field." +msgstr "" + +msgid "In {project_name}, paste the value of the `Secret` into the *Client Secret* field." +msgstr "" + +msgid "Facebook" +msgstr "" + +msgid "From the *Add provider* list, select *Facebook*." +msgstr "" + +msgid "image:images/facebook-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "In a separate browser tab, open the https://developers.facebook.com/[Meta for Developers]." +msgstr "" + +msgid "Click *My Apps*." +msgstr "" + +msgid "Select *Create App*." +msgstr "" + +msgid "Add a use case" +msgstr "" + +msgid "image:images/meta-add-use-case.png[Add a use case]" +msgstr "" + +msgid "Select *Other*." +msgstr "" + +msgid "Select an app type" +msgstr "" + +msgid "image:images/meta-select-app-type.png[Select an app type]" +msgstr "" + +msgid "Select *Consumer*." +msgstr "" + +msgid "Create an app" +msgstr "" + +msgid "image:images/meta-create-app.png[Create an app]" +msgstr "" + +msgid "Fill in all required fields." +msgstr "" + +msgid "Click *Create app*. Meta then brings you to the dashboard." +msgstr "" + +msgid "Add a product" +msgstr "" + +msgid "image:images/meta-add-product.png[Add Product]" +msgstr "" + +msgid "Click *Set Up* in the *Facebook Login* box." +msgstr "" + +msgid "Select *Web*." +msgstr "" + +msgid "Enter the *Redirect URI's* value into the *Site URL* field and click *Save*." +msgstr "" + +msgid "In the navigation panel, select *App settings* - *Basic*." +msgstr "" + +msgid "Click *Show* in the *App Secret* field." +msgstr "" + +msgid "Note the *App ID* and the *App Secret*." +msgstr "" + +msgid "Enter the https://developers.facebook.com/docs/facebook-login/guides/access-tokens[`App ID` and `App Secret`] values from your Facebook app into the *Client ID* and *Client Secret* fields in {project_name}." +msgstr "" + +msgid "Click *Add*" +msgstr "" + +msgid "Enter the required scopes into the *Default Scopes* field. By default, {project_name} uses the *email* scope. See https://developers.facebook.com/docs/graph-api[Graph API] for more information about Facebook scopes." +msgstr "" + +msgid "{project_name} sends profile requests to `graph.facebook.com/me?fields=id,name,email,first_name,last_name` by default. The response contains the id, name, email, first_name, and last_name fields only. To fetch additional fields from the Facebook profile, add a corresponding scope and add the field name in the `Additional user's profile fields` configuration option field." +msgstr "" + +msgid "GitHub" +msgstr "" + +msgid "To log in with GitHub, perform the following procedure." +msgstr "" + +msgid "From the *Add provider* list, select *Github*." +msgstr "" + +msgid "image:images/github-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "In a separate browser tab, https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app[create an OAUTH app]." +msgstr "" + +msgid "Enter the value of *Redirect URI* into the *Authorization callback URL* field when creating the app." +msgstr "" + +msgid "Note the *Client ID* and *Client secret* on the management page of your OAUTH app." +msgstr "" + +msgid "In {project_name}, paste the value of the `Client ID` into the *Client ID* field." +msgstr "" + +msgid "In {project_name}, paste the value of the `Client secret` into the *Client Secret* field." +msgstr "" + +msgid "GitLab" +msgstr "" + +msgid "From the *Add provider* list, select *GitLab*." +msgstr "" + +msgid "image:images/gitlab-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "In a separate browser tab, https://docs.gitlab.com/ee/integration/oauth_provider.html[add a new GitLab application]." +msgstr "" + +msgid "Use the *Redirect URI* in your clipboard as the *Redirect URI*." +msgstr "" + +msgid "Note the *Application ID* and *Secret* when you save the application." +msgstr "" + +msgid "In {project_name}, paste the value of the `Application ID` into the *Client ID* field." +msgstr "" + +msgid "Google" +msgstr "" + +msgid "From the *Add provider* list, select *Google*." +msgstr "" + +msgid "image:images/google-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "In a separate browser tab open https://console.cloud.google.com/[the Google Cloud Platform console]." +msgstr "" + +msgid "In the Google dashboard for your Google app, in the Navigation menu on the left side, hover over *APIs & Services* and then click on the *OAuth consent screen* option. Create a consent screen, ensuring that the user type of the consent screen is *External*." +msgstr "" + +msgid "In the Google dashboard:" +msgstr "" + +msgid "Click the *Credentials* menu." +msgstr "" + +msgid "Click *CREATE CREDENTIALS* - *OAuth Client ID*." +msgstr "" + +msgid "From the *Application type* list, select *Web application*." +msgstr "" + +msgid "Use the *Redirect URI* in your clipboard as the *Authorized redirect URIs*" +msgstr "" + +msgid "Note *Your Client ID* and *Your Client secret*." +msgstr "" + +msgid "In {project_name}, paste the value of the `Your Client ID` into the *Client ID* field." +msgstr "" + +msgid "In {project_name}, paste the value of the `Your Client secret` into the *Client Secret* field." +msgstr "" + +msgid "Enter the required scopes into the *Default Scopes* field. By default, {project_name} uses the following scopes: *openid* *profile* *email*. See the https://developers.google.com/oauthplayground/[OAuth Playground] for a list of Google scopes." +msgstr "" + +msgid "To restrict access to your GSuite organization's members only, enter the G Suite domain into the *Hosted Domain* field." +msgstr "" + +msgid "Instagram" +msgstr "" + +msgid "From the *Add provider* list, select *Instagram*." +msgstr "" + +msgid "image:images/instagram-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "Select *+ Add Platform* at the bottom of the page." +msgstr "" + +msgid "Click *[Website]*." +msgstr "" + +msgid "Enter a URL for your site." +msgstr "" + +msgid "Select *Dashboard* from the menu." +msgstr "" + +msgid "Click *Set Up* in the *Instagram Basic Display* box." +msgstr "" + +msgid "Click *Create New App*." +msgstr "" + +msgid "Create a New Instagram App ID" +msgstr "" + +msgid "image:images/instagram-create-instagram-app-id.png[Create a New Instagram App ID]" +msgstr "" + +msgid "Enter a value into the *Display name* field." +msgstr "" + +msgid "Set up the app" +msgstr "" + +msgid "image:images/instagram-app-settings.png[Setup the App]" +msgstr "" + +msgid "Paste the *Redirect URL* from {project_name} into the *Valid OAuth Redirect URIs* field." +msgstr "" + +msgid "Paste the *Redirect URL* from {project_name} into the *Deauthorize Callback URL* field." +msgstr "" + +msgid "Paste the *Redirect URL* from {project_name} into the *Data Deletion Request URL* field." +msgstr "" + +msgid "Click *Show* in the *Instagram App Secret* field." +msgstr "" + +msgid "Note the *Instagram App ID* and the *Instagram App Secret*." +msgstr "" + +msgid "Click *App Review* - *Requests*." +msgstr "" + +msgid "Follow the instructions on the screen." +msgstr "" + +msgid "In {project_name}, paste the value of the `Instagram App ID` into the *Client ID* field." +msgstr "" + +msgid "In {project_name}, paste the value of the `Instagram App Secret` into the *Client Secret* field." +msgstr "" + +msgid "LinkedIn" +msgstr "" + +msgid "From the *Add provider* list, select *LinkedIn*." +msgstr "" + +msgid "image:images/linked-in-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "In a separate browser tab, https://developer.linkedin.com[create an app] in the LinkedIn developer portal." +msgstr "" + +msgid "After you create the app, click the *Auth* tab." +msgstr "" + +msgid "Enter the value of *Redirect URI* into the *Authorized redirect URLs for your app* field." +msgstr "" + +msgid "Note *Your Client ID* and *Your Client Secret*." +msgstr "" + +msgid "Click the *Products* tab and *Request access* for the *Sign In with LinkedIn using OpenID Connect* product." +msgstr "" + +msgid "In {project_name}, paste the value of the `Client Secret` into the *Client Secret* field." +msgstr "" + +msgid "Microsoft" +msgstr "" + +msgid "From the *Add provider* list, select *Microsoft*." +msgstr "" + +msgid "image:images/microsoft-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "In a separate browser tab, register an app on https://azure.microsoft.com/en-us/[Microsoft Azure] under *App registrations*." +msgstr "" + +msgid "In the Redirect URI section, select *Web* as a platform and paste the value of *Redirect URI* into the field." +msgstr "" + +msgid "Find you application under *App registrations* and add a new client secret in the *Certificates & secrets* section." +msgstr "" + +msgid "Note the *Value* of the created secret." +msgstr "" + +msgid "Note the *Application (client) ID* in the *Overview* section." +msgstr "" + +msgid "In {project_name}, paste the value of the `Application (client) ID` into the *Client ID* field." +msgstr "" + +msgid "In {project_name}, paste the `Value` of the secret into the *Client Secret* field." +msgstr "" + +msgid "OpenShift 3" +msgstr "" + +msgid "From the *Add provider* list, select *Openshift v3*." +msgstr "" + +msgid "image:images/openshift-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "Register your client using the `oc` command-line tool." +msgstr "" + +msgid "" +"$ oc create -f <(echo '\n" +"kind: OAuthClient\n" +"apiVersion: v1\n" +"metadata:\n" +" name: kc-client <1>\n" +"secret: \"...\" <2>\n" +"redirectURIs:\n" +" - \"http://www.example.com/\" <3>\n" +"grantMethod: prompt <4>\n" +"')" +msgstr "" + +msgid "The `name` of your OAuth client. Passed as `client_id` request parameter when making requests to `__/oauth/authorize` and `__/oauth/token`." +msgstr "" + +msgid "The `secret` {project_name} uses for the `client_secret` request parameter." +msgstr "" + +msgid "The `redirect_uri` parameter specified in requests to `__/oauth/authorize` and `__/oauth/token` must be equal to (or prefixed by) one of the URIs in `redirectURIs`. You can obtain this from the *Redirect URI* field in the Identity Provider screen" +msgstr "" + +msgid "The `grantMethod` {project_name} uses to determine the action when this client requests tokens but has not been granted access by the user." +msgstr "" + +msgid "In {project_name}, paste the value of the *Client ID* into the *Client ID* field." +msgstr "" + +msgid "In {project_name}, paste the value of the *Client Secret* into the *Client Secret* field." +msgstr "" + +msgid "OpenShift 4" +msgstr "" + +msgid "A certificate of the OpenShift 4 instance stored in the Keycloak Truststore." +msgstr "" + +msgid "A Keycloak server configured in order to use the truststore. For more information, see the https://www.keycloak.org/server/keycloak-truststore[Configuring a Truststore] {section}." +msgstr "" + +msgid "From the *Add provider* list, select *Openshift v4*." +msgstr "" + +msgid "Enter the *Client ID* and *Client Secret* and in the *Base URL* field, enter the API URL of your OpenShift 4 instance. Additionally, you can copy the *Redirect URI* to your clipboard." +msgstr "" + +msgid "image:images/openshift-4-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "Register your client, either via OpenShift 4 Console (Home -> API Explorer -> OAuth Client -> Instances) or using the `oc` command-line tool." +msgstr "" + +msgid "" +"$ oc create -f <(echo '\n" +"kind: OAuthClient\n" +"apiVersion: oauth.openshift.io/v1\n" +"metadata:\n" +" name: kc-client <1>\n" +"secret: \"...\" <2>\n" +"redirectURIs:\n" +" - \"\" <3>\n" +"grantMethod: prompt <4>\n" +"')" +msgstr "" + +msgid "The `name` of your OAuth client. Passed as `client_id` request parameter when making requests to `__/oauth/authorize` and `__/oauth/token`. The `name` parameter must be the same in the `OAuthClient` object and the {project_name} configuration." +msgstr "" + +msgid "The `secret` {project_name} uses as the `client_secret` request parameter." +msgstr "" + +msgid "The `redirect_uri` parameter specified in requests to `__/oauth/authorize` and `__/oauth/token` must be equal to (or prefixed by) one of the URIs in `redirectURIs`. The easiest way to configure it correctly is to copy-paste it from {project_name} OpenShift 4 Identity Provider configuration page (`Redirect URI` field)." +msgstr "" + +msgid "In the end you should see the OpenShift 4 Identity Provider on the login page of your {project_name} instance. After clicking on it, you should be redirected to the OpenShift 4 login page." +msgstr "" + +msgid "Result" +msgstr "" + +msgid "image:images/openshift-4-result.png[Result]" +msgstr "" + +msgid "See https://docs.okd.io/latest/authentication/configuring-oauth-clients.html#oauth-register-additional-client_configuring-oauth-clients[official OpenShift documentation] for more information." +msgstr "" + +msgid "PayPal" +msgstr "" + +msgid "From the *Add provider* list, select *PayPal*." +msgstr "" + +msgid "image:images/paypal-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "In a separate browser tab, open the https://developer.paypal.com/developer/applications[PayPal Developer applications area]." +msgstr "" + +msgid "Click *Create App* to create a PayPal app." +msgstr "" + +msgid "Note the *Client ID* and *Client Secret*. Click the *Show* link to view the secret." +msgstr "" + +msgid "Ensure *Log in with PayPal* is checked." +msgstr "" + +msgid "Under Log in with PayPal click on *Advanced Settings*." +msgstr "" + +msgid "Set the value of the *Return URL* field to the value of *Redirect URI* from {project_name}. Note that the URL can not contain `localhost`. If you want to use {project_name} locally, replace the `localhost` in the *Return URL* by `127.0.0.1` and then access {project_name} using `127.0.0.1` in the browser intead of `localhost`." +msgstr "" + +msgid "Ensure *Full Name* and *Email* fields are checked." +msgstr "" + +msgid "Click *Save* and then *Save Changes*." +msgstr "" + +msgid "In {project_name}, paste the value of the `Secret key 1` into the *Client Secret* field." +msgstr "" + +msgid "Stack overflow" +msgstr "" + +msgid "From the *Add provider* list, select *Stack Overflow*." +msgstr "" + +msgid "image:images/stack-overflow-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "In a separate browser tab, log into https://stackapps.com/apps/oauth/register[registering your application on Stack Apps]." +msgstr "" + +msgid "Register application" +msgstr "" + +msgid "image:images/stack-overflow-app-register.png[Register Application]" +msgstr "" + +msgid "Enter your application name into the *Application Name* field." +msgstr "" + +msgid "Enter the OAuth domain into the *OAuth Domain* field." +msgstr "" + +msgid "Click *Register Your Application*." +msgstr "" + +msgid "Settings" +msgstr "" + +msgid "image:images/stack-overflow-app-settings.png[Settings]" +msgstr "" + +msgid "Note the *Client Id*, *Client Secret*, and *Key*." +msgstr "" + +msgid "In {project_name}, paste the value of the `Client Id` into the *Client ID* field." +msgstr "" + +msgid "In {project_name}, paste the value of the `Key` into the *Key* field." +msgstr "" + +msgid "Twitter" +msgstr "" + +msgid "A Twitter developer account." +msgstr "" + +msgid "From the *Add provider* list, select *Twitter*." +msgstr "" + +msgid "image:images/twitter-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "In a separate browser tab, create an app in https://developer.twitter.com/apps/[Twitter Application Management]." +msgstr "" + +msgid "Enter App name and click *Next*." +msgstr "" + +msgid "Note the value of *API Key* and *API Key Secret* and click *App settings*." +msgstr "" + +msgid "In the *User authentication settings* section click on the *Set up* button." +msgstr "" + +msgid "Select *Web App* as the *Type of App*." +msgstr "" + +msgid "Paste the value of the *Redirect URL* into the *Callback URI / Redirect URL* field." +msgstr "" + +msgid "The value for *Website URL* can be any valid URL except `localhost`." +msgstr "" + +msgid "Click *Save* and then *Done*." +msgstr "" + +msgid "In {project_name}, paste the value of the `API Key` into the *Client ID* field." +msgstr "" + +msgid "In {project_name}, paste the value of the `API Key Secret` into the *Client Secret* field." +msgstr "" + +msgid "OpenID Connect v1.0 identity providers" +msgstr "" + +msgid "{project_name} brokers identity providers based on the OpenID Connect protocol. These identity providers (IDPs) must support the xref:con-oidc-auth-flows_{context}[Authorization Code Flow] defined in the specification to authenticate users and authorize access." +msgstr "" + +msgid "From the `Add provider` list, select `OpenID Connect v1.0`." +msgstr "" + +msgid "image:images/oidc-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "Enter your initial configuration options. See <<_general-idp-config, General IDP Configuration>> for more information about configuration options." +msgstr "" + +msgid "OpenID connect config" +msgstr "" + +msgid "Authorization URL" +msgstr "" + +msgid "The authorization URL endpoint the OIDC protocol requires." +msgstr "" + +msgid "Token URL" +msgstr "" + +msgid "The token URL endpoint the OIDC protocol requires." +msgstr "" + +msgid "Logout URL" +msgstr "" + +msgid "The logout URL endpoint in the OIDC protocol. This value is optional." +msgstr "" + +msgid "Backchannel Logout" +msgstr "" + +msgid "A background, out-of-band, REST request to the IDP to log out the user. Some IDPs perform logout through browser redirects only, as they may identify sessions using a browser cookie." +msgstr "" + +msgid "User Info URL" +msgstr "" + +msgid "An endpoint the OIDC protocol defines. This endpoint points to user profile information." +msgstr "" + +msgid "Client Authentication" +msgstr "" + +msgid "Defines the Client Authentication method {project_name} uses with the Authorization Code Flow. In the case of JWT signed with a private key, {project_name} uses the realm private key. In the other cases, define a client secret. See the https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication[Client Authentication specifications] for more information." +msgstr "" + +msgid "Client ID" +msgstr "" + +msgid "A realm acting as an OIDC client to the external IDP. The realm must have an OIDC client ID if you use the Authorization Code Flow to interact with the external IDP." +msgstr "" + +msgid "Client Secret" +msgstr "" + +msgid "Client secret from an external <<_vault-administration,vault>>. This secret is necessary if you are using the Authorization Code Flow." +msgstr "" + +msgid "Client Assertion Signature Algorithm" +msgstr "" + +msgid "" +"Signature algorithm to create JWT assertion as client authentication.\n" +"In the case of JWT signed with private key or Client secret as jwt, it is required. If no algorithm is specified, the following algorithm is adapted. `RS256` is adapted in the case of JWT signed with private key. `HS256` is adapted in the case of Client secret as jwt." +msgstr "" + +msgid "Client Assertion Audience" +msgstr "" + +msgid "The audience to use for the client assertion. The default value is the IDP's token endpoint URL." +msgstr "" + +msgid "Issuer" +msgstr "" + +msgid "{project_name} validates issuer claims, in responses from the IDP, against this value." +msgstr "" + +msgid "Default Scopes" +msgstr "" + +msgid "A list of OIDC scopes {project_name} sends with the authentication request. The default value is `openid`. A space separates each scope." +msgstr "" + +msgid "Prompt" +msgstr "" + +msgid "The prompt parameter in the OIDC specification. Through this parameter, you can force re-authentication and other options. See the specification for more details." +msgstr "" + +msgid "Accepts prompt=none forward from client" +msgstr "" + +msgid "" +"Specifies if the IDP accepts forwarded authentication requests containing the `prompt=none` query parameter. If a realm receives an auth request with `prompt=none`, the realm checks if the user is currently authenticated and returns a `login_required` error if the user has not logged in. When {project_name} determines a default IDP for the auth request (using the `kc_idp_hint` query parameter or having a default IDP for the realm), you can forward the auth request with `prompt=none` to the default IDP. The default IDP checks the authentication of the user there. Because not all IDPs support requests with `prompt=none`, {project_name} uses this switch to indicate that the default IDP supports the parameter before redirecting the authentication request.\n" +"\n" +"If the user is unauthenticated in the IDP, the client still receives a `login_required` error. If the user is authentic in the IDP, the client can still receive an `interaction_required` error if {project_name} must display authentication pages that require user interaction. This authentication includes required actions (for example, password change), consent screens, and screens set to display by the `first broker login` flow or `post broker login` flow." +msgstr "" + +msgid "Validate Signatures" +msgstr "" + +msgid "Specifies if {project_name} verifies signatures on the external ID Token signed by this IDP. If *ON*, {project_name} must know the public key of the external OIDC IDP. For performance purposes, {project_name} caches the public key of the external OIDC identity provider." +msgstr "" + +msgid "Use JWKS URL" +msgstr "" + +msgid "This switch is applicable if `Validate Signatures` is *ON*. If *Use JWKS URL* is *ON*, {project_name} downloads the IDP's public keys from the JWKS URL. New keys download when the identity provider generates a new keypair. If *OFF*, {project_name} uses the public key (or certificate) from its database, so when the IDP keypair changes, import the new key to the {project_name} database as well." +msgstr "" + +msgid "JWKS URL" +msgstr "" + +msgid "The URL pointing to the location of the IDP JWK keys. For more information, see the https://datatracker.ietf.org/doc/html/rfc7517[JWK specification]. If you use an external {project_name} as an IDP, you can use a URL such as http://broker-keycloak:8180{kc_realms_path}/test/protocol/openid-connect/certs if your brokered {project_name} is running on http://broker-keycloak:8180 and its realm is `test`." +msgstr "" + +msgid "Validating Public Key" +msgstr "" + +msgid "The public key in PEM format that {project_name} uses to verify external IDP signatures. This key applies if `Use JWKS URL` is *OFF*." +msgstr "" + +msgid "Validating Public Key Id" +msgstr "" + +msgid "This setting applies if *Use JWKS URL* is *OFF*. This setting specifies the ID of the public key in PEM format. Because there is no standard way for computing key ID from the key, external identity providers can use different algorithms from what {project_name} uses. If this field's value is not specified, {project_name} uses the validating public key for all requests, regardless of the key ID sent by the external IDP. When *ON*, this field's value is the key ID used by {project_name} for validating signatures from providers and must match the key ID specified by the IDP." +msgstr "" + +msgid "You can import all this configuration data by providing a URL or file that points to OpenID Provider Metadata. If you connect to a {project_name} external IDP, you can import the IDP settings from `{kc_realms_path}/{realm-name}/.well-known/openid-configuration`. This link is a JSON document describing metadata about the IDP." +msgstr "" + +msgid "If you want to use https://datatracker.ietf.org/doc/html/rfc7516[Json Web Encryption (JWE)] ID Tokens or UserInfo responses in the provider, the IDP needs to know the public key to use with {project_name}. The provider uses the <> defined for the different encryption algorithms to decrypt the tokens. {project_name} provides a standard xref:con-server-oidc-uri-endpoints_{context}[JWKS endpoint] which the IDP can use for downloading the keys automatically." +msgstr "" + +msgid "SAML v2.0 Identity Providers" +msgstr "" + +msgid "{project_name} can broker identity providers based on the SAML v2.0 protocol." +msgstr "" + +msgid "From the `Add provider` list, select `SAML v2.0`." +msgstr "" + +msgid "image:images/saml-add-identity-provider.png[Add Identity Provider]" +msgstr "" + +msgid "SAML Config" +msgstr "" + +msgid "Service Provider Entity ID" +msgstr "" + +msgid "The SAML Entity ID that the remote Identity Provider uses to identify requests from this Service Provider. By default, this setting is set to the realms base URL `{kc_realms_path}/{realm-name}`." +msgstr "" + +msgid "Identity Provider Entity ID" +msgstr "" + +msgid "The Entity ID used to validate the Issuer for received SAML assertions. If empty, no Issuer validation is performed." +msgstr "" + +msgid "Single Sign-On Service URL" +msgstr "" + +msgid "The SAML endpoint that starts the authentication process. If your SAML IDP publishes an IDP entity descriptor, the value of this field is specified there." +msgstr "" + +msgid "Single Logout Service URL" +msgstr "" + +msgid "The SAML logout endpoint. If your SAML IDP publishes an IDP entity descriptor, the value of this field is specified there." +msgstr "" + +msgid "Toggle this switch to *ON* if your SAML IDP supports back channel logout." +msgstr "" + +msgid "NameID Policy Format" +msgstr "" + +msgid "The URI reference corresponding to a name identifier format. By default, {project_name} sets it to `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`." +msgstr "" + +msgid "Principal Type" +msgstr "" + +msgid "Specifies which part of the SAML assertion will be used to identify and track external user identities. Can be either Subject NameID or SAML attribute (either by name or by friendly name). Subject NameID value can not be set together with 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' NameID Policy Format value." +msgstr "" + +msgid "Principal Attribute" +msgstr "" + +msgid "If a Principal type is non-blank, this field specifies the name (\"Attribute [Name]\") or the friendly name (\"Attribute [Friendly Name]\") of the identifying attribute." +msgstr "" + +msgid "Allow create" +msgstr "" + +msgid "Allow the external identity provider to create a new identifier to represent the principal." +msgstr "" + +msgid "HTTP-POST Binding Response" +msgstr "" + +msgid "Controls the SAML binding in response to any SAML requests sent by an external IDP. When *OFF*, {project_name} uses Redirect Binding." +msgstr "" + +msgid "HTTP-POST Binding for AuthnRequest" +msgstr "" + +msgid "Controls the SAML binding when requesting authentication from an external IDP. When *OFF*, {project_name} uses Redirect Binding." +msgstr "" + +msgid "Want AuthnRequests Signed" +msgstr "" + +msgid "When *ON*, {project_name} uses the realm's keypair to sign requests sent to the external SAML IDP." +msgstr "" + +msgid "Want Assertions Signed" +msgstr "" + +msgid "Indicates whether this service provider expects a signed Assertion." +msgstr "" + +msgid "Want Assertions Encrypted" +msgstr "" + +msgid "Indicates whether this service provider expects an encrypted Assertion." +msgstr "" + +msgid "Signature Algorithm" +msgstr "" + +msgid "" +"If *Want AuthnRequests Signed* is *ON*, the signature algorithm to use. Note that `SHA1` based algorithms are deprecated and may be removed in a future release.\n" +"We recommend to use some more secure algorithm instead of `*_SHA1`. Also, with `*_SHA1` algorithms, verifying signatures\n" +"do not work if the SAML identity provider (for example another instance of {project_name}) runs on Java 17 or higher." +msgstr "" + +msgid "Encryption Algorithm" +msgstr "" + +msgid "" +"Encryption algorithm, which is used by SAML IDP for encryption of SAML\n" +"documents, assertions, or IDs. The corresponding decryption key for decrypt\n" +"SAML document parts will be chosen based on this configured algorithm and\n" +"should be available in realm keys for the encryption (ENC) usage. If the\n" +"algorithm is not configured, any supported algorithm is allowed and a\n" +"decryption key will be chosen based on the algorithm specified in SAML document\n" +"itself." +msgstr "" + +msgid "SAML Signature Key Name" +msgstr "" + +msgid "" +"Signed SAML documents sent using POST binding contain the identification of signing key in `KeyName` element, which, by default, contains the {project_name} key ID. External SAML IDPs can expect a different key name. This switch controls whether `KeyName` contains:\n" +"* `KEY_ID` - Key ID.\n" +"* `CERT_SUBJECT` - the subject from the certificate corresponding to the realm key. Microsoft Active Directory Federation Services expect `CERT_SUBJECT`.\n" +"* `NONE` - {project_name} omits the key name hint from the SAML message." +msgstr "" + +msgid "Force Authentication" +msgstr "" + +msgid "The user must enter their credentials at the external IDP even when the user is already logged in." +msgstr "" + +msgid "Validate Signature" +msgstr "" + +msgid "When *ON*, the realm expects SAML requests and responses from the external IDP to be digitally signed." +msgstr "" + +msgid "Validating X509 Certificate" +msgstr "" + +msgid "The public certificate {project_name} uses to validate the signatures of SAML requests and responses from the external IDP." +msgstr "" + +msgid "Sign Service Provider Metadata" +msgstr "" + +msgid "When *ON*, {project_name} uses the realm's key pair to sign the <<_identity_broker_saml_sp_descriptor, SAML Service Provider Metadata descriptor>>." +msgstr "" + +msgid "Pass subject" +msgstr "" + +msgid "Controls if {project_name} forwards a `login_hint` query parameter to the IDP. {project_name} adds this field's value to the login_hint parameter in the AuthnRequest's Subject so destination providers can pre-fill their login form." +msgstr "" + +msgid "Attribute Consuming Service Index" +msgstr "" + +msgid "Identifies the attribute set to request to the remote IDP. {project_name} automatically adds the attributes mapped in the identity provider configuration to the autogenerated SP metadata document." +msgstr "" + +msgid "Attribute Consuming Service Name" +msgstr "" + +msgid "A descriptive name for the set of attributes that are advertised in the autogenerated SP metadata document." +msgstr "" + +msgid "You can import all configuration data by providing a URL or a file pointing to the SAML IDP entity descriptor of the external IDP. If you are connecting to a {project_name} external IDP, you can import the IDP settings from the URL `{kc_realms_path}/{realm-name}/protocol/saml/descriptor`. This link is an XML document describing metadata about the IDP. You can also import all this configuration data by providing a URL or XML file pointing to the external SAML IDP's entity descriptor to connect to." +msgstr "" + +msgid "Requesting specific AuthnContexts" +msgstr "" + +msgid "Identity Providers facilitate clients specifying constraints on the authentication method verifying the user identity. For example, asking for MFA, Kerberos authentication, or security requirements. These constraints use particular AuthnContext criteria. A client can ask for one or more criteria and specify how the Identity Provider must match the requested AuthnContext, exactly, or by satisfying other equivalents." +msgstr "" + +msgid "You can list the criteria your Service Provider requires by adding ClassRefs or DeclRefs in the Requested AuthnContext Constraints section. Usually, you need to provide either ClassRefs or DeclRefs, so check with your Identity Provider documentation which values are supported. If no ClassRefs or DeclRefs are present, the Identity Provider does not enforce additional constraints." +msgstr "" + +msgid "Requested AuthnContext Constraints" +msgstr "" + +msgid "Comparison" +msgstr "" + +msgid "The method the Identity Provider uses to evaluate the context requirements. The available values are `Exact`, `Minimum`, `Maximum`, or `Better`. The default value is `Exact`." +msgstr "" + +msgid "AuthnContext ClassRefs" +msgstr "" + +msgid "The AuthnContext ClassRefs describing the required criteria." +msgstr "" + +msgid "AuthnContext DeclRefs" +msgstr "" + +msgid "The AuthnContext DeclRefs describing the required criteria." +msgstr "" + +msgid "SP Descriptor" +msgstr "" + +msgid "When you access the provider's SAML SP metadata, look for the `Endpoints` item in the identity provider configuration settings. It contains a `SAML 2.0 Service Provider Metadata` link which generates the SAML entity descriptor for the Service Provider. You can download the descriptor or copy its URL and then import it into the remote Identity Provider." +msgstr "" + +msgid "This metadata is also available publicly by going to the following URL:" +msgstr "" + +msgid "http[s]://{host:port}{kc_realms_path}/{realm-name}/broker/{broker-alias}/endpoint/descriptor" +msgstr "" + +msgid "Ensure you save any configuration changes before accessing the descriptor." +msgstr "" + +msgid "Send subject in SAML requests" +msgstr "" + +msgid "By default, a social button pointing to a SAML Identity Provider redirects the user to the following login URL:" +msgstr "" + +msgid "http[s]://{host:port}{kc_realms_path}/${realm-name}/broker/{broker-alias}/login" +msgstr "" + +msgid "Adding a query parameter named `login_hint` to this URL adds the parameter's value to SAML request as a Subject attribute. If this query parameter is empty, {project_name} does not add a subject to the request." +msgstr "" + +msgid "Enable the \"Pass subject\" option to send the subject in SAML requests." +msgstr "" + +msgid "Client-suggested Identity Provider" +msgstr "" + +msgid "OIDC applications can bypass the {project_name} login page by hinting at the identity provider they want to use. You can enable this by setting the `kc_idp_hint` query parameter in the Authorization Code Flow authorization endpoint." +msgstr "" + +msgid "With {project_name} OIDC client adapters, you can specify this query parameter when you access a secured resource in the application." +msgstr "" + +msgid "" +"GET /myapplication.com?kc_idp_hint=facebook HTTP/1.1\n" +"Host: localhost:8080" +msgstr "" + +msgid "In this case, your realm must have an identity provider with a `facebook` alias. If this provider does not exist, the login form is displayed." +msgstr "" + +msgid "If you are using the `keycloak.js` adapter, you can also achieve the same behavior as follows:" +msgstr "" + +msgid "" +"const keycloak = new Keycloak('keycloak.json');\n" +"\n" +"keycloak.createLoginUrl({\n" +"\tidpHint: 'facebook'\n" +"});" +msgstr "" + +msgid "With the `kc_idp_hint` query parameter, the client can override the default identity provider if you configure one for the `Identity Provider Redirector` authenticator. The client can disable the automatic redirecting by setting the `kc_idp_hint` query parameter to an empty value." +msgstr "" + +msgid "Mapping claims and assertions" +msgstr "" + +msgid "You can import the SAML and OpenID Connect metadata, provided by the external IDP you are authenticating with, into the realm. After importing, you can extract user profile metadata and other information, so you can make it available to your applications." +msgstr "" + +msgid "Each user logging into your realm using an external identity provider has an entry in the local {project_name} database, based on the metadata from the SAML or OIDC assertions and claims." +msgstr "" + +msgid "Select one of the identity providers in the list." +msgstr "" + +msgid "Click the *Mappers* tab." +msgstr "" + +msgid "Identity provider mappers" +msgstr "" + +msgid "image:images/identity-provider-mappers.png[identity provider mappers]" +msgstr "" + +msgid "Click *Add mapper*." +msgstr "" + +msgid "Identity provider mapper" +msgstr "" + +msgid "image:images/identity-provider-mapper.png[identity provider mapper]" +msgstr "" + +msgid "Select a value for *Sync Mode Override*. The mapper updates user information when users log in repeatedly according to this setting." +msgstr "" + +msgid "Select *legacy* to use the behavior of the previous {project_name} version." +msgstr "" + +msgid "Select *import* to import data from when the user was first created in {project_name} during the first login to {project_name} with a particular identity provider." +msgstr "" + +msgid "Select *force* to update user data at each user login." +msgstr "" + +msgid "Select *inherit* to use the sync mode configured in the identity provider. All other options will override this sync mode." +msgstr "" + +msgid "Select a mapper from the *Mapper Type* list. Hover over the *Mapper Type* for a description of the mapper and configuration to enter for the mapper." +msgstr "" + +msgid "For JSON-based claims, you can use dot notation for nesting and square brackets to access array fields by index. For example, `contact.address[0].country`." +msgstr "" + +msgid "To investigate the structure of user profile JSON data provided by social providers, you can enable the `DEBUG` level logger `org.keycloak.social.user_profile_dump` when starting the server." +msgstr "" + +msgid "Available user session data" +msgstr "" + +msgid "After a user login from an external IDP, {project_name} stores user session note data that you can access. This data can be propagated to the client requesting log in using the token or SAML assertion passed back to the client using an appropriate client mapper." +msgstr "" + +msgid "identity_provider" +msgstr "" + +msgid "The IDP alias of the broker used to perform the login." +msgstr "" + +msgid "identity_provider_identity" +msgstr "" + +msgid "The IDP username of the currently authenticated user. Often, but not always, the same as the {project_name} username. For example, {project_name} can link a user john` to a Facebook user `john123@gmail.com`. In that case, the value of the user session note is `john123@gmail.com`." +msgstr "" + +msgid "You can use a <<_protocol-mappers, Protocol Mapper>> of type `User Session Note` to propagate this information to your clients." +msgstr "" + +msgid "First login flow" +msgstr "" + +msgid "When users log in through identity brokering, {project_name} imports and links aspects of the user within the realm's local database. When {project_name} successfully authenticates users through an external identity provider, two situations can exist:" +msgstr "" + +msgid "{project_name} has already imported and linked a user account with the authenticated identity provider account. In this case, {project_name} authenticates as the existing user and redirects back to the application." +msgstr "" + +msgid "No account exists for this user in {project_name}. Usually, you register and import a new account into the {project_name} database, but there may be an existing {project_name} account with the same email address. Automatically linking the existing local account to the external identity provider is a potential security hole. You cannot always trust the information you get from the external identity provider." +msgstr "" + +msgid "Different organizations have different requirements when dealing with some of these situations. With {project_name}, you can use the `First Login Flow` option in the IDP settings to choose a <<_authentication-flows, workflow>> for a user logging in from an external IDP for the first time. By default, the `First Login Flow` option points to the `first broker login` flow, but you can use your flow or different flows for different identity providers." +msgstr "" + +msgid "The flow is in the Admin Console under the *Authentication* tab. When you choose the `First Broker Login` flow, you see the authenticators used by default. You can re-configure the existing flow. For example, you can disable some authenticators, mark some of them as `required`, or configure some authenticators." +msgstr "" + +msgid "You can also create a new authentication flow, write your own Authenticator implementations, and use it in your flow. See link:{developerguide_link}[{developerguide_name}] for more information." +msgstr "" + +msgid "Default first login flow authenticators" +msgstr "" + +msgid "Review Profile" +msgstr "" + +msgid "This authenticator displays the profile information page, so the users can review their profile that {project_name} retrieves from an identity provider." +msgstr "" + +msgid "You can set the `Update Profile On First Login` option in the *Actions* menu." +msgstr "" + +msgid "When *ON*, users are presented with the profile page requesting additional information to federate the user's identities." +msgstr "" + +msgid "When *missing*, users are presented with the profile page if the identity provider does not provide mandatory information, such as email, first name, or last name." +msgstr "" + +msgid "When *OFF*, the profile page does not display unless the user clicks in a later phase on the `Review profile info` link in the page displayed by the `Confirm Link Existing Account` authenticator." +msgstr "" + +msgid "Create User If Unique" +msgstr "" + +msgid "This authenticator checks if there is already an existing {project_name} account with the same email or username like the account from the identity provider. If it's not, then the authenticator just creates a new local {project_name} account and links it with the identity provider and the whole flow is finished. Otherwise it goes to the next `Handle Existing Account` subflow. If you always want to ensure that there is no duplicated account, you can mark this authenticator as `REQUIRED`. In this case, the user will see the error page if there is an existing {project_name} account and the user will need to link the identity provider account through Account management." +msgstr "" + +msgid "This authenticator verifies that there is already a {project_name} account with the same email or username as the identity provider's account." +msgstr "" + +msgid "If an account does not exist, the authenticator creates a local {project_name} account, links this account with the identity provider, and terminates the flow." +msgstr "" + +msgid "If an account exists, the authenticator implements the next `Handle Existing Account` sub-flow." +msgstr "" + +msgid "To ensure there is no duplicated account, you can mark this authenticator as `REQUIRED`. The user sees the error page if a {project_name} account exists, and users must link their identity provider account through Account management." +msgstr "" + +msgid "Confirm Link Existing Account" +msgstr "" + +msgid "On the information page, users see a {project_name} account with the same email. Users can review their profile again and use a different email or username. The flow restarts and goes back to the `Review Profile` authenticator." +msgstr "" + +msgid "Alternatively, users can confirm that they want to link their identity provider account with their existing {project_name} account." +msgstr "" + +msgid "Disable this authenticator if you do not want users to see this confirmation page and go straight to linking identity provider account by email verification or re-authentication." +msgstr "" + +msgid "Verify Existing Account By Email" +msgstr "" + +msgid "This authenticator is `ALTERNATIVE` by default. {project_name} uses this authenticator if the realm has an SMTP setup configured." +msgstr "" + +msgid "The authenticator sends an email to users to confirm that they want to link the identity provider with their {project_name} account." +msgstr "" + +msgid "Disable this authenticator if you do not want to confirm linking by email, but want users to reauthenticate with their password." +msgstr "" + +msgid "Verify Existing Account By Re-authentication" +msgstr "" + +msgid "Use this authenticator if the email authenticator is not available. For example, you have not configured SMTP for your realm. This authenticator displays a login screen for users to authenticate to link their {project_name} account with the Identity Provider." +msgstr "" + +msgid "Users can also re-authenticate with another identity provider already linked to their {project_name} account." +msgstr "" + +msgid "You can force users to use OTP. Otherwise, it is optional and used if you have set OTP for the user account." +msgstr "" + +msgid "Automatically link existing first login flow" +msgstr "" + +msgid "The AutoLink authenticator is dangerous in a generic environment where users can register themselves using arbitrary usernames or email addresses. Do not use this authenticator unless you are carefully curating user registration and assigning usernames and email addresses." +msgstr "" + +msgid "To configure a first login flow that links users automatically without prompting, create a new flow with the following two authenticators:" +msgstr "" + +msgid "This authenticator ensures {project_name} handles unique users. Set the authenticator requirement to *Alternative*." +msgstr "" + +msgid "Automatically Set Existing User" +msgstr "" + +msgid "This authenticator sets an existing user to the authentication context without verification. Set the authenticator requirement to \"Alternative\"." +msgstr "" + +msgid "This setup is the simplest setup available, but it is possible to use other authenticators. For example: * You can add the Review Profile authenticator to the beginning of the flow if you want end users to confirm their profile information. * You can add authentication mechanisms to this flow, forcing a user to verify their credentials. Adding authentication mechanisms requires a complex flow. For example, you can set the \"Automatically Set Existing User\" and \"Password Form\" as \"Required\" in an \"Alternative\" sub-flow." +msgstr "" + +msgid "Disabling automatic user creation" +msgstr "" + +msgid "The Default first login flow looks up the {project_name} account matching the external identity and offers to link them. If no matching {project_name} account exists, the flow automatically creates one." +msgstr "" + +msgid "This default behavior may be unsuitable for some setups. One example is when you use a read-only LDAP user store, where all users are pre-created. In this case, you must switch off automatic user creation." +msgstr "" + +msgid "To disable user creation:" +msgstr "" + +msgid "Select *First Broker Login* from the list." +msgstr "" + +msgid "Set *Create User If Unique* to *DISABLED*." +msgstr "" + +msgid "Set *Confirm Link Existing Account* to *DISABLED*." +msgstr "" + +msgid "This configuration also implies that {project_name} itself won't be able to determine which internal account would correspond to the external identity. Therefore, the `Verify Existing Account By Re-authentication` authenticator will ask the user to provide both username and password." +msgstr "" + +msgid "Enabling or disabling user creation by identity provider is completely independent on the realm <>. You can have enabled user-creation by identity provider and at the same time disabled user self-registration in the realm login settings or vice-versa." +msgstr "" + +msgid "Detect existing user first login flow" +msgstr "" + +msgid "In order to configure a first login flow in which:" +msgstr "" + +msgid "only users already registered in this realm can log in," +msgstr "" + +msgid "users are automatically linked without being prompted," +msgstr "" + +msgid "create a new flow with the following two authenticators:" +msgstr "" + +msgid "Detect Existing Broker User" +msgstr "" + +msgid "This authenticator ensures that unique users are handled. Set the authenticator requirement to `REQUIRED`." +msgstr "" + +msgid "Automatically sets an existing user to the authentication context without any verification. Set the authenticator requirement to `REQUIRED`." +msgstr "" + +msgid "You have to set the `First Login Flow` of the identity provider configuration to that flow. You could set the also set `Sync Mode` to `force` if you want to update the user profile (Last Name, First Name...) with the identity provider attributes." +msgstr "" + +msgid "This flow can be used if you want to delegate the identity to other identity providers (such as GitHub, Facebook ...) but you want to manage which users that can log in." +msgstr "" + +msgid "With this configuration, {project_name} is unable to determine which internal account corresponds to the external identity. The *Verify Existing Account By Re-authentication* authenticator asks the provider for the username and password." +msgstr "" + +msgid "Retrieving external IDP tokens" +msgstr "" + +msgid "With {project_name}, you can store tokens and responses from the authentication process with the external IDP using the `Store Token` configuration option on the IDP's settings page." +msgstr "" + +msgid "Application code can retrieve these tokens and responses to import extra user information or to request the external IDP securely. For example, an application can use the Google token to use other Google services and REST APIs. To retrieve a token for a particular identity provider, send a request as follows:" +msgstr "" + +msgid "" +"GET {kc_realms_path}/{realm}/broker/{provider_alias}/token HTTP/1.1\n" +"Host: localhost:8080\n" +"Authorization: Bearer " +msgstr "" + +msgid "An application must authenticate with {project_name} and receive an access token. This access token must have the `broker` client-level role `read-token` set, so the user must have a role mapping for this role, and the client application must have that role within its scope. In this case, since you are accessing a protected service in {project_name}, send the access token issued by {project_name} during the user authentication. You can assign this role to newly imported users in the broker configuration page by setting the *Stored Tokens Readable* switch to *ON*." +msgstr "" + +msgid "These external tokens can be re-established by logging in again through the provider or using the client-initiated account linking API." +msgstr "" + +msgid "Identity broker logout" +msgstr "" + +msgid "When logging out, {project_name} sends a request to the external identity provider that is used to log in initially and logs the user out of this identity provider. You can skip this behavior and avoid logging out of the external identity provider. See link:{adapterguide_logout_link}[adapter logout documentation] for more information." +msgstr "" + +msgid "SSO protocols" +msgstr "" + +msgid "This section discusses authentication protocols, the {project_name} authentication server and how applications, secured by the {project_name} authentication server, interact with these protocols." +msgstr "" + +msgid "OpenID Connect" +msgstr "" + +msgid "link:https://openid.net/developers/how-connect-works/[OpenID Connect] (OIDC) is an authentication protocol that is an extension of link:https://datatracker.ietf.org/doc/html/rfc6749[OAuth 2.0]." +msgstr "" + +msgid "OAuth 2.0 is a framework for building authorization protocols and is incomplete. OIDC, however, is a full authentication and authorization protocol that uses the link:https://jwt.io[Json Web Token] (JWT) standards. The JWT standards define an identity token JSON format and methods to digitally sign and encrypt data in a compact and web-friendly way." +msgstr "" + +msgid "In general, OIDC implements two use cases. The first case is an application requesting that a {project_name} server authenticates a user. Upon successful login, the application receives an _identity token_ and an _access token_. The _identity token_ contains user information including user name, email, and profile information. The realm digitally signs the _access token_ which contains access information (such as user role mappings) that applications use to determine the resources users can access in the application." +msgstr "" + +msgid "The second use case is a client accessing remote services." +msgstr "" + +msgid "The client requests an _access token_ from {project_name} to invoke on remote services on behalf of the user." +msgstr "" + +msgid "{project_name} authenticates the user and asks the user for consent to grant access to the requesting client." +msgstr "" + +msgid "The client receives the _access token_ which is digitally signed by the realm." +msgstr "" + +msgid "The client makes REST requests on remote services using the _access token_." +msgstr "" + +msgid "The remote REST service extracts the _access token_." +msgstr "" + +msgid "The remote REST service verifies the tokens signature." +msgstr "" + +msgid "The remote REST service decides, based on access information within the token, to process or reject the request." +msgstr "" + +msgid "OIDC auth flows" +msgstr "" + +msgid "OIDC has several methods, or flows, that clients or applications can use to authenticate users and receive _identity_ and _access_ tokens. The method depends on the type of application or client requesting access." +msgstr "" + +msgid "Authorization Code Flow" +msgstr "" + +msgid "The Authorization Code Flow is a browser-based protocol and suits authenticating and authorizing browser-based applications. It uses browser redirects to obtain _identity_ and _access_ tokens." +msgstr "" + +msgid "A user connects to an application using a browser. The application detects the user is not logged into the application." +msgstr "" + +msgid "The application redirects the browser to {project_name} for authentication." +msgstr "" + +msgid "The application passes a callback URL as a query parameter in the browser redirect. {project_name} uses the parameter upon successful authentication." +msgstr "" + +msgid "{project_name} authenticates the user and creates a one-time, short-lived, temporary code." +msgstr "" + +msgid "{project_name} redirects to the application using the callback URL and adds the temporary code as a query parameter in the callback URL." +msgstr "" + +msgid "The application extracts the temporary code and makes a background REST invocation to {project_name} to exchange the code for an _identity_ and _access_ and _refresh_ token. To prevent replay attacks, the temporary code cannot be used more than once." +msgstr "" + +msgid "A system is vulnerable to a stolen token for the lifetime of that token. For security and scalability reasons, access tokens are generally set to expire quickly so subsequent token requests fail. If a token expires, an application can obtain a new access token using the additional _refresh_ token sent by the login protocol." +msgstr "" + +msgid "_Confidential_ clients provide client secrets when they exchange the temporary codes for tokens. _Public_ clients are not required to provide client secrets. _Public_ clients are secure when HTTPS is strictly enforced and redirect URIs registered for the client are strictly controlled. HTML5/JavaScript clients have to be _public_ clients because there is no way to securely transmit the client secret to HTML5/JavaScript clients. For more details, see the xref:assembly-managing-clients_{context}[Managing Clients] chapter." +msgstr "" + +msgid "{project_name} also supports the https://datatracker.ietf.org/doc/html/rfc7636[Proof Key for Code Exchange] specification." +msgstr "" + +msgid "Implicit Flow" +msgstr "" + +msgid "The Implicit Flow is a browser-based protocol. It is similar to the Authorization Code Flow but with fewer requests and no refresh tokens." +msgstr "" + +msgid "The possibility exists of _access_ tokens leaking in the browser history when tokens are transmitted via redirect URIs (see below)." +msgstr "" + +msgid "Also, this flow does not provide clients with refresh tokens. Therefore, access tokens have to be long-lived or users have to re-authenticate when they expire." +msgstr "" + +msgid "We do not advise using this flow. This flow is supported because it is in the OIDC and OAuth 2.0 specification." +msgstr "" + +msgid "The protocol works as follows:" +msgstr "" + +msgid "The application passes a callback URL as a query parameter in the browser redirect. {project_name} uses the query parameter upon successful authentication." +msgstr "" + +msgid "{project_name} authenticates the user and creates an _identity_ and _access_ token. {project_name} redirects to the application using the callback URL and additionally adds the _identity_ and _access_ tokens as a query parameter in the callback URL." +msgstr "" + +msgid "The application extracts the _identity_ and _access_ tokens from the callback URL." +msgstr "" + +msgid "Resource owner password credentials grant (Direct Access Grants)" +msgstr "" + +msgid "_Direct Access Grants_ are used by REST clients to obtain tokens on behalf of users. It is a HTTP POST request that contains:" +msgstr "" + +msgid "The credentials of the user. The credentials are sent within form parameters." +msgstr "" + +msgid "The id of the client." +msgstr "" + +msgid "The clients secret (if it is a confidential client)." +msgstr "" + +msgid "The HTTP response contains the _identity_, _access_, and _refresh_ tokens." +msgstr "" + +msgid "Client credentials grant" +msgstr "" + +msgid "The _Client Credentials Grant_ creates a token based on the metadata and permissions of a service account associated with the client instead of obtaining a token that works on behalf of an external user. _Client Credentials Grants_ are used by REST clients." +msgstr "" + +msgid "See the <<_service_accounts,Service Accounts>> chapter for more information." +msgstr "" + +msgid "Device authorization grant" +msgstr "" + +msgid "This is used by clients running on internet-connected devices that have limited input capabilities or lack a suitable browser. Here's a brief summary of the protocol:" +msgstr "" + +msgid "The application requests {project_name} a device code and a user code. {project_name} creates a device code and a user code. {project_name} returns a response including the device code and the user code to the application." +msgstr "" + +msgid "The application provides the user with the user code and the verification URI. The user accesses a verification URI to be authenticated by using another browser. You could define a short verification_uri that will be redirected to Keycloak verification URI (/realms/realm_name/device)outside Keycloak - fe in a proxy." +msgstr "" + +msgid "The application repeatedly polls {project_name} to find out if the user completed the user authorization. If user authentication is complete, the application exchanges the device code for an _identity_, _access_ and _refresh_ token." +msgstr "" + +msgid "Client initiated backchannel authentication grant" +msgstr "" + +msgid "This feature is used by clients who want to initiate the authentication flow by communicating with the OpenID Provider directly without redirect through the user's browser like OAuth 2.0's authorization code grant. Here's a brief summary of the protocol:" +msgstr "" + +msgid "The client requests {project_name} an auth_req_id that identifies the authentication request made by the client. {project_name} creates the auth_req_id." +msgstr "" + +msgid "After receiving this auth_req_id, this client repeatedly needs to poll {project_name} to obtain an Access Token, Refresh Token and ID Token from {project_name} in return for the auth_req_id until the user is authenticated." +msgstr "" + +msgid "An administrator can configure Client Initiated Backchannel Authentication (CIBA) related operations as `CIBA Policy` per realm." +msgstr "" + +msgid "Also please refer to other places of {project_name} documentation like link:{adapterguide_link}#_backchannel_authentication_endpoint[Backchannel Authentication Endpoint section] of {adapterguide_name} and link:{adapterguide_link}#_client_initiated_backchannel_authentication_grant[Client Initiated Backchannel Authentication Grant section] of {adapterguide_name}." +msgstr "" + +msgid "CIBA Policy" +msgstr "" + +msgid "An administrator carries out the following operations on the `Admin Console` :" +msgstr "" + +msgid "Open the `Authentication -> CIBA Policy` tab." +msgstr "" + +msgid "Configure items and click `Save`." +msgstr "" + +msgid "The configurable items and their description follow." +msgstr "" + +msgid "Backchannel Token Delivery Mode" +msgstr "" + +msgid "" +"Specifying how the CD (Consumption Device) gets the authentication result and related tokens. There are three modes, \"poll\", \"ping\" and \"push\". {project_name} only supports \"poll\". The default setting is \"poll\". This configuration is required.\n" +" For more details, see https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.5[CIBA Specification]." +msgstr "" + +msgid "Expires In" +msgstr "" + +msgid "" +"The expiration time of the \"auth_req_id\" in seconds since the authentication request was received. The default setting is 120. This configuration is required.\n" +" For more details, see https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#successful_authentication_request_acknowdlegment[CIBA Specification]." +msgstr "" + +msgid "Interval" +msgstr "" + +msgid "" +"The interval in seconds the CD (Consumption Device) needs to wait for between polling requests to the token endpoint. The default setting is 5. This configuration is optional.\n" +" For more details, see https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#successful_authentication_request_acknowdlegment[CIBA Specification]." +msgstr "" + +msgid "Authentication Requested User Hint" +msgstr "" + +msgid "" +"The way of identifying the end-user for whom authentication is being requested. The default setting is \"login_hint\". There are three modes, \"login_hint\", \"login_hint_token\" and \"id_token_hint\". {project_name} only supports \"login_hint\". This configuration is required.\n" +" For more details, see https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.1[CIBA Specification]." +msgstr "" + +msgid "Provider Setting" +msgstr "" + +msgid "The CIBA grant uses the following two providers." +msgstr "" + +msgid "Authentication Channel Provider : provides the communication between {project_name} and the entity that actually authenticates the user via AD (Authentication Device)." +msgstr "" + +msgid "User Resolver Provider : get `UserModel` of {project_name} from the information provided by the client to identify the user." +msgstr "" + +msgid "{project_name} has both default providers. However, the administrator needs to set up Authentication Channel Provider like this:" +msgstr "" + +msgid "kc.[sh|bat] start --spi-ciba-auth-channel-ciba-http-auth-channel-http-authentication-channel-uri=https://backend.internal.example.com{kc_base_path}" +msgstr "" + +msgid "http-authentication-channel-uri" +msgstr "" + +msgid "Specifying URI of the entity that actually authenticates the user via AD (Authentication Device)." +msgstr "" + +msgid "Authentication Channel Provider" +msgstr "" + +msgid "CIBA standard document does not specify how to authenticate the user by AD. Therefore, it might be implemented at the discretion of products. {project_name} delegates this authentication to an external authentication entity. To communicate with the authentication entity, {project_name} provides Authentication Channel Provider." +msgstr "" + +msgid "Its implementation of {project_name} assumes that the authentication entity is under the control of the administrator of {project_name} so that {project_name} trusts the authentication entity. It is not recommended to use the authentication entity that the administrator of {project_name} cannot control." +msgstr "" + +msgid "Authentication Channel Provider is provided as SPI provider so that users of {project_name} can implement their own provider in order to meet their environment. {project_name} provides its default provider called HTTP Authentication Channel Provider that uses HTTP to communicate with the authentication entity." +msgstr "" + +msgid "If a user of {project_name} user want to use the HTTP Authentication Channel Provider, they need to know its contract between {project_name} and the authentication entity consisting of the following two parts." +msgstr "" + +msgid "Authentication Delegation Request/Response" +msgstr "" + +msgid "{project_name} sends an authentication request to the authentication entity." +msgstr "" + +msgid "Authentication Result Notification/ACK" +msgstr "" + +msgid "The authentication entity notifies the result of the authentication to {project_name}." +msgstr "" + +msgid "Authentication Delegation Request/Response consists of the following messaging." +msgstr "" + +msgid "Authentication Delegation Request" +msgstr "" + +msgid "The request is sent from {project_name} to the authentication entity to ask it for user authentication by AD." +msgstr "" + +msgid "POST [delegation_reception]" +msgstr "" + +msgid "Headers" +msgstr "" + +msgid "Value" +msgstr "" + +msgid "Content-Type" +msgstr "" + +msgid "application/json" +msgstr "" + +msgid "The message body is json formatted." +msgstr "" + +msgid "Authorization" +msgstr "" + +msgid "Bearer [token]" +msgstr "" + +msgid "The [token] is used when the authentication entity notifies the result of the authentication to {project_name}." +msgstr "" + +msgid "Parameters" +msgstr "" + +msgid "Path" +msgstr "" + +msgid "delegation_reception" +msgstr "" + +msgid "The endpoint provided by the authentication entity to receive the delegation request" +msgstr "" + +msgid "Body" +msgstr "" + +msgid "login_hint" +msgstr "" + +msgid "" +"It tells the authentication entity who is authenticated by AD. +\n" +"By default, it is the user's \"username\". +\n" +"This field is required and was defined by CIBA standard document." +msgstr "" + +msgid "scope" +msgstr "" + +msgid "" +"It tells which scopes the authentication entity gets consent from the authenticated user. +\n" +"This field is required and was defined by CIBA standard document." +msgstr "" + +msgid "is_consent_required" +msgstr "" + +msgid "" +"It shows whether the authentication entity needs to get consent from the authenticated user about the scope. +\n" +" This field is required." +msgstr "" + +msgid "binding_message" +msgstr "" + +msgid "" +"Its value is intended to be shown in both CD and AD's UI to make the user recognize that the authentication by AD is triggered by CD. +\n" +"This field is optional and was defined by CIBA standard document." +msgstr "" + +msgid "acr_values" +msgstr "" + +msgid "" +"It tells the requesting Authentication Context Class Reference from CD. +\n" +"This field is optional and was defined by CIBA standard document." +msgstr "" + +msgid "Authentication Delegation Response" +msgstr "" + +msgid "The response is returned from the authentication entity to {project_name} to notify that the authentication entity received the authentication request from {project_name}." +msgstr "" + +msgid "Responses" +msgstr "" + +msgid "HTTP Status Code" +msgstr "" + +msgid "201" +msgstr "" + +msgid "It notifies {project_name} of receiving the authentication delegation request." +msgstr "" + +msgid "Authentication Result Notification/ACK consists of the following messaging." +msgstr "" + +msgid "Authentication Result Notification" +msgstr "" + +msgid "The authentication entity sends the result of the authentication request to {project_name}." +msgstr "" + +msgid "POST {kc_realms_path}/[realm]/protocol/openid-connect/ext/ciba/auth/callback" +msgstr "" + +msgid "The [token] must be the one the authentication entity has received from {project_name} in Authentication Delegation Request." +msgstr "" + +msgid "realm" +msgstr "" + +msgid "The realm name" +msgstr "" + +msgid "status" +msgstr "" + +msgid "" +"It tells the result of user authentication by AD. +\n" +"It must be one of the following status. +\n" +" SUCCEED : The authentication by AD has been successfully completed. +\n" +" UNAUTHORIZED : The authentication by AD has not been completed. +\n" +" CANCELLED : The authentication by AD has been cancelled by the user." +msgstr "" + +msgid "Authentication Result ACK" +msgstr "" + +msgid "The response is returned from {project_name} to the authentication entity to notify {project_name} received the result of user authentication by AD from the authentication entity." +msgstr "" + +msgid "200" +msgstr "" + +msgid "It notifies the authentication entity of receiving the notification of the authentication result." +msgstr "" + +msgid "User Resolver Provider" +msgstr "" + +msgid "Even if the same user, its representation may differ in each CD, {project_name} and the authentication entity." +msgstr "" + +msgid "For CD, {project_name} and the authentication entity to recognize the same user, this User Resolver Provider converts their own user representations among them." +msgstr "" + +msgid "User Resolver Provider is provided as SPI provider so that users of {project_name} can implement their own provider in order to meet their environment. {project_name} provides its default provider called Default User Resolver Provider that has the following characteristics." +msgstr "" + +msgid "Only support `login_hint` parameter and is used as default." +msgstr "" + +msgid "`username` of UserModel in {project_name} is used to represent the user on CD, {project_name} and the authentication entity." +msgstr "" + +msgid "OIDC Logout" +msgstr "" + +msgid "OIDC has four specifications relevant to logout mechanisms. These specifications are in draft status:" +msgstr "" + +msgid "https://openid.net/specs/openid-connect-session-1_0.html[Session Management]" +msgstr "" + +msgid "https://openid.net/specs/openid-connect-rpinitiated-1_0.html[RP-Initiated Logout]" +msgstr "" + +msgid "https://openid.net/specs/openid-connect-frontchannel-1_0.html[Front-Channel Logout]" +msgstr "" + +msgid "https://openid.net/specs/openid-connect-backchannel-1_0.html[Back-Channel Logout]" +msgstr "" + +msgid "Again since all of this is described in the OIDC specification we will only give a brief overview here." +msgstr "" + +msgid "Session Management" +msgstr "" + +msgid "This is a browser-based logout. The application obtains session status information from {project_name} at a regular basis. When the session is terminated at {project_name} the application will notice and trigger its own logout." +msgstr "" + +msgid "RP-Initiated Logout" +msgstr "" + +msgid "This is also a browser-based logout where the logout starts by redirecting the user to a specific endpoint at {project_name}. This redirect usually happens when the user clicks the `Log Out` link on the page of some application, which previously used {project_name} to authenticate the user." +msgstr "" + +msgid "Once the user is redirected to the logout endpoint, {project_name} is going to send logout requests to clients to let them invalidate their local user sessions, and potentially redirect the user to some URL once the logout process is finished. The user might be optionally requested to confirm the logout in case the `id_token_hint` parameter was not used. After logout, the user is automatically redirected to the specified `post_logout_redirect_uri` as long as it is provided as a parameter. Note that you need to include either the `client_id` or `id_token_hint` parameter in case the `post_logout_redirect_uri` is included. Also the `post_logout_redirect_uri` parameter needs to match one of the `Valid Post Logout Redirect URIs` specified in the client configuration." +msgstr "" + +msgid "Depending on the client configuration, logout requests can be sent to clients through the front-channel or through the back-channel. For the frontend browser clients, which rely on the Session Management described in the previous section, {project_name} does not need to send any logout requests to them; these clients automatically detect that SSO session in the browser is logged out." +msgstr "" + +msgid "Front-channel Logout" +msgstr "" + +msgid "To configure clients to receive logout requests through the front-channel, look at the <<_front-channel-logout, Front-Channel Logout>> client setting. When using this method, consider the following:" +msgstr "" + +msgid "Logout requests sent by {project_name} to clients rely on the browser and on embedded `iframes` that are rendered for the logout page." +msgstr "" + +msgid "By being based on `iframes`, front-channel logout might be impacted by Content Security Policies (CSP) and logout requests might be blocked." +msgstr "" + +msgid "If the user closes the browser prior to rendering the logout page or before logout requests are actually sent to clients, their sessions at the client might not be invalidated." +msgstr "" + +msgid "Consider using Back-Channel Logout as it provides a more reliable and secure approach to log out users and terminate their sessions on the clients." +msgstr "" + +msgid "If the client is not enabled with front-channel logout, then {project_name} is going to try first to send logout requests through the back-channel using the <<_back-channel-logout-url, Back-Channel Logout URL>>. If not defined, the server is going to fall back to using the <<_admin-url, Admin URL>>." +msgstr "" + +msgid "This is a non-browser-based logout that uses direct backchannel communication between {project_name} and clients. {project_name} sends a HTTP POST request containing a logout token to all clients logged into {project_name}. These requests are sent to a registered backchannel logout URLs at {project_name} and are supposed to trigger a logout at client side." +msgstr "" + +msgid "{project_name} server OIDC URI endpoints" +msgstr "" + +msgid "The following is a list of OIDC endpoints that {project_name} publishes. These endpoints can be used when a non-{project_name} client adapter uses OIDC to communicate with the authentication server. They are all relative URLs. The root of the URL consists of the HTTP(S) protocol, hostname, and optionally the path: For example" +msgstr "" + +msgid "https://localhost:8080{kc_base_path}" +msgstr "" + +msgid "/realms/{realm-name}/protocol/openid-connect/auth" +msgstr "" + +msgid "Used for obtaining a temporary code in the Authorization Code Flow or obtaining tokens using the Implicit Flow, Direct Grants, or Client Grants." +msgstr "" + +msgid "/realms/{realm-name}/protocol/openid-connect/token" +msgstr "" + +msgid "Used by the Authorization Code Flow to convert a temporary code into a token." +msgstr "" + +msgid "/realms/{realm-name}/protocol/openid-connect/logout" +msgstr "" + +msgid "Used for performing logouts." +msgstr "" + +msgid "/realms/{realm-name}/protocol/openid-connect/userinfo" +msgstr "" + +msgid "Used for the User Info service described in the OIDC specification." +msgstr "" + +msgid "/realms/{realm-name}/protocol/openid-connect/revoke" +msgstr "" + +msgid "Used for OAuth 2.0 Token Revocation described in https://datatracker.ietf.org/doc/html/rfc7009[RFC7009]." +msgstr "" + +msgid "/realms/{realm-name}/protocol/openid-connect/certs" +msgstr "" + +msgid "Used for the JSON Web Key Set (JWKS) containing the public keys used to verify any JSON Web Token (jwks_uri)" +msgstr "" + +msgid "/realms/{realm-name}/protocol/openid-connect/auth/device" +msgstr "" + +msgid "Used for Device Authorization Grant to obtain a device code and a user code." +msgstr "" + +msgid "/realms/{realm-name}/protocol/openid-connect/ext/ciba/auth" +msgstr "" + +msgid "This is the URL endpoint for Client Initiated Backchannel Authentication Grant to obtain an auth_req_id that identifies the authentication request made by the client." +msgstr "" + +msgid "/realms/{realm-name}/protocol/openid-connect/logout/backchannel-logout" +msgstr "" + +msgid "This is the URL endpoint for performing backchannel logouts described in the OIDC specification." +msgstr "" + +msgid "In all of these, replace {realm-name} with the name of the realm." +msgstr "" + +msgid "SAML" +msgstr "" + +msgid "link:https://saml.xml.org/saml-specifications[SAML 2.0] is a similar specification to OIDC but more mature. It is descended from SOAP and web service messaging specifications so is generally more verbose than OIDC. SAML 2.0 is an authentication protocol that exchanges XML documents between authentication servers and applications. XML signatures and encryption are used to verify requests and responses." +msgstr "" + +msgid "In general, SAML implements two use cases." +msgstr "" + +msgid "The first use case is an application that requests the {project_name} server authenticates a user. Upon successful login, the application will receive an XML document. This document contains an SAML assertion that specifies user attributes. The realm digitally signs the document which contains access information (such as user role mappings) that applications use to determine the resources users are allowed to access in the application." +msgstr "" + +msgid "The second use case is a client accessing remote services. The client requests a SAML assertion from {project_name} to invoke on remote services on behalf of the user." +msgstr "" + +msgid "SAML bindings" +msgstr "" + +msgid "{project_name} supports three binding types." +msgstr "" + +msgid "Redirect binding" +msgstr "" + +msgid "_Redirect_ binding uses a series of browser redirect URIs to exchange information." +msgstr "" + +msgid "A user connects to an application using a browser. The application detects the user is not authenticated." +msgstr "" + +msgid "The application generates an XML authentication request document and encodes it as a query parameter in a URI. The URI is used to redirect to the {project_name} server. Depending on your settings, the application can also digitally sign the XML document and include the signature as a query parameter in the redirect URI to {project_name}. This signature is used to validate the client that sends the request." +msgstr "" + +msgid "The browser redirects to {project_name}." +msgstr "" + +msgid "The server extracts the XML auth request document and verifies the digital signature, if required." +msgstr "" + +msgid "The user enters their authentication credentials." +msgstr "" + +msgid "After authentication, the server generates an XML authentication response document. The document contains a SAML assertion that holds metadata about the user, including name, address, email, and any role mappings the user has. The document is usually digitally signed using XML signatures, and may also be encrypted." +msgstr "" + +msgid "The XML authentication response document is encoded as a query parameter in a redirect URI. The URI brings the browser back to the application. The digital signature is also included as a query parameter." +msgstr "" + +msgid "The application receives the redirect URI and extracts the XML document." +msgstr "" + +msgid "The application verifies the realm's signature to ensure it is receiving a valid authentication response. The information inside the SAML assertion is used to make access decisions or display user data." +msgstr "" + +msgid "POST binding" +msgstr "" + +msgid "_POST_ binding is similar to _Redirect_ binding but _POST_ binding exchanges XML documents using POST requests instead of using GET requests. _POST_ Binding uses JavaScript to make the browser send a POST request to the {project_name} server or application when exchanging documents. HTTP responds with an HTML document which contains an HTML form containing embedded JavaScript. When the page loads, the JavaScript automatically invokes the form." +msgstr "" + +msgid "_POST_ binding is recommended due to two restrictions:" +msgstr "" + +msgid "*Security* -- With _Redirect_ binding, the SAML response is part of the URL. It is less secure as it is possible to capture the response in logs." +msgstr "" + +msgid "*Size* -- Sending the document in the HTTP payload provides more scope for large amounts of data than in a limited URL." +msgstr "" + +msgid "ECP" +msgstr "" + +msgid "Enhanced Client or Proxy (ECP) is a SAML v.2.0 profile which allows the exchange of SAML attributes outside the context of a web browser. It is often used by REST or SOAP-based clients." +msgstr "" + +msgid "{project_name} Server SAML URI Endpoints" +msgstr "" + +msgid "{project_name} has one endpoint for all SAML requests." +msgstr "" + +msgid "`http(s)://authserver.host{kc_realms_path}/{realm-name}/protocol/saml`" +msgstr "" + +msgid "All bindings use this endpoint." +msgstr "" + +msgid "OpenID Connect compared to SAML" +msgstr "" + +msgid "The following lists a number of factors to consider when choosing a protocol." +msgstr "" + +msgid "For most purposes, {project_name} recommends using OIDC." +msgstr "" + +msgid "*OIDC*" +msgstr "" + +msgid "OIDC is specifically designed to work with the web." +msgstr "" + +msgid "OIDC is suited for HTML5/JavaScript applications because it is easier to implement on the client side than SAML." +msgstr "" + +msgid "OIDC tokens are in the JSON format which makes them easier for Javascript to consume." +msgstr "" + +msgid "OIDC has features to make security implementation easier. For example, see the link:https://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification[iframe trick] that the specification uses to determine a users login status." +msgstr "" + +msgid "*SAML*" +msgstr "" + +msgid "SAML is designed as a layer to work on top of the web." +msgstr "" + +msgid "SAML can be more verbose than OIDC." +msgstr "" + +msgid "Users pick SAML over OIDC because there is a perception that it is mature." +msgstr "" + +msgid "Users pick SAML over OIDC existing applications that are secured with it." +msgstr "" + +msgid "Docker registry v2 authentication" +msgstr "" + +msgid "Docker authentication is disabled by default. To enable docker authentication, see the https://www.keycloak.org/server/features[Enabling and disabling features] {section}." +msgstr "" + +msgid "link:https://distribution.github.io/distribution/spec/auth/[Docker Registry V2 Authentication] is a protocol, similar to OIDC, that authenticates users against Docker registries. {project_name}'s implementation of this protocol lets Docker clients use a {project_name} authentication server authenticate against a registry. This protocol uses standard token and signature mechanisms but it does deviate from a true OIDC implementation. It deviates by using a very specific JSON format for requests and responses as well as mapping repository names and permissions to the OAuth scope mechanism." +msgstr "" + +msgid "Docker authentication flow" +msgstr "" + +msgid "The authentication flow is described in the link:https://distribution.github.io/distribution/spec/auth/token/[Docker API documentation]. The following is a summary from the perspective of the {project_name} authentication server:" +msgstr "" + +msgid "Perform a `docker login`." +msgstr "" + +msgid "The Docker client requests a resource from the Docker registry. If the resource is protected and no authentication token is in the request, the Docker registry server responds with a 401 HTTP message with some information on the permissions that are required and the location of the authorization server." +msgstr "" + +msgid "The Docker client constructs an authentication request based on the 401 HTTP message from the Docker registry. The client uses the locally cached credentials (from the `docker login` command) as part of the link:https://datatracker.ietf.org/doc/html/rfc2617[HTTP Basic Authentication] request to the {project_name} authentication server." +msgstr "" + +msgid "The {project_name} authentication server attempts to authenticate the user and return a JSON body containing an OAuth-style Bearer token." +msgstr "" + +msgid "The Docker client receives a bearer token from the JSON response and uses it in the authorization header to request the protected resource." +msgstr "" + +msgid "The Docker registry receives the new request for the protected resource with the token from the {project_name} server. The registry validates the token and grants access to the requested resource (if appropriate)." +msgstr "" + +msgid "{project_name} does not create a browser SSO session after successful authentication with the Docker protocol. The browser SSO session does not use the Docker protocol as it cannot refresh tokens or obtain the status of a token or session from the {project_name} server; therefore a browser SSO session is not necessary. For more details, see the <<_transient-session, transient session>> section." +msgstr "" + +msgid "{project_name} Docker Registry v2 Authentication Server URI Endpoints" +msgstr "" + +msgid "{project_name} has one endpoint for all Docker auth v2 requests." +msgstr "" + +msgid "`http(s)://authserver.host{kc_realms_path}/{realm-name}/protocol/docker-v2`" +msgstr "" + +msgid "Controlling access to the Admin Console" +msgstr "" + +msgid "Each realm created on the {project_name} has a dedicated Admin Console from which that realm can be managed. The `master` realm is a special realm that allows admins to manage more than one realm on the system. You can also define fine-grained access to users in different realms to manage the server. This chapter goes over all the scenarios for this." +msgstr "" + +msgid "Master realm access control" +msgstr "" + +msgid "The `master` realm in {project_name} is a special realm and treated differently than other realms. Users in the {project_name} `master` realm can be granted permission to manage zero or more realms that are deployed on the {project_name} server. When a realm is created, {project_name} automatically creates various roles that grant fine-grain permissions to access that new realm. Access to The Admin Console and Admin REST endpoints can be controlled by mapping these roles to users in the `master` realm. It's possible to create multiple superusers, as well as users that can only manage specific realms." +msgstr "" + +msgid "Global roles" +msgstr "" + +msgid "There are two realm-level roles in the `master` realm. These are:" +msgstr "" + +msgid "admin" +msgstr "" + +msgid "create-realm" +msgstr "" + +msgid "Users with the `admin` role are superusers and have full access to manage any realm on the server. Users with the `create-realm` role are allowed to create new realms. They will be granted full access to any new realm they create." +msgstr "" + +msgid "Realm specific roles" +msgstr "" + +msgid "Admin users within the `master` realm can be granted management privileges to one or more other realms in the system. Each realm in {project_name} is represented by a client in the `master` realm. The name of the client is `-realm`. These clients each have client-level roles defined which define varying level of access to manage an individual realm." +msgstr "" + +msgid "The roles available are:" +msgstr "" + +msgid "view-realm" +msgstr "" + +msgid "view-users" +msgstr "" + +msgid "view-clients" +msgstr "" + +msgid "view-events" +msgstr "" + +msgid "manage-realm" +msgstr "" + +msgid "manage-users" +msgstr "" + +msgid "create-client" +msgstr "" + +msgid "manage-clients" +msgstr "" + +msgid "manage-events" +msgstr "" + +msgid "view-identity-providers" +msgstr "" + +msgid "manage-identity-providers" +msgstr "" + +msgid "impersonation" +msgstr "" + +msgid "Assign the roles you want to your users and they will only be able to use that specific part of the administration console." +msgstr "" + +msgid "Admins with the `manage-users` role will only be able to assign admin roles to users that they themselves have. So, if an admin has the `manage-users` role but doesn't have the `manage-realm` role, they will not be able to assign this role." +msgstr "" + +msgid "Dedicated realm admin consoles" +msgstr "" + +msgid "Each realm has a dedicated Admin Console that can be accessed by going to the url `{kc_admins_path}/{realm-name}/console`. Users within that realm can be granted realm management permissions by assigning specific user role mappings." +msgstr "" + +msgid "Each realm has a built-in client called `realm-management`. You can view this client by going to the `Clients` left menu item of your realm. This client defines client-level roles that specify permissions that can be granted to manage the realm." +msgstr "" + +msgid "Fine grain admin permissions" +msgstr "" + +msgid "Sometimes roles like `manage-realm` or `manage-users` are too coarse grain and you want to create restricted admin accounts that have more fine grain permissions. {project_name} allows you to define and assign restricted access policies for managing a realm. Things like:" +msgstr "" + +msgid "Managing one specific client" +msgstr "" + +msgid "Managing users that belong to a specific group" +msgstr "" + +msgid "Managing membership of a group" +msgstr "" + +msgid "Limited user management." +msgstr "" + +msgid "Fine grain impersonation control" +msgstr "" + +msgid "Being able to assign a specific restricted set of roles to users." +msgstr "" + +msgid "Being able to assign a specific restricted set of roles to a composite role." +msgstr "" + +msgid "Being able to assign a specific restricted set of roles to a client's scope." +msgstr "" + +msgid "New general policies for viewing and managing users, groups, roles, and clients." +msgstr "" + +msgid "There are some important things to note about fine grain admin permissions:" +msgstr "" + +msgid "Fine grain admin permissions were implemented on top of link:{authorizationguide_link}[Authorization Services]. It is highly recommended that you read up on those features before diving into fine grain permissions." +msgstr "" + +msgid "Fine grain permissions are only available within <<_per_realm_admin_permissions, dedicated admin consoles>> and admins defined within those realms. You cannot define cross-realm fine grain permissions." +msgstr "" + +msgid "Fine grain permissions are used to grant additional permissions. You cannot override the default behavior of the built-in admin roles." +msgstr "" + +msgid "Let's look first at allowing an admin to manage one client and one client only. In our example, we have a realm called `test` and a client called `sales-application`. In the realm `test` we will give a user in that realm permission to only manage that application." +msgstr "" + +msgid "You cannot do cross realm fine grain permissions. Admins in the `master` realm are limited to the predefined admin roles defined in previous chapters." +msgstr "" + +msgid "Permission setup" +msgstr "" + +msgid "The first thing we must do is login to the Admin Console so we can set up permissions for that client. We navigate to the management section of the client, we want to define fine-grain permissions for." +msgstr "" + +msgid "Client management" +msgstr "" + +msgid "image:images/fine-grain-client.png[Fine grain client]" +msgstr "" + +msgid "You should see a tab menu item called `Permissions`. Click on that tab." +msgstr "" + +msgid "Client permissions tab" +msgstr "" + +msgid "image:images/fine-grain-client-permissions-tab-off.png[Fine grain client permissions tab]" +msgstr "" + +msgid "By default, each client is not enabled to do fine grain permissions. So turn the `Permissions Enabled` switch to on to initialize permissions." +msgstr "" + +msgid "If you turn the `Permissions Enabled` switch to off, it will delete any and all permissions you have defined for this client." +msgstr "" + +msgid "image:images/fine-grain-client-permissions-tab-on.png[Fine grain permission tab]" +msgstr "" + +msgid "When you switch `Permissions Enabled` to on, it initializes various permission objects behind the scenes using link:{authorizationguide_link}[Authorization Services]. For this example, we're interested in the `manage` permission for the client. Clicking on that will redirect you to the permission that handles the `manage` permission for the client. All authorization objects are contained in the `realm-management` client's `Authorization` tab." +msgstr "" + +msgid "Client manage permission" +msgstr "" + +msgid "image:images/fine-grain-client-manage-permissions.png[Fine grain client manage permission ]" +msgstr "" + +msgid "When first initialized the `manage` permission does not have any policies associated with it. You will need to create one by going to the policy tab. To get there fast, click on the `Authorization` link shown in the above image. Then click on the policies tab." +msgstr "" + +msgid "There's a pull down menu on this page called `Create policy`. There's a multitude of policies you can define. You can define a policy that is associated with a role or a group or even define rules in JavaScript. For this simple example, we're going to create a `User Policy`." +msgstr "" + +msgid "User policy" +msgstr "" + +msgid "image:images/fine-grain-client-user-policy.png[Fine grain client user policy]" +msgstr "" + +msgid "This policy will match a hard-coded user in the user database. In this case, it is the `sales-admin` user. We must then go back to the `sales-application` client's `manage` permission page and assign the policy to the permission object." +msgstr "" + +msgid "Assign user policy" +msgstr "" + +msgid "image:images/fine-grain-client-assign-user-policy.png[Fine grain client assign user policy]" +msgstr "" + +msgid "The `sales-admin` user can now has permission to manage the `sales-application` client." +msgstr "" + +msgid "There's one more thing we have to do. Go to the `Role Mappings` tab and assign the `query-clients` role to the `sales-admin`." +msgstr "" + +msgid "Assign query-clients" +msgstr "" + +msgid "image:images/fine-grain-assign-query-clients.png[Fine grain assign query clients]" +msgstr "" + +msgid "Why do you have to do this? This role tells the Admin Console what menu items to render when the `sales-admin` visits the Admin Console. The `query-clients` role tells the Admin Console that it should render client menus for the `sales-admin` user." +msgstr "" + +msgid "IMPORTANT If you do not set the `query-clients` role, restricted admins like `sales-admin` will not see any menu options when they log into the Admin Console" +msgstr "" + +msgid "Testing it out" +msgstr "" + +msgid "Next, we log out of the master realm and re-login to the <<_per_realm_admin_permissions, dedicated admin console>> for the `test` realm using the `sales-admin` as a username. This is located under `{kc_admins_path}/test/console`." +msgstr "" + +msgid "Sales admin login" +msgstr "" + +msgid "image:images/fine-grain-sales-admin-login.png[Fine grain sales admin login]" +msgstr "" + +msgid "This admin is now able to manage this one client." +msgstr "" + +msgid "Restrict user role mapping" +msgstr "" + +msgid "Another thing you might want to do is to restrict the set of roles an admin is allowed to assign to a user. Continuing our last example, let's expand the permission set of the 'sales-admin' user so that he can also control which users are allowed to access this application. Through fine grain permissions, we can enable it so that the `sales-admin` can only assign roles that grant specific access to the `sales-application`. We can also restrict it so that the admin can only map roles and not perform any other types of user administration." +msgstr "" + +msgid "The `sales-application` has defined three different client roles." +msgstr "" + +msgid "Sales application roles" +msgstr "" + +msgid "image:images/fine-grain-sales-application-roles.png[Fine grain sales application roles]" +msgstr "" + +msgid "We want the `sales-admin` user to be able to map these roles to any user in the system. The first step to do this is to allow the role to be mapped by the admin. If we click on the `viewLeads` role, you'll see that there is a `Permissions` tab for this role." +msgstr "" + +msgid "View leads role permission tab" +msgstr "" + +msgid "image:images/fine-grain-view-leads-role-tab.png[Fine grain view leads role]" +msgstr "" + +msgid "If we click on that tab and turn the `Permissions Enabled` on, you'll see that there are a number of actions we can apply policies to." +msgstr "" + +msgid "View leads permissions" +msgstr "" + +msgid "image:images/fine-grain-view-leads-permissions.png[Fine grain view leads permissions]" +msgstr "" + +msgid "The one we are interested in is `map-role`. Click on this permission and add the same User Policy that was created in the earlier example." +msgstr "" + +msgid "Map-roles permission" +msgstr "" + +msgid "image:images/fine-grain-map-roles-permission.png[Fine grain map roles permission]" +msgstr "" + +msgid "What we've done is say that the `sales-admin` can map the `viewLeads` role. What we have not done is specify which users the admin is allowed to map this role too. To do that we must go to the `Users` section of the admin console for this realm. Clicking on the `Users` left menu item brings us to the users interface of the realm. You should see a `Permissions` tab. Click on that and enable it." +msgstr "" + +msgid "Users permissions" +msgstr "" + +msgid "image:images/fine-grain-users-permissions.png[Fine grain user permissions]" +msgstr "" + +msgid "The permission we are interested in is `map-roles`. This is a restrictive policy in that it only allows admins the ability to map roles to a user. If we click on the `map-roles` permission and again add the User Policy we created for this, our `sales-admin` will be able to map roles to any user." +msgstr "" + +msgid "The last thing we have to do is add the `view-users` role to the `sales-admin`. This will allow the admin to view users in the realm he wants to add the `sales-application` roles to." +msgstr "" + +msgid "Add view-users" +msgstr "" + +msgid "image:images/fine-grain-add-view-users.png[Fine grain add view users]" +msgstr "" + +msgid "You will see that now the `sales-admin` can view users in the system. If you select one of the users you'll see that each user detail page is read only, except for the `Role Mappings` tab. Going to this tab you'll find that there are no `Available` roles for the admin to map to the user except when we browse the `sales-application` roles." +msgstr "" + +msgid "Add viewleads" +msgstr "" + +msgid "image:images/fine-grain-add-view-leads.png[Fine grain add view leads]" +msgstr "" + +msgid "We've only specified that the `sales-admin` can map the `viewLeads` role." +msgstr "" + +msgid "Per client map-roles shortcut" +msgstr "" + +msgid "It would be tedious if we had to do this for every client role that the `sales-application` published. to make things easier, there's a way to specify that an admin can map any role defined by a client. If we log back into the admin console to our master realm admin and go back to the `sales-application` permissions page, you'll see the `map-roles` permission." +msgstr "" + +msgid "Client map-roles permission" +msgstr "" + +msgid "image:images/fine-grain-client-permissions-tab-on.png[Fine grain client permissions]" +msgstr "" + +msgid "If you grant access to this particular permission to an admin, that admin will be able map any role defined by the client." +msgstr "" + +msgid "Full list of permissions" +msgstr "" + +msgid "You can do a lot more with fine grain permissions beyond managing a specific client or the specific roles of a client. This chapter defines the whole list of permission types that can be described for a realm." +msgstr "" + +msgid "Role" +msgstr "" + +msgid "When going to the `Permissions` tab for a specific role, you will see these permission types listed." +msgstr "" + +msgid "map-role" +msgstr "" + +msgid "Policies that decide if an admin can map this role to a user. These policies only specify that the role can be mapped to a user, not that the admin is allowed to perform user role mapping tasks. The admin will also have to have manage or role mapping permissions. See <<_users-permissions, Users Permissions>> for more information." +msgstr "" + +msgid "map-role-composite" +msgstr "" + +msgid "Policies that decide if an admin can map this role as a composite to another role. An admin can define roles for a client if he has to manage permissions for that client but he will not be able to add composites to those roles unless he has the `map-role-composite` privileges for the role he wants to add as a composite." +msgstr "" + +msgid "map-role-client-scope" +msgstr "" + +msgid "Policies that decide if an admin can apply this role to the scope of a client. Even if the admin can manage the client, he will not have permission to create tokens for that client that contain this role unless this privilege is granted." +msgstr "" + +msgid "Client" +msgstr "" + +msgid "When going to the `Permissions` tab for a specific client, you will see these permission types listed." +msgstr "" + +msgid "view" +msgstr "" + +msgid "Policies that decide if an admin can view the client's configuration." +msgstr "" + +msgid "manage" +msgstr "" + +msgid "Policies that decide if an admin can view and manage the client's configuration. There are some issues with this in that privileges could be leaked unintentionally. For example, the admin could define a protocol mapper that hardcoded a role even if the admin does not have privileges to map the role to the client's scope. This is currently the limitation of protocol mappers as they don't have a way to assign individual permissions to them like roles do." +msgstr "" + +msgid "configure" +msgstr "" + +msgid "Reduced set of privileges to manage the client. It is like the `manage` scope except the admin is not allowed to define protocol mappers, change the client template, or the client's scope." +msgstr "" + +msgid "map-roles" +msgstr "" + +msgid "Policies that decide if an admin can map any role defined by the client to a user. This is a shortcut, easy-of-use feature to avoid having to define policies for each and every role defined by the client." +msgstr "" + +msgid "map-roles-composite" +msgstr "" + +msgid "Policies that decide if an admin can map any role defined by the client as a composite to another role. This is a shortcut, easy-of-use feature to avoid having to define policies for each and every role defined by the client." +msgstr "" + +msgid "map-roles-client-scope" +msgstr "" + +msgid "Policies that decide if an admin can map any role defined by the client to the scope of another client. This is a shortcut, easy-of-use feature to avoid having to define policies for each and every role defined by the client." +msgstr "" + +msgid "When going to the `Permissions` tab for all users, you will see these permission types listed." +msgstr "" + +msgid "Policies that decide if an admin can view all users in the realm." +msgstr "" + +msgid "Policies that decide if an admin can manage all users in the realm. This permission grants the admin the privilege to perform user role mappings, but it does not specify which roles the admin is allowed to map. You'll need to define the privilege for each role you want the admin to be able to map." +msgstr "" + +msgid "This is a subset of the privileges granted by the `manage` scope. In this case the admin is only allowed to map roles. The admin is not allowed to perform any other user management operation. Also, like `manage`, the roles that the admin is allowed to apply must be specified per role or per set of roles if dealing with client roles." +msgstr "" + +msgid "manage-group-membership" +msgstr "" + +msgid "Similar to `map-roles` except that it pertains to group membership: which groups a user can be added or removed from. These policies just grant the admin permission to manage group membership, not which groups the admin is allowed to manage membership for. You'll have to specify policies for each group's `manage-members` permission." +msgstr "" + +msgid "impersonate" +msgstr "" + +msgid "Policies that decide if the admin is allowed to impersonate other users. These policies are applied to the administrator's attributes and role mappings." +msgstr "" + +msgid "user-impersonated" +msgstr "" + +msgid "Policies that decide which users can be impersonated. These policies will be applied to the user being impersonated. For example, you might want to define a policy that will forbid anybody from impersonating a user that has admin privileges." +msgstr "" + +msgid "When going to the `Permissions` tab for a specific group, you will see these permission types listed." +msgstr "" + +msgid "Policies that decide if the admin can view information about the group." +msgstr "" + +msgid "Policies that decide if the admin can manage the configuration of the group." +msgstr "" + +msgid "view-members" +msgstr "" + +msgid "Policies that decide if the admin can view the user details of members of the group." +msgstr "" + +msgid "manage-members" +msgstr "" + +msgid "Policies that decide if the admin can manage the users that belong to this group." +msgstr "" + +msgid "manage-membership" +msgstr "" + +msgid "Policies that decide if an admin can change the membership of the group. Add or remove members from the group." +msgstr "" + +msgid "Managing OpenID Connect and SAML Clients" +msgstr "" + +msgid "Clients are entities that can request authentication of a user. Clients come in two forms. The first type of client is an application that wants to participate in single-sign-on. These clients just want {project_name} to provide security for them. The other type of client is one that is requesting an access token so that it can invoke other services on behalf of the authenticated user. This section discusses various aspects around configuring clients and various ways to do it." +msgstr "" + +msgid "Managing OpenID Connect clients" +msgstr "" + +msgid "xref:con-oidc_{context}[OpenID Connect] is the recommended protocol to secure applications. It was designed from the ground up to be web friendly and it works best with HTML5/JavaScript applications." +msgstr "" + +msgid "Creating an OpenID Connect client" +msgstr "" + +msgid "To protect an application that uses the OpenID connect protocol, you create a client." +msgstr "" + +msgid "Click *Create client*." +msgstr "" + +msgid "Create client" +msgstr "" + +msgid "image:images/add-client-oidc.png[Create Client]" +msgstr "" + +msgid "Leave *Client type* set to *OpenID Connect*." +msgstr "" + +msgid "Enter a *Client ID.*" +msgstr "" + +msgid "This ID is an alphanumeric string that is used in OIDC requests and in the {project_name} database to identify the client." +msgstr "" + +msgid "Supply a *Name* for the client." +msgstr "" + +msgid "If you plan to localize this name, set up a replacement string value. For example, a string value such as $\\{myapp}. See the link:{developerguide_link}[{developerguide_name}] for more information." +msgstr "" + +msgid "This action creates the client and bring you to the *Settings* tab, where you can perform xref:con-basic-settings_{context}[Basic configuration]." +msgstr "" + +msgid "Basic configuration" +msgstr "" + +msgid "The *Settings* tab includes many options to configure this client." +msgstr "" + +msgid "Settings tab" +msgstr "" + +msgid "image:images/client-settings-oidc.png[Settings tab]" +msgstr "" + +msgid "General Settings" +msgstr "" + +msgid "*Client ID*" +msgstr "" + +msgid "The alphanumeric ID string that is used in OIDC requests and in the {project_name} database to identify the client." +msgstr "" + +msgid "*Name*" +msgstr "" + +msgid "The name for the client in {project_name} UI screen. To localize the name, set up a replacement string value. For example, a string value such as $\\{myapp}. See the link:{developerguide_link}[{developerguide_name}] for more information." +msgstr "" + +msgid "*Description*" +msgstr "" + +msgid "The description of the client. This setting can also be localized." +msgstr "" + +msgid "*Always Display in Console*" +msgstr "" + +msgid "Always list this client in the Account Console even if this user does not have an active session." +msgstr "" + +msgid "Access Settings" +msgstr "" + +msgid "*Root URL*" +msgstr "" + +msgid "If {project_name} uses any configured relative URLs, this value is prepended to them." +msgstr "" + +msgid "*Home URL*" +msgstr "" + +msgid "Provides the default URL for when the auth server needs to redirect or link back to the client." +msgstr "" + +msgid "*Valid Redirect URIs*" +msgstr "" + +msgid "Required field. Enter a URL pattern and click *+* to add and *-* to remove existing URLs and click *Save*. You can use wildcards at the end of the URL pattern. For example $$http://host.com/*$$" +msgstr "" + +msgid "Exclusive redirect URL patterns are typically more secure. See xref:unspecific-redirect-uris_{context}[Unspecific Redirect URIs] for more information." +msgstr "" + +msgid "Web Origins" +msgstr "" + +msgid "Enter a URL pattern and click + to add and - to remove existing URLs. Click Save." +msgstr "" + +msgid "This option handles link:https://fetch.spec.whatwg.org/[Cross-Origin Resource Sharing (CORS)]. If browser JavaScript attempts an AJAX HTTP request to a server whose domain is different from the one that the JavaScript code came from, the request must use CORS. The server must handle CORS requests, otherwise the browser will not display or allow the request to be processed. This protocol protects against XSS, CSRF, and other JavaScript-based attacks." +msgstr "" + +msgid "Domain URLs listed here are embedded within the access token sent to the client application. The client application uses this information to decide whether to allow a CORS request to be invoked on it. Only {project_name} client adapters support this feature. See link:{adapterguide_link}[{adapterguide_name}] for more information." +msgstr "" + +msgid "Admin URL" +msgstr "" + +msgid "Callback endpoint for a client. The server uses this URL to make callbacks like pushing revocation policies, performing backchannel logout, and other administrative operations. For {project_name} servlet adapters, this URL can be the root URL of the servlet application. For more information, see link:{adapterguide_link}[{adapterguide_name}]." +msgstr "" + +msgid "Capability Config" +msgstr "" + +msgid "*Client authentication*" +msgstr "" + +msgid "The type of OIDC client." +msgstr "" + +msgid "_ON_" +msgstr "" + +msgid "For server-side clients that perform browser logins and require client secrets when making an Access Token Request. This setting should be used for server-side applications." +msgstr "" + +msgid "_OFF_" +msgstr "" + +msgid "For client-side clients that perform browser logins. As it is not possible to ensure that secrets can be kept safe with client-side clients, it is important to restrict access by configuring correct redirect URIs." +msgstr "" + +msgid "*Authorization*" +msgstr "" + +msgid "Enables or disables fine-grained authorization support for this client." +msgstr "" + +msgid "*Standard Flow*" +msgstr "" + +msgid "If enabled, this client can use the OIDC xref:_oidc-auth-flows-authorization[Authorization Code Flow]." +msgstr "" + +msgid "*Direct Access Grants*" +msgstr "" + +msgid "If enabled, this client can use the OIDC xref:_oidc-auth-flows-direct[Direct Access Grants]." +msgstr "" + +msgid "*Implicit Flow*" +msgstr "" + +msgid "If enabled, this client can use the OIDC xref:_oidc-auth-flows-implicit[Implicit Flow]." +msgstr "" + +msgid "*Service account roles*" +msgstr "" + +msgid "If enabled, this client can authenticate to {project_name} and retrieve access token dedicated to this client. In terms of OAuth2 specification, this enables support of `Client Credentials Grant` for this client." +msgstr "" + +msgid "*Auth 2.0 Device Authorization Grant*" +msgstr "" + +msgid "If enabled, this client can use the OIDC xref:con-oidc-auth-flows_server_administration_guide[Device Authorization Grant]." +msgstr "" + +msgid "*OIDC CIBA Grant*" +msgstr "" + +msgid "If enabled, this client can use the OIDC xref:con-oidc-auth-flows_{context}[Client Initiated Backchannel Authentication Grant]." +msgstr "" + +msgid "Login settings" +msgstr "" + +msgid "*Login theme*" +msgstr "" + +msgid "A theme to use for login, OTP, grant registration, and forgotten password pages." +msgstr "" + +msgid "*Consent required*" +msgstr "" + +msgid "If enabled, users have to consent to client access." +msgstr "" + +msgid "*Display client on screen*" +msgstr "" + +msgid "This switch applies if *Consent Required* is *Off*." +msgstr "" + +msgid "_Off_" +msgstr "" + +msgid "The consent screen will contain only the consents corresponding to configured client scopes." +msgstr "" + +msgid "_On_" +msgstr "" + +msgid "There will be also one item on the consent screen about this client itself." +msgstr "" + +msgid "*Client consent screen text*" +msgstr "" + +msgid "Applies if *Consent required* and *Display client on screen* are enabled. Contains the text that will be on the consent screen about permissions for this client." +msgstr "" + +msgid "Logout settings" +msgstr "" + +msgid "*Front channel logout*" +msgstr "" + +msgid "If *Front Channel Logout* is enabled, the application should be able to log out users through the front channel as per link:https://openid.net/specs/openid-connect-frontchannel-1_0.html[OpenID Connect Front-Channel Logout] specification. If enabled, you should also provide the `Front-Channel Logout URL`." +msgstr "" + +msgid "*Front-channel logout URL*" +msgstr "" + +msgid "URL that will be used by {project_name} to send logout requests to clients through the front-channel." +msgstr "" + +msgid "*Backchannel logout URL*" +msgstr "" + +msgid "URL that will cause the client to log itself out when a logout request is sent to this realm (via end_session_endpoint). If omitted, no logout requests are sent to the client." +msgstr "" + +msgid "*Backchannel logout session required*" +msgstr "" + +msgid "Specifies whether a session ID Claim is included in the Logout Token when the *Backchannel Logout URL* is used." +msgstr "" + +msgid "*Backchannel logout revoke offline sessions*" +msgstr "" + +msgid "Specifies whether a revoke_offline_access event is included in the Logout Token when the Backchannel Logout URL is used. {project_name} will revoke offline sessions when receiving a Logout Token with this event." +msgstr "" + +msgid "Advanced configuration" +msgstr "" + +msgid "After completing the fields on the *Settings* tab, you can use the other tabs to perform advanced configuration. For example, you can use the *Permissions* and *Roles* tabs to configure fine-grained authentication for administrators. See <<_fine_grain_permissions, Fine grain admin permissions>>. Also, see the remaining sections in this chapter for other capabilities." +msgstr "" + +msgid "Advanced tab" +msgstr "" + +msgid "When you click the *Advanced* tab, additional fields are displayed. For details on a specific field, click the question mark icon for that field. However, certain fields are described in detail in this section." +msgstr "" + +msgid "Fine grain OpenID Connect configuration" +msgstr "" + +msgid "*Logo URL*" +msgstr "" + +msgid "URL that references a logo for the Client application." +msgstr "" + +msgid "*Policy URL*" +msgstr "" + +msgid "URL that the Relying Party Client provides to the End-User to read about how the profile data will be used." +msgstr "" + +msgid "*Terms of Service URL*" +msgstr "" + +msgid "URL that the Relying Party Client provides to the End-User to read about the Relying Party's terms of service." +msgstr "" + +msgid "*Signed and Encrypted ID Token Support*" +msgstr "" + +msgid "{project_name} can encrypt ID tokens according to the https://datatracker.ietf.org/doc/html/rfc7516[Json Web Encryption (JWE)] specification. The administrator determines if ID tokens are encrypted for each client." +msgstr "" + +msgid "The key used for encrypting the ID token is the Content Encryption Key (CEK). {project_name} and a client must negotiate which CEK is used and how it is delivered. The method used to determine the CEK is the Key Management Mode. The Key Management Mode that {project_name} supports is Key Encryption." +msgstr "" + +msgid "In Key Encryption:" +msgstr "" + +msgid "The client generates an asymmetric cryptographic key pair." +msgstr "" + +msgid "The public key is used to encrypt the CEK." +msgstr "" + +msgid "{project_name} generates a CEK per ID token" +msgstr "" + +msgid "{project_name} encrypts the ID token using this generated CEK" +msgstr "" + +msgid "{project_name} encrypts the CEK using the client's public key." +msgstr "" + +msgid "The client decrypts this encrypted CEK using their private key" +msgstr "" + +msgid "The client decrypts the ID token using the decrypted CEK." +msgstr "" + +msgid "No party, other than the client, can decrypt the ID token." +msgstr "" + +msgid "The client must pass its public key for encrypting CEK to {project_name}. {project_name} supports downloading public keys from a URL provided by the client. The client must provide public keys according to the https://datatracker.ietf.org/doc/html/rfc7517[Json Web Keys (JWK)] specification." +msgstr "" + +msgid "The procedure is:" +msgstr "" + +msgid "Open the client's *Keys* tab." +msgstr "" + +msgid "Toggle *JWKS URL* to ON." +msgstr "" + +msgid "Input the client's public key URL in the *JWKS URL* textbox." +msgstr "" + +msgid "Key Encryption's algorithms are defined in the https://datatracker.ietf.org/doc/html/rfc7518#section-4.1[Json Web Algorithm (JWA)] specification. {project_name} supports:" +msgstr "" + +msgid "RSAES-PKCS1-v1_5(RSA1_5)" +msgstr "" + +msgid "RSAES OAEP using default parameters (RSA-OAEP)" +msgstr "" + +msgid "RSAES OAEP 256 using SHA-256 and MFG1 (RSA-OAEP-256)" +msgstr "" + +msgid "The procedure to select the algorithm is:" +msgstr "" + +msgid "Open the client's *Advanced* tab." +msgstr "" + +msgid "Open *Fine Grain OpenID Connect Configuration*." +msgstr "" + +msgid "Select the algorithm from *ID Token Encryption Content Encryption Algorithm* pulldown menu." +msgstr "" + +msgid "Open ID Connect Compatibility Modes" +msgstr "" + +msgid "This section exists for backward compatibility. Click the question mark icons for details on each field." +msgstr "" + +msgid "*OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled*" +msgstr "" + +msgid "Mutual TLS binds an access token and a refresh token together with a client certificate, which is exchanged during a TLS handshake. This binding prevents an attacker from using stolen tokens." +msgstr "" + +msgid "This type of token is a holder-of-key token. Unlike bearer tokens, the recipient of a holder-of-key token can verify if the sender of the token is legitimate." +msgstr "" + +msgid "If this setting is on, the workflow is:" +msgstr "" + +msgid "A token request is sent to the token endpoint in an authorization code flow or hybrid flow." +msgstr "" + +msgid "{project_name} requests a client certificate." +msgstr "" + +msgid "{project_name} receives the client certificate." +msgstr "" + +msgid "{project_name} successfully verifies the client certificate." +msgstr "" + +msgid "If verification fails, {project_name} rejects the token." +msgstr "" + +msgid "In the following cases, {project_name} will verify the client sending the access token or the refresh token:" +msgstr "" + +msgid "A token refresh request is sent to the token endpoint with a holder-of-key refresh token." +msgstr "" + +msgid "A UserInfo request is sent to UserInfo endpoint with a holder-of-key access token." +msgstr "" + +msgid "A logout request is sent to non-OIDC compliant {project_name} proprietary Logout endpoint with a holder-of-key refresh token." +msgstr "" + +msgid "See https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-08#section-3[Mutual TLS Client Certificate Bound Access Tokens] in the OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens for more details." +msgstr "" + +msgid "Currently, {project_name} client adapters do not support holder-of-key token verification. {project_name} adapters treat access and refresh tokens as bearer tokens." +msgstr "" + +msgid "*OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)*" +msgstr "" + +msgid "DPoP binds an access token and a refresh token together with the public part of a client's key pair. This binding prevents an attacker from using stolen tokens." +msgstr "" + +msgid "If the client switch `OAuth 2.0 DPoP Bound Access Tokens Enabled` is on, the workflow is:" +msgstr "" + +msgid "{project_name} requests a DPoP proof." +msgstr "" + +msgid "{project_name} receives the DPoP proof." +msgstr "" + +msgid "{project_name} successfully verifies the DPoP proof." +msgstr "" + +msgid "If the switch `OAuth 2.0 DPoP Bound Access Tokens Enabled` is off, the client can still send `DPoP` proof in the token request. In that case, {project_name} will verify DPoP proof and will add the thumbprint to the token. But if the switch is off, DPoP binding is not enforced by the {project_name} server for this client. It is recommended to have this switch on if you want to make sure that particular client always uses DPoP binding." +msgstr "" + +msgid "A token refresh request is sent to the token endpoint with a holder-of-key refresh token. This verification is done only for public clients as described in the DPoP specification. For confidential clients, the verification is not done as client authentication with proper client credentials is in place to ensure that request comes from the legitimate client. For public clients, both access tokens and refresh tokens are DPoP bound. For confidential clients, only access tokens are DPoP bound." +msgstr "" + +msgid "A logout request is sent to a non-OIDC compliant {project_name} proprietary logout endpoint Logout endpoint with a holder-of-key refresh token. This verification is done only for public clients as described above." +msgstr "" + +msgid "See https://datatracker.ietf.org/doc/html/rfc9449[OAuth 2.0 Demonstrating Proof of Possession (DPoP)] for more details." +msgstr "" + +msgid "Currently, {project_name} client adapters do not support DPoP holder-of-key token verification. {project_name} adapters treat access and refresh tokens as bearer tokens." +msgstr "" + +msgid "*Advanced Settings for OIDC*" +msgstr "" + +msgid "The Advanced Settings for OpenID Connect allows you to configure overrides at the client level for <<_timeouts, session and token timeouts>>." +msgstr "" + +msgid "image:images/client-advanced-settings-oidc.png[Advanced Settings]" +msgstr "" + +msgid "The value overrides the realm option with same name." +msgstr "" + +msgid "The value overrides the realm option with same name. The value should be shorter than the global *SSO Session Idle*." +msgstr "" + +msgid "The value overrides the realm option with same name. The value should be shorter than the global *SSO Session Max*." +msgstr "" + +msgid "Client Offline Session Idle" +msgstr "" + +msgid "This setting allows you to configure a shorter offline session idle timeout for the client. The timeout is amount of time the session remains idle before {project_name} revokes its offline token. If not set, realm <<_offline-session-idle,Offline Session Idle>> is used." +msgstr "" + +msgid "Client Offline Session Max" +msgstr "" + +msgid "This setting allows you to configure a shorter offline session max lifespan for the client. The lifespan is the maximum time before {project_name} revokes the corresponding offline token. This option needs <<_offline-session-max-limited,Offline Session Max Limited>> enabled globally in the realm, and defaults to <<_offline-session-max,Offline Session Max>>." +msgstr "" + +msgid "*Proof Key for Code Exchange Code Challenge Method*" +msgstr "" + +msgid "If an attacker steals an authorization code of a legitimate client, Proof Key for Code Exchange (PKCE) prevents the attacker from receiving the tokens that apply to the code." +msgstr "" + +msgid "An administrator can select one of these options:" +msgstr "" + +msgid "*(blank)*" +msgstr "" + +msgid "{project_name} does not apply PKCE unless the client sends appropriate PKCE parameters to {project_name}s authorization endpoint." +msgstr "" + +msgid "*S256*" +msgstr "" + +msgid "{project_name} applies to the client PKCE whose code challenge method is S256." +msgstr "" + +msgid "*plain*" +msgstr "" + +msgid "{project_name} applies to the client PKCE whose code challenge method is plain." +msgstr "" + +msgid "See https://datatracker.ietf.org/doc/html/rfc7636[RFC 7636 Proof Key for Code Exchange by OAuth Public Clients] for more details." +msgstr "" + +msgid "*ACR to Level of Authentication (LoA) Mapping*" +msgstr "" + +msgid "In the advanced settings of a client, you can define which `Authentication Context Class Reference (ACR)` value is mapped to which `Level of Authentication (LoA)`. This mapping can be specified also at the realm as mentioned in the <<_mapping-acr-to-loa-realm,ACR to LoA Mapping>>. A best practice is to configure this mapping at the realm level, which allows to share the same settings across multiple clients." +msgstr "" + +msgid "The `Default ACR Values` can be used to specify the default values when the login request is sent from this client to {project_name} without `acr_values` parameter and without a `claims` parameter that has an `acr` claim attached. See https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata[official OIDC dynamic client registration specification]." +msgstr "" + +msgid "Note that default ACR values are used as the default level, however it cannot be reliably used to enforce login with the particular level. For example, assume that you configure the `Default ACR Values` to level 2. Then by default, users will be required to authenticate with level 2. However when the user explicitly attaches the parameter into login request such as `acr_values=1`, then the level 1 will be used. As a result, if the client really requires level 2, the client is encouraged to check the presence of the `acr` claim inside ID Token and double-check that it contains the requested level 2." +msgstr "" + +msgid "image:images/client-oidc-map-acr-to-loa.png[alt=\"ACR to LoA mapping\"]" +msgstr "" + +msgid "Confidential client credentials" +msgstr "" + +msgid "If the <<_access-type, Client authentication>> of the client is set to *ON*, the credentials of the client must be configured under the *Credentials* tab." +msgstr "" + +msgid "Credentials tab" +msgstr "" + +msgid "image:images/client-credentials.png[Credentials Tab]" +msgstr "" + +msgid "The *Client Authenticator* drop-down list specifies the type of credential to use for your client." +msgstr "" + +msgid "*Client ID and Secret*" +msgstr "" + +msgid "This choice is the default setting. The secret is automatically generated. Click *Regenerate* to recreate the secret if necessary." +msgstr "" + +msgid "Signed JWT" +msgstr "" + +msgid "image:images/client-credentials-jwt.png[Signed JWT]" +msgstr "" + +msgid "*Signed JWT* is \"Signed Json Web Token\"." +msgstr "" + +msgid "When choosing this credential type you will have to also generate a private key and certificate for the client in the tab `Keys`. The private key will be used to sign the JWT, while the certificate is used by the server to verify the signature." +msgstr "" + +msgid "Keys tab" +msgstr "" + +msgid "image:images/client-oidc-keys.png[Keys tab]" +msgstr "" + +msgid "Click on the `Generate new keys` button to start this process." +msgstr "" + +msgid "Generate keys" +msgstr "" + +msgid "image:images/generate-client-keys.png[]" +msgstr "" + +msgid "Select the archive format you want to use." +msgstr "" + +msgid "Enter a *key password*." +msgstr "" + +msgid "Enter a *store password*." +msgstr "" + +msgid "Click *Generate*." +msgstr "" + +msgid "When you generate the keys, {project_name} will store the certificate and you download the private key and certificate for your client." +msgstr "" + +msgid "You can also generate keys using an external tool and then import the client's certificate by clicking *Import Certificate*." +msgstr "" + +msgid "Import certificate" +msgstr "" + +msgid "image:images/import-client-cert.png[Import Certificate]" +msgstr "" + +msgid "Select the archive format of the certificate." +msgstr "" + +msgid "Enter the store password." +msgstr "" + +msgid "Select the certificate file by clicking *Import File*." +msgstr "" + +msgid "Click *Import*." +msgstr "" + +msgid "Importing a certificate is unnecessary if you click *Use JWKS URL*. In this case, you can provide the URL where the public key is published in https://datatracker.ietf.org/doc/html/rfc7517[JWK] format. With this option, if the key is ever changed, {project_name} reimports the key." +msgstr "" + +msgid "If you are using a client secured by {project_name} adapter, you can configure the JWKS URL in this format, assuming that https://myhost.com/myapp is the root URL of your client application:" +msgstr "" + +msgid "https://myhost.com/myapp/k_jwks" +msgstr "" + +msgid "See link:{developerguide_link}[{developerguide_name}] for more details." +msgstr "" + +msgid "*Signed JWT with Client Secret*" +msgstr "" + +msgid "If you select this option, you can use a JWT signed by client secret instead of the private key." +msgstr "" + +msgid "The client secret will be used to sign the JWT by the client." +msgstr "" + +msgid "*X509 Certificate*" +msgstr "" + +msgid "{project_name} will validate if the client uses proper X509 certificate during the TLS Handshake." +msgstr "" + +msgid "X509 certificate" +msgstr "" + +msgid "image:images/x509-client-auth.png[]" +msgstr "" + +msgid "The validator also checks the Subject DN field of the certificate with a configured regexp validation expression. For some use cases, it is sufficient to accept all certificates. In that case, you can use `(.*?)(?:$)` expression." +msgstr "" + +msgid "Two ways exist for {project_name} to obtain the Client ID from the request:" +msgstr "" + +msgid "The `client_id` parameter in the query (described in Section 2.2 of the https://datatracker.ietf.org/doc/html/rfc6749[OAuth 2.0 Specification])." +msgstr "" + +msgid "Supply `client_id` as a form parameter." +msgstr "" + +msgid "Client Secret Rotation" +msgstr "" + +msgid "Please note that Client Secret Rotation support is in development. Use this feature experimentally." +msgstr "" + +msgid "For a client with <<_client-credentials, Confidential>> <<_access-type, Client authentication>> {project_name} supports the functionality of rotating client secrets through <<_client_policies, Client Policies>>." +msgstr "" + +msgid "The client secrets rotation policy provides greater security in order to alleviate problems such as secret leakage. Once enabled, {project_name} supports up to two concurrently active secrets for each client. The policy manages rotations according to the following settings:" +msgstr "" + +msgid "*Secret expiration:* [seconds] - When the secret is rotated, this is the expiration of time of the new secret. The amount, _in seconds_, added to the secret creation date. Calculated at policy execution time." +msgstr "" + +msgid "*Rotated secret expiration:* [seconds] - When the secret is rotated, this value is the remaining expiration time for the old secret. This value should be always smaller than Secret expiration. When the value is 0, the old secret will be immediately removed during client rotation. The amount, _in seconds_, added to the secret rotation date. Calculated at policy execution time." +msgstr "" + +msgid "*Remaining expiration time for rotation during update:* [seconds] - Time period when an update to a dynamic client should perform client secret rotation. Calculated at policy execution time." +msgstr "" + +msgid "When a client secret rotation occurs, a new main secret is generated and the old client main secret becomes the secondary secret with a new expiration date." +msgstr "" + +msgid "Rules for client secret rotation" +msgstr "" + +msgid "Rotations do not occur automatically or through a background process. In order to perform the rotation, an update action is required on the client, either through the {project_name} Admin Console through the function of *Regenerate Secret*, in the client's credentials tab or Admin REST API. When invoking a client update action, secret rotation occurs according to the rules:" +msgstr "" + +msgid "When the value of *Secret expiration* is less than the current date." +msgstr "" + +msgid "During dynamic client registration client-update request, the client secret will be automatically rotated if the value of *Remaining expiration time for rotation during update* match the period between the current date and the *Secret expiration*." +msgstr "" + +msgid "Additionally it is possible through Admin REST API to force a client secret rotation at any time." +msgstr "" + +msgid "During the creation of new clients, if the client secret rotation policy is active, the behavior will be applied automatically." +msgstr "" + +msgid "To apply the secret rotation behavior to an existing client, update that client after you define the policy so that the behavior is applied." +msgstr "" + +msgid "Creating an OIDC Client Secret Rotation Policy" +msgstr "" + +msgid "The following is an example of defining a secret rotation policy:" +msgstr "" + +msgid "Click *Client Policies* tab." +msgstr "" + +msgid "On the *Profiles* page, click *Create client profile*." +msgstr "" + +msgid "Create a profile" +msgstr "" + +msgid "image:images/create-oidc-client-profile.png[Create Client Profile]" +msgstr "" + +msgid "Enter any name for *Name*." +msgstr "" + +msgid "Enter a description that helps you identify the purpose of the profile for *Description*." +msgstr "" + +msgid "This action creates the profile and enables you to configure executors." +msgstr "" + +msgid "Click *Add executor* to configure an executor for this profile." +msgstr "" + +msgid "Create a profile executor" +msgstr "" + +msgid "image:images/create-oidc-client-secret-rotation-executor.png[Client Profile Executor]" +msgstr "" + +msgid "Select _secret-rotation_ for *Executor Type*." +msgstr "" + +msgid "Enter the maximum duration time of each secret, in seconds, for *Secret Expiration*." +msgstr "" + +msgid "Enter the maximum duration time of each rotated secret, in seconds, for *Rotated Secret Expiration*." +msgstr "" + +msgid "Remember that the *Rotated Secret Expiration* value must always be less than *Secret Expiration*." +msgstr "" + +msgid "Enter the amount of time, in seconds, after which any update action will update the client for *Remain Expiration Time*." +msgstr "" + +msgid "In the example above:" +msgstr "" + +msgid "Each secret is valid for one week." +msgstr "" + +msgid "The rotated secret expires after two days." +msgstr "" + +msgid "The window for updating dynamic clients starts one day before the secret expires." +msgstr "" + +msgid "Return to the *Client Policies* tab." +msgstr "" + +msgid "Click *Policies*." +msgstr "" + +msgid "Click *Create client policy*." +msgstr "" + +msgid "Create the Client Secret Rotation Policy" +msgstr "" + +msgid "image:images/create-oidc-client-secret-rotation-policy.png[Client Rotation Policy]" +msgstr "" + +msgid "Enter a description that helps you identify the purpose of the policy for *Description*." +msgstr "" + +msgid "This action creates the policy and enables you to associate policies with profiles. It also allows you to configure the conditions for policy execution." +msgstr "" + +msgid "Under Conditions, click *Add condition*." +msgstr "" + +msgid "Create the Client Secret Rotation Policy Condition" +msgstr "" + +msgid "image:images/create-oidc-client-secret-rotation-condition.png[Client Rotation Policy Condition]" +msgstr "" + +msgid "To apply the behavior to all confidential clients select _client-access-type_ in the *Condition Type* field" +msgstr "" + +msgid "To apply to a specific group of clients, another approach would be to select the _client-roles_ type in the *Condition Type* field. In this way, you could create specific roles and assign a custom rotation configuration to each role." +msgstr "" + +msgid "Add _confidential_ to the field *Client Access Type*." +msgstr "" + +msgid "Back in the policy setting, under _Client Profiles_, click *Add client profile* and then select *Weekly Client Secret Rotation Profile* from the list and then click *Add*." +msgstr "" + +msgid "Client Secret Rotation Policy" +msgstr "" + +msgid "image:images/oidc-client-secret-rotation-policy.png[Client Rotation Policy]" +msgstr "" + +msgid "To apply the secret rotation behavior to an existing client, follow the following steps:" +msgstr "" + +msgid "Click a client." +msgstr "" + +msgid "Click *Re-generate* of the client secret." +msgstr "" + +msgid "Using client REST services it can be executed in two ways:" +msgstr "" + +msgid "Through an update operation on a client" +msgstr "" + +msgid "Through the regenerate client secret endpoint" +msgstr "" + +msgid "Using a service account" +msgstr "" + +msgid "Each OIDC client has a built-in _service account_. Use this _service account_ to obtain an access token." +msgstr "" + +msgid "Select your client." +msgstr "" + +msgid "Click the *Settings* tab." +msgstr "" + +msgid "Toggle <<_access-type, Client authentication>> to *On*." +msgstr "" + +msgid "Select *Service accounts roles*." +msgstr "" + +msgid "Configure your <<_client-credentials, client credentials>>." +msgstr "" + +msgid "Verify that you have roles or toggle *Full Scope Allowed* to *ON*." +msgstr "" + +msgid "Click the *Service Account Roles* tab" +msgstr "" + +msgid "Configure the roles available to this service account for your client." +msgstr "" + +msgid "Roles from access tokens are the intersection of:" +msgstr "" + +msgid "Role scope mappings of a client combined with the role scope mappings inherited from linked client scopes." +msgstr "" + +msgid "Service account roles." +msgstr "" + +msgid "The REST URL to invoke is `{kc_realms_path}/{realm-name}/protocol/openid-connect/token`. This URL must be invoked as a POST request and requires that you post the client credentials with the request." +msgstr "" + +msgid "By default, client credentials are represented by the clientId and clientSecret of the client in the *Authorization: Basic* header but you can also authenticate the client with a signed JWT assertion or any other custom mechanism for client authentication." +msgstr "" + +msgid "You also need to set the *grant_type* parameter to \"client_credentials\" as per the OAuth2 specification." +msgstr "" + +msgid "For example, the POST invocation to retrieve a service account can look like this:" +msgstr "" + +msgid "" +"\n" +" POST {kc_realms_path}/demo/protocol/openid-connect/token\n" +" Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=\n" +" Content-Type: application/x-www-form-urlencoded\n" +"\n" +" grant_type=client_credentials" +msgstr "" + +msgid "The response would be similar to this https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3[Access Token Response] from the OAuth 2.0 specification." +msgstr "" + +msgid "" +"\n" +"HTTP/1.1 200 OK\n" +"Content-Type: application/json;charset=UTF-8\n" +"Cache-Control: no-store\n" +"Pragma: no-cache\n" +"\n" +"{\n" +" \"access_token\":\"2YotnFZFEjr1zCsicMWpAA\",\n" +" \"token_type\":\"bearer\",\n" +" \"expires_in\":60\n" +"}" +msgstr "" + +msgid "Only the access token is returned by default. No refresh token is returned and no user session is created on the {project_name} side upon successful authentication by default. Due to the lack of a refresh token, re-authentication is required when the access token expires. However, this situation does not mean any additional overhead for the {project_name} server because sessions are not created by default." +msgstr "" + +msgid "In this situation, logout is unnecessary. However, issued access tokens can be revoked by sending requests to the OAuth2 Revocation Endpoint as described in the xref:con-oidc_{context}[OpenID Connect Endpoints] section." +msgstr "" + +msgid "For more details, see <<_client_credentials_grant,Client Credentials Grant>>." +msgstr "" + +msgid "Audience support" +msgstr "" + +msgid "Typically, the environment where {project_name} is deployed consists of a set of _confidential_ or _public_ client applications that use {project_name} for authentication." +msgstr "" + +msgid "_Services_ (_Resource Servers_ in the https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-08#section-4.2[OAuth 2 specification]) are also available that serve requests from client applications and provide resources to these applications. These services require an _Access token_ (Bearer token) to be sent to them to authenticate a request. This token is obtained by the frontend application upon login to {project_name}." +msgstr "" + +msgid "In the environment where trust among services is low, you may encounter this scenario:" +msgstr "" + +msgid "A frontend client application requires authentication against {project_name}." +msgstr "" + +msgid "{project_name} authenticates a user." +msgstr "" + +msgid "{project_name} issues a token to the application." +msgstr "" + +msgid "The application uses the token to invoke an untrusted service." +msgstr "" + +msgid "The untrusted service returns the response to the application. However, it keeps the applications token." +msgstr "" + +msgid "The untrusted service then invokes a trusted service using the applications token. This results in broken security as the untrusted service misuses the token to access other services on behalf of the client application." +msgstr "" + +msgid "This scenario is unlikely in environments with a high level of trust between services but not in environments where trust is low. In some environments, this workflow may be correct as the untrusted service may have to retrieve data from a trusted service to return data to the original client application." +msgstr "" + +msgid "An unlimited audience is useful when a high level of trust exists between services. Otherwise, the audience should be limited. You can limit the audience and, at the same time, allow untrusted services to retrieve data from trusted services. In this case, ensure that the untrusted service and the trusted service are added as audiences to the token." +msgstr "" + +msgid "To prevent any misuse of the access token, limit the audience on the token and configure your services to verify the audience on the token. The flow will change as follows:" +msgstr "" + +msgid "A frontend application authenticates against {project_name}." +msgstr "" + +msgid "{project_name} issues a token to the application. The application knows that it will need to invoke an untrusted service so it places *scope=* in the authentication request sent to {project_name} (see <<_client_scopes, Client Scopes section>> for more details about the _scope_ parameter)." +msgstr "" + +msgid "The token issued to the application contains a reference to the untrusted service in its audience (*\"audience\": [ \"\" ]*) which declares that the client uses this access token to invoke the untrusted service." +msgstr "" + +msgid "The untrusted service invokes a trusted service with the token. Invocation is not successful because the trusted service checks the audience on the token and find that its audience is only for the untrusted service. This behavior is expected and security is not broken." +msgstr "" + +msgid "If the client wants to invoke the trusted service later, it must obtain another token by reissuing the SSO login with *scope=*. The returned token will then contain the trusted service as an audience:" +msgstr "" + +msgid "\"audience\": [ \"\" ]" +msgstr "" + +msgid "Use this value to invoke the **." +msgstr "" + +msgid "When setting up audience checking:" +msgstr "" + +msgid "Ensure that services are configured to check audience on the access token sent to them by adding the flag *_verify-token-audience_* in the adapter configuration. See link:{adapterguide_link_latest}#_java_adapter_config[Adapter configuration] for details." +msgstr "" + +msgid "Ensure that access tokens issued by {project_name} contain all necessary audiences. Audiences can be added using the client roles as described in the <<_audience_resolve, next section>> or hardcoded. See <<_audience_hardcoded, Hardcoded audience>>." +msgstr "" + +msgid "Automatically add audience" +msgstr "" + +msgid "An _Audience Resolve_ protocol mapper is defined in the default client scope _roles_. The mapper checks for clients that have at least one client role available for the current token. The client ID of each client is then added as an audience, which is useful if your service clients rely on client roles. Service client could be usually a client without any flows enabled, which may not have any tokens issued directly to itself. It represents an OAuth 2 _Resource Server_." +msgstr "" + +msgid "For example, for a service client and a confidential client, you can use the access token issued for the confidential client to invoke the service client REST service. The service client will be automatically added as an audience to the access token issued for the confidential client if the following are true:" +msgstr "" + +msgid "The service client has any client roles defined on itself." +msgstr "" + +msgid "Target user has at least one of those client roles assigned." +msgstr "" + +msgid "Confidential client has the role scope mappings for the assigned role." +msgstr "" + +msgid "If you want to ensure that the audience is not added automatically, do not configure role scope mappings directly on the confidential client. Instead, you can create a dedicated client scope that contains the role scope mappings for the client roles of your dedicated client scope." +msgstr "" + +msgid "Assuming that the client scope is added as an optional client scope to the confidential client, the client roles and the audience will be added to the token if explicitly requested by the *scope=* parameter." +msgstr "" + +msgid "The frontend client itself is not automatically added to the access token audience, therefore allowing easy differentiation between the access token and the ID token, since the access token will not contain the client for which the token is issued as an audience." +msgstr "" + +msgid "If you need the client itself as an audience, see the <<_audience_hardcoded, hardcoded audience>> option. However, using the same client as both frontend and REST service is not recommended." +msgstr "" + +msgid "Hardcoded audience" +msgstr "" + +msgid "When your service relies on realm roles or does not rely on the roles in the token at all, it can be useful to use a hardcoded audience. A hardcoded audience is a protocol mapper, that will add the client ID of the specified service client as an audience to the token. You can use any custom value, for example a URL, if you want to use a different audience than the client ID." +msgstr "" + +msgid "You can add the protocol mapper directly to the frontend client. If the protocol mapper is added directly, the audience will always be added as well." +msgstr "" + +msgid "For more control over the protocol mapper, you can create the protocol mapper on the dedicated client scope, which will be called for example *good-service*." +msgstr "" + +msgid "Audience protocol mapper" +msgstr "" + +msgid "image:images/audience_mapper.png[]" +msgstr "" + +msgid "From the <<_client_installation, Client details tab>> of the *good-service* client, you can generate the adapter configuration and confirm that _verify-token-audience_ is set to *true*. This action forces the adapter to verify the audience if you use this configuration." +msgstr "" + +msgid "You need to ensure that the confidential client is able to request *good-service* as an audience in its tokens." +msgstr "" + +msgid "On the confidential client:" +msgstr "" + +msgid "Click the _Client Scopes_ tab." +msgstr "" + +msgid "Assign *good-service* as an optional (or default) client scope." +msgstr "" + +msgid "See <<_client_scopes_linking, Client Scopes Linking section>> for more details." +msgstr "" + +msgid "You can optionally <<_client_scopes_evaluate, Evaluate Client Scopes>> and generate an example access token. *good-service* will be added to the audience of the generated access token if *good-service* is included in the _scope_ parameter, when you assigned it as an optional client scope." +msgstr "" + +msgid "In your confidential client application, ensure that the _scope_ parameter is used. The value *good-service* must be included when you want to issue the token for accessing *good-service*." +msgstr "" + +msgid "See:" +msgstr "" + +msgid "link:{adapterguide_link}#_params_forwarding[parameters forwarding section] if your application uses the servlet adapter." +msgstr "" + +msgid "link:{adapterguide_link}#_javascript_adapter[javascript adapter section] if your application uses the javascript adapter." +msgstr "" + +msgid "Both the _Audience_ and _Audience Resolve_ protocol mappers add the audiences to the access token only, by default. The ID Token typically contains only a single audience, the client ID for which the token was issued, a requirement of the OpenID Connect specification. However, the access token does not necessarily have the client ID, which was the token issued for, unless the audience mappers added it." +msgstr "" + +msgid "Creating a SAML client" +msgstr "" + +msgid "{project_name} supports <<_saml,SAML 2.0>> for registered applications. POST and Redirect bindings are supported. You can choose to require client signature validation. You can have the server sign and/or encrypt responses as well." +msgstr "" + +msgid "Click *Create client* to go to the *Create client* page." +msgstr "" + +msgid "Set *Client type* to *SAML*." +msgstr "" + +msgid "image:images/add-client-saml.png[]" +msgstr "" + +msgid "Enter the *Client ID* of the client. This is often a URL and is the expected *issuer* value in SAML requests sent by the application." +msgstr "" + +msgid "Click *Save*. This action creates the client and brings you to the *Settings* tab." +msgstr "" + +msgid "The following sections describe each setting on this tab." +msgstr "" + +msgid "Client settings" +msgstr "" + +msgid "image:images/client-settings-saml.png[]" +msgstr "" + +msgid "General settings" +msgstr "" + +msgid "The alphanumeric ID string that is used in OIDC requests and in the {project_name} database to identify the client. This value must match the issuer value sent with AuthNRequests. {project_name} pulls the issuer from the Authn SAML request and match it to a client by this value." +msgstr "" + +msgid "The name for the client in a {project_name} UI screen. To localize the name, set up a replacement string value. For example, a string value such as $\\{myapp}. See the link:{developerguide_link}[{developerguide_name}] for more information." +msgstr "" + +msgid "When {project_name} uses a configured relative URL, this value is prepended to the URL." +msgstr "" + +msgid "If {project_name} needs to link to a client, this URL is used." +msgstr "" + +msgid "Enter a URL pattern and click the + sign to add. Click the - sign to remove. Click *Save* to save these changes. Wildcards values are allowed only at the end of a URL. For example, http://host.com/*$$. This field is used when the exact SAML endpoints are not registered and {project_name} pulls the Assertion Consumer URL from a request." +msgstr "" + +msgid "*IDP-Initiated SSO URL name*" +msgstr "" + +msgid "URL fragment name to reference client when you want to do IDP Initiated SSO. Leaving this empty will disable IDP Initiated SSO. The URL you will reference from your browser will be: _server-root_/realms/{realm}/protocol/saml/clients/{client-url-name}" +msgstr "" + +msgid "*IDP Initiated SSO Relay State*" +msgstr "" + +msgid "Relay state you want to send with SAML request when you want to do IDP Initiated SSO." +msgstr "" + +msgid "*Master SAML Processing URL*" +msgstr "" + +msgid "This URL is used for all SAML requests and the response is directed to the SP. It is used as the Assertion Consumer Service URL and the Single Logout Service URL." +msgstr "" + +msgid "If login requests contain the Assertion Consumer Service URL then those login requests will take precedence. This URL must be validated by a registered Valid Redirect URI pattern." +msgstr "" + +msgid "SAML capabilities" +msgstr "" + +msgid "*Name ID Format*" +msgstr "" + +msgid "The Name ID Format for the subject. This format is used if no name ID policy is specified in a request, or if the Force Name ID Format attribute is set to ON." +msgstr "" + +msgid "*Force Name ID Format*" +msgstr "" + +msgid "If a request has a name ID policy, ignore it and use the value configured in the Admin Console under *Name ID Format*." +msgstr "" + +msgid "*Force POST Binding*" +msgstr "" + +msgid "By default, {project_name} responds using the initial SAML binding of the original request. By enabling *Force POST Binding*, {project_name} responds using the SAML POST binding even if the original request used the redirect binding." +msgstr "" + +msgid "*Force artifact binding*" +msgstr "" + +msgid "If enabled, response messages are returned to the client through the SAML ARTIFACT binding system." +msgstr "" + +msgid "*Include AuthnStatement*" +msgstr "" + +msgid "SAML login responses may specify the authentication method used, such as password, as well as timestamps of the login and the session expiration. *Include AuthnStatement* is enabled by default, so that the *AuthnStatement* element will be included in login responses. Setting this to OFF prevents clients from determining the maximum session length, which can create client sessions that do not expire." +msgstr "" + +msgid "*Include OneTimeUse Condition*" +msgstr "" + +msgid "If enable, a OneTimeUse Condition is included in login responses." +msgstr "" + +msgid "*Optimize REDIRECT signing key lookup*" +msgstr "" + +msgid "When set to ON, the SAML protocol messages include the {project_name} native extension. This extension contains a hint with the signing key ID. The SP uses the extension for signature validation instead of attempting to validate the signature using keys." +msgstr "" + +msgid "This option applies to REDIRECT bindings where the signature is transferred in query parameters and this information is not found in the signature information. This is contrary to POST binding messages where key ID is always included in document signature." +msgstr "" + +msgid "This option is used when {project_name} server and adapter provide the IDP and SP. This option is only relevant when *Sign Documents* is set to ON." +msgstr "" + +msgid "Signature and Encryption" +msgstr "" + +msgid "*Sign Documents*" +msgstr "" + +msgid "When set to ON, {project_name} signs the document using the realms private key." +msgstr "" + +msgid "*Sign Assertions*" +msgstr "" + +msgid "The assertion is signed and embedded in the SAML XML Auth response." +msgstr "" + +msgid "*Signature Algorithm*" +msgstr "" + +msgid "The algorithm used in signing SAML documents. Note that `SHA1` based algorithms are deprecated and may be removed in a future release. We recommend the use of some more secure algorithm instead of `*_SHA1`. Also, with `*_SHA1` algorithms, verifying signatures do not work if the SAML client runs on Java 17 or higher." +msgstr "" + +msgid "*SAML Signature Key Name*" +msgstr "" + +msgid "Signed SAML documents sent using POST binding contain the identification of the signing key in the *KeyName* element. This action can be controlled by the *SAML Signature Key Name* option. This option controls the contents of the *Keyname*." +msgstr "" + +msgid "*KEY_ID* The *KeyName* contains the key ID. This option is the default option." +msgstr "" + +msgid "*CERT_SUBJECT* The *KeyName* contains the subject from the certificate corresponding to the realm key. This option is expected by Microsoft Active Directory Federation Services." +msgstr "" + +msgid "*NONE* The *KeyName* hint is completely omitted from the SAML message." +msgstr "" + +msgid "*Canonicalization Method*" +msgstr "" + +msgid "The canonicalization method for XML signatures." +msgstr "" + +msgid "If *Front Channel Logout* is enabled, the application requires a browser redirect to perform a logout. For example, the application may require a cookie to be reset which could only be done via a redirect. If *Front Channel Logout* is disabled, {project_name} invokes a background SAML request to log out of the application." +msgstr "" + +msgid "*Encrypt Assertions*" +msgstr "" + +msgid "Encrypts the assertions in SAML documents with the realms private key. The AES algorithm uses a key size of 128 bits." +msgstr "" + +msgid "*Client Signature Required*" +msgstr "" + +msgid "If *Client Signature Required* is enabled, documents coming from a client are expected to be signed. {project_name} will validate this signature using the client public key or cert set up in the `Keys` tab." +msgstr "" + +msgid "*Allow ECP Flow*" +msgstr "" + +msgid "If true, this application is allowed to use SAML ECP profile for authentication." +msgstr "" + +msgid "This tab has many fields for specific situations. Some fields are covered in other topics. For details on other fields, click the question mark icon." +msgstr "" + +msgid "Fine Grain SAML Endpoint Configuration" +msgstr "" + +msgid "*Assertion Consumer Service POST Binding URL*" +msgstr "" + +msgid "POST Binding URL for the Assertion Consumer Service." +msgstr "" + +msgid "*Assertion Consumer Service Redirect Binding URL*" +msgstr "" + +msgid "Redirect Binding URL for the Assertion Consumer Service." +msgstr "" + +msgid "*Logout Service POST Binding URL*" +msgstr "" + +msgid "POST Binding URL for the Logout Service." +msgstr "" + +msgid "*Logout Service Redirect Binding URL*" +msgstr "" + +msgid "Redirect Binding URL for the Logout Service." +msgstr "" + +msgid "*Logout Service Artifact Binding URL*" +msgstr "" + +msgid "_Artifact_ Binding URL for the Logout Service. When set together with the `Force Artifact Binding` option, _Artifact_ binding is forced for both login and logout flows. _Artifact_ binding is not used for logout unless this property is set." +msgstr "" + +msgid "*Logout Service SOAP Binding URL*" +msgstr "" + +msgid "Redirect Binding URL for the Logout Service. Only applicable if *back channel logout* is used." +msgstr "" + +msgid "*Artifact Binding URL*" +msgstr "" + +msgid "URL to send the HTTP artifact messages to." +msgstr "" + +msgid "*Artifact Resolution Service*" +msgstr "" + +msgid "URL of the client SOAP endpoint where to send the `ArtifactResolve` messages to." +msgstr "" + +msgid "IDP Initiated login" +msgstr "" + +msgid "IDP Initiated Login is a feature that allows you to set up an endpoint on the {project_name} server that will log you into a specific application/client. In the *Settings* tab for your client, you need to specify the *IDP Initiated SSO URL Name*. This is a simple string with no whitespace in it. After this you can reference your client at the following URL: `root{kc_realms_path}/{realm}/protocol/saml/clients/{url-name}`" +msgstr "" + +msgid "The IDP initiated login implementation prefers _POST_ over _REDIRECT_ binding (check <<_saml, saml bindings>> for more information). Therefore the final binding and SP URL are selected in the following way:" +msgstr "" + +msgid "If the specific *Assertion Consumer Service POST Binding URL* is defined (inside *Fine Grain SAML Endpoint Configuration* section of the client settings) _POST_ binding is used through that URL." +msgstr "" + +msgid "If the general *Master SAML Processing URL* is specified then _POST_ binding is used again throughout this general URL." +msgstr "" + +msgid "As the last resort, if the *Assertion Consumer Service Redirect Binding URL* is configured (inside *Fine Grain SAML Endpoint Configuration*) _REDIRECT_ binding is used with this URL." +msgstr "" + +msgid "If your client requires a special relay state, you can also configure this on the *Settings* tab in the *IDP Initiated SSO Relay State* field. Alternatively, browsers can specify the relay state in a *RelayState* query parameter, i.e. `root{kc_realms_path}/{realm}/protocol/saml/clients/{url-name}?RelayState=thestate`." +msgstr "" + +msgid "When using <<_identity_broker,identity brokering>>, it is possible to set up an IDP Initiated Login for a client from an external IDP. The actual client is set up for IDP Initiated Login at broker IDP as described above. The external IDP has to set up the client for application IDP Initiated Login that will point to a special URL pointing to the broker and representing IDP Initiated Login endpoint for a selected client at the brokering IDP. This means that in client settings at the external IDP:" +msgstr "" + +msgid "*IDP Initiated SSO URL Name* is set to a name that will be published as IDP Initiated Login initial point," +msgstr "" + +msgid "*Assertion Consumer Service POST Binding URL* in the *Fine Grain SAML Endpoint Configuration* section has to be set to the following URL: `broker-root{kc_realms_path}/{broker-realm}/broker/{idp-name}/endpoint/clients/{client-id}`, where:" +msgstr "" + +msgid "_broker-root_ is base broker URL" +msgstr "" + +msgid "_broker-realm_ is name of the realm at broker where external IDP is declared" +msgstr "" + +msgid "_idp-name_ is name of the external IDP at broker" +msgstr "" + +msgid "_client-id_ is the value of *IDP Initiated SSO URL Name* attribute of the SAML client defined at broker. It is this client, which will be made available for IDP Initiated Login from the external IDP." +msgstr "" + +msgid "Please note that you can import basic client settings from the brokering IDP into client settings of the external IDP - just use <<_identity_broker_saml_sp_descriptor,SP Descriptor>> available from the settings of the identity provider in the brokering IDP, and add `clients/_client-id_` to the endpoint URL." +msgstr "" + +msgid "Using an entity descriptor to create a client" +msgstr "" + +msgid "Instead of registering a SAML 2.0 client manually, you can import the client using a standard SAML Entity Descriptor XML file." +msgstr "" + +msgid "The Client page includes an *Import client* option." +msgstr "" + +msgid "Add client" +msgstr "" + +msgid "image:images/import-client-saml.png[Import SAML client]" +msgstr "" + +msgid "Click *Browse*." +msgstr "" + +msgid "Load the file that contains the XML entity descriptor information." +msgstr "" + +msgid "Review the information to ensure everything is set up correctly." +msgstr "" + +msgid "Some SAML client adapters, such as _mod-auth-mellon_, need the XML Entity Descriptor for the IDP. You can find this descriptor by going to this URL:" +msgstr "" + +msgid "root{kc_realms_path}/{realm}/protocol/saml/descriptor" +msgstr "" + +msgid "where _realm_ is the realm of your client." +msgstr "" + +msgid "Client links" +msgstr "" + +msgid "To link from one client to another, {project_name} provides a redirect endpoint: `/realms/realm_name/clients/\\{client-id}/redirect`." +msgstr "" + +msgid "If a client accesses this endpoint using a `HTTP GET` request, {project_name} returns the configured base URL for the provided Client and Realm in the form of an `HTTP 307` (Temporary Redirect) in the response's `Location` header. As a result of this, a client needs only to know the Realm name and the Client ID to link to them. This indirection avoids hard-coding client base URLs." +msgstr "" + +msgid "As an example, given the realm `master` and the client-id `account`:" +msgstr "" + +msgid "http://host:port{kc_realms_path}/master/clients/account/redirect" +msgstr "" + +msgid "This URL temporarily redirects to: http://host:port{kc_realms_path}/master/account" +msgstr "" + +msgid "OIDC token and SAML assertion mappings" +msgstr "" + +msgid "Applications receiving ID tokens, access tokens, or SAML assertions may require different roles and user metadata." +msgstr "" + +msgid "You can use {project_name} to:" +msgstr "" + +msgid "Hardcode roles, claims and custom attributes." +msgstr "" + +msgid "Pull user metadata into a token or assertion." +msgstr "" + +msgid "Rename roles." +msgstr "" + +msgid "You perform these actions in the *Mappers* tab in the Admin Console." +msgstr "" + +msgid "Mappers tab" +msgstr "" + +msgid "image:images/mappers-oidc.png[]" +msgstr "" + +msgid "New clients do not have built-in mappers but they can inherit some mappers from client scopes. See the <<_client_scopes, client scopes section>> for more details." +msgstr "" + +msgid "Protocol mappers map items (such as an email address, for example) to a specific claim in the identity and access token. The function of a mapper should be self-explanatory from its name. You add pre-configured mappers by clicking *Add Builtin*." +msgstr "" + +msgid "Each mapper has a set of common settings. Additional settings are available, depending on the mapper type. Click *Edit* next to a mapper to access the configuration screen to adjust these settings." +msgstr "" + +msgid "Mapper config" +msgstr "" + +msgid "image:images/mapper-config.png[]" +msgstr "" + +msgid "Details on each option can be viewed by hovering over its tooltip." +msgstr "" + +msgid "You can use most OIDC mappers to control where the claim gets placed. You opt to include or exclude the claim from the _id_ and _access_ tokens by adjusting the *Add to ID token* and *Add to access token* switches." +msgstr "" + +msgid "You can add mapper types as follows:" +msgstr "" + +msgid "Go to the *Mappers* tab." +msgstr "" + +msgid "Click *Configure a new mapper*." +msgstr "" + +msgid "Add mapper" +msgstr "" + +msgid "image:images/add-mapper.png[]" +msgstr "" + +msgid "Select a *Mapper Type* from the list box." +msgstr "" + +msgid "Priority order" +msgstr "" + +msgid "Mapper implementations have _priority order_. _Priority order_ is not the configuration property of the mapper. It is the property of the concrete implementation of the mapper." +msgstr "" + +msgid "Mappers are sorted by the order in the list of mappers. The changes in the token or assertion are applied in that order with the lowest applying first. Therefore, the implementations that are dependent on other implementations are processed in the necessary order." +msgstr "" + +msgid "For example, to compute the roles which will be included with a token:" +msgstr "" + +msgid "Resolve audiences based on those roles." +msgstr "" + +msgid "Process a JavaScript script that uses the roles and audiences already available in the token." +msgstr "" + +msgid "OIDC user session note mappers" +msgstr "" + +msgid "User session details are defined using mappers and are automatically included when you use or enable a feature on a client. Click *Add builtin* to include session details." +msgstr "" + +msgid "Impersonated user sessions provide the following details:" +msgstr "" + +msgid "*IMPERSONATOR_ID*: The ID of an impersonating user." +msgstr "" + +msgid "*IMPERSONATOR_USERNAME*: The username of an impersonating user." +msgstr "" + +msgid "Service account sessions provide the following details:" +msgstr "" + +msgid "*clientId*: The client ID of the service account." +msgstr "" + +msgid "*client_id*: The client ID of the service account." +msgstr "" + +msgid "*clientAddress*: The remote host IP of the service account's authenticated device." +msgstr "" + +msgid "*clientHost*: The remote host name of the service account's authenticated device." +msgstr "" + +msgid "Script mapper" +msgstr "" + +msgid "Use the *Script Mapper* to map claims to tokens by running user-defined JavaScript code. For more details about deploying scripts to the server, see link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}]." +msgstr "" + +msgid "When scripts deploy, you should be able to select the deployed scripts from the list of available mappers." +msgstr "" + +msgid "Generating client adapter config" +msgstr "" + +msgid "{project_name} can generate configuration files that you can use to install a client adapter in your application's deployment environment. A number of adapter types are supported for OIDC and SAML." +msgstr "" + +msgid "Click on the _Action_ menu and select the *Download adapter config* option" +msgstr "" + +msgid "image:images/client-installation.png[]" +msgstr "" + +msgid "Select the *Format Option* you want configuration generated for." +msgstr "" + +msgid "All {project_name} client adapters for OIDC and SAML are supported. The mod-auth-mellon Apache HTTPD adapter for SAML is supported as well as standard SAML entity descriptor files." +msgstr "" + +msgid "Client scopes" +msgstr "" + +msgid "Use {project_name} to define a shared client configuration in an entity called a _client scope_. A _client scope_ configures <<_protocol-mappers, protocol mappers>> and <<_role_scope_mappings, role scope mappings>> for multiple clients." +msgstr "" + +msgid "Client scopes also support the OAuth 2 *scope* parameter. Client applications use this parameter to request claims or roles in the access token, depending on the requirement of the application." +msgstr "" + +msgid "To create a client scope, follow these steps:" +msgstr "" + +msgid "Click *Client Scopes* in the menu." +msgstr "" + +msgid "Client scopes list" +msgstr "" + +msgid "image:images/client-scopes-list.png[]" +msgstr "" + +msgid "Name your client scope." +msgstr "" + +msgid "A _client scope_ has similar tabs to regular clients. You can define <<_protocol-mappers, protocol mappers>> and <<_role_scope_mappings, role scope mappings>>. These mappings can be inherited by other clients and are configured to inherit from this client scope." +msgstr "" + +msgid "Protocol" +msgstr "" + +msgid "When you create a client scope, choose the *Protocol*. Clients linked in the same scope must have the same protocol." +msgstr "" + +msgid "Each realm has a set of pre-defined built-in client scopes in the menu." +msgstr "" + +msgid "SAML protocol: The *role_list*. This scope contains one protocol mapper for the roles list in the SAML assertion." +msgstr "" + +msgid "OpenID Connect protocol: Several client scopes are available:" +msgstr "" + +msgid "*roles*" +msgstr "" + +msgid "This scope is not defined in the OpenID Connect specification and is not added automatically to the *scope* claim in the access token. This scope has mappers, which are used to add the roles of the user to the access token and add audiences for clients that have at least one client role. These mappers are described in more detail in the <<_audience_resolve, Audience section>>." +msgstr "" + +msgid "*web-origins*" +msgstr "" + +msgid "This scope is also not defined in the OpenID Connect specification and not added to the *scope* claiming the access token. This scope is used to add allowed web origins to the access token *allowed-origins* claim." +msgstr "" + +msgid "*microprofile-jwt*" +msgstr "" + +msgid "This scope handles claims defined in the https://wiki.eclipse.org/MicroProfile/JWT_Auth[MicroProfile/JWT Auth Specification]. This scope defines a user property mapper for the *upn* claim and a realm role mapper for the *groups* claim. These mappers can be changed so different properties can be used to create the MicroProfile/JWT specific claims." +msgstr "" + +msgid "*offline_access*" +msgstr "" + +msgid "This scope is used in cases when clients need to obtain offline tokens. More details on offline tokens is available in the <<_offline-access, Offline Access section>> and in the https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess[OpenID Connect specification]." +msgstr "" + +msgid "*profile*" +msgstr "" + +msgid "*email*" +msgstr "" + +msgid "*address*" +msgstr "" + +msgid "*phone*" +msgstr "" + +msgid "The client scopes *profile*, *email*, *address* and *phone* are defined in the https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims[OpenID Connect specification]. These scopes do not have any role scope mappings defined but they do have protocol mappers defined. These mappers correspond to the claims defined in the OpenID Connect specification." +msgstr "" + +msgid "For example, when you open the *phone* client scope and open the *Mappers* tab, you will see the protocol mappers which correspond to the claims defined in the specification for the scope *phone*." +msgstr "" + +msgid "Client scope mappers" +msgstr "" + +msgid "image:images/client-scopes-phone.png[]" +msgstr "" + +msgid "When the *phone* client scope is linked to a client, the client automatically inherits all the protocol mappers defined in the *phone* client scope. Access tokens issued for this client contain the phone number information about the user, assuming that the user has a defined phone number." +msgstr "" + +msgid "Built-in client scopes contain the protocol mappers as defined in the specification. You are free to edit client scopes and create, update, or remove any protocol mappers or role scope mappings." +msgstr "" + +msgid "Consent related settings" +msgstr "" + +msgid "Client scopes contain options related to the consent screen. Those options are useful if the linked client if *Consent Required* is enabled on the client." +msgstr "" + +msgid "Display On Consent Screen" +msgstr "" + +msgid "If *Display On Consent Screen* is enabled, and the scope is added to a client that requires consent, the text specified in *Consent Screen Text* will be displayed on the consent screen. This text is shown when the user is authenticated and before the user is redirected from {project_name} to the client. If *Display On Consent Screen* is disabled, this client scope will not be displayed on the consent screen." +msgstr "" + +msgid "Consent Screen Text" +msgstr "" + +msgid "The text displayed on the consent screen when this client scope is added to a client when consent required defaults to the name of client scope. The value for this text can be customised by specifying a substitution variable with *${var-name}* strings. The customised value is configured within the property files in your theme. See the link:{developerguide_link}[{developerguide_name}] for more information on customisation." +msgstr "" + +msgid "Link client scope with the client" +msgstr "" + +msgid "Linking between a client scope and a client is configured in the *Client Scopes* tab of the client. Two ways of linking between client scope and client are available." +msgstr "" + +msgid "Default Client Scopes" +msgstr "" + +msgid "This setting is applicable to the OpenID Connect and SAML clients. Default client scopes are applied when issuing OpenID Connect tokens or SAML assertions for a client. The client will inherit Protocol Mappers and Role Scope Mappings that are defined on the client scope. For the OpenID Connect Protocol, the Mappers and Role Scope Mappings are always applied, regardless of the value used for the scope parameter in the OpenID Connect authorization request." +msgstr "" + +msgid "Optional Client Scopes" +msgstr "" + +msgid "This setting is applicable only for OpenID Connect clients. Optional client scopes are applied when issuing tokens for this client but only when requested by the *scope* parameter in the OpenID Connect authorization request." +msgstr "" + +msgid "Example" +msgstr "" + +msgid "For this example, assume the client has *profile* and *email* linked as default client scopes, and *phone* and *address* linked as optional client scopes. The client uses the value of the scope parameter when sending a request to the OpenID Connect authorization endpoint." +msgstr "" + +msgid "scope=openid phone" +msgstr "" + +msgid "The scope parameter contains the string, with the scope values divided by spaces. The value *openid* is the meta-value used for all OpenID Connect requests. The token will contain mappers and role scope mappings from the default client scopes *profile* and *email* as well as *phone*, an optional client scope requested by the scope parameter." +msgstr "" + +msgid "Evaluating Client Scopes" +msgstr "" + +msgid "The *Mappers* tab contains the protocol mappers and the *Scope* tab contains the role scope mappings declared for this client. They do not contain the mappers and scope mappings inherited from client scopes. It is possible to see the effective protocol mappers (that is the protocol mappers defined on the client itself as well as inherited from the linked client scopes) and the effective role scope mappings used when generating a token for a client." +msgstr "" + +msgid "Click the *Client Scopes* tab for the client." +msgstr "" + +msgid "Open the sub-tab *Evaluate*." +msgstr "" + +msgid "Select the optional client scopes that you want to apply." +msgstr "" + +msgid "This will also show you the value of the *scope* parameter. This parameter needs to be sent from the application to the {project_name} OpenID Connect authorization endpoint." +msgstr "" + +msgid "Evaluating client scopes" +msgstr "" + +msgid "image:images/client-scopes-evaluate.png[]" +msgstr "" + +msgid "To send a custom value for a *scope* parameter from your application, see the link:{adapterguide_link_latest}#_params_forwarding[parameters forwarding section], for servlet adapters or the link:{adapterguide_link_latest}#_javascript_adapter[javascript adapter section], for javascript adapters." +msgstr "" + +msgid "All examples are generated for the particular user and issued for the particular client, with the specified value of the *scope* parameter. The examples include all of the claims and role mappings used." +msgstr "" + +msgid "Client scopes permissions" +msgstr "" + +msgid "When issuing tokens to a user, the client scope applies only if the user is permitted to use it." +msgstr "" + +msgid "When a client scope does not have any role scope mappings defined, each user is permitted to use this client scope. However, when a client scope has role scope mappings defined, the user must be a member of at least one of the roles. There must be an intersection between the user roles and the roles of the client scope. Composite roles are factored into evaluating this intersection." +msgstr "" + +msgid "If a user is not permitted to use the client scope, no protocol mappers or role scope mappings will be used when generating tokens. The client scope will not appear in the _scope_ value in the token." +msgstr "" + +msgid "Realm default client scopes" +msgstr "" + +msgid "Use *Realm Default Client Scopes* to define sets of client scopes that are automatically linked to newly created clients." +msgstr "" + +msgid "From here, select the client scopes that you want to add as *Default Client Scopes* to newly created clients and *Optional Client Scopes*." +msgstr "" + +msgid "Default client scopes" +msgstr "" + +msgid "image:images/client-scopes-default.png[]" +msgstr "" + +msgid "When a client is created, you can unlink the default client scopes, if needed. This is similar to removing <<_default_roles, Default Roles>>." +msgstr "" + +msgid "Scopes explained" +msgstr "" + +msgid "Client scope" +msgstr "" + +msgid "Client scopes are entities in {project_name} that are configured at the realm level and can be linked to clients. Client scopes are referenced by their name when a request is sent to the {project_name} authorization endpoint with a corresponding value of the *scope* parameter. See the <<_client_scopes_linking, client scopes linking>> section for more details." +msgstr "" + +msgid "Role scope mapping" +msgstr "" + +msgid "This is available under the *Scope* tab of a client or client scope. Use *Role scope mapping* to limit the roles that can be used in the access tokens. See the <<_role_scope_mappings, Role Scope Mappings section>> for more details." +msgstr "" + +msgid "Authorization scopes" +msgstr "" + +msgid "The *Authorization Scope* covers the actions that can be performed in the application. See the link:{authorizationguide_link}[Authorization Services Guide] for more details." +msgstr "" + +msgid "Client Policies" +msgstr "" + +msgid "To make it easy to secure client applications, it is beneficial to realize the following points in a unified way." +msgstr "" + +msgid "Setting policies on what configuration a client can have" +msgstr "" + +msgid "Validation of client configurations" +msgstr "" + +msgid "Conformance to a required security standards and profiles such as Financial-grade API (FAPI)" +msgstr "" + +msgid "To realize these points in a unified way, _Client Policies_ concept is introduced." +msgstr "" + +msgid "Use-cases" +msgstr "" + +msgid "Client Policies realize the following points mentioned as follows." +msgstr "" + +msgid "Configuration settings on the client can be enforced by client policies during client creation/update, but also during OpenID Connect requests to {project_name} server, which are related to particular client. {project_name} supports similar thing also through the Client Registration Policies described in the link:{adapterguide_link}#_client_registration_policies[{adapterguide_name}]. However, Client Registration Policies can only cover OIDC Dynamic Client Registration. Client Policies cover not only what Client Registration Policies can do, but other client registration and configuration ways. The current plans are for Client Registration to be replaced by Client Policies." +msgstr "" + +msgid "{project_name} supports validation whether the client follows settings like Proof Key for Code Exchange, Request Object Signing Algorithm, Holder-of-Key Token, and so on some endpoints like Authorization Endpoint, Token Endpoint, and so on. These can be specified by each setting item (on Admin Console, switch, pull-down menu and so on). To make the client application secure, the administrator needs to set many settings in the appropriate way, which makes it difficult for the administrator to secure the client application. Client Policies can do these validation of client configurations mentioned just above and they can also be used to autoconfigure some client configuration switches to meet the advanced security requirements. In the future, individual client configuration settings may be replaced by Client Policies directly performing required validations." +msgstr "" + +msgid "Conformance to a required security standards and profiles such as FAPI" +msgstr "" + +msgid "The _Global client profiles_ are client profiles pre-configured in {project_name} by default. They are pre-configured to be compliant with standard security profiles like link:{adapterguide_link}#_fapi-support[FAPI], which makes it easy for the administrator to secure their client application to be compliant with the particular security profile. At this moment, {project_name} has global profiles for the support of FAPI specifications. The administrator will just need to configure the client policies to specify which clients should be compliant with the FAPI. The administrator can configure client profiles and client policies, so that {project_name} clients can be easily made compliant with various other security profiles like SPA, Native App, Open Banking and so on." +msgstr "" + +msgid "The client policy concept is independent of any specific protocol. However, {project_name} currently supports it only just for the link:{adapterguide_link}#_oidc[OpenID Connect (OIDC) protocol]." +msgstr "" + +msgid "Architecture" +msgstr "" + +msgid "Client Policies consists of the four building blocks: Condition, Executor, Profile and Policy." +msgstr "" + +msgid "Condition" +msgstr "" + +msgid "A condition determines to which client a policy is adopted and when it is adopted. Some conditions are checked at the time of client create/update when some other conditions are checked during client requests (OIDC Authorization request, Token endpoint request and so on). The condition checks whether one specified criteria is satisfied. For example, some condition checks whether the access type of the client is confidential." +msgstr "" + +msgid "The condition can not be used solely by itself. It can be used in a <<_client_policy_policy,policy>> that is described afterwards." +msgstr "" + +msgid "A condition can be configurable the same as other configurable providers. What can be configured depends on each condition's nature." +msgstr "" + +msgid "The following conditions are provided:" +msgstr "" + +msgid "The way of creating/updating a client" +msgstr "" + +msgid "Dynamic Client Registration (Anonymous or Authenticated with Initial access token or Registration access token)" +msgstr "" + +msgid "Admin REST API (Admin Console and so on)" +msgstr "" + +msgid "So for example when creating a client, a condition can be configured to evaluate to true when this client is created by OIDC Dynamic Client Registration without initial access token (Anonymous Dynamic Client Registration). So this condition can be used for example to ensure that all clients registered through OIDC Dynamic Client Registration are FAPI compliant." +msgstr "" + +msgid "Author of a client (Checked by presence to the particular role or group)" +msgstr "" + +msgid "On OpenID Connect dynamic client registration, an author of a client is the end user who was authenticated to get an access token for generating a new client, not Service Account of the existing client that actually accesses the registration endpoint with the access token. On registration by Admin REST API, an author of a client is the end user like the administrator of the {project_name}." +msgstr "" + +msgid "Client Access Type (confidential, public, bearer-only)" +msgstr "" + +msgid "For example when a client sends an authorization request, a policy is adopted if this client is confidential. Confidential client has enabled client authentication when public client has disabled client authentication. Bearer-only is a deprecated client type." +msgstr "" + +msgid "Client Scope" +msgstr "" + +msgid "Evaluates to true if the client has a particular client scope (either as default or as an optional scope used in current request). This can be used for example to ensure that OIDC authorization requests with scope `fapi-example-scope` need to be FAPI compliant." +msgstr "" + +msgid "Client Role" +msgstr "" + +msgid "Applies for clients with the client role of the specified name" +msgstr "" + +msgid "Client Domain Name, Host or IP Address" +msgstr "" + +msgid "Applied for specific domain names of client. Or for the cases when the administrator registers/updates client from particular Host or IP Address." +msgstr "" + +msgid "Any Client" +msgstr "" + +msgid "This condition always evaluates to true. It can be used for example to ensure that all clients in the particular realm are FAPI compliant." +msgstr "" + +msgid "Executor" +msgstr "" + +msgid "An executor specifies what action is executed on a client to which a policy is adopted. The executor executes one or several specified actions. For example, some executor checks whether the value of the parameter `redirect_uri` in the authorization request matches exactly with one of the pre-registered redirect URIs on Authorization Endpoint and rejects this request if not." +msgstr "" + +msgid "The executor can not be used solely by itself. It can be used in a <<_client_policy_profile,profile>> that is described afterwards." +msgstr "" + +msgid "An executor can be configurable the same as other configurable providers. What can be configured depends on the nature of each executor." +msgstr "" + +msgid "An executor acts on various events. An executor implementation can ignore certain types of events (For example, executor for checking OIDC `request` object acts just on the OIDC authorization request). Events are:" +msgstr "" + +msgid "Creating a client (including creation through dynamic client registration)" +msgstr "" + +msgid "Updating a client" +msgstr "" + +msgid "Sending an authorization request" +msgstr "" + +msgid "Sending a token request" +msgstr "" + +msgid "Sending a token refresh request" +msgstr "" + +msgid "Sending a token revocation request" +msgstr "" + +msgid "Sending a token introspection request" +msgstr "" + +msgid "Sending a userinfo request" +msgstr "" + +msgid "Sending a logout request with a refresh token" +msgstr "" + +msgid "On each event, an executor can work in multiple phases. For example, on creating/updating a client, the executor can modify the client configuration by autoconfigure specific client settings. After that, the executor validates this configuration in validation phase." +msgstr "" + +msgid "One of several purposes for this executor is to realize the security requirements of client conformance profiles like FAPI. To do so, the following executors are needed:" +msgstr "" + +msgid "Enforce secure <<_client-credentials,Client Authentication method>> is used for the client" +msgstr "" + +msgid "Enforce <<_mtls-client-certificate-bound-tokens,Holder-of-key tokens>> are used" +msgstr "" + +msgid "Enforce <<_proof-key-for-code-exchange,Proof Key for Code Exchange (PKCE)>> is used" +msgstr "" + +msgid "Enforce secure signature algorithm for <<_client-credentials,Signed JWT client authentication (private-key-jwt)>> is used" +msgstr "" + +msgid "Enforce HTTPS redirect URI and make sure that configured redirect URI does not contain wildcards" +msgstr "" + +msgid "Enforce OIDC `request` object satisfying high security level" +msgstr "" + +msgid "Enforce Response Type of OIDC Hybrid Flow including ID Token used as _detached signature_ as described in the FAPI 1 specification, which means that ID Token returned from Authorization response won't contain user profile data" +msgstr "" + +msgid "Enforce more secure `state` and `nonce` parameters treatment for preventing CSRF" +msgstr "" + +msgid "Enforce more secure signature algorithm when client registration" +msgstr "" + +msgid "Enforce `binding_message` parameter is used for CIBA requests" +msgstr "" + +msgid "Enforce <<_secret_rotation, Client Secret Rotation>>" +msgstr "" + +msgid "Enforce Client Registration Access Token" +msgstr "" + +msgid "Enforce checking if a client is the one to which an intent was issued in a use case where an intent is issued before starting an authorization code flow to get an access token like UK OpenBanking" +msgstr "" + +msgid "Enforce prohibiting implicit and hybrid flow" +msgstr "" + +msgid "Enforce checking if a PAR request includes necessary parameters included by an authorization request" +msgstr "" + +msgid "Profile" +msgstr "" + +msgid "A profile consists of several executors, which can realize a security profile like FAPI. Profile can be configured by the Admin REST API (Admin Console) together with its executors. Three _global profiles_ exist and they are configured in {project_name} by default with pre-configured executors compliant with the FAPI 1 Baseline, FAPI 1 Advanced, FAPI CIBA and FAPI 2 specifications. More details exist in the FAPI section of the link:{adapterguide_link}#_fapi-support[{adapterguide_name}]." +msgstr "" + +msgid "Policy" +msgstr "" + +msgid "A policy consists of several conditions and profiles. The policy can be adopted to clients satisfying all conditions of this policy. The policy refers several profiles and all executors of these profiles execute their task against the client that this policy is adopted to." +msgstr "" + +msgid "Policies, profiles, conditions, executors can be configured by Admin REST API, which means also the Admin Console. To do so, there is a tab _Realm_ -> _Realm Settings_ -> _Client Policies_ , which means the administrator can have client policies per realm." +msgstr "" + +msgid "The _Global Client Profiles_ are automatically available in each realm. However there are no client policies configured by default. This means that the administrator is always required to create any client policy if they want for example the clients of his realm to be FAPI compliant. Global profiles cannot be updated, but the administrator can easily use them as a template and create their own profile if they want to do some slight changes in the global profile configurations. There is JSON Editor available in the Admin Console, which simplifies the creation of new profile based on some global profile." +msgstr "" + +msgid "Backward Compatibility" +msgstr "" + +msgid "Client Policies can replace Client Registration Policies described in the link:{adapterguide_link}#_client_registration_policies[{adapterguide_name}]. However, Client Registration Policies also still co-exist. This means that for example during a Dynamic Client Registration request to create/update a client, both client policies and client registration policies are applied." +msgstr "" + +msgid "The current plans are for the Client Registration Policies feature to be removed and the existing client registration policies will be migrated into new client policies automatically." +msgstr "" + +msgid "Client Secret Rotation Example" +msgstr "" + +msgid "See an example configuration for <<_proc-secret-rotation,client secret rotation>>." +msgstr "" + +msgid "Using a vault to obtain secrets" +msgstr "" + +msgid "Keycloak currently provides two out-of-the-box implementations of the Vault SPI: a plain-text file-based vault and Java KeyStore-based vault." +msgstr "" + +msgid "To obtain a secret from a vault rather than entering it directly, enter the following specially crafted string into the appropriate field:" +msgstr "" + +msgid "${vault.key}" +msgstr "" + +msgid "where the `key` is the name of the secret recognized by the vault." +msgstr "" + +msgid "To prevent secrets from leaking across realms, {project_name} combines the realm name with the `key` obtained from the vault expression. This method means that the `key` does not directly map to an entry in the vault but creates the final entry name according to the algorithm used to combine the `key` with the realm name. In case of the file-based vault, such combination reflects to a specific filename, for the Java KeyStore-based vault it's a specific alias name." +msgstr "" + +msgid "You can obtain the secret from the vault in the following fields:" +msgstr "" + +msgid "SMTP password" +msgstr "" + +msgid "In the realm <<_email,SMTP settings>>" +msgstr "" + +msgid "LDAP bind credential" +msgstr "" + +msgid "In the <<_ldap,LDAP settings>> of LDAP-based user federation." +msgstr "" + +msgid "OIDC identity provider secret" +msgstr "" + +msgid "In the _Client Secret_ inside identity provider <<_identity_broker_oidc,OpenID Connect Config>>" +msgstr "" + +msgid "Key resolvers" +msgstr "" + +msgid "All built-in providers support the configuration of key resolvers. A key resolver implements the algorithm or strategy for combining the realm name with the key, obtained from the `${vault.key}` expression, into the final entry name used to retrieve the secret from the vault. {project_name} uses the `keyResolvers` property to configure the resolvers that the provider uses. The value is a comma-separated list of resolver names. An example of the configuration for the `files-plaintext` provider follows:" +msgstr "" + +msgid "kc.[sh|bat] start --spi-vault-file-key-resolvers=REALM_UNDERSCORE_KEY,KEY_ONLY" +msgstr "" + +msgid "The resolvers run in the same order you declare them in the configuration. For each resolver, {project_name} uses the last entry name the resolver produces, which combines the realm with the vault key to search for the vault's secret. If {project_name} finds a secret, it returns the secret. If not, {project_name} uses the next resolver. This search continues until {project_name} finds a non-empty secret or runs out of resolvers. If {project_name} finds no secret, {project_name} returns an empty secret." +msgstr "" + +msgid "In the previous example, {project_name} uses the `REALM_UNDERSCORE_KEY` resolver first. If {project_name} finds an entry in the vault that using that resolver, {project_name} returns that entry. If not, {project_name} searches again using the `KEY_ONLY` resolver. If {project_name} finds an entry by using the `KEY_ONLY` resolver, {project_name} returns that entry. If {project_name} uses all resolvers, {project_name} returns an empty secret." +msgstr "" + +msgid "A list of the currently available resolvers follows:" +msgstr "" + +msgid "KEY_ONLY" +msgstr "" + +msgid "{project_name} ignores the realm name and uses the key from the vault expression." +msgstr "" + +msgid "REALM_UNDERSCORE_KEY" +msgstr "" + +msgid "{project_name} combines the realm and key by using an underscore character. {project_name} escapes occurrences of underscores in the realm or key with another underscore character. For example, if the realm is called `master_realm` and the key is `smtp_key`, the combined key is `master+++__+++realm_smtp+++__+++key`." +msgstr "" + +msgid "REALM_FILESEPARATOR_KEY" +msgstr "" + +msgid "{project_name} combines the realm and key by using the platform file separator character." +msgstr "" + +msgid "FACTORY_PROVIDED" +msgstr "" + +msgid "{project_name} combines the realm and key by using the vault provider factory's `VaultKeyResolver`, allowing the creation of a custom key resolver by extending an existing factory and implementing the `getFactoryResolver` method." +msgstr "" + +msgid "If you have not configured a resolver for the built-in providers, {project_name} selects the `REALM_UNDERSCORE_KEY`." +msgstr "" + +msgid "Configuring auditing to track events" +msgstr "" + +msgid "{project_name} includes a suite of auditing capabilities. You can record every login and administrator action and review those actions in the Admin Console. {project_name} also includes a Listener SPI that listens for events and can trigger actions. Examples of built-in listeners include log files and sending emails if an event occurs." +msgstr "" + +msgid "Auditing user events" +msgstr "" + +msgid "You can record and view every event that affects users. {project_name} triggers login events for actions such as successful user login, a user entering an incorrect password, or a user account updating. By default, {project_name} does not store or display events in the Admin Console. Only the error events are logged to the Admin Console and the server’s log file." +msgstr "" + +msgid "Use this procedure to start auditing user events." +msgstr "" + +msgid "Click the *Events* tab." +msgstr "" + +msgid "Click the *User events settings* tab." +msgstr "" + +msgid "Toggle *Save events* to *ON*." +msgstr "" + +msgid "User events settings" +msgstr "" + +msgid "image:images/user-events-settings.png[User events settings]" +msgstr "" + +msgid "Specify the length of time to store events in the *Expiration* field." +msgstr "" + +msgid "Click *Add saved types* to see other events you can save." +msgstr "" + +msgid "Add types" +msgstr "" + +msgid "image:images/add-event-types.png[Add types]" +msgstr "" + +msgid "Click *Clear user events* when you want to delete all saved events." +msgstr "" + +msgid "You can now view events." +msgstr "" + +msgid "Click the *Events* tab in the menu." +msgstr "" + +msgid "User events" +msgstr "" + +msgid "image:images/user-events.png[Login Events]" +msgstr "" + +msgid "To filter events, click *Search user event*." +msgstr "" + +msgid "Search user event" +msgstr "" + +msgid "image:images/search-user-event.png[Search user event]" +msgstr "" + +msgid "Event types" +msgstr "" + +msgid "*Login events:*" +msgstr "" + +msgid "Event" +msgstr "" + +msgid "Login" +msgstr "" + +msgid "A user logs in." +msgstr "" + +msgid "Register" +msgstr "" + +msgid "A user registers." +msgstr "" + +msgid "Logout" +msgstr "" + +msgid "A user logs out." +msgstr "" + +msgid "Code to Token" +msgstr "" + +msgid "An application, or client, exchanges a code for a token." +msgstr "" + +msgid "Refresh Token" +msgstr "" + +msgid "An application, or client, refreshes a token." +msgstr "" + +msgid "*Account events:*" +msgstr "" + +msgid "Social Link" +msgstr "" + +msgid "A user account links to a social media provider." +msgstr "" + +msgid "Remove Social Link" +msgstr "" + +msgid "The link from a social media account to a user account severs." +msgstr "" + +msgid "Update Email" +msgstr "" + +msgid "An email address for an account changes." +msgstr "" + +msgid "A profile for an account changes." +msgstr "" + +msgid "Send Password Reset" +msgstr "" + +msgid "{project_name} sends a password reset email." +msgstr "" + +msgid "The password for an account changes." +msgstr "" + +msgid "Update TOTP" +msgstr "" + +msgid "The Time-based One-time Password (TOTP) settings for an account changes." +msgstr "" + +msgid "Remove TOTP" +msgstr "" + +msgid "{project_name} removes TOTP from an account." +msgstr "" + +msgid "Send Verify Email" +msgstr "" + +msgid "{project_name} sends an email verification email." +msgstr "" + +msgid "{project_name} verifies the email address for an account." +msgstr "" + +msgid "Each event has a corresponding error event." +msgstr "" + +msgid "Event listener" +msgstr "" + +msgid "Event listeners listen for events and perform actions based on that event. {project_name} includes two built-in listeners, the Logging Event Listener and Email Event Listener." +msgstr "" + +msgid "The logging event listener" +msgstr "" + +msgid "When the Logging Event Listener is enabled, this listener writes to a log file when an error event occurs." +msgstr "" + +msgid "An example log message from a Logging Event Listener:" +msgstr "" + +msgid "" +"11:36:09,965 WARN [org.keycloak.events] (default task-51) type=LOGIN_ERROR, realmId=master,\n" +" clientId=myapp,\n" +" userId=19aeb848-96fc-44f6-b0a3-59a17570d374, ipAddress=127.0.0.1,\n" +" error=invalid_user_credentials, auth_method=openid-connect, auth_type=code,\n" +" redirect_uri=http://localhost:8180/myapp,\n" +" code_id=b669da14-cdbb-41d0-b055-0810a0334607, username=admin" +msgstr "" + +msgid "You can use the Logging Event Listener to protect against hacker bot attacks:" +msgstr "" + +msgid "Parse the log file for the `LOGIN_ERROR` event." +msgstr "" + +msgid "Extract the IP Address of the failed login event." +msgstr "" + +msgid "Send the IP address to an intrusion prevention software framework tool." +msgstr "" + +msgid "The Logging Event Listener logs events to the `org.keycloak.events` log category. {project_name} does not include debug log events in server logs, by default." +msgstr "" + +msgid "To include debug log events in server logs:" +msgstr "" + +msgid "Change the log level for the `org.keycloak.events` category" +msgstr "" + +msgid "Change the log level used by the Logging Event listener." +msgstr "" + +msgid "To change the log level used by the Logging Event listener, add the following:" +msgstr "" + +msgid "bin/kc.[sh|bat] start --spi-events-listener-jboss-logging-success-level=info --spi-events-listener-jboss-logging-error-level=error" +msgstr "" + +msgid "The valid values for log levels are `debug`, `info`, `warn`, `error`, and `fatal`." +msgstr "" + +msgid "The Email Event Listener" +msgstr "" + +msgid "The Email Event Listener sends an email to the user's account when an event occurs and supports the following events:" +msgstr "" + +msgid "Login Error." +msgstr "" + +msgid "Update Password." +msgstr "" + +msgid "Update Time-based One-time Password (TOTP)." +msgstr "" + +msgid "Remove Time-based One-time Password (TOTP)." +msgstr "" + +msgid "To enable the Email Listener:" +msgstr "" + +msgid "Click the *Event listeners* field." +msgstr "" + +msgid "Select `email`." +msgstr "" + +msgid "Event listeners" +msgstr "" + +msgid "image:images/event-listeners.png[Event listeners]" +msgstr "" + +msgid "You can exclude events by using the `--spi-events-listener-email-exclude-events` argument. For example:" +msgstr "" + +msgid "kc.[sh|bat] --spi-events-listener-email-exclude-events=UPDATE_TOTP,REMOVE_TOTP" +msgstr "" + +msgid "Auditing admin events" +msgstr "" + +msgid "You can record all actions that are performed by an administrator in the Admin Console. The Admin Console performs administrative actions by invoking the {project_name} REST interface and {project_name} audits these REST invocations. You can view the resulting events in the Admin Console." +msgstr "" + +msgid "Use this procedure to start auditing admin actions." +msgstr "" + +msgid "Click the *Admin events settings* tab." +msgstr "" + +msgid "{project_name} displays the *Include representation* switch." +msgstr "" + +msgid "Toggle *Include representation* to *ON*." +msgstr "" + +msgid "The `Include Representation` switch includes JSON documents sent through the admin REST API so you can view the administrators actions." +msgstr "" + +msgid "Admin events settings" +msgstr "" + +msgid "image:images/admin-events-settings.png[Admin events settings]" +msgstr "" + +msgid "To clear the database of stored actions, click *Clear admin events*." +msgstr "" + +msgid "You can now view admin events." +msgstr "" + +msgid "Click *Events* in the menu." +msgstr "" + +msgid "Click the *Admin events* tab." +msgstr "" + +msgid "Admin events" +msgstr "" + +msgid "image:images/admin-events.png[Admin events]" +msgstr "" + +msgid "When the `Include Representation` switch is ON, it can lead to storing a lot of information in the database. You can set a maximum length of the representation by using the `--spi-events-store-jpa-max-field-length` argument. This setting is useful if you want to adhere to the underlying storage limitation. For example:" +msgstr "" + +msgid "kc.[sh|bat] --spi-events-store-jpa-max-field-length=2500" +msgstr "" + +msgid "Mitigating security threats" +msgstr "" + +msgid "Security vulnerabilities exist in any authentication server. See the Internet Engineering Task Force's (IETF) https://datatracker.ietf.org/doc/html/rfc6819[OAuth 2.0 Threat Model] and the https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15[OAuth 2.0 Security Best Current Practice] for more information." +msgstr "" + +msgid "{project_name} uses the public hostname in several ways, such as within token issuer fields and URLs in password reset emails." +msgstr "" + +msgid "By default, the hostname derives from request headers. No validation exists to ensure a hostname is valid. If you are not using a load balancer, or proxy, with {project_name} to prevent invalid host headers, configure the acceptable hostnames." +msgstr "" + +msgid "The hostname's Service Provider Interface (SPI) provides a way to configure the hostname for requests. You can use this built-in provider to set a fixed URL for frontend requests while allowing backend requests based on the request URI. If the built-in provider does not have the required capability, you can develop a customized provider." +msgstr "" + +msgid "Admin endpoints and Admin Console" +msgstr "" + +msgid "{project_name} exposes the administrative REST API and the web console on the same port as non-administrative usage. Do not expose administrative endpoints externally if external access is not necessary." +msgstr "" + +msgid "Brute force attacks" +msgstr "" + +msgid "A brute force attack attempts to guess a user's password by trying to log in multiple times. {project_name} has brute force detection capabilities and can temporarily disable a user account if the number of login failures exceeds a specified threshold." +msgstr "" + +msgid "{project_name} disables brute force detection by default. Enable this feature to protect against brute force attacks." +msgstr "" + +msgid "To enable this protection:" +msgstr "" + +msgid "Click *Realm Settings* in the menu" +msgstr "" + +msgid "Click the *Brute Force Detection* tab." +msgstr "" + +msgid "Brute force detection" +msgstr "" + +msgid "image:images/brute-force.png[]" +msgstr "" + +msgid "{project_name} can deploy permanent lockout and temporary lockout actions when it detects an attack. Permanent lockout disables a user account until an administrator re-enables it. Temporary lockout disables a user account for a specific period of time. The time period that the account is disabled increases as the attack continues." +msgstr "" + +msgid "When a user is temporarily locked and attempts to log in, {project_name} displays the default `Invalid username or password` error message. This message is the same error message as the message displayed for an invalid username or invalid password to ensure the attacker is unaware the account is disabled." +msgstr "" + +msgid "*Common Parameters*" +msgstr "" + +msgid "Default" +msgstr "" + +msgid "Max Login Failures" +msgstr "" + +msgid "The maximum number of login failures." +msgstr "" + +msgid "30 failures." +msgstr "" + +msgid "Quick Login Check Milliseconds" +msgstr "" + +msgid "The minimum time between login attempts." +msgstr "" + +msgid "1000 milliseconds." +msgstr "" + +msgid "Minimum Quick Login Wait" +msgstr "" + +msgid "The minimum time the user is disabled when login attempts are quicker than _Quick Login Check Milliseconds_." +msgstr "" + +msgid "1 minute." +msgstr "" + +msgid "*Permanent Lockout Flow*" +msgstr "" + +msgid "On successful login" +msgstr "" + +msgid "Reset `count`" +msgstr "" + +msgid "On failed login" +msgstr "" + +msgid "Increment `count`" +msgstr "" + +msgid "If `count` greater than _Max Login Failures_" +msgstr "" + +msgid "Permanently disable user" +msgstr "" + +msgid "Else if the time between this failure and the last failure is less than _Quick Login Check Milliseconds_" +msgstr "" + +msgid "Temporarily disable user for _Minimum Quick Login Wait_" +msgstr "" + +msgid "When {project_name} disables a user, the user cannot log in until an administrator enables the user. Enabling an account resets the `count`." +msgstr "" + +msgid "*Temporary Lockout Parameters*" +msgstr "" + +msgid "Wait Increment" +msgstr "" + +msgid "The time added to the time a user is temporarily disabled when the user's login attempts exceed _Max Login Failures_." +msgstr "" + +msgid "Max Wait" +msgstr "" + +msgid "The maximum time a user is temporarily disabled." +msgstr "" + +msgid "15 minutes." +msgstr "" + +msgid "Failure Reset Time" +msgstr "" + +msgid "The time when the failure count resets. The timer runs from the last failed login." +msgstr "" + +msgid "12 hours." +msgstr "" + +msgid "*Temporary Lockout Algorithm*" +msgstr "" + +msgid "If the time between this failure and the last failure is greater than _Failure Reset Time_" +msgstr "" + +msgid "Calculate `wait` using _Wait Increment_ * (`count` / _Max Login Failures_). The division is an integer division rounded down to a whole number" +msgstr "" + +msgid "If `wait` equals 0 and the time between this failure and the last failure is less than _Quick Login Check Milliseconds_, set `wait` to _Minimum Quick Login Wait_." +msgstr "" + +msgid "Temporarily disable the user for the smallest of `wait` and _Max Wait_ seconds" +msgstr "" + +msgid "`count` does not increment when a temporarily disabled account commits a login failure." +msgstr "" + +msgid "The downside of {project_name} brute force detection is that the server becomes vulnerable to denial of service attacks. When implementing a denial of service attack, an attacker can attempt to log in by guessing passwords for any accounts it knows and eventually causing {project_name} to disable the accounts." +msgstr "" + +msgid "Consider using intrusion prevention software (IPS). {project_name} logs every login failure and client IP address failure. You can point the IPS to the {project_name} server's log file, and the IPS can modify firewalls to block connections from these IP addresses." +msgstr "" + +msgid "Ensure you have a complex password policy to force users to choose complex passwords. See the <<_password-policies, Password Policies>> chapter for more information. Prevent password guessing by setting up the {project_name} server to use one-time-passwords." +msgstr "" + +msgid "Read-only user attributes" +msgstr "" + +msgid "Typical users who are stored in {project_name} have various attributes related to their user profiles. Such attributes include email, firstName or lastName. However users may also have attributes, which are not typical profile data, but rather metadata. The metadata attributes usually should be read-only for the users and the typical users never should have a way to update those attributes from the {project_name} user interface or Account REST API. Some of the attributes should be even read-only for the administrators when creating or updating user with the Admin REST API." +msgstr "" + +msgid "The metadata attributes are usually attributes from those groups:" +msgstr "" + +msgid "Various links or metadata related to the user storage providers. For example in case of the LDAP integration, the `LDAP_ID` attribute contains the ID of the user in the LDAP server." +msgstr "" + +msgid "Metadata provisioned by User Storage. For example `createdTimestamp` provisioned from the LDAP should be always read-only by user or administrator." +msgstr "" + +msgid "Metadata related to various authenticators. For example `KERBEROS_PRINCIPAL` attribute can contain the kerberos principal name of the particular user. Similarly attribute `usercertificate` can contain metadata related to binding the user with the data from the X.509 certificate, which is used typically when X.509 certificate authentication is enabled." +msgstr "" + +msgid "Metadata related to the identificator of users by the applications/clients. For example `saml.persistent.name.id.for.my_app` can contain SAML NameID, which will be used by the client application `my_app` as the identifier of the user." +msgstr "" + +msgid "Metadata related to the authorization policies, which are used for the attribute based access control (ABAC). Values of those attributes may be used for the authorization decisions. Hence it is important that those attributes cannot be updated by the users." +msgstr "" + +msgid "From the long term perspective, {project_name} will have a proper User Profile SPI, which will allow fine-grained configuration of every user attribute. Currently this capability is not fully available yet. So {project_name} has the internal list of user attributes, which are read-only for the users and read-only for the administrators configured at the server level." +msgstr "" + +msgid "This is the list of the read-only attributes, which are used internally by the {project_name} default providers and functionalities and hence are always read-only:" +msgstr "" + +msgid "For users: `KERBEROS_PRINCIPAL`, `LDAP_ID`, `LDAP_ENTRY_DN`, `CREATED_TIMESTAMP`, `createTimestamp`, `modifyTimestamp`, `userCertificate`, `saml.persistent.name.id.for.*`, `ENABLED`, `EMAIL_VERIFIED`" +msgstr "" + +msgid "For administrators: `KERBEROS_PRINCIPAL`, `LDAP_ID`, `LDAP_ENTRY_DN`, `CREATED_TIMESTAMP`, `createTimestamp`, `modifyTimestamp`" +msgstr "" + +msgid "System administrators have a way to add additional attributes to this list. The configuration is currently available at the server level." +msgstr "" + +msgid "You can add this configuration by using the `spi-user-profile-declarative-user-profile-read-only-attributes` and ``spi-user-profile-declarative-user-profile-admin-read-only-attributes` options. For example:" +msgstr "" + +msgid "kc.[sh|bat] start --spi-user-profile-declarative-user-profile-read-only-attributes=foo,bar*" +msgstr "" + +msgid "For this example, users and administrators would not be able to update attribute `foo`. Users would not be able to edit any attributes starting with the `bar`. So for example `bar` or `barrier`. Configuration is case-insensitive, so attributes like `FOO` or `BarRier` will be denied as well for this example. The wildcard character `\\*` is supported only at the end of the attribute name, so the administrator can effectively deny all the attributes starting with the specified character. The `*` in the middle of the attribute is considered as a normal character." +msgstr "" + +msgid "Clickjacking" +msgstr "" + +msgid "Clickjacking is a technique of tricking users into clicking on a user interface element different from what users perceive. A malicious site loads the target site in a transparent iFrame, overlaid on top of a set of dummy buttons placed directly under important buttons on the target site. When a user clicks a visible button, they are clicking a button on the hidden page. An attacker can steal a user's authentication credentials and access their resources by using this method." +msgstr "" + +msgid "By default, every response by {project_name} sets some specific HTTP headers that can prevent this from happening. Specifically, it sets https://datatracker.ietf.org/doc/html/rfc7034[X-Frame-Options] and https://www.w3.org/TR/CSP/[Content-Security-Policy]. You should take a look at the definition of both of these headers as there is a lot of fine-grain browser access you can control." +msgstr "" + +msgid "In the Admin Console, you can specify the values of the X-Frame-Options and Content-Security-Policy headers." +msgstr "" + +msgid "Click the *Realm Settings* menu item." +msgstr "" + +msgid "Security Defenses" +msgstr "" + +msgid "image:images/security-headers.png[Security Defenses]" +msgstr "" + +msgid "By default, {project_name} only sets up a _same-origin_ policy for iframes." +msgstr "" + +msgid "SSL/HTTPS requirement" +msgstr "" + +msgid "OAuth 2.0/OpenID Connect uses access tokens for security. Attackers can scan your network for access tokens and use them to perform malicious operations for which the token has permission. This attack is known as a man-in-the-middle attack. Use SSL/HTTPS for communication between the {project_name} auth server and the clients {project_name} secures to prevent man-in-the-middle attacks." +msgstr "" + +msgid "{project_name} has <<_ssl_modes,three modes for SSL/HTTPS>>. SSL is complex to set up, so {project_name} allows non-HTTPS communication over private IP addresses such as localhost, 192.168.x.x, and other private IP addresses. In production, ensure you enable SSL and SSL is compulsory for all operations." +msgstr "" + +msgid "On the adapter/client-side, you can disable the SSL trust manager. The trust manager ensures the client's identity that {project_name} communicates with is valid and ensures the DNS domain name against the server's certificate. In production, ensure that each of your client adapters uses a truststore to prevent DNS man-in-the-middle attacks." +msgstr "" + +msgid "CSRF attacks" +msgstr "" + +msgid "A Cross-site request forgery (CSRF) attack uses HTTP requests from users that websites have already authenticated. Any site using cookie-based authentication is vulnerable to CSRF attacks. You can mitigate these attacks by matching a state cookie against a posted form or query parameter." +msgstr "" + +msgid "The OAuth 2.0 login specification requires that a state cookie matches against a transmitted state parameter. {project_name} fully implements this part of the specification, so all logins are protected." +msgstr "" + +msgid "The {project_name} Admin Console is a JavaScript/HTML5 application that makes REST calls to the backend {project_name} admin REST API. These calls all require bearer token authentication and consist of JavaScript Ajax calls, so CSRF is impossible. You can configure the admin REST API to validate the CORS origins." +msgstr "" + +msgid "The user account management section in {project_name} can be vulnerable to CSRF. To prevent CSRF attacks, {project_name} sets a state cookie and embeds the value of this cookie in hidden form fields or query parameters within action links. {project_name} checks the query/form parameter against the state cookie to verify that the user makes the call." +msgstr "" + +msgid "Unspecific redirect URIs" +msgstr "" + +msgid "Make your registered redirect URIs as specific as feasible. Registering vague redirect URIs for xref:con-oidc-auth-flows_{context}[Authorization Code Flows] can allow malicious clients to impersonate another client with broader access. Impersonation can happen if two clients live under the same domain, for example." +msgstr "" + +msgid "FAPI compliance" +msgstr "" + +msgid "To make sure that {project_name} server will validate your client to be more secure and FAPI compliant, you can configure client policies for the FAPI support. Details are described in the FAPI section of link:{adapterguide_link}#_fapi-support[{adapterguide_name}]. Among other things, this ensures some security best practices described above like SSL required for clients, secure redirect URI used and more of similar best practices." +msgstr "" + +msgid "Compromised access and refresh tokens" +msgstr "" + +msgid "{project_name} includes several actions to prevent malicious actors from stealing access tokens and refresh tokens. The crucial action is to enforce SSL/HTTPS communication between {project_name} and its clients and applications. {project_name} does not enable SSL by default." +msgstr "" + +msgid "Another action to mitigate damage from leaked access tokens is to shorten the token's lifespans. You can specify token lifespans within the <<_timeouts, timeouts page>>. Short lifespans for access tokens force clients and applications to refresh their access tokens after a short time. If an admin detects a leak, the admin can log out all user sessions to invalidate these refresh tokens or set up a revocation policy." +msgstr "" + +msgid "Ensure refresh tokens always stay private to the client and are never transmitted." +msgstr "" + +msgid "You can mitigate damage from leaked access tokens and refresh tokens by issuing these tokens as holder-of-key tokens. See <<_mtls-client-certificate-bound-tokens, OAuth 2.0 Mutual TLS Client Certificate Bound Access Token>> for more information." +msgstr "" + +msgid "If an access token or refresh token is compromised, access the Admin Console and push a not-before revocation policy to all applications. Pushing a not-before policy ensures that any tokens issued before that time become invalid. Pushing a new not-before policy ensures that applications must download new public keys from {project_name} and mitigate damage from a compromised realm signing key. See the <> for more information." +msgstr "" + +msgid "You can disable specific applications, clients, or users if they are compromised." +msgstr "" + +msgid "Compromised authorization code" +msgstr "" + +msgid "For the xref:con-oidc-auth-flows_{context}[OIDC Auth Code Flow], {project_name} generates a cryptographically strong random value for its authorization codes. An authorization code is used only once to obtain an access token." +msgstr "" + +msgid "On the <<_timeouts, timeouts page>> in the Admin Console, you can specify the length of time an authorization code is valid. Ensure that the length of time is less than 10 seconds, which is long enough for a client to request a token from the code." +msgstr "" + +msgid "You can also defend against leaked authorization codes by applying <<_proof-key-for-code-exchange, Proof Key for Code Exchange (PKCE)>> to clients." +msgstr "" + +msgid "Open redirectors" +msgstr "" + +msgid "An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without validation. An attacker can use the end-user authorization endpoint and the redirect URI parameter to use the authorization server as an open redirector, using a user's trust in an authorization server to launch a phishing attack." +msgstr "" + +msgid "{project_name} requires that all registered applications and clients register at least one redirection URI pattern. When a client requests that {project_name} performs a redirect, {project_name} checks the redirect URI against the list of valid registered URI patterns. Clients and applications must register as specific a URI pattern as possible to mitigate open redirector attacks." +msgstr "" + +msgid "If an application requires a non http(s) custom scheme, it should be an explicit part of the validation pattern (for example `custom:/app/\\*`). For security reasons a general pattern like `*` does not cover non http(s) schemes." +msgstr "" + +msgid "Password database compromised" +msgstr "" + +msgid "{project_name} does not store passwords in raw text but as hashed text, using the PBKDF2 hashing algorithm. {project_name} performs 27,500 hashing iterations, the number of iterations recommended by the security community. This number of hashing iterations can adversely affect performance as PBKDF2 hashing uses a significant amount of CPU resources." +msgstr "" + +msgid "Limiting scope" +msgstr "" + +msgid "By default, new client applications have unlimited `role scope mappings`. Every access token for that client contains all permissions that the user has. If an attacker compromises the client and obtains the client's access tokens, each system that the user can access is compromised." +msgstr "" + +msgid "Limit the roles of an access token by using the <<_role_scope_mappings, Scope menu>> for each client. Alternatively, you can set role scope mappings at the Client Scope level and assign Client Scopes to your client by using the <<_client_scopes_linking, Client Scope menu>>." +msgstr "" + +msgid "Limit token audience" +msgstr "" + +msgid "In environments with low levels of trust among services, limit the audiences on the token. See the https://datatracker.ietf.org/doc/html/rfc6819#section-5.1.5.5[OAuth2 Threat Model] and the <> section for more information." +msgstr "" + +msgid "Limit Authentication Sessions" +msgstr "" + +msgid "When a login page is opened for the first time in a web browser, {project_name} creates an object called authentication session that stores some useful information about the request. Whenever a new login page is opened from a different tab in the same browser, {project_name} creates a new record called authentication sub-session that is stored within the authentication session. Authentication requests can come from any type of clients such as the Admin CLI. In that case, a new authentication session is also created with one authentication sub-session. Please note that authentication sessions can be created also in other ways than using a browser flow. The text below is applicable regardless of the source flow." +msgstr "" + +msgid "This section describes deployments that use the {jdgserver_name} provider for authentication sessions." +msgstr "" + +msgid "Authentication session is internally stored as `RootAuthenticationSessionEntity`. Each `RootAuthenticationSessionEntity` can have multiple authentication sub-sessions stored within the `RootAuthenticationSessionEntity` as a collection of `AuthenticationSessionEntity` objects. {project_name} stores authentication sessions in a dedicated {jdgserver_name} cache. The number of `AuthenticationSessionEntity` per `RootAuthenticationSessionEntity` contributes to the size of each cache entry. Total memory footprint of authentication session cache is determined by the number of stored `RootAuthenticationSessionEntity` and by the number of `AuthenticationSessionEntity` within each `RootAuthenticationSessionEntity`." +msgstr "" + +msgid "The number of maintained `RootAuthenticationSessionEntity` objects corresponds to the number of unfinished login flows from the browser. To keep the number of `RootAuthenticationSessionEntity` under control, using an advanced firewall control to limit ingress network traffic is recommended." +msgstr "" + +msgid "Higher memory usage may occur for deployments where there are many active `RootAuthenticationSessionEntity` with a lot of `AuthenticationSessionEntity`. If the load balancer does not support or is not configured for session stickiness, the load over network in a cluster can increase significantly. The reason for this load is that each request that lands on a node that does not own the appropriate authentication session needs to retrieve and update the authentication session record in the owner node which involves a separate network transmission for both the retrieval and the storage." +msgstr "" + +msgid "The maximum number of `AuthenticationSessionEntity` per `RootAuthenticationSessionEntity` can be configured in `authenticationSessions` SPI by setting property `authSessionsLimit`. The default value is set to 300 `AuthenticationSessionEntity` per a `RootAuthenticationSessionEntity`. When this limit is reached, the oldest authentication sub-session will be removed after a new authentication session request." +msgstr "" + +msgid "The following example shows how to limit the number of active `AuthenticationSessionEntity` per a `RootAuthenticationSessionEntity` to 100." +msgstr "" + +msgid "bin/kc.[sh|bat] start --spi-authentication-sessions-infinispan-auth-sessions-limit=100" +msgstr "" + +msgid "The equivalent command for the new map storage:" +msgstr "" + +msgid "bin/kc.[sh|bat] start --spi-authentication-sessions-map-auth-sessions-limit=100" +msgstr "" + +msgid "SQL injection attacks" +msgstr "" + +msgid "Currently, {project_name} has no known SQL injection vulnerabilities." +msgstr "" + +msgid "Account Console" +msgstr "" + +msgid "{project_name} users can manage their accounts through the Account Console. Users can configure their profiles, add two-factor authentication, include identity provider accounts, and oversee device activity." +msgstr "" + +msgid "The Account Console can be configured in terms of appearance and language preferences. An example is adding attributes to the *Personal info* page by clicking *Personal info* link and completing and saving details. For more information, see the {developerguide_link}[{developerguide_name}]." +msgstr "" + +msgid "Accessing the Account Console" +msgstr "" + +msgid "Any user can access the Account Console." +msgstr "" + +msgid "Make note of the realm name and IP address for the {project_name} server where your account exists." +msgstr "" + +msgid "In a web browser, enter a URL in this format: _server-root_{kc_realms_path}/{realm-name}/account." +msgstr "" + +msgid "Enter your login name and password." +msgstr "" + +msgid "image:images/account-console-intro.png[Account Console]" +msgstr "" + +msgid "Configuring ways to sign in" +msgstr "" + +msgid "You can sign in to this console using basic authentication (a login name and password) or two-factor authentication. For two-factor authentication, use one of the following procedures." +msgstr "" + +msgid "Two-factor authentication with OTP" +msgstr "" + +msgid "OTP is a valid authentication mechanism for your realm." +msgstr "" + +msgid "Click *Account security* in the menu." +msgstr "" + +msgid "Click *Signing in*." +msgstr "" + +msgid "Click *Set up authenticator application*." +msgstr "" + +msgid "Signing in" +msgstr "" + +msgid "image:images/account-console-signing-in.png[Signing in]" +msgstr "" + +msgid "Follow the directions that appear on the screen to use either https://freeotp.github.io/[FreeOTP] or https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2[Google Authenticator] on your mobile device as your OTP generator." +msgstr "" + +msgid "Scan the QR code in the screen shot into the OTP generator on your mobile device." +msgstr "" + +msgid "Log out and log in again." +msgstr "" + +msgid "Respond to the prompt by entering an OTP that is provided on your mobile device." +msgstr "" + +msgid "Two-factor authentication with WebAuthn" +msgstr "" + +msgid "WebAuthn is a valid two-factor authentication mechanism for your realm. Please follow the xref:webauthn_{context}[WebAuthn] section for more details." +msgstr "" + +msgid "Click *Account Security* in the menu." +msgstr "" + +msgid "Click *Signing In*." +msgstr "" + +msgid "Click *Set up Security Key*." +msgstr "" + +msgid "Signing In" +msgstr "" + +msgid "image:images/account-console-signing-in-webauthn-2factor.png[Signing In With Security Key]" +msgstr "" + +msgid "Prepare your WebAuthn Security Key. How you prepare this key depends on the type of WebAuthn security key you use. For example, for a USB based Yubikey, you may need to put your key into the USB port on your laptop." +msgstr "" + +msgid "Click *Register* to register your security key." +msgstr "" + +msgid "Assuming authentication flow was correctly set, a message appears asking you to authenticate with your Security Key as second factor." +msgstr "" + +msgid "Passwordless authentication with WebAuthn" +msgstr "" + +msgid "WebAuthn is a valid passwordless authentication mechanism for your realm. Please follow the <<_webauthn_passwordless,Passwordless WebAuthn section>> for more details." +msgstr "" + +msgid "Click *Set up Security Key* in the *Passwordless* section." +msgstr "" + +msgid "image:images/account-console-signing-in-webauthn-passwordless.png[Signing In With Security Key]" +msgstr "" + +msgid "Assuming authentication flow was correctly set, a message appears asking you to authenticate with your Security Key as second factor. You no longer need to provide your password to log in." +msgstr "" + +msgid "Viewing device activity" +msgstr "" + +msgid "You can view the devices that are logged in to your account." +msgstr "" + +msgid "Click *Device activity*." +msgstr "" + +msgid "Log out a device if it looks suspicious." +msgstr "" + +msgid "Devices" +msgstr "" + +msgid "image:images/account-console-device.png[Devices]" +msgstr "" + +msgid "Adding an identity provider account" +msgstr "" + +msgid "You can link your account with an <<_identity_broker, identity broker>>. This option is often used to link social provider accounts." +msgstr "" + +msgid "Log into the Admin Console." +msgstr "" + +msgid "Click *Identity providers* in the menu." +msgstr "" + +msgid "Select a provider and complete the fields." +msgstr "" + +msgid "Return to the Account Console." +msgstr "" + +msgid "Click *Linked accounts*." +msgstr "" + +msgid "The identity provider you added appears in this page." +msgstr "" + +msgid "Linked Accounts" +msgstr "" + +msgid "image:images/account-console-linked.png[Linked Accounts]" +msgstr "" + +msgid "Accessing other applications" +msgstr "" + +msgid "The *Applications* menu item shows users which applications you can access. In this case, only the Account Console is available." +msgstr "" + +msgid "Applications" +msgstr "" + +msgid "image:images/account-console-applications.png[Applications]" +msgstr "" + +msgid "Viewing group memberships" +msgstr "" + +msgid "You can view the groups you are associated with by clicking the *Groups* menu. If you select *Direct membership* checkbox, you will see only the groups you are direct associated with." +msgstr "" + +msgid "You need to have the *view-groups* account role for being able to view *Groups* menu." +msgstr "" + +msgid "View group memberships" +msgstr "" + +msgid "image:images/groups_account_console.png[View group memberships]" +msgstr "" + +msgid "Admin CLI" +msgstr "" + +msgid "With {project_name}, you can perform administration tasks from the command-line interface (CLI) by using the Admin CLI command-line tool." +msgstr "" + +msgid "Installing the Admin CLI" +msgstr "" + +msgid "{project_name} packages the Admin CLI server distribution with the execution scripts in the `bin` directory." +msgstr "" + +msgid "The Linux script is called `kcadm.sh`, and the script for Windows is called `kcadm.bat`. Add the {project_name} server directory to your `PATH` to use the client from any location on your file system." +msgstr "" + +msgid "Linux:" +msgstr "" + +msgid "" +"$ export PATH=$PATH:$KEYCLOAK_HOME/bin\n" +"$ kcadm.sh" +msgstr "" + +msgid "Windows:" +msgstr "" + +msgid "" +"c:\\> set PATH=%PATH%;%KEYCLOAK_HOME%\\bin\n" +"c:\\> kcadm" +msgstr "" + +msgid "You must set the `KEYCLOAK_HOME` environment variable to the path where you extracted the {project_name} Server distribution." +msgstr "" + +msgid "To avoid repetition, the rest of this document only uses Windows examples in places where the CLI differences are more than just in the `kcadm` command name." +msgstr "" + +msgid "Using the Admin CLI" +msgstr "" + +msgid "The Admin CLI makes HTTP requests to Admin REST endpoints. Access to the Admin REST endpoints requires authentication." +msgstr "" + +msgid "Consult the Admin REST API documentation for details about JSON attributes for specific endpoints." +msgstr "" + +msgid "Start an authenticated session by logging in. You can now perform create, read, update, and delete (CRUD) operations." +msgstr "" + +msgid "" +"$ kcadm.sh config credentials --server http://localhost:8080{kc_base_path} --realm demo --user admin --client admin\n" +"$ kcadm.sh create realms -s realm=demorealm -s enabled=true -o\n" +"$ CID=$(kcadm.sh create clients -r demorealm -s clientId=my_client -s 'redirectUris=[\"http://localhost:8980/myapp/*\"]' -i)\n" +"$ kcadm.sh get clients/$CID/installation/providers/keycloak-oidc-keycloak-json" +msgstr "" + +msgid "" +"c:\\> kcadm config credentials --server http://localhost:8080{kc_base_path} --realm demo --user admin --client admin\n" +"c:\\> kcadm create realms -s realm=demorealm -s enabled=true -o\n" +"c:\\> kcadm create clients -r demorealm -s clientId=my_client -s \"redirectUris=[\\\"http://localhost:8980/myapp/*\\\"]\" -i > clientid.txt\n" +"c:\\> set /p CID= kcadm get clients/%CID%/installation/providers/keycloak-oidc-keycloak-json" +msgstr "" + +msgid "In a production environment, access {project_name} by using `https:` to avoid exposing tokens. If a trusted certificate authority, included in Java's default certificate truststore, has not issued a server's certificate, prepare a `truststore.jks` file and instruct the Admin CLI to use it." +msgstr "" + +msgid "$ kcadm.sh config truststore --trustpass $PASSWORD ~/.keycloak/truststore.jks" +msgstr "" + +msgid "c:\\> kcadm config truststore --trustpass %PASSWORD% %HOMEPATH%\\.keycloak\\truststore.jks" +msgstr "" + +msgid "Authenticating" +msgstr "" + +msgid "When you log in with the Admin CLI, you specify:" +msgstr "" + +msgid "A server endpoint URL" +msgstr "" + +msgid "A realm" +msgstr "" + +msgid "A user name" +msgstr "" + +msgid "Another option is to specify a clientId only, which creates a unique service account for you to use." +msgstr "" + +msgid "When you log in using a user name, use a password for the specified user. When you log in using a clientId, you need the client secret only, not the user password. You can also use the `Signed JWT` rather than the client secret." +msgstr "" + +msgid "Ensure the account used for the session has the proper permissions to invoke Admin REST API operations. For example, the `realm-admin` role of the `realm-management` client can administer the realm of the user." +msgstr "" + +msgid "Two primary mechanisms are available for authentication. One mechanism uses `kcadm config credentials` to start an authenticated session." +msgstr "" + +msgid "$ kcadm.sh config credentials --server http://localhost:8080{kc_base_path} --realm master --user admin --password admin" +msgstr "" + +msgid "This mechanism maintains an authenticated session between the `kcadm` command invocations by saving the obtained access token and its associated refresh token. It can maintain other secrets in a private configuration file. See the <<_working_with_alternative_configurations, next chapter>> for more information." +msgstr "" + +msgid "The second mechanism authenticates each command invocation for the duration of the invocation. This mechanism increases the load on the server and the time spent on round trips obtaining tokens. The benefit of this approach is that it is unnecessary to save tokens between invocations, so nothing is saved to disk. {project_name} uses this mode when the `--no-config` argument is specified." +msgstr "" + +msgid "For example, when performing an operation, specify all the information required for authentication." +msgstr "" + +msgid "$ kcadm.sh get realms --no-config --server http://localhost:8080{kc_base_path} --realm master --user admin --password admin" +msgstr "" + +msgid "Run the `kcadm.sh help` command for more information on using the Admin CLI." +msgstr "" + +msgid "Run the `kcadm.sh config credentials --help` command for more information about starting an authenticated session." +msgstr "" + +msgid "Working with alternative configurations" +msgstr "" + +msgid "By default, the Admin CLI maintains a configuration file named `kcadm.config`. {project_name} places this file in the user's home directory. In Linux-based systems, the full pathname is `$HOME/.keycloak/kcadm.config`. In Windows, the full pathname is `%HOMEPATH%\\.keycloak\\kcadm.config`." +msgstr "" + +msgid "You can use the `--config` option to point to a different file or location so you can maintain multiple authenticated sessions in parallel." +msgstr "" + +msgid "Perform operations tied to a single configuration file from a single thread." +msgstr "" + +msgid "Ensure the configuration file is invisible to other users on the system. It contains access tokens and secrets that must be private. {project_name} creates the `~/.keycloak` directory and its contents automatically with proper access limits. If the directory already exists, {project_name} does not update the directory's permissions." +msgstr "" + +msgid "It is possible to avoid storing secrets inside a configuration file, but doing so is inconvenient and increases the number of token requests. Use the `--no-config` option with all commands and specify the authentication information the `config credentials` command requires with each invocation of `kcadm`." +msgstr "" + +msgid "Basic operations and resource URIs" +msgstr "" + +msgid "The Admin CLI can generically perform CRUD operations against Admin REST API endpoints with additional commands that simplify particular tasks." +msgstr "" + +msgid "The main usage pattern is listed here:" +msgstr "" + +msgid "" +"$ kcadm.sh create ENDPOINT [ARGUMENTS]\n" +"$ kcadm.sh get ENDPOINT [ARGUMENTS]\n" +"$ kcadm.sh update ENDPOINT [ARGUMENTS]\n" +"$ kcadm.sh delete ENDPOINT [ARGUMENTS]" +msgstr "" + +msgid "The `create`, `get`, `update`, and `delete` commands map to the HTTP verbs `POST`, `GET`, `PUT`, and `DELETE`, respectively. ENDPOINT is a target resource URI and can be absolute (starting with `http:` or `https:`) or relative, that {project_name} uses to compose absolute URLs in the following format:" +msgstr "" + +msgid "SERVER_URI/admin/realms/REALM/ENDPOINT" +msgstr "" + +msgid "For example, if you authenticate against the server http://localhost:8080{kc_base_path} and realm is `master`, using `users` as ENDPOINT creates the http://localhost:8080{kc_admins_path}/realms/master/users resource URL." +msgstr "" + +msgid "If you set ENDPOINT to `clients`, the effective resource URI is http://localhost:8080{kc_admins_path}/realms/master/clients." +msgstr "" + +msgid "{project_name} has a `realms` endpoint that is the container for realms. It resolves to:" +msgstr "" + +msgid "SERVER_URI/admin/realms" +msgstr "" + +msgid "{project_name} has a `serverinfo` endpoint. This endpoint is independent of realms." +msgstr "" + +msgid "When you authenticate as a user with realm-admin powers, you may need to perform commands on multiple realms. If so, specify the `-r` option to tell the CLI which realm the command is to execute against explicitly. Instead of using `REALM` as specified by the `--realm` option of `kcadm.sh config credentials`, the command uses `TARGET_REALM`." +msgstr "" + +msgid "SERVER_URI/admin/realms/TARGET_REALM/ENDPOINT" +msgstr "" + +msgid "" +"$ kcadm.sh config credentials --server http://localhost:8080{kc_base_path} --realm master --user admin --password admin\n" +"$ kcadm.sh create users -s username=testuser -s enabled=true -r demorealm" +msgstr "" + +msgid "In this example, you start a session authenticated as the `admin` user in the `master` realm. You then perform a POST call against the resource URL `http://localhost:8080{kc_admins_path}/realms/demorealm/users`." +msgstr "" + +msgid "The `create` and `update` commands send a JSON body to the server. You can use `-f FILENAME` to read a pre-made document from a file. When you can use the `-f -` option, {project_name} reads the message body from the standard input. You can specify individual attributes and their values, as seen in the `create users` example. {project_name} composes the attributes into a JSON body and sends them to the server." +msgstr "" + +msgid "Several methods are available in {project_name} to update a resource using the `update` command. You can determine the current state of a resource and save it to a file, edit that file, and send it to the server for an update." +msgstr "" + +msgid "" +"$ kcadm.sh get realms/demorealm > demorealm.json\n" +"$ vi demorealm.json\n" +"$ kcadm.sh update realms/demorealm -f demorealm.json" +msgstr "" + +msgid "This method updates the resource on the server with the attributes in the sent JSON document." +msgstr "" + +msgid "Another method is to perform an on-the-fly update by using the `-s, --set` options to set new values." +msgstr "" + +msgid "$ kcadm.sh update realms/demorealm -s enabled=false" +msgstr "" + +msgid "This method sets the `enabled` attribute to `false`." +msgstr "" + +msgid "By default, the `update` command performs a `get` and then merges the new attribute values with existing values. In some cases, the endpoint may support the `put` command but not the `get` command. You can use the `-n` option to perform a no-merge update, which performs a `put` command without first running a `get` command." +msgstr "" + +msgid "Realm operations" +msgstr "" + +msgid "Creating a new realm" +msgstr "" + +msgid "Use the `create` command on the `realms` endpoint to create a new enabled realm. Set the attributes to `realm` and `enabled`." +msgstr "" + +msgid "$ kcadm.sh create realms -s realm=demorealm -s enabled=true" +msgstr "" + +msgid "{project_name} disables realms by default. You can use a realm immediately for authentication by enabling it." +msgstr "" + +msgid "A description for a new object can also be in JSON format." +msgstr "" + +msgid "$ kcadm.sh create realms -f demorealm.json" +msgstr "" + +msgid "You can send a JSON document with realm attributes directly from a file or pipe the document to standard input." +msgstr "" + +msgid "" +"$ kcadm.sh create realms -f - << EOF\n" +"{ \"realm\": \"demorealm\", \"enabled\": true }\n" +"EOF" +msgstr "" + +msgid "c:\\> echo { \"realm\": \"demorealm\", \"enabled\": true } | kcadm create realms -f -" +msgstr "" + +msgid "Listing existing realms" +msgstr "" + +msgid "This command returns a list of all realms." +msgstr "" + +msgid "$ kcadm.sh get realms" +msgstr "" + +msgid "{project_name} filters the list of realms on the server to return realms a user can see only." +msgstr "" + +msgid "The list of all realm attributes can be verbose, and most users are interested in a subset of attributes, such as the realm name and the enabled status of the realm. You can specify the attributes to return by using the `--fields` option." +msgstr "" + +msgid "$ kcadm.sh get realms --fields realm,enabled" +msgstr "" + +msgid "You can display the result as comma-separated values." +msgstr "" + +msgid "$ kcadm.sh get realms --fields realm --format csv --noquotes" +msgstr "" + +msgid "Getting a specific realm" +msgstr "" + +msgid "Append a realm name to a collection URI to get an individual realm." +msgstr "" + +msgid "$ kcadm.sh get realms/master" +msgstr "" + +msgid "Updating a realm" +msgstr "" + +msgid "Use the `-s` option to set new values for the attributes when you do not want to change all of the realm's attributes." +msgstr "" + +msgid "If you want to set all writable attributes to new values:" +msgstr "" + +msgid "Run a `get` command." +msgstr "" + +msgid "Edit the current values in the JSON file." +msgstr "" + +msgid "Resubmit." +msgstr "" + +msgid "Deleting a realm" +msgstr "" + +msgid "Run the following command to delete a realm:" +msgstr "" + +msgid "$ kcadm.sh delete realms/demorealm" +msgstr "" + +msgid "Turning on all login page options for the realm" +msgstr "" + +msgid "Set the attributes that control specific capabilities to `true`." +msgstr "" + +msgid "$ kcadm.sh update realms/demorealm -s registrationAllowed=true -s registrationEmailAsUsername=true -s rememberMe=true -s verifyEmail=true -s resetPasswordAllowed=true -s editUsernameAllowed=true" +msgstr "" + +msgid "Listing the realm keys" +msgstr "" + +msgid "Use the `get` operation on the `keys` endpoint of the target realm." +msgstr "" + +msgid "$ kcadm.sh get keys -r demorealm" +msgstr "" + +msgid "Generating new realm keys" +msgstr "" + +msgid "Get the ID of the target realm before adding a new RSA-generated key pair." +msgstr "" + +msgid "$ kcadm.sh get realms/demorealm --fields id --format csv --noquotes" +msgstr "" + +msgid "Add a new key provider with a higher priority than the existing providers as revealed by `kcadm.sh get keys -r demorealm`." +msgstr "" + +msgid "$ kcadm.sh create components -r demorealm -s name=rsa-generated -s providerId=rsa-generated -s providerType=org.keycloak.keys.KeyProvider -s parentId=959844c1-d149-41d7-8359-6aa527fca0b0 -s 'config.priority=[\"101\"]' -s 'config.enabled=[\"true\"]' -s 'config.active=[\"true\"]' -s 'config.keySize=[\"2048\"]'" +msgstr "" + +msgid "c:\\> kcadm create components -r demorealm -s name=rsa-generated -s providerId=rsa-generated -s providerType=org.keycloak.keys.KeyProvider -s parentId=959844c1-d149-41d7-8359-6aa527fca0b0 -s \"config.priority=[\\\"101\\\"]\" -s \"config.enabled=[\\\"true\\\"]\" -s \"config.active=[\\\"true\\\"]\" -s \"config.keySize=[\\\"2048\\\"]\"" +msgstr "" + +msgid "Set the `parentId` attribute to the value of the target realm's ID." +msgstr "" + +msgid "The newly added key is now the active key, as revealed by `kcadm.sh get keys -r demorealm`." +msgstr "" + +msgid "Adding new realm keys from a Java Key Store file" +msgstr "" + +msgid "Add a new key provider to add a new key pair pre-prepared as a JKS file." +msgstr "" + +msgid "For example, on:" +msgstr "" + +msgid "$ kcadm.sh create components -r demorealm -s name=java-keystore -s providerId=java-keystore -s providerType=org.keycloak.keys.KeyProvider -s parentId=959844c1-d149-41d7-8359-6aa527fca0b0 -s 'config.priority=[\"101\"]' -s 'config.enabled=[\"true\"]' -s 'config.active=[\"true\"]' -s 'config.keystore=[\"/opt/keycloak/keystore.jks\"]' -s 'config.keystorePassword=[\"secret\"]' -s 'config.keyPassword=[\"secret\"]' -s 'config.keyAlias=[\"localhost\"]'" +msgstr "" + +msgid "c:\\> kcadm create components -r demorealm -s name=java-keystore -s providerId=java-keystore -s providerType=org.keycloak.keys.KeyProvider -s parentId=959844c1-d149-41d7-8359-6aa527fca0b0 -s \"config.priority=[\\\"101\\\"]\" -s \"config.enabled=[\\\"true\\\"]\" -s \"config.active=[\\\"true\\\"]\" -s \"config.keystore=[\\\"/opt/keycloak/keystore.jks\\\"]\" -s \"config.keystorePassword=[\\\"secret\\\"]\" -s \"config.keyPassword=[\\\"secret\\\"]\" -s \"config.keyAlias=[\\\"localhost\\\"]\"" +msgstr "" + +msgid "Ensure you change the attribute values for `keystore`, `keystorePassword`, `keyPassword`, and `alias` to match your specific keystore." +msgstr "" + +msgid "Making the key passive or disabling the key" +msgstr "" + +msgid "Identify the key you want to make passive." +msgstr "" + +msgid "Use the key's `providerId` attribute to construct an endpoint URI, such as `components/PROVIDER_ID`." +msgstr "" + +msgid "Perform an `update`." +msgstr "" + +msgid "$ kcadm.sh update components/PROVIDER_ID -r demorealm -s 'config.active=[\"false\"]'" +msgstr "" + +msgid "c:\\> kcadm update components/PROVIDER_ID -r demorealm -s \"config.active=[\\\"false\\\"]\"" +msgstr "" + +msgid "You can update other key attributes:" +msgstr "" + +msgid "Set a new `enabled` value to disable the key, for example, `config.enabled=[\"false\"]`." +msgstr "" + +msgid "Set a new `priority` value to change the key's priority, for example, `config.priority=[\"110\"]`." +msgstr "" + +msgid "Deleting an old key" +msgstr "" + +msgid "Ensure the key you are deleting is inactive and you have disabled it. This action is to prevent existing tokens held by applications and users from failing." +msgstr "" + +msgid "Identify the key to delete." +msgstr "" + +msgid "Use the `providerId` of the key to perform the delete." +msgstr "" + +msgid "$ kcadm.sh delete components/PROVIDER_ID -r demorealm" +msgstr "" + +msgid "Configuring event logging for a realm" +msgstr "" + +msgid "Use the `update` command on the `events/config` endpoint." +msgstr "" + +msgid "The `eventsListeners` attribute contains a list of EventListenerProviderFactory IDs, specifying all event listeners that receive events. Attributes are available that control built-in event storage, so you can query past events using the Admin REST API. {project_name} has separate control over the logging of service calls (`eventsEnabled`) and the auditing events triggered by the Admin Console or Admin REST API (`adminEventsEnabled`). You can set up the `eventsExpiration` event to expire to prevent your database from filling. {project_name} sets `eventsExpiration` to time-to-live expressed in seconds." +msgstr "" + +msgid "You can set up a built-in event listener that receives all events and logs the events through JBoss-logging. Using the `org.keycloak.events` logger, {project_name} logs error events as `WARN` and other events as `DEBUG`." +msgstr "" + +msgid "$ kcadm.sh update events/config -r demorealm -s 'eventsListeners=[\"jboss-logging\"]'" +msgstr "" + +msgid "c:\\> kcadm update events/config -r demorealm -s \"eventsListeners=[\\\"jboss-logging\\\"]\"" +msgstr "" + +msgid "You can turn on storage for all available ERROR events, not including auditing events, for two days so you can retrieve the events through Admin REST." +msgstr "" + +msgid "$ kcadm.sh update events/config -r demorealm -s eventsEnabled=true -s 'enabledEventTypes=[\"LOGIN_ERROR\",\"REGISTER_ERROR\",\"LOGOUT_ERROR\",\"CODE_TO_TOKEN_ERROR\",\"CLIENT_LOGIN_ERROR\",\"FEDERATED_IDENTITY_LINK_ERROR\",\"REMOVE_FEDERATED_IDENTITY_ERROR\",\"UPDATE_EMAIL_ERROR\",\"UPDATE_PROFILE_ERROR\",\"UPDATE_PASSWORD_ERROR\",\"UPDATE_TOTP_ERROR\",\"VERIFY_EMAIL_ERROR\",\"REMOVE_TOTP_ERROR\",\"SEND_VERIFY_EMAIL_ERROR\",\"SEND_RESET_PASSWORD_ERROR\",\"SEND_IDENTITY_PROVIDER_LINK_ERROR\",\"RESET_PASSWORD_ERROR\",\"IDENTITY_PROVIDER_FIRST_LOGIN_ERROR\",\"IDENTITY_PROVIDER_POST_LOGIN_ERROR\",\"CUSTOM_REQUIRED_ACTION_ERROR\",\"EXECUTE_ACTIONS_ERROR\",\"CLIENT_REGISTER_ERROR\",\"CLIENT_UPDATE_ERROR\",\"CLIENT_DELETE_ERROR\"]' -s eventsExpiration=172800" +msgstr "" + +msgid "c:\\> kcadm update events/config -r demorealm -s eventsEnabled=true -s \"enabledEventTypes=[\\\"LOGIN_ERROR\\\",\\\"REGISTER_ERROR\\\",\\\"LOGOUT_ERROR\\\",\\\"CODE_TO_TOKEN_ERROR\\\",\\\"CLIENT_LOGIN_ERROR\\\",\\\"FEDERATED_IDENTITY_LINK_ERROR\\\",\\\"REMOVE_FEDERATED_IDENTITY_ERROR\\\",\\\"UPDATE_EMAIL_ERROR\\\",\\\"UPDATE_PROFILE_ERROR\\\",\\\"UPDATE_PASSWORD_ERROR\\\",\\\"UPDATE_TOTP_ERROR\\\",\\\"VERIFY_EMAIL_ERROR\\\",\\\"REMOVE_TOTP_ERROR\\\",\\\"SEND_VERIFY_EMAIL_ERROR\\\",\\\"SEND_RESET_PASSWORD_ERROR\\\",\\\"SEND_IDENTITY_PROVIDER_LINK_ERROR\\\",\\\"RESET_PASSWORD_ERROR\\\",\\\"IDENTITY_PROVIDER_FIRST_LOGIN_ERROR\\\",\\\"IDENTITY_PROVIDER_POST_LOGIN_ERROR\\\",\\\"CUSTOM_REQUIRED_ACTION_ERROR\\\",\\\"EXECUTE_ACTIONS_ERROR\\\",\\\"CLIENT_REGISTER_ERROR\\\",\\\"CLIENT_UPDATE_ERROR\\\",\\\"CLIENT_DELETE_ERROR\\\"]\" -s eventsExpiration=172800" +msgstr "" + +msgid "You can reset stored event types to *all available event types*. Setting the value to an empty list is the same as enumerating all." +msgstr "" + +msgid "$ kcadm.sh update events/config -r demorealm -s enabledEventTypes=[]" +msgstr "" + +msgid "You can enable storage of auditing events." +msgstr "" + +msgid "$ kcadm.sh update events/config -r demorealm -s adminEventsEnabled=true -s adminEventsDetailsEnabled=true" +msgstr "" + +msgid "You can get the last 100 events. The events are ordered from newest to oldest." +msgstr "" + +msgid "$ kcadm.sh get events --offset 0 --limit 100" +msgstr "" + +msgid "You can delete all saved events." +msgstr "" + +msgid "$ kcadm delete events" +msgstr "" + +msgid "Flushing the caches" +msgstr "" + +msgid "Use the `create` command with one of these endpoints to clear caches:" +msgstr "" + +msgid "`clear-realm-cache`" +msgstr "" + +msgid "`clear-user-cache`" +msgstr "" + +msgid "`clear-keys-cache`" +msgstr "" + +msgid "Set `realm` to the same value as the target realm." +msgstr "" + +msgid "" +"$ kcadm.sh create clear-realm-cache -r demorealm -s realm=demorealm\n" +"$ kcadm.sh create clear-user-cache -r demorealm -s realm=demorealm\n" +"$ kcadm.sh create clear-keys-cache -r demorealm -s realm=demorealm" +msgstr "" + +msgid "Importing a realm from exported .json file" +msgstr "" + +msgid "Use the `create` command on the `partialImport` endpoint." +msgstr "" + +msgid "Set `ifResourceExists` to `FAIL`, `SKIP`, or `OVERWRITE`." +msgstr "" + +msgid "Use `-f` to submit the exported realm `.json` file." +msgstr "" + +msgid "$ kcadm.sh create partialImport -r demorealm2 -s ifResourceExists=FAIL -o -f demorealm.json" +msgstr "" + +msgid "If the realm does not yet exist, create it first." +msgstr "" + +msgid "$ kcadm.sh create realms -s realm=demorealm2 -s enabled=true" +msgstr "" + +msgid "Role operations" +msgstr "" + +msgid "Use the `roles` endpoint to create a realm role." +msgstr "" + +msgid "$ kcadm.sh create roles -r demorealm -s name=user -s 'description=Regular user with a limited set of permissions'" +msgstr "" + +msgid "Creating a client role" +msgstr "" + +msgid "Identify the client." +msgstr "" + +msgid "Use the `get` command to list the available clients." +msgstr "" + +msgid "$ kcadm.sh get clients -r demorealm --fields id,clientId" +msgstr "" + +msgid "Create a new role by using the `clientId` attribute to construct an endpoint URI, such as `clients/ID/roles`." +msgstr "" + +msgid "$ kcadm.sh create clients/a95b6af3-0bdc-4878-ae2e-6d61a4eca9a0/roles -r demorealm -s name=editor -s 'description=Editor can edit, and publish any article'" +msgstr "" + +msgid "Listing realm roles" +msgstr "" + +msgid "Use the `get` command on the `roles` endpoint to list existing realm roles." +msgstr "" + +msgid "$ kcadm.sh get roles -r demorealm" +msgstr "" + +msgid "You can use the `get-roles` command also." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm" +msgstr "" + +msgid "Listing client roles" +msgstr "" + +msgid "{project_name} has a dedicated `get-roles` command to simplify the listing of realm and client roles. The command is an extension of the `get` command and behaves the same as the `get` command but with additional semantics for listing roles." +msgstr "" + +msgid "Use the `get-roles` command by passing it the clientId (`--cclientid`) option or the `id` (`--cid`) option to identify the client to list client roles." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --cclientid realm-management" +msgstr "" + +msgid "Getting a specific realm role" +msgstr "" + +msgid "Use the `get` command and the role `name` to construct an endpoint URI for a specific realm role, `roles/ROLE_NAME`, where `user` is the existing role's name." +msgstr "" + +msgid "$ kcadm.sh get roles/user -r demorealm" +msgstr "" + +msgid "You can use the `get-roles` command, passing it a role name (`--rolename` option) or ID (`--roleid` option)." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --rolename user" +msgstr "" + +msgid "Getting a specific client role" +msgstr "" + +msgid "Use the `get-roles` command, passing it the clientId attribute (`--cclientid` option) or ID attribute (`--cid` option) to identify the client, and pass the role name (`--rolename` option) or the role ID attribute (`--roleid`) to identify a specific client role." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --cclientid realm-management --rolename manage-clients" +msgstr "" + +msgid "Updating a realm role" +msgstr "" + +msgid "Use the `update` command with the endpoint URI you used to get a specific realm role." +msgstr "" + +msgid "$ kcadm.sh update roles/user -r demorealm -s 'description=Role representing a regular user'" +msgstr "" + +msgid "Updating a client role" +msgstr "" + +msgid "Use the `update` command with the endpoint URI that you used to get a specific client role." +msgstr "" + +msgid "$ kcadm.sh update clients/a95b6af3-0bdc-4878-ae2e-6d61a4eca9a0/roles/editor -r demorealm -s 'description=User that can edit, and publish articles'" +msgstr "" + +msgid "Deleting a realm role" +msgstr "" + +msgid "Use the `delete` command with the endpoint URI that you used to get a specific realm role." +msgstr "" + +msgid "$ kcadm.sh delete roles/user -r demorealm" +msgstr "" + +msgid "Deleting a client role" +msgstr "" + +msgid "Use the `delete` command with the endpoint URI that you used to get a specific client role." +msgstr "" + +msgid "$ kcadm.sh delete clients/a95b6af3-0bdc-4878-ae2e-6d61a4eca9a0/roles/editor -r demorealm" +msgstr "" + +msgid "Listing assigned, available, and effective realm roles for a composite role" +msgstr "" + +msgid "Use the `get-roles` command to list assigned, available, and effective realm roles for a composite role." +msgstr "" + +msgid "To list *assigned* realm roles for the composite role, specify the target composite role by name (`--rname` option) or ID (`--rid` option)." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --rname testrole" +msgstr "" + +msgid "Use the `--effective` option to list *effective* realm roles." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --rname testrole --effective" +msgstr "" + +msgid "Use the `--available` option to list realm roles that you can add to the composite role." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --rname testrole --available" +msgstr "" + +msgid "Listing assigned, available, and effective client roles for a composite role" +msgstr "" + +msgid "Use the `get-roles` command to list assigned, available, and effective client roles for a composite role." +msgstr "" + +msgid "To list *assigned* client roles for the composite role, you can specify the target composite role by name (`--rname` option) or ID (`--rid` option) and client by the clientId attribute (`--cclientid` option) or ID (`--cid` option)." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --rname testrole --cclientid realm-management" +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --rname testrole --cclientid realm-management --effective" +msgstr "" + +msgid "Use the `--available` option to list realm roles that you can add to the target composite role." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --rname testrole --cclientid realm-management --available" +msgstr "" + +msgid "Adding realm roles to a composite role" +msgstr "" + +msgid "{project_name} provides an `add-roles` command for adding realm roles and client roles." +msgstr "" + +msgid "This example adds the `user` role to the composite role `testrole`." +msgstr "" + +msgid "$ kcadm.sh add-roles --rname testrole --rolename user -r demorealm" +msgstr "" + +msgid "Removing realm roles from a composite role" +msgstr "" + +msgid "{project_name} provides a `remove-roles` command for removing realm roles and client roles." +msgstr "" + +msgid "The following example removes the `user` role from the target composite role `testrole`." +msgstr "" + +msgid "$ kcadm.sh remove-roles --rname testrole --rolename user -r demorealm" +msgstr "" + +msgid "Adding client roles to a realm role" +msgstr "" + +msgid "The following example adds the roles defined on the client `realm-management`, `create-client`, and `view-users`, to the `testrole` composite role." +msgstr "" + +msgid "$ kcadm.sh add-roles -r demorealm --rname testrole --cclientid realm-management --rolename create-client --rolename view-users" +msgstr "" + +msgid "Adding client roles to a client role" +msgstr "" + +msgid "Determine the ID of the composite client role by using the `get-roles` command." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --cclientid test-client --rolename operations" +msgstr "" + +msgid "Assume that a client exists with a clientId attribute named `test-client`, a client role named `support`, and a client role named `operations` which becomes a composite role that has an ID of \"fc400897-ef6a-4e8c-872b-1581b7fa8a71\"." +msgstr "" + +msgid "Use the following example to add another role to the composite role." +msgstr "" + +msgid "$ kcadm.sh add-roles -r demorealm --cclientid test-client --rid fc400897-ef6a-4e8c-872b-1581b7fa8a71 --rolename support" +msgstr "" + +msgid "List the roles of a composite role by using the `get-roles --all` command." +msgstr "" + +msgid "$ kcadm.sh get-roles --rid fc400897-ef6a-4e8c-872b-1581b7fa8a71 --all" +msgstr "" + +msgid "Removing client roles from a composite role" +msgstr "" + +msgid "Use the `remove-roles` command to remove client roles from a composite role." +msgstr "" + +msgid "Use the following example to remove two roles defined on the client `realm-management`, the `create-client` role and the `view-users` role, from the `testrole` composite role." +msgstr "" + +msgid "$ kcadm.sh remove-roles -r demorealm --rname testrole --cclientid realm-management --rolename create-client --rolename view-users" +msgstr "" + +msgid "Adding client roles to a group" +msgstr "" + +msgid "Use the `add-roles` command to add realm roles and client roles." +msgstr "" + +msgid "The following example adds the roles defined on the client `realm-management`, `create-client` and `view-users`, to the `Group` group (`--gname` option). Alternatively, you can specify the group by ID (`--gid` option)." +msgstr "" + +msgid "See <<_group_operations, Group operations>> for more information." +msgstr "" + +msgid "$ kcadm.sh add-roles -r demorealm --gname Group --cclientid realm-management --rolename create-client --rolename view-users" +msgstr "" + +msgid "Removing client roles from a group" +msgstr "" + +msgid "Use the `remove-roles` command to remove client roles from a group." +msgstr "" + +msgid "The following example removes two roles defined on the client `realm management`, `create-client` and `view-users`, from the `Group` group." +msgstr "" + +msgid "$ kcadm.sh remove-roles -r demorealm --gname Group --cclientid realm-management --rolename create-client --rolename view-users" +msgstr "" + +msgid "Client operations" +msgstr "" + +msgid "Creating a client" +msgstr "" + +msgid "Run the `create` command on a `clients` endpoint to create a new client." +msgstr "" + +msgid "$ kcadm.sh create clients -r demorealm -s clientId=myapp -s enabled=true" +msgstr "" + +msgid "Specify a secret if to set a secret for adapters to authenticate." +msgstr "" + +msgid "$ kcadm.sh create clients -r demorealm -s clientId=myapp -s enabled=true -s clientAuthenticatorType=client-secret -s secret=d0b8122f-8dfb-46b7-b68a-f5cc4e25d000" +msgstr "" + +msgid "Listing clients" +msgstr "" + +msgid "Use the `get` command on the `clients` endpoint to list clients." +msgstr "" + +msgid "This example filters the output to list only the `id` and `clientId` attributes:" +msgstr "" + +msgid "Getting a specific client" +msgstr "" + +msgid "Use the client ID to construct an endpoint URI that targets a specific client, such as `clients/ID`." +msgstr "" + +msgid "$ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm" +msgstr "" + +msgid "Getting the current secret for a specific client" +msgstr "" + +msgid "Use the client ID to construct an endpoint URI, such as `clients/ID/client-secret`." +msgstr "" + +msgid "$ kcadm.sh get clients/$CID/client-secret -r demorealm" +msgstr "" + +msgid "Generate a new secret for a specific client" +msgstr "" + +msgid "$ kcadm.sh create clients/$CID/client-secret -r demorealm" +msgstr "" + +msgid "Updating the current secret for a specific client" +msgstr "" + +msgid "Use the client ID to construct an endpoint URI, such as `clients/ID`." +msgstr "" + +msgid "$ kcadm.sh update clients/$CID -s \"secret=newSecret\" -r demorealm" +msgstr "" + +msgid "Getting an adapter configuration file (keycloak.json) for a specific client" +msgstr "" + +msgid "Use the client ID to construct an endpoint URI that targets a specific client, such as `clients/ID/installation/providers/keycloak-oidc-keycloak-json`." +msgstr "" + +msgid "$ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3/installation/providers/keycloak-oidc-keycloak-json -r demorealm" +msgstr "" + +msgid "Getting a WildFly subsystem adapter configuration for a specific client" +msgstr "" + +msgid "Use the client ID to construct an endpoint URI that targets a specific client, such as `clients/ID/installation/providers/keycloak-oidc-jboss-subsystem`." +msgstr "" + +msgid "$ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3/installation/providers/keycloak-oidc-jboss-subsystem -r demorealm" +msgstr "" + +msgid "Getting a Docker-v2 example configuration for a specific client" +msgstr "" + +msgid "Use the client ID to construct an endpoint URI that targets a specific client, such as `clients/ID/installation/providers/docker-v2-compose-yaml`." +msgstr "" + +msgid "The response is in `.zip` format." +msgstr "" + +msgid "$ kcadm.sh get http://localhost:8080{kc_admins_path}/realms/demorealm/clients/8f271c35-44e3-446f-8953-b0893810ebe7/installation/providers/docker-v2-compose-yaml -r demorealm > keycloak-docker-compose-yaml.zip" +msgstr "" + +msgid "Use the `update` command with the same endpoint URI that you use to get a specific client." +msgstr "" + +msgid "$ kcadm.sh update clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm -s enabled=false -s publicClient=true -s 'redirectUris=[\"http://localhost:8080/myapp/*\"]' -s baseUrl=http://localhost:8080/myapp -s adminUrl=http://localhost:8080/myapp" +msgstr "" + +msgid "c:\\> kcadm update clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm -s enabled=false -s publicClient=true -s \"redirectUris=[\\\"http://localhost:8080/myapp/*\\\"]\" -s baseUrl=http://localhost:8080/myapp -s adminUrl=http://localhost:8080/myapp" +msgstr "" + +msgid "Deleting a client" +msgstr "" + +msgid "Use the `delete` command with the same endpoint URI that you use to get a specific client." +msgstr "" + +msgid "$ kcadm.sh delete clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm" +msgstr "" + +msgid "Adding or removing roles for client's service account" +msgstr "" + +msgid "A client's service account is a user account with username `service-account-CLIENT_ID`. You can perform the same user operations on this account as a regular account." +msgstr "" + +msgid "User operations" +msgstr "" + +msgid "Creating a user" +msgstr "" + +msgid "Run the `create` command on the `users` endpoint to create a new user." +msgstr "" + +msgid "$ kcadm.sh create users -r demorealm -s username=testuser -s enabled=true" +msgstr "" + +msgid "Listing users" +msgstr "" + +msgid "Use the `users` endpoint to list users. The target user must change their password the next time they log in." +msgstr "" + +msgid "$ kcadm.sh get users -r demorealm --offset 0 --limit 1000" +msgstr "" + +msgid "You can filter users by `username`, `firstName`, `lastName`, or `email`." +msgstr "" + +msgid "" +"$ kcadm.sh get users -r demorealm -q email=google.com\n" +"$ kcadm.sh get users -r demorealm -q username=testuser" +msgstr "" + +msgid "Filtering does not use exact matching. This example matches the value of the `username` attribute against the `\\*testuser*` pattern." +msgstr "" + +msgid "You can filter across multiple attributes by specifying multiple `-q` options. {project_name} returns users that match the condition for all the attributes only." +msgstr "" + +msgid "Getting a specific user" +msgstr "" + +msgid "Use the user ID to compose an endpoint URI, such as `users/USER_ID`." +msgstr "" + +msgid "$ kcadm.sh get users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm" +msgstr "" + +msgid "Updating a user" +msgstr "" + +msgid "Use the `update` command with the same endpoint URI that you use to get a specific user." +msgstr "" + +msgid "$ kcadm.sh update users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm -s 'requiredActions=[\"VERIFY_EMAIL\",\"UPDATE_PROFILE\",\"CONFIGURE_TOTP\",\"UPDATE_PASSWORD\"]'" +msgstr "" + +msgid "c:\\> kcadm update users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm -s \"requiredActions=[\\\"VERIFY_EMAIL\\\",\\\"UPDATE_PROFILE\\\",\\\"CONFIGURE_TOTP\\\",\\\"UPDATE_PASSWORD\\\"]\"" +msgstr "" + +msgid "Use the `delete` command with the same endpoint URI that you use to get a specific user." +msgstr "" + +msgid "$ kcadm.sh delete users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm" +msgstr "" + +msgid "Resetting a user's password" +msgstr "" + +msgid "Use the dedicated `set-password` command to reset a user's password." +msgstr "" + +msgid "$ kcadm.sh set-password -r demorealm --username testuser --new-password NEWPASSWORD --temporary" +msgstr "" + +msgid "This command sets a temporary password for the user. The target user must change the password the next time they log in." +msgstr "" + +msgid "You can use `--userid` to specify the user by using the `id` attribute." +msgstr "" + +msgid "You can achieve the same result using the `update` command on an endpoint constructed from the one you used to get a specific user, such as `users/USER_ID/reset-password`." +msgstr "" + +msgid "$ kcadm.sh update users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2/reset-password -r demorealm -s type=password -s value=NEWPASSWORD -s temporary=true -n" +msgstr "" + +msgid "The `-n` parameter ensures that {project_name} performs the `PUT` command without performing a `GET` command before the `PUT` command. This is necessary because the `reset-password` endpoint does not support `GET`." +msgstr "" + +msgid "Listing assigned, available, and effective realm roles for a user" +msgstr "" + +msgid "You can use a `get-roles` command to list assigned, available, and effective realm roles for a user." +msgstr "" + +msgid "Specify the target user by user name or ID to list the user's *assigned* realm roles." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --uusername testuser" +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --uusername testuser --effective" +msgstr "" + +msgid "Use the `--available` option to list realm roles that you can add to a user." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --uusername testuser --available" +msgstr "" + +msgid "Listing assigned, available, and effective client roles for a user" +msgstr "" + +msgid "Use a `get-roles` command to list assigned, available, and effective client roles for a user." +msgstr "" + +msgid "Specify the target user by user name (`--uusername` option) or ID (`--uid` option) and client by a clientId attribute (`--cclientid` option) or an ID (`--cid` option) to list *assigned* client roles for the user." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --uusername testuser --cclientid realm-management" +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --uusername testuser --cclientid realm-management --effective" +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --uusername testuser --cclientid realm-management --available" +msgstr "" + +msgid "Adding realm roles to a user" +msgstr "" + +msgid "Use an `add-roles` command to add realm roles to a user." +msgstr "" + +msgid "Use the following example to add the `user` role to user `testuser`:" +msgstr "" + +msgid "$ kcadm.sh add-roles --uusername testuser --rolename user -r demorealm" +msgstr "" + +msgid "Removing realm roles from a user" +msgstr "" + +msgid "Use a `remove-roles` command to remove realm roles from a user." +msgstr "" + +msgid "Use the following example to remove the `user` role from the user `testuser`:" +msgstr "" + +msgid "$ kcadm.sh remove-roles --uusername testuser --rolename user -r demorealm" +msgstr "" + +msgid "Adding client roles to a user" +msgstr "" + +msgid "Use an `add-roles` command to add client roles to a user." +msgstr "" + +msgid "Use the following example to add two roles defined on the client `realm management`, the `create-client` role and the `view-users` role, to the user `testuser`." +msgstr "" + +msgid "$ kcadm.sh add-roles -r demorealm --uusername testuser --cclientid realm-management --rolename create-client --rolename view-users" +msgstr "" + +msgid "Removing client roles from a user" +msgstr "" + +msgid "Use a `remove-roles` command to remove client roles from a user." +msgstr "" + +msgid "Use the following example to remove two roles defined on the realm management client:" +msgstr "" + +msgid "$ kcadm.sh remove-roles -r demorealm --uusername testuser --cclientid realm-management --rolename create-client --rolename view-users" +msgstr "" + +msgid "Listing a user's sessions" +msgstr "" + +msgid "Identify the user's ID," +msgstr "" + +msgid "Use the ID to compose an endpoint URI, such as `users/ID/sessions`." +msgstr "" + +msgid "Use the `get` command to retrieve a list of the user's sessions." +msgstr "" + +msgid "$ kcadm.sh get users/6da5ab89-3397-4205-afaa-e201ff638f9e/sessions -r demorealm" +msgstr "" + +msgid "Logging out a user from a specific session" +msgstr "" + +msgid "Determine the session's ID as described earlier." +msgstr "" + +msgid "Use the session's ID to compose an endpoint URI, such as `sessions/ID`." +msgstr "" + +msgid "Use the `delete` command to invalidate the session." +msgstr "" + +msgid "$ kcadm.sh delete sessions/d0eaa7cc-8c5d-489d-811a-69d3c4ec84d1 -r demorealm" +msgstr "" + +msgid "Logging out a user from all sessions" +msgstr "" + +msgid "Use the user's ID to construct an endpoint URI, such as `users/ID/logout`." +msgstr "" + +msgid "Use the `create` command to perform `POST` on that endpoint URI." +msgstr "" + +msgid "$ kcadm.sh create users/6da5ab89-3397-4205-afaa-e201ff638f9e/logout -r demorealm -s realm=demorealm -s user=6da5ab89-3397-4205-afaa-e201ff638f9e" +msgstr "" + +msgid "Group operations" +msgstr "" + +msgid "Creating a group" +msgstr "" + +msgid "Use the `create` command on the `groups` endpoint to create a new group." +msgstr "" + +msgid "$ kcadm.sh create groups -r demorealm -s name=Group" +msgstr "" + +msgid "Listing groups" +msgstr "" + +msgid "Use the `get` command on the `groups` endpoint to list groups." +msgstr "" + +msgid "$ kcadm.sh get groups -r demorealm" +msgstr "" + +msgid "Getting a specific group" +msgstr "" + +msgid "Use the group's ID to construct an endpoint URI, such as `groups/GROUP_ID`." +msgstr "" + +msgid "$ kcadm.sh get groups/51204821-0580-46db-8f2d-27106c6b5ded -r demorealm" +msgstr "" + +msgid "Updating a group" +msgstr "" + +msgid "Use the `update` command with the same endpoint URI that you use to get a specific group." +msgstr "" + +msgid "$ kcadm.sh update groups/51204821-0580-46db-8f2d-27106c6b5ded -s 'attributes.email=[\"group@example.com\"]' -r demorealm" +msgstr "" + +msgid "Deleting a group" +msgstr "" + +msgid "Use the `delete` command with the same endpoint URI that you use to get a specific group." +msgstr "" + +msgid "$ kcadm.sh delete groups/51204821-0580-46db-8f2d-27106c6b5ded -r demorealm" +msgstr "" + +msgid "Creating a subgroup" +msgstr "" + +msgid "Find the ID of the parent group by listing groups. Use that ID to construct an endpoint URI, such as `groups/GROUP_ID/children`." +msgstr "" + +msgid "$ kcadm.sh create groups/51204821-0580-46db-8f2d-27106c6b5ded/children -r demorealm -s name=SubGroup" +msgstr "" + +msgid "Moving a group under another group" +msgstr "" + +msgid "Find the ID of an existing parent group and the ID of an existing child group." +msgstr "" + +msgid "Use the parent group's ID to construct an endpoint URI, such as `groups/PARENT_GROUP_ID/children`." +msgstr "" + +msgid "Run the `create` command on this endpoint and pass the child group's ID as a JSON body." +msgstr "" + +msgid "$ kcadm.sh create groups/51204821-0580-46db-8f2d-27106c6b5ded/children -r demorealm -s id=08d410c6-d585-4059-bb07-54dcb92c5094 -s name=SubGroup" +msgstr "" + +msgid "Get groups for a specific user" +msgstr "" + +msgid "Use a user's ID to determine a user's membership in groups to compose an endpoint URI, such as `users/USER_ID/groups`." +msgstr "" + +msgid "$ kcadm.sh get users/b544f379-5fc4-49e5-8a8d-5cfb71f46f53/groups -r demorealm" +msgstr "" + +msgid "Adding a user to a group" +msgstr "" + +msgid "Use the `update` command with an endpoint URI composed of a user's ID and a group's ID, such as `users/USER_ID/groups/GROUP_ID`, to add a user to a group." +msgstr "" + +msgid "$ kcadm.sh update users/b544f379-5fc4-49e5-8a8d-5cfb71f46f53/groups/ce01117a-7426-4670-a29a-5c118056fe20 -r demorealm -s realm=demorealm -s userId=b544f379-5fc4-49e5-8a8d-5cfb71f46f53 -s groupId=ce01117a-7426-4670-a29a-5c118056fe20 -n" +msgstr "" + +msgid "Removing a user from a group" +msgstr "" + +msgid "Use the `delete` command on the same endpoint URI you use for adding a user to a group, such as `users/USER_ID/groups/GROUP_ID`, to remove a user from a group." +msgstr "" + +msgid "$ kcadm.sh delete users/b544f379-5fc4-49e5-8a8d-5cfb71f46f53/groups/ce01117a-7426-4670-a29a-5c118056fe20 -r demorealm" +msgstr "" + +msgid "Listing assigned, available, and effective realm roles for a group" +msgstr "" + +msgid "Use a dedicated `get-roles` command to list assigned, available, and effective realm roles for a group." +msgstr "" + +msgid "Specify the target group by name (`--gname` option), path (`--gpath` option), or ID (`--gid` option) to list *assigned* realm roles for the group." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --gname Group" +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --gname Group --effective" +msgstr "" + +msgid "Use the `--available` option to list realm roles that you can add to the group." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --gname Group --available" +msgstr "" + +msgid "Listing assigned, available, and effective client roles for a group" +msgstr "" + +msgid "Use the `get-roles` command to list assigned, available, and effective client roles for a group." +msgstr "" + +msgid "Specify the target group by name (`--gname` option) or ID (`--gid` option)," +msgstr "" + +msgid "Specify the client by the clientId attribute (`--cclientid` option) or ID (`--id` option) to list *assigned* client roles for the user." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --gname Group --cclientid realm-management" +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --gname Group --cclientid realm-management --effective" +msgstr "" + +msgid "Use the `--available` option to list realm roles that you can still add to the group." +msgstr "" + +msgid "$ kcadm.sh get-roles -r demorealm --gname Group --cclientid realm-management --available" +msgstr "" + +msgid "Identity provider operations" +msgstr "" + +msgid "Listing available identity providers" +msgstr "" + +msgid "Use the `serverinfo` endpoint to list available identity providers." +msgstr "" + +msgid "$ kcadm.sh get serverinfo -r demorealm --fields 'identityProviders(*)'" +msgstr "" + +msgid "{project_name} processes the `serverinfo` endpoint similarly to the `realms` endpoint. {project_name} does not resolve the endpoint relative to a target realm because it exists outside any specific realm." +msgstr "" + +msgid "Listing configured identity providers" +msgstr "" + +msgid "Use the `identity-provider/instances` endpoint." +msgstr "" + +msgid "$ kcadm.sh get identity-provider/instances -r demorealm --fields alias,providerId,enabled" +msgstr "" + +msgid "Getting a specific configured identity provider" +msgstr "" + +msgid "Use the identity provider's `alias` attribute to construct an endpoint URI, such as `identity-provider/instances/ALIAS`, to get a specific identity provider." +msgstr "" + +msgid "$ kcadm.sh get identity-provider/instances/facebook -r demorealm" +msgstr "" + +msgid "Removing a specific configured identity provider" +msgstr "" + +msgid "Use the `delete` command with the same endpoint URI that you use to get a specific configured identity provider to remove a specific configured identity provider." +msgstr "" + +msgid "$ kcadm.sh delete identity-provider/instances/facebook -r demorealm" +msgstr "" + +msgid "Configuring a Keycloak OpenID Connect identity provider" +msgstr "" + +msgid "Use `keycloak-oidc` as the `providerId` when you create a new identity provider instance." +msgstr "" + +msgid "Provide the `config` attributes: `authorizationUrl`, `tokenUrl`, `clientId`, and `clientSecret`." +msgstr "" + +msgid "$ kcadm.sh create identity-provider/instances -r demorealm -s alias=keycloak-oidc -s providerId=keycloak-oidc -s enabled=true -s 'config.useJwksUrl=\"true\"' -s config.authorizationUrl=http://localhost:8180{kc_realms_path}/demorealm/protocol/openid-connect/auth -s config.tokenUrl=http://localhost:8180{kc_realms_path}/demorealm/protocol/openid-connect/token -s config.clientId=demo-oidc-provider -s config.clientSecret=secret" +msgstr "" + +msgid "Configuring an OpenID Connect identity provider" +msgstr "" + +msgid "Configure the generic OpenID Connect provider the same way you configure the Keycloak OpenID Connect provider, except you set the `providerId` attribute value to `oidc`." +msgstr "" + +msgid "Configuring a SAML 2 identity provider" +msgstr "" + +msgid "Use `saml` as the `providerId`." +msgstr "" + +msgid "Provide the `config` attributes: `singleSignOnServiceUrl`, `nameIDPolicyFormat`, and `signatureAlgorithm`." +msgstr "" + +msgid "$ kcadm.sh create identity-provider/instances -r demorealm -s alias=saml -s providerId=saml -s enabled=true -s 'config.useJwksUrl=\"true\"' -s config.singleSignOnServiceUrl=http://localhost:8180{kc_realms_path}/saml-broker-realm/protocol/saml -s config.nameIDPolicyFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent -s config.signatureAlgorithm=RSA_SHA256" +msgstr "" + +msgid "Configuring a Facebook identity provider" +msgstr "" + +msgid "Use `facebook` as the `providerId`." +msgstr "" + +msgid "Provide the `config` attributes: `clientId` and `clientSecret`. You can find these attributes in the Facebook Developers application configuration page for your application. See the <<_facebook, Facebook identity broker>> page for more information." +msgstr "" + +msgid "$ kcadm.sh create identity-provider/instances -r demorealm -s alias=facebook -s providerId=facebook -s enabled=true -s 'config.useJwksUrl=\"true\"' -s config.clientId=FACEBOOK_CLIENT_ID -s config.clientSecret=FACEBOOK_CLIENT_SECRET" +msgstr "" + +msgid "Configuring a Google identity provider" +msgstr "" + +msgid "Use `google` as the `providerId`." +msgstr "" + +msgid "Provide the `config` attributes: `clientId` and `clientSecret`. You can find these attributes in the Google Developers application configuration page for your application. See the <<_google, Google identity broker>> page for more information." +msgstr "" + +msgid "$ kcadm.sh create identity-provider/instances -r demorealm -s alias=google -s providerId=google -s enabled=true -s 'config.useJwksUrl=\"true\"' -s config.clientId=GOOGLE_CLIENT_ID -s config.clientSecret=GOOGLE_CLIENT_SECRET" +msgstr "" + +msgid "Configuring a Twitter identity provider" +msgstr "" + +msgid "Use `twitter` as the `providerId`." +msgstr "" + +msgid "Provide the `config` attributes `clientId` and `clientSecret`. You can find these attributes in the Twitter Application Management application configuration page for your application. See the <<_twitter, Twitter identity broker>> page for more information." +msgstr "" + +msgid "$ kcadm.sh create identity-provider/instances -r demorealm -s alias=google -s providerId=google -s enabled=true -s 'config.useJwksUrl=\"true\"' -s config.clientId=TWITTER_API_KEY -s config.clientSecret=TWITTER_API_SECRET" +msgstr "" + +msgid "Configuring a GitHub identity provider" +msgstr "" + +msgid "Use `github` as the `providerId`." +msgstr "" + +msgid "Provide the `config` attributes `clientId` and `clientSecret`. You can find these attributes in the GitHub Developer Application Settings page for your application. See the <<_github, GitHub identity broker>> page for more information." +msgstr "" + +msgid "$ kcadm.sh create identity-provider/instances -r demorealm -s alias=github -s providerId=github -s enabled=true -s 'config.useJwksUrl=\"true\"' -s config.clientId=GITHUB_CLIENT_ID -s config.clientSecret=GITHUB_CLIENT_SECRET" +msgstr "" + +msgid "Configuring a LinkedIn identity provider" +msgstr "" + +msgid "Use `linkedin` as the `providerId`." +msgstr "" + +msgid "Provide the `config` attributes `clientId` and `clientSecret`. You can find these attributes in the LinkedIn Developer Console application page for your application. See the <<_linkedin, LinkedIn identity broker>> page for more information." +msgstr "" + +msgid "$ kcadm.sh create identity-provider/instances -r demorealm -s alias=linkedin -s providerId=linkedin -s enabled=true -s 'config.useJwksUrl=\"true\"' -s config.clientId=LINKEDIN_CLIENT_ID -s config.clientSecret=LINKEDIN_CLIENT_SECRET" +msgstr "" + +msgid "Configuring a Microsoft Live identity provider" +msgstr "" + +msgid "Use `microsoft` as the `providerId`." +msgstr "" + +msgid "Provide the `config` attributes `clientId` and `clientSecret`. You can find these attributes in the Microsoft Application Registration Portal page for your application. See the <<_microsoft, Microsoft identity broker>> page for more information." +msgstr "" + +msgid "$ kcadm.sh create identity-provider/instances -r demorealm -s alias=microsoft -s providerId=microsoft -s enabled=true -s 'config.useJwksUrl=\"true\"' -s config.clientId=MICROSOFT_APP_ID -s config.clientSecret=MICROSOFT_PASSWORD" +msgstr "" + +msgid "Configuring a Stack Overflow identity provider" +msgstr "" + +msgid "Use `stackoverflow` command as the `providerId`." +msgstr "" + +msgid "Provide the `config` attributes `clientId`, `clientSecret`, and `key`. You can find these attributes in the Stack Apps OAuth page for your application. See the <<_stackoverflow, Stack Overflow identity broker>> page for more information." +msgstr "" + +msgid "$ kcadm.sh create identity-provider/instances -r demorealm -s alias=stackoverflow -s providerId=stackoverflow -s enabled=true -s 'config.useJwksUrl=\"true\"' -s config.clientId=STACKAPPS_CLIENT_ID -s config.clientSecret=STACKAPPS_CLIENT_SECRET -s config.key=STACKAPPS_KEY" +msgstr "" + +msgid "Storage provider operations" +msgstr "" + +msgid "Configuring a Kerberos storage provider" +msgstr "" + +msgid "Use the `create` command against the `components` endpoint." +msgstr "" + +msgid "Specify the realm id as a value of the `parentId` attribute." +msgstr "" + +msgid "Specify `kerberos` as the value of the `providerId` attribute, and `org.keycloak.storage.UserStorageProvider` as the value of the `providerType` attribute." +msgstr "" + +msgid "$ kcadm.sh create components -r demorealm -s parentId=demorealmId -s id=demokerberos -s name=demokerberos -s providerId=kerberos -s providerType=org.keycloak.storage.UserStorageProvider -s 'config.priority=[\"0\"]' -s 'config.debug=[\"false\"]' -s 'config.allowPasswordAuthentication=[\"true\"]' -s 'config.editMode=[\"UNSYNCED\"]' -s 'config.updateProfileFirstLogin=[\"true\"]' -s 'config.allowKerberosAuthentication=[\"true\"]' -s 'config.kerberosRealm=[\"KEYCLOAK.ORG\"]' -s 'config.keyTab=[\"http.keytab\"]' -s 'config.serverPrincipal=[\"HTTP/localhost@KEYCLOAK.ORG\"]' -s 'config.cachePolicy=[\"DEFAULT\"]'" +msgstr "" + +msgid "Configuring an LDAP user storage provider" +msgstr "" + +msgid "Specify `ldap` as the value of the `providerId` attribute, and `org.keycloak.storage.UserStorageProvider` as the value of the `providerType` attribute." +msgstr "" + +msgid "Provide the realm ID as the value of the `parentId` attribute." +msgstr "" + +msgid "Use the following example to create a Kerberos-integrated LDAP provider." +msgstr "" + +msgid "$ kcadm.sh create components -r demorealm -s name=kerberos-ldap-provider -s providerId=ldap -s providerType=org.keycloak.storage.UserStorageProvider -s parentId=3d9c572b-8f33-483f-98a6-8bb421667867 -s 'config.priority=[\"1\"]' -s 'config.fullSyncPeriod=[\"-1\"]' -s 'config.changedSyncPeriod=[\"-1\"]' -s 'config.cachePolicy=[\"DEFAULT\"]' -s config.evictionDay=[] -s config.evictionHour=[] -s config.evictionMinute=[] -s config.maxLifespan=[] -s 'config.batchSizeForSync=[\"1000\"]' -s 'config.editMode=[\"WRITABLE\"]' -s 'config.syncRegistrations=[\"false\"]' -s 'config.vendor=[\"other\"]' -s 'config.usernameLDAPAttribute=[\"uid\"]' -s 'config.rdnLDAPAttribute=[\"uid\"]' -s 'config.uuidLDAPAttribute=[\"entryUUID\"]' -s 'config.userObjectClasses=[\"inetOrgPerson, organizationalPerson\"]' -s 'config.connectionUrl=[\"ldap://localhost:10389\"]' -s 'config.usersDn=[\"ou=People,dc=keycloak,dc=org\"]' -s 'config.authType=[\"simple\"]' -s 'config.bindDn=[\"uid=admin,ou=system\"]' -s 'config.bindCredential=[\"secret\"]' -s 'config.searchScope=[\"1\"]' -s 'config.useTruststoreSpi=[\"always\"]' -s 'config.connectionPooling=[\"true\"]' -s 'config.pagination=[\"true\"]' -s 'config.allowKerberosAuthentication=[\"true\"]' -s 'config.serverPrincipal=[\"HTTP/localhost@KEYCLOAK.ORG\"]' -s 'config.keyTab=[\"http.keytab\"]' -s 'config.kerberosRealm=[\"KEYCLOAK.ORG\"]' -s 'config.debug=[\"true\"]' -s 'config.useKerberosForPasswordAuthentication=[\"true\"]'" +msgstr "" + +msgid "Removing a user storage provider instance" +msgstr "" + +msgid "Use the storage provider instance's `id` attribute to compose an endpoint URI, such as `components/ID`." +msgstr "" + +msgid "Run the `delete` command against this endpoint." +msgstr "" + +msgid "$ kcadm.sh delete components/3d9c572b-8f33-483f-98a6-8bb421667867 -r demorealm" +msgstr "" + +msgid "Triggering synchronization of all users for a specific user storage provider" +msgstr "" + +msgid "Use the storage provider's `id` attribute to compose an endpoint URI, such as `user-storage/ID_OF_USER_STORAGE_INSTANCE/sync`." +msgstr "" + +msgid "Add the `action=triggerFullSync` query parameter." +msgstr "" + +msgid "Run the `create` command." +msgstr "" + +msgid "$ kcadm.sh create user-storage/b7c63d02-b62a-4fc1-977c-947d6a09e1ea/sync?action=triggerFullSync" +msgstr "" + +msgid "Triggering synchronization of changed users for a specific user storage provider" +msgstr "" + +msgid "Add the `action=triggerChangedUsersSync` query parameter." +msgstr "" + +msgid "$ kcadm.sh create user-storage/b7c63d02-b62a-4fc1-977c-947d6a09e1ea/sync?action=triggerChangedUsersSync" +msgstr "" + +msgid "Test LDAP user storage connectivity" +msgstr "" + +msgid "Run the `get` command on the `testLDAPConnection` endpoint." +msgstr "" + +msgid "Provide query parameters `bindCredential`, `bindDn`, `connectionUrl`, and `useTruststoreSpi`." +msgstr "" + +msgid "Set the `action` query parameter to `testConnection`." +msgstr "" + +msgid "$ kcadm.sh create testLDAPConnection -s action=testConnection -s bindCredential=secret -s bindDn=uid=admin,ou=system -s connectionUrl=ldap://localhost:10389 -s useTruststoreSpi=always" +msgstr "" + +msgid "Test LDAP user storage authentication" +msgstr "" + +msgid "Provide the query parameters `bindCredential`, `bindDn`, `connectionUrl`, and `useTruststoreSpi`." +msgstr "" + +msgid "Set the `action` query parameter to `testAuthentication`." +msgstr "" + +msgid "$ kcadm.sh create testLDAPConnection -s action=testAuthentication -s bindCredential=secret -s bindDn=uid=admin,ou=system -s connectionUrl=ldap://localhost:10389 -s useTruststoreSpi=always" +msgstr "" + +msgid "Adding mappers" +msgstr "" + +msgid "Adding a hard-coded role LDAP mapper" +msgstr "" + +msgid "Run the `create` command on the `components` endpoint." +msgstr "" + +msgid "Set the `providerType` attribute to `org.keycloak.storage.ldap.mappers.LDAPStorageMapper`." +msgstr "" + +msgid "Set the `parentId` attribute to the ID of the LDAP provider instance." +msgstr "" + +msgid "Set the `providerId` attribute to `hardcoded-ldap-role-mapper`. Ensure you provide a value of `role` configuration parameter." +msgstr "" + +msgid "$ kcadm.sh create components -r demorealm -s name=hardcoded-ldap-role-mapper -s providerId=hardcoded-ldap-role-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea -s 'config.role=[\"realm-management.create-client\"]'" +msgstr "" + +msgid "Adding an MS Active Directory mapper" +msgstr "" + +msgid "Set the `providerId` attribute to `msad-user-account-control-mapper`." +msgstr "" + +msgid "$ kcadm.sh create components -r demorealm -s name=msad-user-account-control-mapper -s providerId=msad-user-account-control-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea" +msgstr "" + +msgid "Adding a user attribute LDAP mapper" +msgstr "" + +msgid "Set the `providerId` attribute to `user-attribute-ldap-mapper`." +msgstr "" + +msgid "$ kcadm.sh create components -r demorealm -s name=user-attribute-ldap-mapper -s providerId=user-attribute-ldap-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea -s 'config.\"user.model.attribute\"=[\"email\"]' -s 'config.\"ldap.attribute\"=[\"mail\"]' -s 'config.\"read.only\"=[\"false\"]' -s 'config.\"always.read.value.from.ldap\"=[\"false\"]' -s 'config.\"is.mandatory.in.ldap\"=[\"false\"]'" +msgstr "" + +msgid "Adding a group LDAP mapper" +msgstr "" + +msgid "Set the `providerId` attribute to `group-ldap-mapper`." +msgstr "" + +msgid "$ kcadm.sh create components -r demorealm -s name=group-ldap-mapper -s providerId=group-ldap-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea -s 'config.\"groups.dn\"=[]' -s 'config.\"group.name.ldap.attribute\"=[\"cn\"]' -s 'config.\"group.object.classes\"=[\"groupOfNames\"]' -s 'config.\"preserve.group.inheritance\"=[\"true\"]' -s 'config.\"membership.ldap.attribute\"=[\"member\"]' -s 'config.\"membership.attribute.type\"=[\"DN\"]' -s 'config.\"groups.ldap.filter\"=[]' -s 'config.mode=[\"LDAP_ONLY\"]' -s 'config.\"user.roles.retrieve.strategy\"=[\"LOAD_GROUPS_BY_MEMBER_ATTRIBUTE\"]' -s 'config.\"mapped.group.attributes\"=[\"admins-group\"]' -s 'config.\"drop.non.existing.groups.during.sync\"=[\"false\"]' -s 'config.roles=[\"admins\"]' -s 'config.groups=[\"admins-group\"]' -s 'config.group=[]' -s 'config.preserve=[\"true\"]' -s 'config.membership=[\"member\"]'" +msgstr "" + +msgid "Adding a full name LDAP mapper" +msgstr "" + +msgid "Set the `providerId` attribute to `full-name-ldap-mapper`." +msgstr "" + +msgid "$ kcadm.sh create components -r demorealm -s name=full-name-ldap-mapper -s providerId=full-name-ldap-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea -s 'config.\"ldap.full.name.attribute\"=[\"cn\"]' -s 'config.\"read.only\"=[\"false\"]' -s 'config.\"write.only\"=[\"true\"]'" +msgstr "" + +msgid "Authentication operations" +msgstr "" + +msgid "Setting a password policy" +msgstr "" + +msgid "Set the realm's `passwordPolicy` attribute to an enumeration expression that includes the specific policy provider ID and optional configuration." +msgstr "" + +msgid "Use the following example to set a password policy to default values. The default values include:" +msgstr "" + +msgid "27,500 hashing iterations" +msgstr "" + +msgid "at least one special character" +msgstr "" + +msgid "at least one uppercase character" +msgstr "" + +msgid "at least one digit character" +msgstr "" + +msgid "not be equal to a user's `username`" +msgstr "" + +msgid "be at least eight characters long" +msgstr "" + +msgid "$ kcadm.sh update realms/demorealm -s 'passwordPolicy=\"hashIterations and specialChars and upperCase and digits and notUsername and length\"'" +msgstr "" + +msgid "To use values different from defaults, pass the configuration in brackets." +msgstr "" + +msgid "Use the following example to set a password policy to:" +msgstr "" + +msgid "25,000 hash iterations" +msgstr "" + +msgid "at least two special characters" +msgstr "" + +msgid "at least two uppercase characters" +msgstr "" + +msgid "at least two lowercase characters" +msgstr "" + +msgid "at least two digits" +msgstr "" + +msgid "be at least nine characters long" +msgstr "" + +msgid "not repeat for at least four changes back" +msgstr "" + +msgid "$ kcadm.sh update realms/demorealm -s 'passwordPolicy=\"hashIterations(25000) and specialChars(2) and upperCase(2) and lowerCase(2) and digits(2) and length(9) and notUsername and passwordHistory(4)\"'" +msgstr "" + +msgid "Obtaining the current password policy" +msgstr "" + +msgid "You can get the current realm configuration by filtering all output except for the `passwordPolicy` attribute." +msgstr "" + +msgid "For example, display `passwordPolicy` for `demorealm`." +msgstr "" + +msgid "$ kcadm.sh get realms/demorealm --fields passwordPolicy" +msgstr "" + +msgid "Listing authentication flows" +msgstr "" + +msgid "Run the `get` command on the `authentication/flows` endpoint." +msgstr "" + +msgid "$ kcadm.sh get authentication/flows -r demorealm" +msgstr "" + +msgid "Getting a specific authentication flow" +msgstr "" + +msgid "Run the `get` command on the `authentication/flows/FLOW_ID` endpoint." +msgstr "" + +msgid "$ kcadm.sh get authentication/flows/febfd772-e1a1-42fb-b8ae-00c0566fafb8 -r demorealm" +msgstr "" + +msgid "Listing executions for a flow" +msgstr "" + +msgid "Run the `get` command on the `authentication/flows/FLOW_ALIAS/executions` endpoint." +msgstr "" + +msgid "$ kcadm.sh get authentication/flows/Copy%20of%20browser/executions -r demorealm" +msgstr "" + +msgid "Adding configuration to an execution" +msgstr "" + +msgid "Get execution for a flow." +msgstr "" + +msgid "Note the ID of the flow." +msgstr "" + +msgid "Run the `create` command on the `authentication/executions/{executionId}/config` endpoint." +msgstr "" + +msgid "$ kcadm.sh create \"authentication/executions/a3147129-c402-4760-86d9-3f2345e401c7/config\" -r demorealm -b '{\"config\":{\"x509-cert-auth.mapping-source-selection\":\"Match SubjectDN using regular expression\",\"x509-cert-auth.regular-expression\":\"(.*?)(?:$)\",\"x509-cert-auth.mapper-selection\":\"Custom Attribute Mapper\",\"x509-cert-auth.mapper-selection.user-attribute-name\":\"usercertificate\",\"x509-cert-auth.crl-checking-enabled\":\"\",\"x509-cert-auth.crldp-checking-enabled\":false,\"x509-cert-auth.crl-relative-path\":\"crl.pem\",\"x509-cert-auth.ocsp-checking-enabled\":\"\",\"x509-cert-auth.ocsp-responder-uri\":\"\",\"x509-cert-auth.keyusage\":\"\",\"x509-cert-auth.extendedkeyusage\":\"\",\"x509-cert-auth.confirmation-page-disallowed\":\"\"},\"alias\":\"my_otp_config\"}'" +msgstr "" + +msgid "Getting configuration for an execution" +msgstr "" + +msgid "Note its `authenticationConfig` attribute, which contains the config ID." +msgstr "" + +msgid "Run the `get` command on the `authentication/config/ID` endpoint." +msgstr "" + +msgid "$ kcadm get \"authentication/config/dd91611a-d25c-421a-87e2-227c18421833\" -r demorealm" +msgstr "" + +msgid "Updating configuration for an execution" +msgstr "" + +msgid "Get the execution for the flow." +msgstr "" + +msgid "Get the flow's `authenticationConfig` attribute." +msgstr "" + +msgid "Note the config ID from the attribute." +msgstr "" + +msgid "Run the `update` command on the `authentication/config/ID` endpoint." +msgstr "" + +msgid "$ kcadm update \"authentication/config/dd91611a-d25c-421a-87e2-227c18421833\" -r demorealm -b '{\"id\":\"dd91611a-d25c-421a-87e2-227c18421833\",\"alias\":\"my_otp_config\",\"config\":{\"x509-cert-auth.extendedkeyusage\":\"\",\"x509-cert-auth.mapper-selection.user-attribute-name\":\"usercertificate\",\"x509-cert-auth.ocsp-responder-uri\":\"\",\"x509-cert-auth.regular-expression\":\"(.*?)(?:$)\",\"x509-cert-auth.crl-checking-enabled\":\"true\",\"x509-cert-auth.confirmation-page-disallowed\":\"\",\"x509-cert-auth.keyusage\":\"\",\"x509-cert-auth.mapper-selection\":\"Custom Attribute Mapper\",\"x509-cert-auth.crl-relative-path\":\"crl.pem\",\"x509-cert-auth.crldp-checking-enabled\":\"false\",\"x509-cert-auth.mapping-source-selection\":\"Match SubjectDN using regular expression\",\"x509-cert-auth.ocsp-checking-enabled\":\"\"}}'" +msgstr "" + +msgid "Deleting configuration for an execution" +msgstr "" + +msgid "Get the flows `authenticationConfig` attribute." +msgstr "" + +msgid "Run the `delete` command on the `authentication/config/ID` endpoint." +msgstr "" + +msgid "$ kcadm delete \"authentication/config/dd91611a-d25c-421a-87e2-227c18421833\" -r demorealm" +msgstr "" diff --git a/src/23.0/server_development.po b/src/23.0/server_development.po new file mode 100644 index 000000000..6de556d0a --- /dev/null +++ b/src/23.0/server_development.po @@ -0,0 +1,4336 @@ +msgid "" +msgstr "" +"Content-Type: text/plain; charset=UTF-8\n" + +msgid "{developerguide_name}" +msgstr "" + +msgid "*{release_header_guide}* icon:angle-down[]" +msgstr "" + +msgid "{gettingstarted_link}[{gettingstarted_name_short}]" +msgstr "" + +msgid "{adapterguide_link}[{adapterguide_name_short}]" +msgstr "" + +msgid "{adminguide_link}[{adminguide_name_short}]" +msgstr "" + +msgid "{authorizationguide_link}[{authorizationguide_name_short}]" +msgstr "" + +msgid "{upgradingguide_link}[{upgradingguide_name_short}]" +msgstr "" + +msgid "{releasenotes_link}[{releasenotes_name_short}]" +msgstr "" + +msgid "Version *{project_version}*" +msgstr "" + +msgid "Preface" +msgstr "" + +msgid "In some of the example listings, what is meant to be displayed on one line does not fit inside the available page width. These lines have been broken up. A '\\' at the end of a line means that a break has been introduced to fit in the page, with the following lines indented. So:" +msgstr "" + +msgid "" +"Let's pretend to have an extremely \\\n" +" long line that \\\n" +" does not fit\n" +"This one is short" +msgstr "" + +msgid "Is really:" +msgstr "" + +msgid "" +"Let's pretend to have an extremely long line that does not fit\n" +"This one is short" +msgstr "" + +msgid "Admin REST API" +msgstr "" + +msgid "{project_name} comes with a fully functional Admin REST API with all features provided by the Admin Console." +msgstr "" + +msgid "To invoke the API you need to obtain an access token with the appropriate permissions. The required permissions are described in the link:{adminguide_link}[{adminguide_name}]." +msgstr "" + +msgid "You can obtain a token by enabling authentication for your application using {project_name}; see the Securing Applications and Services Guide. You can also use direct access grant to obtain an access token." +msgstr "" + +msgid "Examples of using CURL" +msgstr "" + +msgid "Authenticating with a username and password" +msgstr "" + +msgid "The following example assumes that you created the user `admin` with the password `password` in the `master` realm as shown in the link:{gettingstarted_link}[{gettingstarted_name}] tutorial." +msgstr "" + +msgid "Procedure" +msgstr "" + +msgid "Obtain an access token for the user in the realm `master` with username `admin` and password `password`:" +msgstr "" + +msgid "" +"curl \\\n" +" -d \"client_id=admin-cli\" \\\n" +" -d \"username=admin\" \\\n" +" -d \"password=password\" \\\n" +" -d \"grant_type=password\" \\\n" +" \"http://localhost:8080{kc_realms_path}/master/protocol/openid-connect/token\"" +msgstr "" + +msgid "By default this token expires in 1 minute" +msgstr "" + +msgid "The result will be a JSON document." +msgstr "" + +msgid "Invoke the API you need by extracting the value of the `access_token` property." +msgstr "" + +msgid "Invoke the API by including the value in the `Authorization` header of requests to the API." +msgstr "" + +msgid "The following example shows how to get the details of the master realm:" +msgstr "" + +msgid "" +"curl \\\n" +" -H \"Authorization: bearer eyJhbGciOiJSUz...\" \\\n" +" \"http://localhost:8080{kc_admins_path}/realms/master\"" +msgstr "" + +msgid "Authenticating with a service account" +msgstr "" + +msgid "To authenticate against the Admin REST API using a `client_id` and a `client_secret`, perform this procedure." +msgstr "" + +msgid "Make sure the client is configured as follows:" +msgstr "" + +msgid "`client_id` is a **confidential** client that belongs to the realm *master*" +msgstr "" + +msgid "`client_id` has `Service Accounts Enabled` option enabled" +msgstr "" + +msgid "`client_id` has a custom \"Audience\" mapper" +msgstr "" + +msgid "Included Client Audience: `security-admin-console`" +msgstr "" + +msgid "Check that `client_id` has the role 'admin' assigned in the \"Service Account Roles\" tab." +msgstr "" + +msgid "" +"curl \\\n" +" -d \"client_id=\" \\\n" +" -d \"client_secret=\" \\\n" +" -d \"grant_type=client_credentials\" \\\n" +" \"http://localhost:8080{kc_realms_path}/master/protocol/openid-connect/token\"" +msgstr "" + +msgid "Example using Java" +msgstr "" + +msgid "There's a Java client library for the Admin REST API that makes it easy to use from Java. To use it from your application add a dependency on the `keycloak-admin-client` library." +msgstr "" + +msgid "The following example shows how to use the Java client library to get the details of the master realm:" +msgstr "" + +msgid "" +"\n" +"import org.keycloak.admin.client.Keycloak;\n" +"import org.keycloak.representations.idm.RealmRepresentation;\n" +"...\n" +"\n" +"Keycloak keycloak = Keycloak.getInstance(\n" +" \"http://localhost:8080{kc_base_path}\",\n" +" \"master\",\n" +" \"admin\",\n" +" \"password\",\n" +" \"admin-cli\");\n" +"RealmRepresentation realm = keycloak.realm(\"master\").toRepresentation();" +msgstr "" + +msgid "Complete Javadoc for the admin client is available at {apidocs_link}[{apidocs_name}]." +msgstr "" + +msgid "Additional resources" +msgstr "" + +msgid "{adminguide_link}[{adminguide_name}]" +msgstr "" + +msgid "{adapterguide_link}[{adapterguide_name}]" +msgstr "" + +msgid "{apidocs_link}[{apidocs_name}]" +msgstr "" + +msgid "Themes" +msgstr "" + +msgid "{project_name} provides theme support for web pages and emails. This allows customizing the look and feel of end-user facing pages so they can be integrated with your applications." +msgstr "" + +msgid "Login page with sunrise example theme" +msgstr "" + +msgid "Theme types" +msgstr "" + +msgid "A theme can provide one or more types to customize different aspects of {project_name}. The types available are:" +msgstr "" + +msgid "Account - Account management" +msgstr "" + +msgid "Admin - Admin Console" +msgstr "" + +msgid "Email - Emails" +msgstr "" + +msgid "Login - Login forms" +msgstr "" + +msgid "Welcome - Welcome page" +msgstr "" + +msgid "Configuring a theme" +msgstr "" + +msgid "All theme types, except welcome, are configured through the Admin Console." +msgstr "" + +msgid "Log into the Admin Console." +msgstr "" + +msgid "Select your realm from the drop-down box in the top left corner." +msgstr "" + +msgid "Click *Realm Settings* from the menu." +msgstr "" + +msgid "Click the *Themes* tab." +msgstr "" + +msgid "To set the theme for the `master` Admin Console you need to set the Admin Console theme for the `master` realm." +msgstr "" + +msgid "To see the changes to the Admin Console refresh the page." +msgstr "" + +msgid "Change the welcome theme by using the `spi-theme-welcome-theme` option." +msgstr "" + +msgid "For example:" +msgstr "" + +msgid "bin/kc.[sh|bat] start --spi-theme-welcome-theme=custom-theme" +msgstr "" + +msgid "Default themes" +msgstr "" + +msgid "{project_name} comes bundled with default themes in the JAR file `keycloak-themes-{project_versionMvn}.jar` inside the server distribution. The server's root `themes` directory does not contain any themes by default, but it contains a README file with some additional details about the default themes. To simplify upgrading, do not edit the bundled themes directly. Instead create your own theme that extends one of the bundled themes." +msgstr "" + +msgid "Creating a theme" +msgstr "" + +msgid "A theme consists of:" +msgstr "" + +msgid "HTML templates (https://freemarker.apache.org/[Freemarker Templates])" +msgstr "" + +msgid "Images" +msgstr "" + +msgid "Message bundles" +msgstr "" + +msgid "Stylesheets" +msgstr "" + +msgid "Scripts" +msgstr "" + +msgid "Theme properties" +msgstr "" + +msgid "Unless you plan to replace every single page you should extend another theme. Most likely you will want to extend the {project_name} theme, but you could also consider extending the base theme if you are significantly changing the look and feel of the pages. The base theme primarily consists of HTML templates and message bundles, while the {project_name} theme primarily contains images and stylesheets." +msgstr "" + +msgid "When extending a theme you can override individual resources (templates, stylesheets, etc.). If you decide to override HTML templates bear in mind that you may need to update your custom template when upgrading to a new release." +msgstr "" + +msgid "While creating a theme it's a good idea to disable caching as this makes it possible to edit theme resources directly from the `themes` directory without restarting {project_name}." +msgstr "" + +msgid "Run Keycloak with the following options:" +msgstr "" + +msgid "bin/kc.[sh|bat] start --spi-theme-static-max-age=-1 --spi-theme-cache-themes=false --spi-theme-cache-templates=false" +msgstr "" + +msgid "Create a directory in the `themes` directory." +msgstr "" + +msgid "The name of the directory becomes the name of the theme. For example to create a theme called `mytheme` create the directory `themes/mytheme`." +msgstr "" + +msgid "Inside the theme directory, create a directory for each of the types your theme is going to provide." +msgstr "" + +msgid "For example, to add the login type to the `mytheme` theme, create the directory `themes/mytheme/login`." +msgstr "" + +msgid "For each type create a file `theme.properties` which allows setting some configuration for the theme." +msgstr "" + +msgid "For example, to configure the theme `themes/mytheme/login` to extend the base theme and import some common resources, create the file `themes/mytheme/login/theme.properties` with following contents:" +msgstr "" + +msgid "" +"parent=base\n" +"import=common/keycloak" +msgstr "" + +msgid "You have now created a theme with support for the login type." +msgstr "" + +msgid "Log into the Admin Console to check out your new theme" +msgstr "" + +msgid "Select your realm" +msgstr "" + +msgid "Click on the *Themes* tab." +msgstr "" + +msgid "For *Login Theme* select *mytheme* and click *Save*." +msgstr "" + +msgid "Open the login page for the realm." +msgstr "" + +msgid "You can do this either by logging in through your application or by opening the Account Management console (`/realms/{realm name}/account`)." +msgstr "" + +msgid "To see the effect of changing the parent theme, set `parent=keycloak` in `theme.properties` and refresh the login page." +msgstr "" + +msgid "Be sure to re-enable caching in production as it will significantly impact performance." +msgstr "" + +msgid "If you want to manually delete the content of the themes cache, you can do so by deleting the `data/tmp/kc-gzip-cache` directory of the server distribution. It can be useful for instance if you redeployed custom providers or custom themes without disabling themes caching in the previous server executions." +msgstr "" + +msgid "Theme properties are set in the file `/theme.properties` in the theme directory." +msgstr "" + +msgid "parent - Parent theme to extend" +msgstr "" + +msgid "import - Import resources from another theme" +msgstr "" + +msgid "common - Override the common resource path. The default value is `common/keycloak` when not specified. This value would be used as value of suffix of `${url.resourcesCommonPath}`, which is used typically in freemarker templates (prefix of `${url.resoucesCommonPath}` value is theme root uri)." +msgstr "" + +msgid "styles - Space-separated list of styles to include" +msgstr "" + +msgid "locales - Comma-separated list of supported locales" +msgstr "" + +msgid "There are a list of properties that can be used to change the css class used for certain element types. For a list of these properties look at the theme.properties file in the corresponding type of the keycloak theme (`themes/keycloak//theme.properties`)." +msgstr "" + +msgid "You can also add your own custom properties and use them from custom templates." +msgstr "" + +msgid "When doing so, you can substitute system properties or environment variables by using these formats:" +msgstr "" + +msgid "`${some.system.property}` - for system properties" +msgstr "" + +msgid "`${env.ENV_VAR}` - for environment variables." +msgstr "" + +msgid "A default value can also be provided in case the system property or the environment variable is not found with `${foo:defaultValue}`." +msgstr "" + +msgid "If no default value is provided and there's no corresponding system property or environment variable, then nothing is replaced and you end up with the format in your template." +msgstr "" + +msgid "Here's an example of what is possible:" +msgstr "" + +msgid "" +"javaVersion=${java.version}\n" +"\n" +"unixHome=${env.HOME:Unix home not found}\n" +"windowsHome=${env.HOMEPATH:Windows home not found}" +msgstr "" + +msgid "Add a stylesheet to a theme" +msgstr "" + +msgid "You can add one or more stylesheets to a theme." +msgstr "" + +msgid "Create a file in the `/resources/css` directory of your theme." +msgstr "" + +msgid "Add this file to the `styles` property in `theme.properties`." +msgstr "" + +msgid "For example, to add `styles.css` to the `mytheme`, create `themes/mytheme/login/resources/css/styles.css` with the following content:" +msgstr "" + +msgid "" +".login-pf body {\n" +" background: DimGrey none;\n" +"}" +msgstr "" + +msgid "Edit `themes/mytheme/login/theme.properties` and add:" +msgstr "" + +msgid "styles=css/styles.css" +msgstr "" + +msgid "To see the changes, open the login page for your realm." +msgstr "" + +msgid "You will notice that the only styles being applied are those from your custom stylesheet." +msgstr "" + +msgid "To include the styles from the parent theme, load the styles from that theme. Edit `themes/mytheme/login/theme.properties` and change `styles` to:" +msgstr "" + +msgid "styles=css/login.css css/styles.css" +msgstr "" + +msgid "To override styles from the parent stylesheets, ensure that your stylesheet is listed last." +msgstr "" + +msgid "Adding a script to a theme" +msgstr "" + +msgid "You can add one or more scripts to a theme." +msgstr "" + +msgid "Create a file in the `/resources/js` directory of your theme." +msgstr "" + +msgid "Add the file to the `scripts` property in `theme.properties`." +msgstr "" + +msgid "For example, to add `script.js` to the `mytheme`, create `themes/mytheme/login/resources/js/script.js` with the following content:" +msgstr "" + +msgid "alert('Hello');" +msgstr "" + +msgid "Then edit `themes/mytheme/login/theme.properties` and add:" +msgstr "" + +msgid "scripts=js/script.js" +msgstr "" + +msgid "Adding an image to a theme" +msgstr "" + +msgid "To make images available to the theme add them to the `/resources/img` directory of your theme. These can be used from within stylesheets or directly in HTML templates." +msgstr "" + +msgid "For example to add an image to the `mytheme` copy an image to `themes/mytheme/login/resources/img/image.jpg`." +msgstr "" + +msgid "You can then use this image from within a custom stylesheet with:" +msgstr "" + +msgid "" +"body {\n" +" background-image: url('../img/image.jpg');\n" +" background-size: cover;\n" +"}" +msgstr "" + +msgid "Or to use directly in HTML templates add the following to a custom HTML template:" +msgstr "" + +msgid "" +msgstr "" + +msgid "Messages" +msgstr "" + +msgid "Text in the templates is loaded from message bundles. A theme that extends another theme will inherit all messages from the parent's message bundle and you can override individual messages by adding `/messages/messages_en.properties` to your theme." +msgstr "" + +msgid "For example to replace `Username` on the login form with `Your Username` for the `mytheme` create the file `themes/mytheme/login/messages/messages_en.properties` with the following content:" +msgstr "" + +msgid "usernameOrEmail=Your Username" +msgstr "" + +msgid "Within a message values like `{0}` and `{1}` are replaced with arguments when the message is used. For example {0} in `Log in to {0}` is replaced with the name of the realm." +msgstr "" + +msgid "Texts of these message bundles can be overwritten by realm-specific values. The realm-specific values are manageable via UI and API." +msgstr "" + +msgid "Adding a language to a realm" +msgstr "" + +msgid "Prerequisites" +msgstr "" + +msgid "To enable internationalization for a realm, see the {adminguide_link}[{adminguide_name}]." +msgstr "" + +msgid "Create the file `/messages/messages_.properties` in the directory of your theme." +msgstr "" + +msgid "Add this file to the `locales` property in `/theme.properties`. For a language to be available to users the realms `login`, `account` and `email`, the theme has to support the language, so you need to add your language for those theme types." +msgstr "" + +msgid "For example, to add Norwegian translations to the `mytheme` theme create the file `themes/mytheme/login/messages/messages_no.properties` with the following content:" +msgstr "" + +msgid "" +"usernameOrEmail=Brukernavn\n" +"password=Passord" +msgstr "" + +msgid "If you omit a translation for messages, they will use English." +msgstr "" + +msgid "locales=en,no" +msgstr "" + +msgid "Add the same for the `account` and `email` theme types. To do this create `themes/mytheme/account/messages/messages_no.properties` and `themes/mytheme/email/messages/messages_no.properties`. Leaving these files empty will result in the English messages being used." +msgstr "" + +msgid "Copy `themes/mytheme/login/theme.properties` to `themes/mytheme/account/theme.properties` and `themes/mytheme/email/theme.properties`." +msgstr "" + +msgid "Add a translation for the language selector. This is done by adding a message to the English translation. To do this add the following to `themes/mytheme/account/messages/messages_en.properties` and `themes/mytheme/login/messages/messages_en.properties`:" +msgstr "" + +msgid "locale_no=Norsk" +msgstr "" + +msgid "By default, message properties files should be encoded using UTF-8. Keycloak falls back to ISO-8859-1 handling if it can't read the contents as UTF-8. Unicode characters can be escaped as described in Java's documentation for https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/PropertyResourceBundle.html[PropertyResourceBundle]. Previous versions of Keycloak supported specifying the encoding in the first line with a comment like `# encoding: UTF-8`, which is no longer supported." +msgstr "" + +msgid "See <<_locale_selector,Locale Selector>> for details on how the current locale is selected." +msgstr "" + +msgid "Adding custom Identity Providers icons" +msgstr "" + +msgid "{project_name} supports adding icons for custom Identity providers, which are displayed on the login screen." +msgstr "" + +msgid "Define icon classes in your login `theme.properties` file (for example, `themes/mytheme/login/theme.properties`) with key pattern `kcLogoIdP-`." +msgstr "" + +msgid "For an Identity Provider with an alias `myProvider`, you may add a line to `theme.properties` file of your custom theme. For example:" +msgstr "" + +msgid "kcLogoIdP-myProvider = fa fa-lock" +msgstr "" + +msgid "All icons are available on the official website of PatternFly4. Icons for social providers are already defined in base login theme properties (`themes/keycloak/login/theme.properties`), where you can inspire yourself." +msgstr "" + +msgid "Creating a custom HTML template" +msgstr "" + +msgid "{project_name} uses https://freemarker.apache.org/[Apache Freemarker] templates to generate HTML. You can override individual templates in your own theme by creating `/