I am following the keycloak documentation to secure my WAR using wildfly adapter subsystem.
I am trying to add the following using jboss-cli.sh -
<secure-deployment name="WAR MODULE NAME.war">
<realm>bkofc</realm>
<auth-server-url>http://192.168.99.100:30001/auth</auth-server-url>
<bearer-only>true</bearer-only>
<ssl-required>EXTERNAL</ssl-required>
<resource>bkofc-svc</resource>
<credential name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
<use-resource-role-mappings>true</use-resource-role-mappings>
</secure-deployment>
However the "credential" attribute is not recognized :
[standalone#localhost:9990 /]
/subsystem=keycloak/securedeployment=my.war/:add(realm=bkofc,auth-server-
url=http://192.168.99.100/30001/auth, bearer-only=true, ssl-
required=EXTERNAL, resource=bkofc-svc, use-resource-role-mappings=true,
credential=9bcc6d9f-9c72-4b58-b297-79f0f207d9e1)
'credential' is not found among the supported properties: [allow-any-
hostname, always-refresh-token, auth-server-url, auth-server-url-for-
backend-requests, autodetect-bearer-only, bearer-only, client-key-password,
client-keystore, client-keystore-password, connection-pool-size, cors-
allowed-headers, cors-allowed-methods, cors-max-age, disable-trust-manager,
enable-basic-auth, enable-cors, expose-token, min-time-between-jwks-
requests, principal-attribute, public-client, realm, realm-public-key,
register-node-at-startup, register-node-period, resource, ssl-required,
token-minimum-time-to-live, token-store, truststore, truststore-passw
ord, turn-off-change-session-id-on-login, use-resource-role-mappings]
[standalone#localhost:9990 /]
Without the credential property, rest are getting added properly.
How can I fix this ?
You have to add credential a bit later, you should try something like:
/subsystem=keycloak/securedeployment=my.war/:add(realm=bkofc,auth-server-url=http://192.168.99.100/30001/auth, bearer-only=true, ssl-required=EXTERNAL, resource=bkofc-svc, use-resource-role-mappings=true)
/subsystem=keycloak/secure-deployment=my.war/credential=secret:add(value="9bcc6d9f-9c72-4b58-b297-79f0f207d9e1")
Related
I am trying to migrate WildFly 21 to 24 .
I have these errors in the console. Server can not running it is stopped.
14:11:19,550 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=microprofile-health-smallrye' are not available:
org.wildfly.extension.health.http-context; There are no known registration points which can provide this capability.
org.wildfly.extension.health.server-probes; There are no known registration points which can provide this capability. 14:11:19,550 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=microprofile-metrics-smallrye' are not available:
org.wildfly.extension.metrics.http-context; There are no known registration points which can provide this capability.
I have added metrics and health extensions to standalone xmls
<extension module="org.wildfly.extension.microprofile.health-smallrye"/>
<extension module="org.wildfly.extension.microprofile.metrics-smallrye"/>
<subsystem xmlns="urn:wildfly:microprofile-health-smallrye:2.0" security-enabled="false" empty-liveness-checks-status="${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}" empty-readiness-checks-status="${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}"/>
<subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>
but for main configuration file I am using a different xml.
I saw in another questions using jboss.cli to add these extensions but jboss cli is not connecting because server can not running currently.
Do you have any suggestions or advices ?
Thanks.
You can still use CLI in "offline" mode to add the extension. First simply enter a CLI session with:
$JBOSS_HOME/bin/jboss-cli.sh
Then you can start the embedded server to make your changes.
embed-server
You should end up seeing something like this:
[disconnected /] embed-server
[standalone#embedded /]
From here you can enter CLI commands like:
/extension=org.wildfly.extension.microprofile.health-smallrye:add
/extension=org.wildfly.extension.microprofile.metrics-smallrye:add
/subsystem=microprofile-health-smallrye:add(security-enabled=false, empty-liveness-checks-status="${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}", empty-readiness-checks-status="${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}")
The output should look something like:
[standalone#embedded /] /extension=org.wildfly.extension.microprofile.health-smallrye:add
{"outcome" => "success"}
[standalone#embedded /] /extension=org.wildfly.extension.microprofile.metrics-smallrye:add
{"outcome" => "success"}
[standalone#embedded /] /subsystem=microprofile-health-smallrye:add(security-enabled=false, empty-liveness-checks-status="${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}", empty-readiness-checks-status="${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}")
{"outcome" => "success"}
Then you can just exit CLI.
I found out microprofile.health-smallrye and microprofile.metrics-smallrye are not supported in WildFly 24. You should use subsystem=metrics,subsystem=health.
If you look into this in detail check here.
I started wildfly 24 server with standalone-full.xml profile, when i run following command in jboss-cli to create jms-queue i get following error
[standalone#localhost:9990 /] jms-queue --profile=full add --queue-address=foo --entries=["java:/jms/queue/foo"]
WFLYCTL0175: Resource [
("subsystem" => "messaging-activemq"),
("server" => "default")
] does not exist; a resource at address [
("subsystem" => "messaging-activemq"),
("server" => "default"),
("jms-queue" => "foo")
] cannot be created until all ancestor resources have been added
What am i missing here? Any reference docs to create the jms server, queues?
Update:
I tried to create the server using web console first
And it filed with the required capabilities are not available, any documentation refernece that indicates what are the required capabilities i need to added prior configuring JMS
Yes don't use the profile parameter which is used in domain mode.
jms-queue add --queue-address=foo --entries=["java:/jms/queue/foo"]
works properly.
The issue is i was using wildfly "WildFly Preview EE 9.1 Distribution" the correct verirsion is "Jakarta EE 8 Full & Web Distribution"
I'm trying to configure SSL for Kafka Connect REST API (2.11-2.1.0).
The problem
I tried two configurations (worker config):
with listeners.https. prefix
listeners=https://localhost:9000
listeners.https.ssl.keystore.location=/mypath/keystore.jks
listeners.https.ssl.keystore.password=mypassword
listeners.https.ssl.key.password=mypassword
and without listeners.https. prefix
listeners=https://localhost:9000
ssl.keystore.location=/mypath/keystore.jks
ssl.keystore.password=mypassword
ssl.key.password=mypassword
Both configurations starts OK, and show following exception when trying to connect to https://localhost:9000 :
javax.net.ssl.SSLHandshakeException: no cipher suites in common
In log, I see that SslContextFactory was created with any keystore, but with ciphers:
210824 ssl.SslContextFactory:350 DEBUG: Selected Protocols [TLSv1.2, TLSv1.1, TLSv1] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]
210824 ssl.SslContextFactory:351 DEBUG: Selected Ciphers [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, ...]
210824 component.AbstractLifeCycle:177 DEBUG: STARTED #10431ms SslContextFactory#42f8285e[provider=null,keyStore=null,trustStore=null]
What I did
As I know that password from keystore is absolutely correct, I digged into source code, and started to debug.
Finally, I find out that neither plain ssl.* nor prefixed listeners.https.ssl.* configurations are not taken into account, and it turns that there is not possibility to configure SSL for Kafka Connect REST API currently.
Call sequence is:
RestServer.createConnector
SSLUtils.createSslContextFactory
AbstractConfig.valuesWithPrefixAllOrNothing
Last method is the reason of troubles.
If we have listeners.https. properties, they cannot be returned, because they filtered out at line 254 (since WorkerConfig contains no properties with the prefix).
Otherwise, if we have unprefixed ssl. properties, they also not returned, because values field contains only known properties from the same WorkerConfig (values are result of ConfigDef.parse).
Am I missing something, and has anyone successfully configured SSL for kafka connect rest api ?
Try export KAFKA_OPTS=-Djava.security.auth.login.config=/apps/kafka/conf/kafka/kf_jaas.conf where kf_jaas.conf contains ZooKeeper client authentication
I haven't test Connect REST API, but KafkaTemplate send and recieves messages with ssl.
From your configuration i may assume two problems:
you not specified the truststore (for certificate chain check)
you used absolute path, but spring keystore-location interprets as
relative to /webapp
I tried test application from examples:
https://memorynotfound.com/spring-kafka-and-spring-boot-configuration-example/
and
https://gist.github.com/itzg/e3ebfd7aec220bf0522e23a65b1296c8
Tested with springboot 2.0.4.RELEASE, used kafka library
<dependency>
<groupId>org.springframework.kafka</groupId>
<artifactId>spring-kafka</artifactId>
</dependency>
and this my application.properties content:
spring.application.name=my-stream-app
spring.kafka.bootstrap-servers=localhost:9093
spring.kafka.ssl.truststore-location=kafka.server.truststore.jks
spring.kafka.ssl.truststore-password=123456
spring.kafka.ssl.keystore-location=kafka.server.keystore.jks
spring.kafka.ssl.keystore-password=123456
spring.kafka.ssl.key-password=123456
spring.kafka.properties.security.protocol=SSL
spring.kafka.consumer.group-id=properties test-consumer-group
app.topic.foo=test
fragment of kafka server configuration:
listeners=SSL://localhost:9093
ssl.truststore.location=/home/legioner/kafka.server.truststore.jks
ssl.truststore.password=123456
ssl.keystore.location=/home/legioner/kafka.server.keystore.jks
ssl.keystore.password=123456
ssl.key.password=123456
We changed the configuration of our WebLogic servers to use HTTPS and T3S for connections and use the secure encrypted port 9002 instead of cleartext port 7001. However when using the Web Logic Scripting Tool (WLST)'s connect() function, errors are thrown. One such error is as follows:
WLSTException: Error occurred while performing connect : Cannot connect via t3s or https. If using demo certs, verify that the -Dweblogic.security.TrustKeyStore=DemoTrust system property is set. : t3s://DatServer:9002: Destination 10.10.100.3, 9002 unreachable; nested exception is:
javax.net.ssl.SSLHandshakeException: General SSLEngine problem; No available router to destination
Use dumpStack() to view the full stacktrace :
The syntax of the connect function is: connect('user', 'password', 't3s://host:9002')
This connect() function works fine before the switch from HTTP to HTTPS. Now we cannot connect to the remote admin server using the connect command. Does anyone have any idea how to fix this?
I read some interesting help options but none of them seemed to work. These help suggestions and tips are located here: https://community.oracle.com/thread/1036828
We were able to connect to the remote host and port via telnet. We saw that the port is open and listening for connections on the loop back address with netstat. We tried adding these options to the script invocation: java -cp /path/to/weblogic.jar weblogic.WLST -Dweblogic.security.TrustKeyStore=DemoTrust -Dssl.debug=true Dweblogic.security.SSL.ignoreHostnameVerification=true -Djava.security.egd=file:/dev/./urandom but this also did not work.
We enabled tunneling in the General tab of WebLogic but not in the HTTP tab. I am not the one in control of the server so I just have to suggest things and hope that the instructions are followed.
I get it running in 12.2. by adding to
../oracle_common/common/bin/setWlstEnv_internal.sh
at the end the following lines (youu need to customize line 5 und 6, the values in brackets):
JAVA_OPTIONS="-Dweblogic.ssl.JSSEEnabled=true ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.SSL.enableJSSE="true" ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.SSL.ignoreHostnameVerification=true ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.TrustKeyStore=CustomTrust ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.CustomTrustKeyStoreFileName= ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.CustomTrustKeyStorePassPhrase= ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.CustomTrustKeyStoreType=JKS ${JAVA_OPTIONS}"
export JAVA_OPTIONS
and modifying in
../oracle_common/common/bin/wlst_internal.sh
the line starting with
eval '"${JAVA_HOME}/bin/java"' ${JVM_ARGS} ...
by adding ${JAVA_OPTIONS}
so that it looks as follows:
eval '"${JAVA_HOME}/bin/java"' ${JVM_ARGS} ${JAVA_OPTIONS} weblogic.WLST '"$#"'
Hope this helps, allthough modifying scripts that are named "..internal.." doesn´t give me a good feeling
export this before running wlst.sh
export WLST_PROPERTIES=" -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/properties/truststore.jks -Dweblogic.security.CustomTrustKeyStoreType=jks -Dweblogic.security.CustomTrustKeyStorePassPhrase=qaz#1234 " ;
I am able to call :suspend and :resume from the cli, however, this suspends all beans (EJB, MDB). Is there a way to only suspend message driven beans MDBs?
In my application all the work comes in via messages. If I can suspend the message consumers, I can be sure that rest of the system will continue to work until all the work in progress is finished. For example if an EJB was trying to put a message on the queue it will be able to do so.
You can use the following CLI operations on the MDB. For details see https://docs.jboss.org/author/display/WFLY10/Message+Driven+Beans+Controlled+Delivery. Though the documentation is for WildFly 10; it also works with WildFly 9.x
For standalone mode:
[standalone#localhost:9990 /] cd deployment=jboss-helloworld-mdb.war/subsystem=ejb3/message-driven-bean=HelloWorldMDB
[standalone#localhost:9990 message-driven-bean=HelloWorldMDB] :stop-delivery
{"outcome" => "success"}
[standalone#localhost:9990 message-driven-bean=HelloWorldMDB] :start-delivery
{"outcome" => "success"}
For domain mode:
Stop delivery
/host=master/server=default/deployment=helloworld.app.war/subsystem=ejb3/message-driven-bean=HelloWorldMDB:stop-delivery
Start delivery:
/host=master/server=default/deployment=helloworld.app.war/subsystem=ejb3/message-driven-bean=HelloWorldMDB:start-delivery
If the MDB resides in an EJB jar inside an EAR file:
/host=master/server=default/deployment=helloworld.app.ear/subdeployment=helloworld.core.impl.jar/subsystem=ejb3/message-driven-bean=HelloWorldMDB:start-delivery