add-user.sh overwrites wildfly one
by Bill Burke
The add-user.sh script overwrites the one that comes distributed with
Wildfly/EAP. Is this intentional? To set up domain mode on multiple
servers you need to be able to add an admin user to the domain and share the
secret with slave hosts so they can connect to the domain controller.
Can I rename add-user.sh to something else?
keycloak-add-user.sh
- or -
sso-add-user.sh
- or -
????
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
server distro BROKEN
by Bill Burke
Doesn't boot anymore on 1.9.x build (not sure about master). Built from
clean clone of keycloak repo. I'll look at it tomorrow (Monday) unless
the Europeans can do it.
Caused by: org.jboss.modules.ModuleNotFoundException:
org.keycloak.keycloak-server-subsystem:main
at
org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
[jboss-modules.jar:1.5.1.Final]
at
org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
[wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
... 8 more
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
domain mode changes
by Bill Burke
I'd like to make the following changes to domain.xml that we distribute
so that it runs as a cluster with a load balance out of the box on one
machine:
* remove the "default" profile. Users should really only be using
domain mode with a cluster
* remove host.xml. Its confusing to have both a host.xml and a
host-master.xml
* host-master.xml will boot only 1 server ("server-one")
* host-slave.xml will boot only 1 server ("server-two")
* Pre-configure a undertow load balancer [1] to loadbalance between
server one and server two
* Point H2 to a shared directory under domain/servers
I've checked that this setup works on my laptop. I hope to write a
Getting Started Guide around this too.
[1]
https://docs.jboss.org/author/display/WFLY10/Using+Wildfly+as+a+Load+Bala...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
Keycloak's SAML AuthnResponse uses wrong binding
by John Dennis
I could use some help from your SAML developers because I'm seeing what
appears to be incorrect behavior.
During testing with keycloak-1.9.0.Final a SAML AuthnRequest is sent
using the HTTP-Redirect binding. The AuthnRequest specifies a
AssertionConsumerServiceURL for the SP which has the HTTP-POST binding.
When Keycloak responds with the Assertion in the SAMLResponse it
incorrectly uses the HTTP-Redirect binding instead of the HTTP-POST
binding (specified in both the AuthnRequest and the SP metadata). This
causes a failure because the endpoint for the SP's
AssertionConsumerServiceURL only expects HTTP-POST, the resulting error
is an invalid HTTP method failure.
I also noticed that when I used the Web UI to examine the SP metadata
(Installation tab of the realm client, selecting the "SAML Metadata
SPSSODescriptor" format) that it did not match the SP metadata that had
been loaded using the client registration service. Not only wasn't it
the exact same metadata, but specifically it was missing several of the
endpoints the SP declared in it's metadata. Why isn't the metadata the
same and why did Keycloak drop essential endpoint/binding information?
Thanks,
--
John
10 years
2 mechanisms to configure UserFederationProvider
by Marek Posolda
Currently we have 2 mechanisms to configure generic UserFederation
providers.
1) The "old" way, which is using the simple list of strings -
UserFederationProviderFactory.getConfigurationOptions()
2) The "new" and more flexible way based on ConfiguredProvider.
Should we remove the old way for the Keycloak 2.X ? If yes, then maybe
even for 1.X we can deprecate
UserFederationProviderFactory.getConfigurationOptions() to notify people
that it will be removed in future versions? I know there will be more
changes, but if we know at 100% that this one will be removed, it's
maybe not bad to deprecate even now?
Marek
10 years
Providing a custom entityId for a SAML identity broker
by Jelmer van Amen
Hi all,
Using keycloak 1.9.1, we use an external identity broker which uses SAML (the dutch government). Now we would like to use the saml implementation in keycloak. For this to function, we need to call our provider with a SAML request containing a specific entityID ("urn:nl:eherkenning:DV:00000003123456780000:entities:9999") instead of getEntityId(uriInfo, realm) as currently used in the SAMLIdentityProvider. Now my question is two-fold. Is there any reason why the entityId is as specified as of speaking and secondly, am I correct in stating that the only way to change this behavior would be to provide a selfwritten different identity broker? Or would a (selfwritten) patch be sufficient to provide this as an optional parameter to the current SAMLIdentityProvider?
Kind regards,
Jelmer
This message is subject to the following E-mail Disclaimer. (http://www.crv4all.com/disclaimer-email/) CRV Holding B.V. seats according to the articles of association in Arnhem, Dutch trade number 09125050.
10 years
