[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)
7 years, 5 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)
7 years, 5 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)
7 years, 5 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)
7 years, 5 months
[JBoss JIRA] (WFLY-7340) Unable to configure Krb5LoginModule options in elytron kerberos implementation
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7340?page=com.atlassian.jira.plugin.... ]
Jan Kalina closed WFLY-7340.
----------------------------
Resolution: Rejected
> Unable to configure Krb5LoginModule options in elytron kerberos implementation
> ------------------------------------------------------------------------------
>
> Key: WFLY-7340
> URL: https://issues.jboss.org/browse/WFLY-7340
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
>
> Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
> {code:java}
> if (debug) {
> options.put("debug", "true");
> }
> options.put("principal", principal);
> final AppConfigurationEntry ace;
> if (IS_IBM) {
> options.put("noAddress", "true");
> options.put("credsType", isServer ? "acceptor" : "initiator");
> options.put("useKeytab", keyTab.toURI().toURL().toString());
> ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
> } else {
> options.put("storeKey", "true");
> options.put("useKeyTab", "true");
> options.put("keyTab", keyTab.getAbsolutePath());
> options.put("isInitiator", isServer ? "false" : "true");
> ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
> }
> {code}
> ^ GSSCredentialSecurityFactory
> * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s...
> * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ELY-674) Unable to configure Krb5LoginModule options in elytron kerberos implementation
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-674?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina closed ELY-674.
--------------------------
Resolution: Rejected
> Unable to configure Krb5LoginModule options in elytron kerberos implementation
> ------------------------------------------------------------------------------
>
> Key: ELY-674
> URL: https://issues.jboss.org/browse/ELY-674
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
> {code:java}
> if (debug) {
> options.put("debug", "true");
> }
> options.put("principal", principal);
> final AppConfigurationEntry ace;
> if (IS_IBM) {
> options.put("noAddress", "true");
> options.put("credsType", isServer ? "acceptor" : "initiator");
> options.put("useKeytab", keyTab.toURI().toURL().toString());
> ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
> } else {
> options.put("storeKey", "true");
> options.put("useKeyTab", "true");
> options.put("keyTab", keyTab.getAbsolutePath());
> options.put("isInitiator", isServer ? "false" : "true");
> ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
> }
> {code}
> ^ GSSCredentialSecurityFactory
> * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/s...
> * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months