
:guide-id: overview
:guide-title: Planning for securing applications and services
:guide-summary: Introduction and basic concepts for securing applications
:guide-priority: 10
:guide-tile-visible: true
:version: 26.0.2

include::../attributes.adoc[]

[[overview]]
= Planning for securing applications and services

ifeval::["" == "true"]
WARNING: This {section} is describing a feature which is currently in preview.
ifeval::["" == ""]
Please provide your feedback while we’re continuing to work on this.
endif::[]
ifeval::["" != ""]
Please provide your feedback by link:[joining this discussion] while we’re continuing to work on this.
endif::[]
endif::[]


As an OAuth2, OpenID Connect, and SAML compliant server, {project_name} can secure any application and service as long
as the technology stack they are using supports any of these protocols. For more details about the security protocols
supported by {project_name}, consider looking at link:{adminguide_link}#sso-protocols[{adminguide_name}].

Most of the support for some of these protocols is already available from the programming language, framework,
or reverse proxy they are using. Leveraging the support already available from the application ecosystem is a key aspect to make your
application fully compliant with security standards and best practices, so that you avoid vendor lock-in.

For some programming languages, {project_name} provides libraries that try to fill the gap for the lack of support of
a particular security protocol or to provide a more rich and tightly coupled integration with the server. These libraries
are known by *Keycloak Client Adapters*, and they should be used as a last resort if you cannot rely on what is available
from the application ecosystem.

include::partials/overview/basic-steps.adoc[]
== Getting Started

The link:{quickstartRepo_link}[{quickstartRepo_name}] provides examples about how to secure applications and services
using different programming languages and frameworks. By going through their documentation and codebase, you will
understand the bare minimum changes required in your application and service in order to secure it with {project_name}.

Also, see the following sections for recommendations for trusted and well-known client-side implementations for both OpenID
Connect and SAML protocols.

=== OpenID Connect

ifeval::[{project_community}==true]
==== Java
* {quickstartRepo_link}/tree/latest/jakarta/servlet-authz-client[Wildfly Elytron OIDC]
* {quickstartRepo_link}/tree/latest/spring/rest-authz-resource-server[Spring Boot]
endif::[]

==== JavaScript (client-side)
* link:{links_securing-apps_javascript-adapter_url}[{links_securing-apps_javascript-adapter_name}]

==== Node.js (server-side)
* link:{links_securing-apps_nodejs-adapter_url}[{links_securing-apps_nodejs-adapter_name}]

ifeval::[{project_community}==true]
==== C#
* https://github.com/dylanplecki/KeycloakOwinAuthentication[OWIN]

==== Python
* https://pypi.org/project/oic/[oidc]

==== Android
* https://github.com/openid/AppAuth-Android[AppAuth]

==== iOS
* https://github.com/openid/AppAuth-iOS[AppAuth]

==== Apache HTTP Server
* https://github.com/OpenIDC/mod_auth_openidc[mod_auth_openidc]
endif::[]

=== SAML

==== Java

* link:{links_securing-apps_saml-galleon-layers_url}[{links_securing-apps_saml-galleon-layers_name}]

ifeval::[{project_community}==true]
==== Apache HTTP Server

* link:{links_securing-apps_mod-auth-mellon_url}[{links_securing-apps_mod-auth-mellon_name}]
endif::[]

include::partials/overview/terminology.adoc[]


