[JBoss JIRA] (WFLY-7709) standalone-minimalistic.xml config got left behind
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-7709?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky updated WFLY-7709:
------------------------------------
Description:
Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
These operations are executed when the minimalistic config is loaded:
{code}
/core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
/socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
/core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
/core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
/socket-binding-group=standard-sockets:add(default-interface="public")
{code}
These operations are executed as part of the default core config:
{code}
/core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
/socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
/core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
/socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
{code}
was:
Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
These operations are executed when the minimalistic config is loaded:
/core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
/socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
/core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
/core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
/socket-binding-group=standard-sockets:add(default-interface="public")
These operations are executed as part of the default core config:
/core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
/socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
/core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
/socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
> standalone-minimalistic.xml config got left behind
> --------------------------------------------------
>
> Key: WFLY-7709
> URL: https://issues.jboss.org/browse/WFLY-7709
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.1.0.Final
> Reporter: Alexey Loubyansky
> Assignee: Brian Stansberry
>
> Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
> These operations are executed when the minimalistic config is loaded:
> {code}
> /core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
> /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
> /socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
> /core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
> /core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
> /socket-binding-group=standard-sockets:add(default-interface="public")
> {code}
> These operations are executed as part of the default core config:
> {code}
> /core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
> /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
> /socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
> /core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
> /socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7709) standalone-minimalistic.xml config got left behind
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-7709:
---------------------------------------
Summary: standalone-minimalistic.xml config got left behind
Key: WFLY-7709
URL: https://issues.jboss.org/browse/WFLY-7709
Project: WildFly
Issue Type: Bug
Components: Domain Management
Affects Versions: 10.1.0.Final
Reporter: Alexey Loubyansky
Assignee: Brian Stansberry
Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
These operations are executed when the minimalistic config is loaded:
/core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
/socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
/core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
/core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
/socket-binding-group=standard-sockets:add(default-interface="public")
These operations are executed as part of the default core config:
/core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
/socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
/core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
/socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7708) support specifying the runtime-name in the deployment descriptor
by Gregor Rosenauer (JIRA)
[ https://issues.jboss.org/browse/WFLY-7708?page=com.atlassian.jira.plugin.... ]
Gregor Rosenauer updated WFLY-7708:
-----------------------------------
Priority: Minor (was: Major)
> support specifying the runtime-name in the deployment descriptor
> ----------------------------------------------------------------
>
> Key: WFLY-7708
> URL: https://issues.jboss.org/browse/WFLY-7708
> Project: WildFly
> Issue Type: Enhancement
> Components: EE
> Affects Versions: 9.0.2.Final
> Environment: Java EE 7
> Reporter: Gregor Rosenauer
> Priority: Minor
> Labels: EE, deployment, descriptor
>
> There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name.
> The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension.
> This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable.
> As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7708) support specifying the runtime-name in the deployment descriptor
by Gregor Rosenauer (JIRA)
Gregor Rosenauer created WFLY-7708:
--------------------------------------
Summary: support specifying the runtime-name in the deployment descriptor
Key: WFLY-7708
URL: https://issues.jboss.org/browse/WFLY-7708
Project: WildFly
Issue Type: Enhancement
Components: EE
Affects Versions: 9.0.2.Final
Environment: Java EE 7
Reporter: Gregor Rosenauer
There is often a need to change the name of a deployment, e.g. the EAR, from the default name to a stable name.
The problem is that common Maven practice mandates a version suffix, generating a fully versioned EAR. Wildfly by default (which is only changable from CLI/management console) takes the full name without the extension.
This leads to clunky and brittle code, e.g. JNDI lookups *have* to use the full name including version, which is most often undesirable.
As suggested in https://developer.jboss.org/thread/213914 I am creating this issue now,-)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7295) Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7295:
----------------------------------
Should be transformed into documentation issue.
> Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------
>
> Key: WFLY-7295
> URL: https://issues.jboss.org/browse/WFLY-7295
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 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.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 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:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> ... 45 more
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> ... 67 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7334) Elytron kerberos implementation ignore java.security.krb5.* system properties
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.... ]
Jan Kalina closed WFLY-7334.
----------------------------
Resolution: Done
> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
> Key: WFLY-7334
> URL: https://issues.jboss.org/browse/WFLY-7334
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code}
> -Djava.security.krb5.conf=/unreal/path -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
> <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
> <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
> <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
> <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months