[JBoss JIRA] (WFLY-10861) MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10861?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda edited comment on WFLY-10861 at 8/24/18 3:53 AM:
-------------------------------------------------------------------
*Web console* - I looked at http://localhost:9990/console and I didn't get redirected to the "help" page http://localhost:9990/error/index.html so I would be notified about adding user.
But I knew what I have to do :) So I added user via {{bin/add-user.sh -s -u admin -p admin.password}}.
Bu to my surprise the password wasn't working when accessing http://localhost:9990/console
The only way is to restart the server. This is mess, PicketBox can handle this case, no need for restarts.
So it's apparent that Elytron is caching the content of mgmt-users.properties. So I went ahead and removed previously defined user and tried {{curl -v --digest -u admin:admin.password http://localhost:9990/health}}
I received valid HTTP/1.1 200 OK response instead of HTTP/1.1 401 Unauthorized.
So server restart/reload is needed when Elytron is used.
Another observation for PicketBox vs. Elytron is that Elytron is really verbose and *curl output* is much longer
PicketBox case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:47:49 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
Elytron case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Connection: keep-alive
< WWW-Authenticate: Digest realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth
< Content-Length: 77
< Content-Type: text/html
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Ignoring the response-body
* Connection #0 to host localhost left intact
* Issue another request to this URL: 'http://localhost:9990/health'
* Found bundle for host localhost: 0x7fa212806370 [can pipeline]
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> Authorization: Digest username="admin", realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", uri="/health", cnonce="NzZlYTJmNTk3YjQwNTIwOTBkZTQ1MWY2MWVhNWU0ZjY=", nc=00000001, qop=auth, response="f00379076346017ab8d81291d82bcb1e", opaque="00000000000000000000000000000000", algorithm="MD5"
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
was (Author: rsvoboda):
I looked now at http://localhost:9990/console and I didn't get redirected to the "help" page http://localhost:9990/error/index.html so I would be notified about adding user.
But I knew what I have to do :) So I added user via {{bin/add-user.sh -s -u admin -p admin.password}}.
Bu to my surprise the password wasn't working when accessing http://localhost:9990/console
The only way is to restart the server. This is mess, PicketBox can handle this case, no need for restarts.
So it's apparent that Elytron is caching the content of mgmt-users.properties. So I went ahead and removed previously defined user and tried {{curl -v --digest -u admin:admin.password http://localhost:9990/health}}
I received valid HTTP/1.1 200 OK response instead of HTTP/1.1 401 Unauthorized.
So server restart/reload is needed when Elytron is used.
Another observation for PicketBox vs. Elytron is that Elytron is really verbose and curl output is long
PicketBox case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:47:49 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
Elytron case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Connection: keep-alive
< WWW-Authenticate: Digest realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth
< Content-Length: 77
< Content-Type: text/html
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Ignoring the response-body
* Connection #0 to host localhost left intact
* Issue another request to this URL: 'http://localhost:9990/health'
* Found bundle for host localhost: 0x7fa212806370 [can pipeline]
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> Authorization: Digest username="admin", realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", uri="/health", cnonce="NzZlYTJmNTk3YjQwNTIwOTBkZTQ1MWY2MWVhNWU0ZjY=", nc=00000001, qop=auth, response="f00379076346017ab8d81291d82bcb1e", opaque="00000000000000000000000000000000", algorithm="MD5"
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
> MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10861
> URL: https://issues.jboss.org/browse/WFLY-10861
> Project: WildFly
> Issue Type: Bug
> Components: Management, MP Health
> Reporter: Rostislav Svoboda
> Assignee: Kabir Khan
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> ----
> Kabir edit: the full command is:
> /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
> ----
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing if user is not yet so familiar with WildFly.
> -I marked this as minor bug.- ... see comments
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10861) MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10861?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda commented on WFLY-10861:
------------------------------------------
[~mjurc] [~msvehla] [~mchoma] fyi ^^^
> MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10861
> URL: https://issues.jboss.org/browse/WFLY-10861
> Project: WildFly
> Issue Type: Bug
> Components: Management, MP Health
> Reporter: Rostislav Svoboda
> Assignee: Kabir Khan
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> ----
> Kabir edit: the full command is:
> /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
> ----
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing if user is not yet so familiar with WildFly.
> -I marked this as minor bug.- ... see comments
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10861) MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10861?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda commented on WFLY-10861:
------------------------------------------
I looked now at http://localhost:9990/console and I didn't get redirected to the "help" page http://localhost:9990/error/index.html so I would be notified about adding user.
But I knew what I have to do :) So I added user via {{bin/add-user.sh -s -u admin -p admin.password}}.
Bu to my surprise the password wasn't working when accessing http://localhost:9990/console
The only way is to restart the server. This is mess, PicketBox can handle this case, no need for restarts.
So it's apparent that Elytron is caching the content of mgmt-users.properties. So I went ahead and removed previously defined user and tried {{curl -v --digest -u admin:admin.password http://localhost:9990/health}}
I received valid HTTP/1.1 200 OK response instead of HTTP/1.1 401 Unauthorized.
So server restart/reload is needed when Elytron is used.
Another observation for PicketBox vs. Elytron is that Elytron is really verbose and curl output is long
PicketBox case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:47:49 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
Elytron case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Connection: keep-alive
< WWW-Authenticate: Digest realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth
< Content-Length: 77
< Content-Type: text/html
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Ignoring the response-body
* Connection #0 to host localhost left intact
* Issue another request to this URL: 'http://localhost:9990/health'
* Found bundle for host localhost: 0x7fa212806370 [can pipeline]
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> Authorization: Digest username="admin", realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", uri="/health", cnonce="NzZlYTJmNTk3YjQwNTIwOTBkZTQ1MWY2MWVhNWU0ZjY=", nc=00000001, qop=auth, response="f00379076346017ab8d81291d82bcb1e", opaque="00000000000000000000000000000000", algorithm="MD5"
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
> MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10861
> URL: https://issues.jboss.org/browse/WFLY-10861
> Project: WildFly
> Issue Type: Bug
> Components: Management, MP Health
> Reporter: Rostislav Svoboda
> Assignee: Kabir Khan
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> ----
> Kabir edit: the full command is:
> /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
> ----
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing if user is not yet so familiar with WildFly.
> -I marked this as minor bug.- ... see comments
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ]
Matej Novotny reassigned WFLY-9631:
-----------------------------------
Assignee: (was: Matej Novotny)
> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
> Key: WFLY-9631
> URL: https://issues.jboss.org/browse/WFLY-9631
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
> Reporter: Marián Macik
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it? For further configuration details, check the Environment field.
> Thank you very much!
> Marian Macik
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10861) MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10861?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda commented on WFLY-10861:
------------------------------------------
https://github.com/wildfly/wildfly/pull/11566 contains test coverage for secured endpoint scenarios.
WFCORE-4045 works fine for default configuration aka security impl by PicketBox
When switching to Elytron testcase MicroProfileHealthSecuredHTTPEndpointEmptyMgmtUsersTestCase fails
java.lang.AssertionError: expected:<500> but was:<401>
401 means Unauthorized
I tried following scenario:
* https://github.com/wildfly/wildfly/blob/master/testsuite/shared/enable-el...
* /subsystem=microprofile-health-smallrye/:write-attribute(name=security-enabled, value=true)
* start the server
* curl -v http://localhost:9990/health
Response is 'HTTP/1.1 401 Unauthorized'.
So there is difference in behavior between PicketBox vs. Elytron.
Elytron goes to 401 Unauthorized and skips the "help" page with details that user must be added first.
[~jmesnil] [~dlofthouse] [~brian.stansberry] fyi
> MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10861
> URL: https://issues.jboss.org/browse/WFLY-10861
> Project: WildFly
> Issue Type: Bug
> Components: Management, MP Health
> Reporter: Rostislav Svoboda
> Assignee: Kabir Khan
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> ----
> Kabir edit: the full command is:
> /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
> ----
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing if user is not yet so familiar with WildFly.
> -I marked this as minor bug.- ... see comments
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10808) Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10808?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned WFLY-10808:
-----------------------------------------
Assignee: Bartosz Baranowski
> Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10808
> URL: https://issues.jboss.org/browse/WFLY-10808
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Reporter: Joshua Swett
> Assignee: Bartosz Baranowski
> Priority: Minor
> Attachments: TestWAR.war
>
>
> The jboss-ejb-client.xml deployment descriptor file can be used to configure the pass semantics of the local EJB receiver using the local-receiver-pass-by-value attribute.
> As per the EJB spec, the default behaviour should be to pass by value, and this is appropriately reflected in the jboss-ejb-client XSD. As of Wildfly 11, the *omission* of the local-receiver-pass-by-value attribute in a jboss-ejb-client deployment descriptor actually results in remote EJB parameters and the return value being passed by reference as opposed to the documented default of being passed by value.
> It appears that this bug is a result of changes made for WFLY-5403. The root cause is that the EJBClientDescriptorMetaDataProcessor.java class only uses the pass-by-value receiver if the local-receiver-pass-by-value attribute is Boolean.TRUE (line 177 in 13.0.0.Final), but EJBClientDescriptor10Parser.java defaults the value to null if it is not included in the jboss-ejb-client.xml (line 132 in 13.0.0.Final). The old and working behaviour was to fallback to the value configured at the ejb subsystem level if the jboss-ejb-client.xml excluded the attribute.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10914) Ldaps tests failing on IBM
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-10914?page=com.atlassian.jira.plugin... ]
Martin Choma commented on WFLY-10914:
-------------------------------------
There is SSLHandshake Exception during ldaps connection
{code}
test3
08:12:49,257 TRACE [org.jboss.security] (default task-1) PBOX00354: Setting security roles ThreadLocal: null
08:12:49,259 TRACE [org.jboss.security] (default task-1) PBOX00354: Setting security roles ThreadLocal: null
08:12:49,260 TRACE [org.jboss.security] (default task-1) PBOX00200: Begin isValid, principal: org.wildfly.extension.undertow.security.AccountImpl$AccountPrincipal@41a318e9, cache entry: null
08:12:49,261 TRACE [org.jboss.security] (default task-1) PBOX00209: defaultLogin, principal: org.wildfly.extension.undertow.security.AccountImpl$AccountPrincipal@41a318e9
08:12:49,261 TRACE [org.jboss.security] (default task-1) PBOX00221: Begin getAppConfigurationEntry(test-DEP3), size: 13
08:12:49,261 TRACE [org.jboss.security] (default task-1) PBOX00224: End getAppConfigurationEntry(test-DEP3), AuthInfo: AppConfigurationEntry[]:
[0]
LoginModule Class: org.jboss.security.negotiation.AdvancedLdapLoginModule
ControlFlag: LoginModuleControlFlag: required
Options:
name=java.naming.factory.initial, value=com.sun.jndi.ldap.LdapCtxFactory
name=java.naming.provider.url, value=ldaps://127.0.0.1:10636
name=referralUserAttributeIDToCheck, value=member
name=rolesCtxDN, value=ou=Roles,o=example3,dc=jboss,dc=org
name=roleFilter, value=(|(objectClass=referral)(member={1}))
name=roleAttributeID, value=cn
name=java.naming.security.authentication, value=simple
name=bindDN, value=uid=admin,ou=system
name=bindCredential, value=****
name=java.naming.referral, value=follow
name=baseCtxDN, value=ou=People,o=example3,dc=jboss,dc=org
name=throwValidateError, value=true
name=baseFilter, value=(|(objectClass=referral)(cn={0}))
08:12:49,261 TRACE [org.jboss.security] (default task-1) PBOX00236: Begin initialize method
08:12:49,261 WARN [org.jboss.security] (default task-1) PBOX00234: Invalid or misspelled module option: throwValidateError
08:12:49,261 TRACE [org.jboss.security] (default task-1) PBOX00240: Begin login method
08:12:49,261 TRACE [org.jboss.security.auth.spi.AbstractServerLoginModule] (default task-1) Identity - Java Duke
08:12:49,261 TRACE [org.jboss.security.auth.spi.AbstractServerLoginModule] (default task-1) Logging into LDAP server, env={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.referral=follow, java.naming.security.principal=uid=admin,ou=system, baseCtxDN=ou=People,o=example3,dc=jboss,dc=org, roleAttributeID=cn, roleFilter=(|(objectClass=referral)(member={1})), rolesCtxDN=ou=Roles,o=example3,dc=jboss,dc=org, referralUserAttributeIDToCheck=member, baseFilter=(|(objectClass=referral)(cn={0})), jboss.security.security_domain=test-DEP3, throwValidateError=true, java.naming.provider.url=ldaps://127.0.0.1:10636, bindDN=uid=admin,ou=system, java.naming.security.authentication=simple, bindCredential=***, java.naming.security.credentials=***}
08:12:49,425 DEBUG [org.jboss.security.auth.spi.AbstractServerLoginModule] (default task-1) Login failed: javax.security.auth.login.LoginException: Unable to create new InitialLdapContext
at org.jboss.security.negotiation.AdvancedLdapLoginModule.constructLdapContext(AdvancedLdapLoginModule.java:499)
at org.jboss.security.negotiation.AdvancedLdapLoginModule.innerLogin(AdvancedLdapLoginModule.java:386)
at org.jboss.security.negotiation.AdvancedLdapLoginModule$AuthorizeAction.run(AdvancedLdapLoginModule.java:981)
at org.jboss.security.negotiation.AdvancedLdapLoginModule.login(AdvancedLdapLoginModule.java:331)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:788)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:196)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
at java.security.AccessController.doPrivileged(AccessController.java:696)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:696)
at javax.security.auth.login.LoginContext.login(LoginContext.java:597)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:123)
at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:94)
at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:268)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$733.00000000680A1620.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$734.00000000680A2680.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$734.00000000680A2680.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$734.00000000680A2680.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$734.00000000680A2680.call(Unknown Source)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:811)
Caused by: javax.naming.CommunicationException: 127.0.0.1:10636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:250)
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:149)
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1627)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2761)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:331)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:204)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:222)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:165)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:95)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:165)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324)
at javax.naming.InitialContext.init(InitialContext.java:255)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:165)
at org.jboss.security.negotiation.AdvancedLdapLoginModule.constructLdapContext(AdvancedLdapLoginModule.java:495)
... 69 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present
at com.ibm.jsse2.k.a(k.java:15)
at com.ibm.jsse2.av.a(av.java:531)
at com.ibm.jsse2.D.a(D.java:68)
at com.ibm.jsse2.D.a(D.java:628)
at com.ibm.jsse2.E.a(E.java:803)
at com.ibm.jsse2.E.a(E.java:447)
at com.ibm.jsse2.D.r(D.java:139)
at com.ibm.jsse2.D.a(D.java:485)
at com.ibm.jsse2.av.a(av.java:717)
at com.ibm.jsse2.av.i(av.java:869)
at com.ibm.jsse2.av.a(av.java:19)
at com.ibm.jsse2.av.startHandshake(av.java:672)
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:406)
at com.sun.jndi.ldap.Connection.<init>(Connection.java:227)
... 87 more
Caused by: java.security.cert.CertificateException: No subject alternative names present
at com.ibm.jsse2.util.b.b(b.java:104)
at com.ibm.jsse2.util.b.a(b.java:88)
at com.ibm.jsse2.aD.a(aD.java:165)
at com.ibm.jsse2.aD.a(aD.java:168)
at com.ibm.jsse2.aD.a(aD.java:211)
at com.ibm.jsse2.aD.checkServerTrusted(aD.java:162)
at com.ibm.jsse2.E.a(E.java:831)
... 96 more
{code}
which reminds me latest jdk ldaps change: https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.htm...
Setting -Dcom.sun.jndi.ldap.object.disableEndpointIdentification on server really helped. Strange is it does not occure on oracle jdk though.
> Ldaps tests failing on IBM
> --------------------------
>
> Key: WFLY-10914
> URL: https://issues.jboss.org/browse/WFLY-10914
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 14.0.0.Beta2
> Reporter: Martin Choma
> Assignee: Martin Choma
>
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLikeAdvancedLdapLMTestCase.test3
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLikeAdvancedLdapLMTestCase.test4
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test2
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test3
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test4
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test2throw
> * org.jboss.as.test.integration.security.loginmodules.LdapLoginModuleTestCase.testLdaps
> * org.jboss.as.test.manualmode.security.OutboundLdapConnectionClientCertTestCase.test
> * org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase.test
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10914) Ldaps tests failing on IBM
by Martin Choma (JIRA)
Martin Choma created WFLY-10914:
-----------------------------------
Summary: Ldaps tests failing on IBM
Key: WFLY-10914
URL: https://issues.jboss.org/browse/WFLY-10914
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 14.0.0.Beta2
Reporter: Martin Choma
* org.jboss.as.test.integration.security.loginmodules.LdapExtLikeAdvancedLdapLMTestCase.test3
* org.jboss.as.test.integration.security.loginmodules.LdapExtLikeAdvancedLdapLMTestCase.test4
* org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test2
* org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test3
* org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test4
* org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test2throw
* org.jboss.as.test.integration.security.loginmodules.LdapLoginModuleTestCase.testLdaps
* org.jboss.as.test.manualmode.security.OutboundLdapConnectionClientCertTestCase.test
* org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase.test
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10914) Ldaps tests failing on IBM
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-10914?page=com.atlassian.jira.plugin... ]
Martin Choma reassigned WFLY-10914:
-----------------------------------
Assignee: Martin Choma
> Ldaps tests failing on IBM
> --------------------------
>
> Key: WFLY-10914
> URL: https://issues.jboss.org/browse/WFLY-10914
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 14.0.0.Beta2
> Reporter: Martin Choma
> Assignee: Martin Choma
>
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLikeAdvancedLdapLMTestCase.test3
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLikeAdvancedLdapLMTestCase.test4
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test2
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test3
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test4
> * org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase.test2throw
> * org.jboss.as.test.integration.security.loginmodules.LdapLoginModuleTestCase.testLdaps
> * org.jboss.as.test.manualmode.security.OutboundLdapConnectionClientCertTestCase.test
> * org.jboss.as.test.manualmode.security.OutboundLdapConnectionTestCase.test
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months