KEYCLOAK-8692 - Make it possible to build on Windows
This commit is contained in:
parent
b6acfc53b9
commit
d59910b4d9
11 changed files with 46 additions and 39 deletions
|
@ -24,6 +24,10 @@ First, clone the Keycloak Documentation repository:
|
|||
git clone https://github.com/keycloak/keycloak-documentation.git
|
||||
cd keycloak-documentation
|
||||
|
||||
If you are using Windows, you need to run the following command with administrator privilege because this project uses symbolic links:
|
||||
|
||||
git clone -c core.symlinks=true https://github.com/keycloak/keycloak-documentation.git
|
||||
|
||||
To build Keycloak Documentation run:
|
||||
|
||||
mvn clean install
|
||||
|
|
|
@ -23,13 +23,10 @@ import org.apache.maven.plugins.annotations.Mojo;
|
|||
import org.apache.maven.plugins.annotations.Parameter;
|
||||
import org.apache.maven.project.MavenProject;
|
||||
|
||||
import java.io.BufferedInputStream;
|
||||
import java.io.BufferedReader;
|
||||
import java.io.File;
|
||||
import java.io.FileInputStream;
|
||||
import java.io.FileOutputStream;
|
||||
import java.io.FileReader;
|
||||
import java.io.FileWriter;
|
||||
import java.io.IOException;
|
||||
import java.io.PrintStream;
|
||||
import java.nio.file.Files;
|
||||
|
@ -52,8 +49,6 @@ public class HeaderMojo extends AbstractMojo {
|
|||
|
||||
private File baseDir;
|
||||
|
||||
private File topicsFile;
|
||||
|
||||
private File topicsDir;
|
||||
|
||||
public void execute() throws MojoExecutionException {
|
||||
|
@ -85,46 +80,54 @@ public class HeaderMojo extends AbstractMojo {
|
|||
}
|
||||
|
||||
private void processTopics(File f) throws IOException {
|
||||
File out = new File(outputDir, f.getAbsolutePath().replaceFirst(topicsDir.getParentFile().getAbsolutePath(), ""));
|
||||
String topicsAbsolutePath = f.getAbsolutePath();
|
||||
String topicsParentDirPath = topicsDir.getParentFile().getAbsolutePath();
|
||||
if (isWindows()) {
|
||||
topicsAbsolutePath = topicsAbsolutePath.replace("\\", "/");
|
||||
topicsParentDirPath = topicsParentDirPath.replace("\\", "/");
|
||||
}
|
||||
File out = new File(outputDir, topicsAbsolutePath.replaceFirst(topicsParentDirPath, ""));
|
||||
|
||||
if (f.isFile() && f.getAbsolutePath().contains("/templates/")) {
|
||||
if (f.isFile() && topicsAbsolutePath.contains("/templates/")) {
|
||||
out.getParentFile().mkdirs();
|
||||
Files.copy(f.toPath(), out.toPath(), StandardCopyOption.REPLACE_EXISTING);
|
||||
} else if (f.isDirectory()) {
|
||||
for (File c : f.listFiles()) {
|
||||
processTopics(c);
|
||||
File[] files = f.listFiles();
|
||||
if(files != null){
|
||||
for (File c : files) {
|
||||
processTopics(c);
|
||||
}
|
||||
}
|
||||
} else if (f.getName().endsWith(".adoc")) {
|
||||
out.getParentFile().mkdirs();
|
||||
|
||||
String filePath = f.getAbsolutePath().replace(baseDir.getParent(), "").substring(1);
|
||||
|
||||
if (isWindows()) {
|
||||
filePath = filePath.replace("\\", "/");
|
||||
}
|
||||
String includeHeaderPath = filePath.substring(baseDir.getName().length() + 7);
|
||||
includeHeaderPath = includeHeaderPath.substring(0, includeHeaderPath.lastIndexOf('/'));
|
||||
includeHeaderPath = includeHeaderPath.replaceAll("/[^/]+", "../");
|
||||
includeHeaderPath = includeHeaderPath + "templates/header.adoc";
|
||||
|
||||
String header = "\n\n:include_filename: " + filePath + "\ninclude::" + includeHeaderPath + "[]\n\n";
|
||||
try(PrintStream ps = new PrintStream(new FileOutputStream(out));BufferedReader br = new BufferedReader(new FileReader(f));){
|
||||
for (String l = br.readLine(); l != null; l = br.readLine()) {
|
||||
ps.println(l);
|
||||
if (l.contains("=")) {
|
||||
break;
|
||||
}
|
||||
}
|
||||
ps.print(header);
|
||||
|
||||
PrintStream ps = new PrintStream(new FileOutputStream(out));
|
||||
|
||||
|
||||
BufferedReader br = new BufferedReader(new FileReader(f));
|
||||
for (String l = br.readLine(); l != null; l = br.readLine()) {
|
||||
ps.println(l);
|
||||
if (l.contains("=")) {
|
||||
break;
|
||||
for (String l = br.readLine(); l != null; l = br.readLine()) {
|
||||
ps.println(l);
|
||||
}
|
||||
}
|
||||
|
||||
ps.print(header);
|
||||
|
||||
for (String l = br.readLine(); l != null; l = br.readLine()) {
|
||||
ps.println(l);
|
||||
}
|
||||
|
||||
br.close();
|
||||
ps.close();
|
||||
}
|
||||
}
|
||||
private boolean isWindows(){
|
||||
String osName = System.getProperty("os.name");
|
||||
return osName != null && osName.toLowerCase().startsWith("windows");
|
||||
}
|
||||
}
|
||||
|
|
|
@ -407,7 +407,7 @@ After the {project_name} web server pod has started, it can be accessed at its c
|
|||
* *\http://sso-_<project-name>_._<hostname>_/auth/admin*: for the {project_name} web server, and
|
||||
* *\https://secure-sso-_<project-name>_._<hostname>_/auth/admin*: for the encrypted {project_name} web server.
|
||||
|
||||
Use the xref:sso-administrator-setup[administrator user credentials] to log in into the `master` realm’s administration console.
|
||||
Use the xref:sso-administrator-setup[administrator user credentials] to log in into the `master` realm's administration console.
|
||||
|
||||
[[SSO-Clients]]
|
||||
=== {project_name} Clients
|
||||
|
|
|
@ -169,14 +169,14 @@ image without requiring a rebuild, and should be set by the user as desired.
|
|||
|*_AB_JOLOKIA_AUTH_OPENSHIFT_*
|
||||
|Switch on client authentication for OpenShift TLS communication. The value of
|
||||
this parameter can be a relative distinguished name which must be contained in
|
||||
a presented client’s certificate. Enabling this parameter will automatically
|
||||
a presented client's certificate. Enabling this parameter will automatically
|
||||
switch Jolokia into https communication mode. The default CA cert is set to
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`.
|
||||
|*_true_*
|
||||
|
||||
|*_AB_JOLOKIA_CONFIG_*
|
||||
|If set uses this file (including path) as Jolokia JVM agent properties (as
|
||||
described in Jolokia’s
|
||||
described in Jolokia's
|
||||
link:https://jolokia.org/reference/html/agents.html#agents-jvm[reference
|
||||
manual]). If not set, the `/opt/jolokia/etc/jolokia.properties` file will be
|
||||
created using the settings as defined in this document, otherwise the rest of
|
||||
|
|
|
@ -84,7 +84,7 @@ We introduced a more flexible way to configure the hostname for RH-SSO which giv
|
|||
|
||||
== X509 Client Authenticator
|
||||
|
||||
The newly added Client Authenticator uses X509 Client Certificates and Mutual TLS to secure a connection from the client. In addition, the RH-SSO Server validates the Subject DN field of the client’s certificate.
|
||||
The newly added Client Authenticator uses X509 Client Certificates and Mutual TLS to secure a connection from the client. In addition, the RH-SSO Server validates the Subject DN field of the client's certificate.
|
||||
|
||||
== Client Scopes
|
||||
|
||||
|
|
|
@ -50,6 +50,6 @@ NOTE: it is recommended that you configure the Docker registry client in a realm
|
|||
|
||||
Once the above configuration has taken place, and the keycloak server and Docker registry are running, docker authentication should be successful:
|
||||
|
||||
[user ~]# docker login localhost:5000 -u $username
|
||||
[user ~]# docker login localhost:5000 -u $username
|
||||
Password: *******
|
||||
Login Succeeded
|
||||
|
|
|
@ -9,7 +9,7 @@ link:{adminguide_link}[{adminguide_name}], but let's give some context and a bri
|
|||
|
||||
external requests::
|
||||
{project_name} can run out of the box without SSL so long as you stick to private IP addresses like `localhost`, `127.0.0.1`, `10.0.x.x`, `192.168.x.x`, and `172.16.x.x`.
|
||||
If you don’t have SSL/HTTPS configured on the server or you try to access {project_name} over HTTP from a non-private IP adress you will get an error.
|
||||
If you don't have SSL/HTTPS configured on the server or you try to access {project_name} over HTTP from a non-private IP adress you will get an error.
|
||||
|
||||
none::
|
||||
{project_name} does not require SSL. This should really only be used in development when you are playing around with things.
|
||||
|
|
|
@ -58,5 +58,5 @@ Or run this CLI command:
|
|||
|
||||
When you start the server with this configuration it checks if the database needs to be migrated. The required changes
|
||||
are written to an SQL file that you can review and manually run against the database. For further details on how to
|
||||
apply this file to the database, see the documentation for the relational database you’re using. After the changes have
|
||||
apply this file to the database, see the documentation for the relational database you're using. After the changes have
|
||||
been written to the file, the server exits.
|
|
@ -5,7 +5,7 @@
|
|||
If you have created any custom themes they must be migrated to the new server. Any changes to the built-in themes might
|
||||
need to be reflected in your custom themes, depending on which aspects you have customized.
|
||||
|
||||
You must copy your custom themes from the old server “themes” directory to the new server “themes” directory.
|
||||
You must copy your custom themes from the old server "themes" directory to the new server "themes" directory.
|
||||
After that you need to review the changes below and consider if the changes need to be applied to your custom theme.
|
||||
|
||||
In summary:
|
||||
|
@ -40,8 +40,8 @@ The following screenshot compares the info.ftl template from the Login theme and
|
|||
.Comparison of the updated version of a Login theme template with an example custom Login theme template
|
||||
image:images/theme-migration-meld-info-1.png[]
|
||||
|
||||
From this comparison it is easy to identify that the first change (“Hello world!!”) was a customization, while the
|
||||
second change (“if pageRedirectUri”) is a change to the base theme. By copying the second change to your custom template,
|
||||
From this comparison it is easy to identify that the first change ("Hello world!!") was a customization, while the
|
||||
second change ("if pageRedirectUri") is a change to the base theme. By copying the second change to your custom template,
|
||||
you have successfully updated your customized template.
|
||||
|
||||
For the alternative approach the following screenshot compares the info.ftl template from the old installation with
|
||||
|
|
|
@ -9,7 +9,7 @@ the adapters.
|
|||
. Prior to applying the upgrade, handle any open transactions and delete the data/tx-object-store/ transaction directory.
|
||||
. Back up the old installation (configuration, themes, and so on).
|
||||
. Back up the database. For detailed information on how to back up the database, see the documentation for the relational
|
||||
database you’re using.
|
||||
database you're using.
|
||||
. Upgrade {project_name} server.
|
||||
* Testing the upgrade in a non-production environment first, to prevent any installation issues from being exposed in
|
||||
production, is a best practice.
|
||||
|
|
|
@ -20,5 +20,5 @@ For RH-SSO 7.0, paginated endpoints in the Admin REST API return all results if
|
|||
For RH-SSO 7.0, server configuration is split between the keycloak-server.json file and the standalone/domain.xml or domain.xml file. For RH-SSO 7.1, the keycloak-server.json file has been removed and all server configuration is done through the standalone.xml or domain.xml file. The upgrading procedure for RH-SSO 7.1 automatically migrates the server configuration from the keycloak-server.json file to the standalone.xml or domain.xml file.
|
||||
|
||||
=== Key Encryption Algorithm in SAML Assertions
|
||||
For RH-SSO 7.1, keys in SAML assertions and documents are now encrypted using the RSA-OAEP encryption scheme. To use encrypted assertions, ensure your service providers support this encryption scheme. In the event that you have service providers that do not support RSA-OAEP, RH-SSO can be configured to use the legacy RSA-v1.5 encryption scheme by starting the server with the system property “keycloak.saml.key_trans.rsa_v1.5” set to true. If you do this, you should upgrade your service providers as soon as possible to be able to revert to the more secure RSA-OAEP encryption scheme.
|
||||
For RH-SSO 7.1, keys in SAML assertions and documents are now encrypted using the RSA-OAEP encryption scheme. To use encrypted assertions, ensure your service providers support this encryption scheme. In the event that you have service providers that do not support RSA-OAEP, RH-SSO can be configured to use the legacy RSA-v1.5 encryption scheme by starting the server with the system property "keycloak.saml.key_trans.rsa_v1.5" set to true. If you do this, you should upgrade your service providers as soon as possible to be able to revert to the more secure RSA-OAEP encryption scheme.
|
||||
|
||||
|
|
Loading…
Reference in a new issue