mariusz.pacek/keycloak
1
0 Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

saml adapters docs/dist

Browse Source
This commit is contained in:
Bill Burke committed 2015-10-06 15:56:44 -04:00
1 parent 3b4b5c11e6
commit d40237b08d
58 files changed
+3209 -2
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docbook/saml-adapter-docs/reference/en/en-US/master.xml
+13
View File
@@ -1,6 +1,12 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.docbook.org/xml/4.4/docbookx.dtd"
[
<!ENTITY AdapterConfig SYSTEM "modules/adapter-config.xml">
<!ENTITY JBossAdapter SYSTEM "modules/jboss-adapter.xml">
<!ENTITY TomcatAdapter SYSTEM "modules/tomcat-adapter.xml">
<!ENTITY Jetty9Adapter SYSTEM "modules/jetty9-adapter.xml">
<!ENTITY Jetty8Adapter SYSTEM "modules/jetty8-adapter.xml">
<!ENTITY Logout SYSTEM "modules/logout.xml">
]>
<book>
@@ -33,6 +39,13 @@ This one is short
</programlisting>
</para>
</preface>
&AdapterConfig;
&JBossAdapter;
&TomcatAdapter;
&Jetty9Adapter;
&Jetty8Adapter;
&Logout;
</book>
docbook/saml-adapter-docs/reference/en/en-US/modules/adapter-config.xml
Executable
+384
View File
@@ -0,0 +1,384 @@
<chapter id="adapter-config">
<title>General Adapter Config</title>
<para>
Each SAML adapter supported by Keycloak can be configured by a simple XML text file. This is what one might
look like:
</para>
<para>
<programlisting><![CDATA[{
"realm" : "demo",
"resource" : "customer-portal",
"realm-public-key" : "MIGfMA0GCSqGSIb3D...31LwIDAQAB",
"auth-server-url" : "https://localhost:8443/auth",
"ssl-required" : "external",
"use-resource-role-mappings" : false,
"enable-cors" : true,
"cors-max-age" : 1000,
"cors-allowed-methods" : "POST, PUT, DELETE, GET",
"bearer-only" : false,
"enable-basic-auth" : false,
"expose-token" : true,
"credentials" : {
"secret" : "234234-234234-234234"
},
"connection-pool-size" : 20,
"disable-trust-manager": false,
"allow-any-hostname" : false,
"truststore" : "path/to/truststore.jks",
"truststore-password" : "geheim",
"client-keystore" : "path/to/client-keystore.jks",
"client-keystore-password" : "geheim",
"client-key-password" : "geheim"
}]]>
</programlisting>
</para>
<para>
Some of these configuration switches may be adapter specific and some are common across all adapters.
For Java adapters you can use <literal>${...}</literal> enclosure as System property replacement.
For example <literal>${jboss.server.config.dir}</literal>. Also, you can obtain a template
for this config file from the admin console. Go to the realm and select the application you want a template for.
Go to the <literal>Installation</literal> tab and this will provide you with a template that includes
the public key of the realm.
</para>
<para>
Here is a description of each item:
</para>
<para>
<variablelist>
<varlistentry>
<term>realm</term>
<listitem>
<para>
Name of the realm representing the users of your distributed applications and services.
This is
<emphasis>REQUIRED.</emphasis>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>resource</term>
<listitem>
<para>
Username of the application. Each application has a username that is used when the
application connects with the Keycloak server to turn an access code into an access token
(part of the OAuth 2.0 protocol). This is
<emphasis>REQUIRED.</emphasis>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>realm-public-key</term>
<listitem>
<para>
PEM format of public key. You can obtain this from the administration console.
This is
<emphasis>REQUIRED.</emphasis>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>auth-server-url</term>
<listitem>
<para>
The base URL of the Keycloak Server. All other Keycloak pages and REST services are derived
from this. It is usually of the form <literal>https://host:port/auth</literal>
This is
<emphasis>REQUIRED.</emphasis>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ssl-required</term>
<listitem>
<para>
Ensures that all communication to and from the Keycloak server from the adapter is over HTTPS.
This is <emphasis>OPTIONAL</emphasis>. The default value is
<emphasis>external</emphasis>
meaning that HTTPS is required by default for external requests. Valid values are 'all', 'external'
and 'none'.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>use-resource-role-mappings</term>
<listitem>
<para>
If set to true, the adapter will look inside the token for application level role mappings for
the
user. If false, it will look at the realm level for user role mappings.
This is <emphasis>OPTIONAL</emphasis>. The default value is <emphasis>false</emphasis>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>public-client</term>
<listitem>
<para>
If set to true, the adapter will not send credentials for the client to Keycloak.
The default value is <emphasis>false</emphasis>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>enable-cors</term>
<listitem>
<para>
This enables CORS support. It will handle CORS preflight requests. It will also look into
the access token to determine valid origins.
This is <emphasis>OPTIONAL</emphasis>. The default value is <emphasis>false</emphasis>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>cors-max-age</term>
<listitem>
<para>
If CORS is enabled, this sets the value of the
<literal>Access-Control-Max-Age</literal>
header.
This is <emphasis>OPTIONAL</emphasis>. If not set, this header is not returned in CORS
responses.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>cors-allowed-methods</term>
<listitem>
<para>
If CORS is enabled, this sets the value of the
<literal>Access-Control-Allow-Methods</literal>
header. This should be a comma-separated string.
This is <emphasis>OPTIONAL</emphasis>. If not set, this header is not returned in CORS
responses.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>cors-allowed-headers</term>
<listitem>
<para>
If CORS is enabled, this sets the value of the
<literal>Access-Control-Allow-Headers</literal>
header. This should be a comma-separated string.
This is <emphasis>OPTIONAL</emphasis>. If not set, this header is not returned in CORS
responses.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>bearer-only</term>
<listitem>
<para>
This tells the adapter to only do bearer token authentication. That is, it will not do
OAuth 2.0 redirects, but only accept bearer tokens through the
<literal>Authorization</literal>
header.
This is <emphasis>OPTIONAL</emphasis>. The default value is <emphasis>false</emphasis>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>enable-basic-auth</term>
<listitem>
<para>
This tells the adapter to also support basic authentication. If this option is enabled,
then <emphasis>secret</emphasis> must also be provided.
This is <emphasis>OPTIONAL</emphasis>. The default value is <emphasis>false</emphasis>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>expose-token</term>
<listitem>
<para>
If <literal>true</literal>, an authenticated browser client (via a Javascript HTTP invocation)
can obtain the signed access token via the URL <literal>root/k_query_bearer_token</literal>.
This is <emphasis>OPTIONAL</emphasis>. The default value is <emphasis>false</emphasis>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>credentials</term>
<listitem>
<para>
Specify 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. Currently only
<literal>password</literal>
is supported.
This is <emphasis>REQUIRED</emphasis>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>connection-pool-size</term>
<listitem>
<para>
Adapters will make separate HTTP invocations to the Keycloak Server to turn an access code
into an access token. This config option defines how many connections to the Keycloak Server
should be pooled.
This is <emphasis>OPTIONAL</emphasis>. The default value is <literal>20</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>disable-trust-manager</term>
<listitem>
<para>
If the Keycloak Server requires HTTPS and this config option is set to <literal>true</literal>
you do not have to specify a truststore. While convenient, this setting is not recommended
as you will not be verifying the host name of the Keycloak Server.
This is <emphasis>OPTIONAL</emphasis>. The default value is <literal>false</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>allow-any-hostname</term>
<listitem>
<para>
If the Keycloak Server requires HTTPS and this config option is set to <literal>true</literal>
the Keycloak Server's certificate is validated via the truststore, but host name validation is
not done. This is not a recommended. This seting may be useful in test environments
This is <emphasis>OPTIONAL</emphasis>. The default value is <literal>false</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>truststore</term>
<listitem>
<para>
This setting is for Java adapters. The value is the file path to a Java keystore file. If
you prefix the path with <literal>classpath:</literal>, then the truststore will be obtained
from the deployment's classpath instead.
Used for outgoing HTTPS communications to the Keycloak server. Client making HTTPS
requests need a way to verify the host of the server they are talking to. This is
what the trustore 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 Keycloak server's SSL
keystore.
This is
<emphasis>OPTIONAL</emphasis>
if
<literal>ssl-required</literal>
is
<literal>none</literal>
or
<literal>disable-trust-manager</literal>
is <literal>true</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>truststore-password</term>
<listitem>
<para>
Password for the truststore keystore.
This is
<emphasis>REQUIRED</emphasis>
if
<literal>truststore</literal>
is set.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>client-keystore</term>
<listitem>
<para>
<emphasis>Not supported yet, but we will support in future versions.</emphasis>
This setting is for Java adapters. This is the file path to a Java keystore file.
This keystore contains client certificate for two-way SSL when the adapter makes
HTTPS requests to the Keycloak server.
This is <emphasis>OPTIONAL</emphasis>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>client-keystore-password</term>
<listitem>
<para>
<emphasis>Not supported yet, but we will support in future versions.</emphasis>
Password for the client keystore.
This is
<emphasis>REQUIRED</emphasis>
if
<literal>client-keystore</literal>
is set.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>client-key-password</term>
<listitem>
<para>
<emphasis>Not supported yet, but we will support in future versions.</emphasis>
Password for the client's key.
This is
<emphasis>REQUIRED</emphasis>
if
<literal>client-keystore</literal>
is set.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>auth-server-url-for-backend-requests</term>
<listitem>
<para>
Alternative location of auth-server-url used just for backend requests. It must be absolute URI. Useful
especially in cluster (see <link linkend="relative-uri-optimization">Relative URI Optimization</link>) or if you would like to use <emphasis>https</emphasis> for browser requests
but stick with <emphasis>http</emphasis> for backend requests etc.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>always-refresh-token</term>
<listitem>
<para>
If <emphasis>true</emphasis>, Keycloak will refresh token in every request. More info in <link linkend="refresh-token-each-req">Refresh token in each request</link> .
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>register-node-at-startup</term>
<listitem>
<para>
If <emphasis>true</emphasis>, then adapter will send registration request to Keycloak. It's <emphasis>false</emphasis>
by default and useful just in cluster (See <link linkend="registration-app-nodes">Registration of application nodes to Keycloak</link>)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>register-node-period</term>
<listitem>
<para>
Period for re-registration adapter to Keycloak. Useful in cluster. See <link linkend="registration-app-nodes">Registration of application nodes to Keycloak</link> for details.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>token-store</term>
<listitem>
<para>
Possible values are <emphasis>session</emphasis> and <emphasis>cookie</emphasis>. Default is <emphasis>session</emphasis>,
which means that adapter stores account info in HTTP Session. Alternative <emphasis>cookie</emphasis> means storage of info in cookie.
See <link linkend="stateless-token-store">Stateless token store</link> for details.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>principal-attribute</term>
<listitem>
<para>
OpenID Connection ID Token attribute to populate the UserPrincipal name with. If token attribute is null, defaults to <literal>sub</literal>.
Possible values are <literal>sub</literal>, <literal>preferred_username</literal>, <literal>email</literal>, <literal>name</literal>, <literal>nickname</literal>, <literal>given_name</literal>, <literal>family_name</literal>.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</chapter>
docbook/saml-adapter-docs/reference/en/en-US/modules/jboss-adapter.xml
Executable
+188
View File
@@ -0,0 +1,188 @@
<chapter id="jboss-adapter">
<title>JBoss/Wildfly Adapter</title>
<para>
To be able to secure WAR apps deployed on JBoss EAP 6.x or Wildfly, you must install and
configure the Keycloak SAML Adapter Subsystem. You then provide a keycloak
config, <literal>/WEB-INF/keycloak-saml</literal> file in your WAR and change the auth-method to KEYCLOAK-SAML within web.xml.
Both methods are described in this section.
</para>
<section id="jboss-adapter-installation">
<title>Adapter Installation</title>
<para>
SAML 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.
</para>
<para>
Install on Wildfly 9:
<programlisting>
$ cd $WILDFLY_HOME
$ unzip keycloak-saml-wf9-adapter-dist.zip
</programlisting>
</para>
<para>
Install on JBoss EAP 6.x:
<programlisting>
$ cd $JBOSS_HOME
$ unzip keycloak-saml-eap6-adapter-dist.zip
</programlisting>
</para>
<para>
This zip file creates new JBoss Modules specific to the Wildfly Keycloak SAML Adapter within your Wildfly distro.
</para>
<para>
After adding the Keycloak modules, you must then enable the Keycloak SAML Subsystem within your app server's server configuration:
<literal>domain.xml</literal> or <literal>standalone.xml</literal>.
</para>
<para>
There is a CLI script that will help you modify your server configuration. Start the server and run the script
from the server's bin directory:
<programlisting>
$ cd $JBOSS_HOME/bin
$ jboss-cli.sh -c --file=adapter-install.cli
</programlisting>
The script will add the extension, subsystem, and optional security-domain as described below.
</para>
<para>
<programlisting><![CDATA[
<server xmlns="urn:jboss:domain:1.4">
<extensions>
<extension module="org.keycloak.keycloak-saml-adapter-subsystem"/>
...
</extensions>
<profile>
<subsystem xmlns="urn:jboss:domain:keycloak-saml:1.6"/>
...
</profile>
]]>
</programlisting>
</para>
<para>
The keycloak security domain should be used with EJBs and other components when you need the security context created
in the secured web tier to be propagated to the EJBs (other EE component) you are invoking. Otherwise
this configuration is optional.
</para>
<programlisting><![CDATA[
<server xmlns="urn:jboss:domain:1.4">
<subsystem xmlns="urn:jboss:domain:security:1.2">
<security-domains>
...
<security-domain name="keycloak">
<authentication>
<login-module code="org.keycloak.adapters.jboss.KeycloakLoginModule"
flag="required"/>
</authentication>
</security-domain>
</security-domains>
]]>
</programlisting>
<para>
For example, if you have a JAX-RS service that is an EJB within your WEB-INF/classes directory, you'll want
to annotate it with the @SecurityDomain annotation as follows:
</para>
<programlisting><![CDATA[
import org.jboss.ejb3.annotation.SecurityDomain;
import org.jboss.resteasy.annotations.cache.NoCache;
import javax.annotation.security.RolesAllowed;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import java.util.ArrayList;
import java.util.List;
@Path("customers")
@Stateless
@SecurityDomain("keycloak")
public class CustomerService {
@EJB
CustomerDB db;
@GET
@Produces("application/json")
@NoCache
@RolesAllowed("db_user")
public List<String> getCustomers() {
return db.getCustomers();
}
}
]]>
</programlisting>
<para>
We hope to improve our integration in the future so that you don't have to specify the @SecurityDomain
annotation when you want to propagate a keycloak security context to the EJB tier.
</para>
</section>
<section>
<title>Required Per WAR Configuration</title>
<para>
This section describes how to secure a WAR directly by adding config and editing files within your WAR package.
</para>
<para>
The first thing you must do is create
a <literal>keycloak-saml.xml</literal> adapter config file within the <literal>WEB-INF</literal> directory
of your WAR. The format of this config file is describe in the <link linkend='adapter-config'>general adapter configuration</link>
section.
</para>
<para>
Next you must set the <literal>auth-method</literal> to <literal>KEYCLOAK-SAML</literal> in <literal>web.xml</literal>. You also
have to use standard servlet security to specify role-base constraints on your URLs. Here's an example
pulled from one of the examples that comes distributed with Keycloak.
</para>
<para>
<programlisting>
<![CDATA[
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<module-name>customer-portal</module-name>
<security-constraint>
<web-resource-collection>
<web-resource-name>Admins</web-resource-name>
<url-pattern>/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Customers</web-resource-name>
<url-pattern>/customers/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>KEYCLOAK-SAML</auth-method>
<realm-name>this is ignored currently</realm-name>
</login-config>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>user</role-name>
</security-role>
</web-app>
]]>
</programlisting>
</para>
</section>
</chapter>
docbook/saml-adapter-docs/reference/en/en-US/modules/jetty8-adapter.xml
Executable
+49
View File
@@ -0,0 +1,49 @@
<chapter id="jetty8-adapter">
<title>Jetty 8.1.x SAML Adapter</title>
<para>
Keycloak has a separate SAML adapter for Jetty 8.1.x that you will have to install into your Jetty
installation. You then have to provide some extra configuration in each WAR you deploy to
Jetty. Let's go over these steps.
</para>
<section id="jetty8-adapter-installation">
<title>Adapter Installation</title>
<para>
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.
</para>
<para>
You must unzip the Jetty 8.1.x distro into Jetty 8.1.x's root directory. Including
adapter's jars within your WEB-INF/lib directory will not work!
</para>
<para>
<programlisting>
$ cd $JETTY_HOME
$ unzip keycloak-saml-jetty81-adapter-dist.zip
</programlisting>
</para>
<para>
Next, you will have to enable the keycloak option. Edit start.ini and add keycloak to the options
</para>
<para>
<programlisting>
<![CDATA[
#===========================================================
# Start classpath OPTIONS.
# These control what classes are on the classpath
# for a full listing do
# java -jar start.jar --list-options
#-----------------------------------------------------------
OPTIONS=Server,jsp,jmx,resources,websocket,ext,plus,annotations,keycloak
]]>
</programlisting>
</para>
</section>
<section>
<title>Required Per WAR Configuration</title>
<para>
Enabling Keycloak for your WARs is the same as the Jetty 9.x adapter. See <link linkend="jetty9_per_war">Required Per WAR Configuration</link>
</para>
</section>
</chapter>
docbook/saml-adapter-docs/reference/en/en-US/modules/jetty9-adapter.xml
Executable
+106
View File
@@ -0,0 +1,106 @@
<chapter id="jetty9-adapter">
<title>Jetty 9.x SAML Adapters</title>
<para>
Keycloak has a separate SAML adapter for Jetty 9.x. You then have to provide some extra configuration in each WAR you deploy to
Jetty. Let's go over these steps.
</para>
<section id="jetty9-adapter-installation">
<title>Adapter Installation</title>
<para>
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.
</para>
<para>
You must unzip the Jetty 9.x distro into Jetty 9.x's root directory. Including
adapter's jars within your WEB-INF/lib directory will not work!
</para>
<para>
<programlisting>
$ cd $JETTY_HOME
$ unzip keycloak-saml-jetty92-adapter-dist.zip
</programlisting>
</para>
<para>
Next, you will have to enable the keycloak module for your jetty.base.
</para>
<para>
<programlisting>
$ cd your-base
$ java -jar $JETTY_HOME/start.jar --add-to-startd=keycloak
</programlisting>
</para>
</section>
<section id="jetty9_per_war">
<title>Required Per WAR Configuration</title>
<para>
This section describes how to secure a WAR directly by adding config and editing files within your WAR package.
</para>
<para>
The first thing you must do is create a <literal>WEB-INF/jetty-web.xml</literal> file in your WAR package. This is
a Jetty specific config file and you must define a Keycloak specific authenticator within it.
</para>
<programlisting>
<![CDATA[
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://www.eclipse.org/jetty/configure_9_0.dtd">
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<Get name="securityHandler">
<Set name="authenticator">
<New class="org.keycloak.adapters.saml.jetty.KeycloakSamlAuthenticator">
</New>
</Set>
</Get>
</Configure>]]>
</programlisting>
<para>
Next you must create
a <literal>keycloak-saml.xml</literal> adapter config file within the <literal>WEB-INF</literal> directory
of your WAR. The format of this config file is describe in the <link linkend='adapter-config'>general adapter configuration</link>
section.
</para>
<para>
Finally you must specify both a <literal>login-config</literal> and use standard servlet security to specify
role-base constraints on your URLs. Here's an example:
</para>
<para>
<programlisting>
<![CDATA[
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<module-name>customer-portal</module-name>
<security-constraint>
<web-resource-collection>
<web-resource-name>Customers</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>this is ignored currently</realm-name>
</login-config>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>user</role-name>
</security-role>
</web-app>
]]>
</programlisting>
</para>
</section>
</chapter>
docbook/saml-adapter-docs/reference/en/en-US/modules/logout.xml
Executable
+10
View File
@@ -0,0 +1,10 @@
<chapter>
<title>Logout</title>
<para>
There are multiple ways you can logout from a web application. For Java 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 constraing and pass in a query parameter GLO, i.e. <literal>http://myapp?GLO=true</literal>.
This will log you out if you have an SSO session with your browser.
</para>
</chapter>
docbook/saml-adapter-docs/reference/en/en-US/modules/multi-tenancy.xml
Executable
+56
View File
@@ -0,0 +1,56 @@
<chapter id="multi_tenancy">
<title>Multi Tenancy</title>
<para>
Multi Tenancy, in our context, means that one single target application (WAR) can be secured by a single (or clustered) Keycloak server, authenticating
its users against different realms. In practice, this means that one application needs to use different <literal>keycloak.json</literal> files.
For this case, there are two possible solutions:
<itemizedlist>
<listitem>
The same WAR file deployed under two different names, each with its own Keycloak configuration (probably via the Keycloak Subsystem).
This scenario is suitable when the number of realms is known in advance or when there's a dynamic provision of application instances.
One example would be a service provider that dynamically creates servers/deployments for their clients, like a PaaS.
</listitem>
<listitem>
A WAR file deployed once (possibly in a cluster), that decides which realm to authenticate against based on the request parameters.
This scenario is suitable when there are an undefined number of realms. One example would be a SaaS provider that have only one deployment
(perhaps in a cluster) serving several companies, differentiating between clients based on the hostname
(<literal>client1.acme.com</literal>, <literal>client2.acme.com</literal>) or path (<literal>/app/client1/</literal>,
<literal>/app/client2/</literal>) or even via a special HTTP Header.
</listitem>
</itemizedlist>
This chapter of the reference guide focus on this second scenario.
</para>
<para>
Keycloak provides an extension point for applications that need to evaluate the realm on a request basis. During the authentication
and authorization phase of the incoming request, Keycloak queries the application via this extension point and expects the application
to return a complete representation of the realm. With this, Keycloak then proceeds the authentication and authorization process,
accepting or refusing the request based on the incoming credentials and on the returned realm.
For this scenario, an application needs to:
<itemizedlist>
<listitem>
Add a context parameter to the <literal>web.xml</literal>, named <literal>keycloak.config.resolver</literal>.
The value of this property should be the fully qualified name of the class extending
<literal>org.keycloak.adapters.KeycloakConfigResolver</literal>.
</listitem>
<listitem>
A concrete implementation of <literal>org.keycloak.adapters.KeycloakConfigResolver</literal>. Keycloak will call the
<literal>resolve(org.keycloak.adapters.HttpFacade.Request)</literal> method and expects a complete
<literal>org.keycloak.adapters.KeycloakDeployment</literal> in response. Note that Keycloak will call this for every request,
so, take the usual performance precautions.
</listitem>
</itemizedlist>
</para>
<para>
An implementation of this feature can be found in the examples.
</para>
</chapter>
docbook/saml-adapter-docs/reference/en/en-US/modules/tomcat-adapter.xml
Executable
+92
View File
@@ -0,0 +1,92 @@
<chapter id="tomcat-adapter">
<title>Tomcat 6, 7 and 8 SAML dapters</title>
<para>
To be able to secure WAR apps deployed on Tomcat 6, 7 and 8 you must install the Keycloak Tomcat 6, 7 or 8 SAML adapter
into your Tomcat installation. You then have to provide some extra configuration in each WAR you deploy to
Tomcat. Let's go over these steps.
</para>
<section id="tomcat-adapter-installation">
<title>Adapter Installation</title>
<para>
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.
</para>
<para>
You must unzip the adapter distro into Tomcat's <literal>lib/</literal> directory. Including
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.
</para>
<para>
<programlisting>
$ cd $TOMCAT_HOME/lib
$ unzip keycloak-saml-tomcat6-adapter-dist.zip
or
$ unzip keycloak-saml-tomcat7-adapter-dist.zip
or
$ unzip keycloak-saml-tomcat8-adapter-dist.zip
</programlisting>
</para>
</section>
<section>
<title>Required Per WAR Configuration</title>
<para>
This section describes how to secure a WAR directly by adding config and editing files within your WAR package.
</para>
<para>
The first thing you must do is create a <literal>META-INF/context.xml</literal> file in your WAR package. This is
a Tomcat specific config file and you must define a Keycloak specific Valve.
</para>
<programlisting>
<![CDATA[
<Context path="/your-context-path">
<Valve className="org.keycloak.adapters.saml.tomcat.SamlAuthenticatorValve"/>
</Context>]]>
</programlisting>
<para>
Next you must create
a <literal>keycloak-saml.xml</literal> adapter config file within the <literal>WEB-INF</literal> directory
of your WAR. The format of this config file is describe in the <link linkend='adapter-config'>general adapter configuration</link>
section.
</para>
<para>
Finally you must specify both a <literal>login-config</literal> and use standard servlet security to specify
role-base constraints on your URLs. Here's an example:
</para>
<para>
<programlisting>
<![CDATA[
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<module-name>customer-portal</module-name>
<security-constraint>
<web-resource-collection>
<web-resource-name>Customers</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>this is ignored currently</realm-name>
</login-config>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>user</role-name>
</security-role>
</web-app>
]]>
</programlisting>
</para>
</section>
</chapter>