[JBoss JIRA] (WFCORE-2015) CLI is unable to connect to EAP with undefined security-realm
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2015?page=com.atlassian.jira.plugi... ]
Marek Kopecký moved JBEAP-7405 to WFCORE-2015:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2015 (was: JBEAP-7405)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
Affects Version/s: 3.0.0.Alpha12
(was: 7.1.0.DR8)
> CLI is unable to connect to EAP with undefined security-realm
> -------------------------------------------------------------
>
> Key: WFCORE-2015
> URL: https://issues.jboss.org/browse/WFCORE-2015
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 3.0.0.Alpha12
> Reporter: Marek Kopecký
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> *Description of problem:*
> CLI is unable to connect to EAP with undefined security-realm
> This is regression against EAP 7.0.0, 6.4.0 and 7.1.0.DR7.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
> # reload
> *Actual results:*
> {noformat}
> [mkopecky@dhcp-10-40-4-180 bin]$ ./jboss-cli.sh -c
> [standalone@localhost:9990 /] /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] reload
> Interrupted while pausing before reconnecting.: sleep interrupted
> [disconnected /]
> [mkopecky@dhcp-10-40-4-180 bin]$ ./jboss-cli.sh -c
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: Authentication failed: none of the mechanisms presented by the server are supported
> [mkopecky@dhcp-10-40-4-180 bin]$
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-7210:
-------------------------------
The nested undefined "sub-resource-locators" in this example is a valid use case which represents possible another layer of sub resource locators. :)
> Expose JAX-RS resources as children of the subsystem
> ----------------------------------------------------
>
> Key: WFLY-7210
> URL: https://issues.jboss.org/browse/WFLY-7210
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Lin Gao
> Attachments: after-wfly7024.png, hal-jaxrs.png
>
>
> Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean)
> This makes it specially easy to navigate trough the web console (attached screenshot).
> To read JAX-RS resources, the command would be:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources()
> I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7624) Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7624?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek updated WFLY-7624:
-------------------------------
Description:
There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. Opposite for {{credential-reference}}, see WFLY-7435.
was:
There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. Opposite for {{credential-reference}}, see JBEAP-6757.
> Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7624
> URL: https://issues.jboss.org/browse/WFLY-7624
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. Opposite for {{credential-reference}}, see WFLY-7435.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7624) Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7624?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek updated WFLY-7624:
-------------------------------
Description:
There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. Opposite for {{credential-reference}}, see JBEAP-6757.
was:
There are inconsistencies between DMR and XSD representation of {{key.-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. Opposite for {{credential-reference}}, see JBEAP-6757.
> Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7624
> URL: https://issues.jboss.org/browse/WFLY-7624
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. Opposite for {{credential-reference}}, see JBEAP-6757.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7624) Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7624?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-7402 to WFLY-7624:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7624 (was: JBEAP-7402)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
(was: User Experience)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR8)
> Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7624
> URL: https://issues.jboss.org/browse/WFLY-7624
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> There are inconsistencies between DMR and XSD representation of {{key.-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. Opposite for {{credential-reference}}, see JBEAP-6757.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7623) Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7623?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-7623:
-------------------------------
Description:
Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
*How to reproduce*
{code}
/subsystem=elytron/credential-store=credStore001:add(uri="cr-store://test/cs001.jceks?store.password=pass123;create.storage=true")
/subsystem=elytron/credential-store=credStore001/alias="alias1":add(secret-value=Elytron)
{code}
{code}
/subsystem=elytron/credential-store=credStore002:add(uri="cr-store://test/cs001.jceks?store.password=pass123")
{code}
check CS file
there is "alias1" entry
{code}
/subsystem=elytron/credential-store=credStore001/alias="alias2":add(secret-value=Elytron)
{code}
check CS file
there are "alias1" and "alias2" entries
{code}
/subsystem=elytron/credential-store=credStore002/alias="alias123":add(secret-value=Elytron)
{code}
check CS file
there are "alias1" and "alias123" entries".
*NOTE*
It is problem, because we have one backed file. In memory we have right values for all Credential Stores, but after restart we can lost new entries.
In my opinion reason for this behaviour is:
We have CS loaded in memory and when we add new alias to CS then we save whole CS from memory to file.
We can set CS as non-modifiable when we use same backed file for CredentialStore but we must find better default behaviour.
*My suggestion for default behaviour*
When we want to add new alias to CredentialStore we can do this:
# refresh CS from file (and this file lock)
# add new alias to CS
# save CS to file
# unlock file
*But there is posible problem with performance....*
was:
Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
*How to reproduce*
{code}
/subsystem=elytron/credential-store=credStore001:add(uri="cr-store://test/cs001.jceks?store.password=pass123;create.storage=true")
/subsystem=elytron/credential-store=credStore001/alias="alias1":add(secret-value=Elytron)
{code}
{code}
/subsystem=elytron/credential-store=credStore002:add(uri="cr-store://test/cs001.jceks?store.password=pass123")
{code}
check CS file
there is "alias1" entry
{code}
/subsystem=elytron/credential-store=credStore001/alias="alias2":add(secret-value=Elytron)
{code}
check CS file
there are "alias1" and "alias2" entries
{code}
/subsystem=elytron/credential-store=credStore002/alias="alias123":add(secret-value=Elytron)
{code}
check CS file
there are "alias1" and "alias123" entries".
*NOTE*
It is problem, because we have one backed file. In memory we have right values for all Credential Stores, but after restart we can lost new entries.
In my opinion reason for this behaviour is:
We have CS loaded in memory and when we add new alias to CS then we save whole CS from memory to file.
We can set CS as non-modifiable when we use same backed file for CredentialStore but we must find better default behaviour.
> Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-7623
> URL: https://issues.jboss.org/browse/WFLY-7623
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=credStore001:add(uri="cr-store://test/cs001.jceks?store.password=pass123;create.storage=true")
> /subsystem=elytron/credential-store=credStore001/alias="alias1":add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=credStore002:add(uri="cr-store://test/cs001.jceks?store.password=pass123")
> {code}
> check CS file
> there is "alias1" entry
> {code}
> /subsystem=elytron/credential-store=credStore001/alias="alias2":add(secret-value=Elytron)
> {code}
> check CS file
> there are "alias1" and "alias2" entries
> {code}
> /subsystem=elytron/credential-store=credStore002/alias="alias123":add(secret-value=Elytron)
> {code}
> check CS file
> there are "alias1" and "alias123" entries".
> *NOTE*
> It is problem, because we have one backed file. In memory we have right values for all Credential Stores, but after restart we can lost new entries.
> In my opinion reason for this behaviour is:
> We have CS loaded in memory and when we add new alias to CS then we save whole CS from memory to file.
> We can set CS as non-modifiable when we use same backed file for CredentialStore but we must find better default behaviour.
> *My suggestion for default behaviour*
> When we want to add new alias to CredentialStore we can do this:
> # refresh CS from file (and this file lock)
> # add new alias to CS
> # save CS to file
> # unlock file
> *But there is posible problem with performance....*
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6703) Failover intermittently fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
by Övünç Sezer (JIRA)
[ https://issues.jboss.org/browse/WFLY-6703?page=com.atlassian.jira.plugin.... ]
Övünç Sezer commented on WFLY-6703:
-----------------------------------
The problem was missing weld.properties file with option org.jboss.weld.serialization.beanIdentifierIndexOptimization=false.
> Failover intermittently fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6703
> URL: https://issues.jboss.org/browse/WFLY-6703
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Tomas Remes
>
> {noformat}
> 13:57:41,855 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /clusterbench/session: org.jboss.weld.exceptions.IllegalStateException: WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
> Expected hash: 1931672237
> Current index: BeanIdentifierIndex [hash=1185198536, indexed=13]
> 0: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-ejb.jar%HttpSession
> 1: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war%HttpSession
> 2: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-granular.war%HttpSession
> 3: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war%HttpSession
> 4: WELD%AbstractBuiltInBean%clusterbench-ee7.ear%HttpSession
> 5: WELD%AbstractBuiltInBean%com.sun.jsf-impl:main.additionalClasses%HttpSession
> 6: WELD%AbstractBuiltInBean%org.hibernate.validator.cdi:main.additionalClasses%HttpSession
> 7: WELD%AbstractBuiltInBean%org.jberet.jberet-core:main.additionalClasses%HttpSession
> 8: WELD%AbstractBuiltInBean%org.jboss.as.jsf:main.additionalClasses%HttpSession
> 9: WELD%AbstractBuiltInBean%org.jboss.resteasy.resteasy-cdi:main.additionalClasses%HttpSession
> 10: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
> 11: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
> 12: WELD%SessionBean%LocalStatefulSB%org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB
> at org.jboss.weld.context.http.HttpSessionContextImpl.checkBeanIdentifierIndexConsistency(HttpSessionContextImpl.java:101)
> at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:47)
> at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:23)
> at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:237)
> at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:245)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 13:57:41,941 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel server: [node1|2] (1) [node1]
> 13:57:41,942 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel web: [node1|2] (1) [node1]
> 13:57:41,943 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel hibernate: [node1|2] (1) [node1]
> 13:57:41,944 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel ejb: [node1|2] (1) [node1]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7623) Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7623?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7623:
----------------------------------------
[~pskopek] Where did we get to re making it possible to inject a KeyStore instead of having the file definition in the CredentialStore?
> Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-7623
> URL: https://issues.jboss.org/browse/WFLY-7623
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=credStore001:add(uri="cr-store://test/cs001.jceks?store.password=pass123;create.storage=true")
> /subsystem=elytron/credential-store=credStore001/alias="alias1":add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=credStore002:add(uri="cr-store://test/cs001.jceks?store.password=pass123")
> {code}
> check CS file
> there is "alias1" entry
> {code}
> /subsystem=elytron/credential-store=credStore001/alias="alias2":add(secret-value=Elytron)
> {code}
> check CS file
> there are "alias1" and "alias2" entries
> {code}
> /subsystem=elytron/credential-store=credStore002/alias="alias123":add(secret-value=Elytron)
> {code}
> check CS file
> there are "alias1" and "alias123" entries".
> *NOTE*
> It is problem, because we have one backed file. In memory we have right values for all Credential Stores, but after restart we can lost new entries.
> In my opinion reason for this behaviour is:
> We have CS loaded in memory and when we add new alias to CS then we save whole CS from memory to file.
> We can set CS as non-modifiable when we use same backed file for CredentialStore but we must find better default behaviour.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
