Remove kcinit and text-based authentication flows
by Stian Thorgersen
kcinit and it's associated text-based authentication flows adds quite a bit
of complexity. It was never fully completed and we don't have capacity to
complete it.
Text-based authentication flows are also not really all that useful. There
are other better approaches to authenticate devices without a web browser,
and when there is a web browser that should be used rather than cli.
I propose we remove both kcinit as well as the text-based authentication
flows. We also need to revert KeycloakInstalled to how it was prior to this
was added as it is currently fairly broken.
4 years, 11 months
Plain-text vault
by Hynek Mlnarik
Recently, vault capability has been introduced recently in Keycloak
(master) with an out-of-the-box implementation that is basically providing
secrets in the same format as if mounting secrets volume within Kubernetes
[1]. Now there have been considerations regarding name and storage layout
which I would like to gather feedback on.
The questions are the following ones. Both have arguments for the current
implementation explained below:
1. Is there any better way of storing the credentials?
2. Is there a better name for the OOTB implementation?
Storage layout:
The aim: The plain text vault implementation respects realm to prevent
leaking a secret used in one vault into another realm. The implementation
also accounts for Kubernetes secret keys naming restrictions [1] which are
only consisting of alphanumeric characters, ‘-’, ‘_’ or ‘.’. Note that
forward slash is not among allowed characters.
Since the vault adheres to the same format as provided by Kubernetes
secrets volume, it also limits the file possible names for easy usage.
While kubernetes support exposing the secret keys as files in various
subdirectories of the mount directory, the default way of providing secrets
is via flat file structure (no subdirectories). To achieve structure where
secret would be looked up in a file with a given key within a realm
directory (i.e. realm_name/secret_key), every secret would have to be
accompanied with "path" specification which is not particularly user
friendly.
Having kubernetes secrets per realm and mounting them into separate
directories could be an option, however that limits the ability to easily
add a new realm because the Pod definition would need to change with every
new realm to incorporate the new volume, and the whole deployment restarted
to reflect the changes. Alternatively, secrets for all realms could be
mounted into a single directory and "path" would be defined for every
secret as described above - but that is error-prone as well.
Thus the implementation where realm name and secret key would be separated
by a single underscore, and to prevent ambiguity, every underscore within
the either realm name and secret keys would be doubled. In other words, to
get secret called "some-secret" or "other_secret" from vault from within
realm called "realm-1" or "other_realm", the files would be called
"realm-1_some-secret" and "other__realm_other__secret", respectively. This
is clearly readable in the former case but may be error-prone in the latter.
Name:
The SPI name was chosen to be "plaintext" since the secrets are stored
openly in the files. Perhaps there is a better name? "kubernetes"? Any
other suggestion or +1 or -1 with arguments to the alternatives are welcome.
I would love to hear your opinion on the two questions.
[Apologies for cross-posting, this can gain valuable feedback from both
devs and users though]
--Hynek
[1] https://kubernetes.io/docs/concepts/configuration/secret/
4 years, 11 months
Performance concerns and improvements for large numbers of clients [KEYCLOAK-8275]
by Cristian Schuszter
Hello everyone,
My team and I have been revisiting some performance issues, namely the ones related to: https://issues.jboss.org/browse/KEYCLOAK-8275 .
>From the comments, I understand that the plan is to re-implement the data access part of Keycloak, which is why the issues have been closed or put back into triage. We are planning to roll out a production Keycloak instance in the coming months / weeks and we've been doing some statistics on the number of clients that we would need to support: somewhere in the region of 15 000.
Firstly, I'd like to know what the status on the new / improved data access is, as I couldn't find any information on your Jira. Could you give us an estimate on when it would be released?
Secondly, assuming that it will take more time until such a high number of clients will be supported fully, I have a few simple improvements or changes in mind, and we'd gladly contribute with a PR. They are as follows:
1. New query parameters for the /auth/admin/realms/:realmId/clients endpoint:
- limit (int): restrict the number of results when pulling all clients, useful for the admin UI as there's no point in pulling 200 pages of stuff, nobody's going to click the arrows to search manually
- search (bool): if set to true, searches with a case-insensitive "LIKE %clientId%" query, as currently the search box on the admin UI works only in the case of an exact match (not particularly useful).
The search flag combined with the limited results will allow admins to search through clients without the need to pull all the data from the server, causing a timeout. Any queries performed like before work the same, listing all clients.
2. Removal of "RedirectUtils.getValidRedirectUris()" from the class LogoutEndpoint (possibly turned on or off via a config flag??). With 15000 clients it took around 5 minutes for the logout endpoint to return successfully. Without the redirect URI validation, it finished in milliseconds. Since any redirect URI of any client of the realm can be used, I don't personally see much use from using it at all. ( see https://issues.jboss.org/browse/KEYCLOAK-8284 )
3. Minor UI tweak: When pressing enter or clicking on search in the admin client list, a "Searching..." prompt appears under the seearch box.
!! Talking about UI, I saw a strange thing in the Angular code, it seems that ALL the clients are pulled from the server when accessing the client details. I added a limit to that as well as they didn't seem to be used. I don't think the client list should be pulled by anything, but maybe somebody knows details here.
The PR is submitted at https://github.com/keycloak/keycloak/pull/6320, any feedback would be appreciated!
Best regards,
Cristian Schuszter
4 years, 11 months
Allow registering only with email and password
by Cliff MAURY
Hello,
We use Keycloak with my team since more than 6 months for our client to
rebuild the authentication process that was previously done with in-house
OAuth2 custom development... :(
Hopefully, Keyckoak is a great product and we thank alls contributors for
their work 👍
I would to like to have feedback about some propositions before doing the
associated pull requests (as mentionned in the contributors guide).
When we enable "User registration" parameter in Login panel of the Realm,
we can access to the built-in registration page of Keycloak.
But we need to the specify the first name and the last name : these 2 fiels
are mandatory...
In our business needs, we wanted only a registration form with email (as
username) and password like many others websites/applications.
So we overrided the registration template with only email and
password fields, but validation failed because RegistrationProfile::validate
checks for first name and last name parameters.
So I would like to submit a proposition : When "User registration" is set,
another options could be displayed "Add first name and last name" (for
instance) disabled by default.
So the default registration page would require only email and password
fields (this could cover many use cases of users registration) and when
needed, the first name and last name could be filled and validated when the
associated realm parameter is set.
In addition, to go further, the "Email as username" parameter could be set
to true, in order to have a registration page with
email/password/confirmation password fields out of the box.
What do you think about it ?
Regards,
Cliff Maury
4 years, 11 months
Incorrect parsing of GUID from eDirectory
by Sven-Torben Janus
Hey all!
one of my customers wants to implement user federation with eDirectory as LDAP server in place. Everything works fine as long as "Import users" is deactivated.
When activating the import, users can no longer be imported. The import fails with the exception shown in https://issues.jboss.org/browse/KEYCLOAK-10942 when "UUID LDAP attribute" is set to "guid".
The exception seems to come from incorrect parsing of the guid attribute in LDAP. The guid attribute in eDirectory is binary, but is not parsed as such.
I have prepared a PR https://github.com/keycloak/keycloak/pull/6251 to fix this.
However, I am unsure about the current state of support for eDirectory. I have seen these PRs and tickets which indicate eDirectory is supported:
* https://github.com/keycloak/keycloak/pull/1154
* https://lists.jboss.org/pipermail/keycloak-user/2015-April/002023.html
I can also choose "Novell eDirectory" from the Vendor list, so I assume it is supported.
In contrast I see tickets like this one, where it states that it isn't supported.
* https://issues.jboss.org/browse/KEYCLOAK-3099 (btw: that seems to be the same issue as described in KEYCLOAK-10942)
And there has been a discussion around a similar (the same?) issue, years ago: https://lists.jboss.org/pipermail/keycloak-user/2016-November/008428.html
Can anyone please clarify on the current state of eDirectory support and whether my fix has a chance be released?
Regards
Sven-Torben
--
Sven-Torben Janus
Senior Software Architect (Dipl.-Inf.), iSAQB® CPSA-A
Conciso GmbH | Westfalendamm 251 | 44141 Dortmund
E sven-torben.janus(a)conciso.de
W https://conciso.de
Rechtlicher Hinweis/Legal notice:
Sitz der Gesellschaft/Registered Office: Dortmund
Amtsgericht/Trade Register: Dortmund, HRB 28364
Geschäftsführer/Managing Directors: Sebastian Neus, Dr. Georg Pietrek, Jens Trompeter
4 years, 11 months
Gatekeeper failing to proxy a redirect link
by Nick Powers
I am using keycloak and gatekeeper to authenticate my web app against
Google. Everything seems to work fine, with regular links, but if I
redirect the user to a page within my web app gatekeeper exposes the
internal URL rather than proxying the data.
I'm using the following to redirect the user, via PHP:
< ?php header("Location: https://commentcontext.com/protected/dashboard"); ?>
But instead of being sent through gatekeeper to that URL it tries to send
the user to https://webapp/protected/dashboard which is the internal URL of
my webapp and of course webapp doesn't resolve in DNS so it fails.
Why is this happening? Is it a known issue? Is there a workaround?
Thanks!!!
Nick
4 years, 11 months
Documentation on metrics introduced in version 6.0.0
by AMIEL Patrice
Hi,
Version 6.0.0 introduces the SmallRye Health and Metrics support. I'm trying to see what are the metrics that are currently supported (in version 6.x and now 7.x of KeyCloak), and how to get them (i.e. what is the port and path to be navigated on a running KeyCloak instance)... but unfortunately, I've not been able to found any of these information !
For sure, the revision history of v6.0.0 mentions "We will add some documentation as well as Keycloak specific metrics soon" ;) , but as we are now already in version 7.0 for a month, I'm wondering if such doc is available somewhere !?
If someone knows, can you give a pointer or provide these information as a reply in this mailing list ?
What is the plan to add new metrics (which one and when) ?
Thanks a lot!
Patrice
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
4 years, 11 months
Keycloak JDK support: JDK11 build fails; JDK11 runtime & JDK8 build/runtime all ok?
by PGNet Dev
This
Building from source
https://github.com/keycloak/keycloak/blob/master/docs/building.md
states
"Ensure you have JDK 8 (or newer), Maven 3.1.1 (or newer) and Git installed"
suggesting build with jdk11 should work.
starting with clean KC v7 source,
git checkout 7.0.0
git log | head
commit e6a274ea0e31c6572e795f3372f006c88122539b
Author: Stian Thorgersen <stianst(a)gmail.com>
Date: Fri Aug 23 14:07:35 2019 +0200
Update release.sh
commit 7bf81b0458fcf39143b3cbef59963daf093079fb
Author: Stian Thorgersen <stianst(a)gmail.com>
Date: Fri Aug 23 14:01:03 2019 +0200
Building with each JDK, both v8 & v11
(1) BUILD WITH JDK8
java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (IcedTea 3.13.0) (build 1.8.0_222-b10 suse-lp151.333.1-x86_64)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
mvn -version
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T12:00:29-07:00)
Maven home: /usr/share/java/maven
Java version: 1.8.0_222, vendor: IcedTea, runtime: /usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.2.13-24.gacd8e88-default", arch: "amd64", family: "unix"
mvn \
--errors \
--update-snapshots \
--activate-profiles distribution \
--projects distribution/server-dist,distribution/adapters/wildfly-adapter \
--also-make \
-Dmaven.test.skip=true \
clean \
install
==> SUCCEEDS
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:56 min
[INFO] Finished at: 2019-09-08T12:05:22-07:00
[INFO] ------------------------------------------------------------------------
& the build *execs* OK under BOTH jre v8 & v11 runtimes.
(2) BUILD WITH JDK11
java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11-suse-lp151.131.1-x8664)
OpenJDK 64-Bit Server VM (build 11.0.4+11-suse-lp151.131.1-x8664, mixed mode)
mvn -version
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T12:00:29-07:00)
Maven home: /usr/share/java/maven
Java version: 11.0.4, vendor: Oracle Corporation, runtime: /usr/lib64/jvm/java-11-openjdk-11
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.2.13-24.gacd8e88-default", arch: "amd64", family: "unix"
mvn -X \
--errors \
--update-snapshots \
--activate-profiles distribution \
--projects distribution/server-dist,distribution/adapters/wildfly-adapter \
--also-make \
-Dmaven.test.skip=true \
clean \
install
==> FAILs
...
[INFO] 50 warnings
[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /home/dev/keycloak/saml-core/src/main/java/org/keycloak/saml/processing/api/util/KeyInfoTools.java:[51,70] incompatible types: java.util.List<javax.xml.crypto.XMLStructure> cannot be converted to java.lang.Iterable<java.lang.Object>
[ERROR] /home/dev/keycloak/saml-core/src/main/java/org/keycloak/saml/processing/api/util/KeyInfoTools.java:[55,70] incompatible types: java.util.List<javax.xml.crypto.XMLStructure> cannot be converted to java.lang.Iterable<java.lang.Object>
[ERROR] /home/dev/keycloak/saml-core/src/main/java/org/keycloak/saml/processing/api/util/KeyInfoTools.java:[60,58] incompatible types: java.util.List<capture#1 of ?> cannot be converted to java.lang.Iterable<java.lang.Object>
[ERROR] /home/dev/keycloak/saml-core/src/main/java/org/keycloak/saml/processing/core/util/XMLSignatureUtil.java:[757,42] incompatible types: java.util.List<java.lang.Object> cannot be converted to java.util.List<? extends javax.xml.crypto.XMLStructure>
[INFO] 4 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Keycloak 7.0.0:
[INFO]
[INFO] Keycloak ........................................... SUCCESS [ 1.321 s]
[INFO] Keycloak Common .................................... SUCCESS [ 4.921 s]
[INFO] Keycloak Core ...................................... SUCCESS [ 2.599 s]
[INFO] Keycloak Server SPI ................................ SUCCESS [ 1.960 s]
[INFO] Keycloak Server Private SPI ........................ SUCCESS [ 3.378 s]
[INFO] Keycloak Kerberos Federation ....................... SUCCESS [ 0.567 s]
[INFO] Keycloak LDAP UserStoreProvider .................... SUCCESS [ 1.368 s]
[INFO] Keycloak SAML Core Public API ...................... SUCCESS [ 1.267 s]
[INFO] Keycloak SAML Core ................................. FAILURE [ 1.537 s]
[INFO] Keycloak REST Services ............................. SKIPPED
[INFO] Keycloak JS Integration ............................ SKIPPED
[INFO] Keycloak Themes .................................... SKIPPED
[INFO] Keycloak Model Parent .............................. SKIPPED
[INFO] Keycloak Model JPA ................................. SKIPPED
[INFO] Keycloak Model Infinispan .......................... SKIPPED
[INFO] Keycloak SSSD Federation ........................... SKIPPED
[INFO] KeyCloak Authz: Parent ............................. SKIPPED
[INFO] KeyCloak AuthZ: Provider Parent .................... SKIPPED
[INFO] KeyCloak AuthZ: Common Policy Providers ............ SKIPPED
[INFO] KeyCloak AuthZ: Drools Policy Provider ............. SKIPPED
[INFO] Keycloak WildFly Integration ....................... SKIPPED
[INFO] Keycloak WildFly Add User Script ................... SKIPPED
[INFO] Keycloak WildFly Extensions ........................ SKIPPED
[INFO] Keycloak WildFly Server Subsystem .................. SKIPPED
[INFO] Keycloak Integration ............................... SKIPPED
[INFO] Keycloak Client CLI ................................ SKIPPED
[INFO] Keycloak Client Registration CLI ................... SKIPPED
[INFO] Keycloak Admin CLI ................................. SKIPPED
[INFO] Keycloak Client CLI Distribution ................... SKIPPED
[INFO] Keycloak Adapter SPI ............................... SKIPPED
[INFO] Keycloak Undertow Integration SPI .................. SKIPPED
[INFO] Common JBoss/Wildfly Core Classes .................. SKIPPED
[INFO] KeyCloak Authz: Client API ......................... SKIPPED
[INFO] Keycloak Adapter Core .............................. SKIPPED
[INFO] Keycloak Undertow Integration ...................... SKIPPED
[INFO] Keycloak Servlet OAuth Client ...................... SKIPPED
[INFO] Keycloak Wildfly Integration ....................... SKIPPED
[INFO] Keycloak Wildfly Elytron OIDC Adapter .............. SKIPPED
[INFO] Keycloak Wildfly Adapter Subsystem ................. SKIPPED
[INFO] Distribution Parent ................................ SKIPPED
[INFO] Keycloak Distribution Licenses Common .............. SKIPPED
[INFO] Keycloak Distribution Maven Plugins Parent ......... SKIPPED
[INFO] Keycloak Licenses Processor Maven Plugin ........... SKIPPED
[INFO] Feature Pack Builds ................................ SKIPPED
[INFO] Keycloak Feature Pack: Adapter ..................... SKIPPED
[INFO] Adapters Distribution Parent ....................... SKIPPED
[INFO] Keycloak Adapter Overlay Distribution .............. SKIPPED
[INFO] Keycloak Feature Pack: Server ...................... SKIPPED
[INFO] Keycloak Server Distribution ....................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 24.322 s
[INFO] Finished at: 2019-09-08T12:10:17-07:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0-jboss-2:compile (default-compile) on project keycloak-saml-core: Compilation failure: Compilation failure:
[ERROR] /home/dev/keycloak/saml-core/src/main/java/org/keycloak/saml/processing/api/util/KeyInfoTools.java:[51,70] incompatible types: java.util.List<javax.xml.crypto.XMLStructure> cannot be converted to java.lang.Iterable<java.lang.Object>
[ERROR] /home/dev/keycloak/saml-core/src/main/java/org/keycloak/saml/processing/api/util/KeyInfoTools.java:[55,70] incompatible types: java.util.List<javax.xml.crypto.XMLStructure> cannot be converted to java.lang.Iterable<java.lang.Object>
[ERROR] /home/dev/keycloak/saml-core/src/main/java/org/keycloak/saml/processing/api/util/KeyInfoTools.java:[60,58] incompatible types: java.util.List<capture#1 of ?> cannot be converted to java.lang.Iterable<java.lang.Object>
[ERROR] /home/dev/keycloak/saml-core/src/main/java/org/keycloak/saml/processing/core/util/XMLSignatureUtil.java:[757,42] incompatible types: java.util.List<java.lang.Object> cannot be converted to java.util.List<? extends javax.xml.crypto.XMLStructure>
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0-jboss-2:compile (default-compile) on project keycloak-saml-core: Compilation failure
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure
at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1215)
at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:196)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :keycloak-saml-core
Is Keycloak known/intended to be JDK11 build-ready? or just @runtime?
4 years, 11 months
Add SAML Extensions (and AuthContext) as another client note to the AuthenticationSessionModel in SamlService
by Roland
Hello,
when a SAML Request is received in Keycloak, the method loginRequest in
abstract class BindingProtocol in class
org.keycloak.protocol.samlSamlService puts the information from the request
into the AuthenticationSessionModel in this section of code:
authSession.setProtocol(SamlProtocol.LOGIN_PROTOCOL);
authSession.setRedirectUri(redirect);
authSession.setAction(
AuthenticationSessionModel.Action.AUTHENTICATE.name());
authSession.setClientNote(SamlProtocol.SAML_BINDING,
bindingType);
authSession.setClientNote(GeneralConstants.RELAY_STATE,
relayState);
authSession.setClientNote(SamlProtocol.SAML_REQUEST_ID,
requestAbstractType.getID());
What we are missing here is the SAML Extensions, which happen to be in the
SAML Request which we receive, and which we want to pass on to a brokered
external Identity Provider.
For example something like this:
ExtensionsType et = requestAbstractType.getExtensions();
List<Object> list = et.getAny();
<create some kind of String representation>
authSession.setAuthNote("SAML_EXTENSION", <the String
representation>);
In the same way we would also like access to the AuthContext through the
authSession.
I would offer to contribute this if the community approves the idea.
Thanks and Regards,
Roland
4 years, 11 months
Javascript adapter refactoring
by Guillaume Vincent
Hello,
since my last email, I continued to work on a javascript adapter called
keycloak-lite. It's a version targetting modern browser only for now. Thank
to the first feedback I started to migrate this first version on TypeScript.
In a recent issue on Jira, I see that you would like to start working on
the refactoring of the javascript adapater using Typescript. I see also
that you would like to change the API a little.
Does this work already started somewhere?
How can I help you on this.
Thank you
--
Guillaume Vincent
Senior Software Engineer
Red Hat <https://www.redhat.com>
<https://www.redhat.com>
4 years, 11 months
