[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)
9 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)
9 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)
9 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)
9 years, 5 months
[JBoss JIRA] (JGRP-2139) Implement DNS-based PING
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/JGRP-2139?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated JGRP-2139:
--------------------------------------
Description:
DNS Discovery might be very useful in Cloud environments (such as Kubernetes or OpenShift). They expose Services (which act as Load Balancers and Clustered Virtual IPs for Pods (Docker Containers)) with DNS {{SRV}} entries using the following scheme: {{_port._proto.ENDPOINT.service.namespace.sv.cluster.local}} (see [this issue|https://github.com/kubernetes/kubernetes/issues/29420] for more information).
The implementation should also allow the following:
* Change the DNS Server address
* Change or override TTL values
* Change DNS record type (either {{A}} or {{SRV}}
** If the record type is {{SRV}}, it should also allow parting port
The implementation might be based on Oracle DNS tutorial: http://docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-dns.html
was:
DNS Discovery might be very useful in Cloud environments (such as Kubernetes or OpenShift). They expose Services (which act as Load Balancers and Clustered Virtual IPs for Pods (Docker Containers)) with DNS {{SRV}} entries using the following scheme: {{_port._proto.ENDPOINT.service.namespace.sv.cluster.local}} (see [this issue|https://github.com/kubernetes/kubernetes/issues/29420] for more information).
The implementation should also allow the following:
* Change the DNS Server address
* Change or override TTL values
* Change DNS record type (either {{A}} or {{SRV}}
** If the record type is {{SRV}}, it should also allow parting port
> Implement DNS-based PING
> ------------------------
>
> Key: JGRP-2139
> URL: https://issues.jboss.org/browse/JGRP-2139
> Project: JGroups
> Issue Type: Enhancement
> Environment: * OpenShift and Kubernetes (service discovery is done using SRV records)
> * Any other environment that use {{A}} or {{SRV}} DNS records
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
> DNS Discovery might be very useful in Cloud environments (such as Kubernetes or OpenShift). They expose Services (which act as Load Balancers and Clustered Virtual IPs for Pods (Docker Containers)) with DNS {{SRV}} entries using the following scheme: {{_port._proto.ENDPOINT.service.namespace.sv.cluster.local}} (see [this issue|https://github.com/kubernetes/kubernetes/issues/29420] for more information).
> The implementation should also allow the following:
> * Change the DNS Server address
> * Change or override TTL values
> * Change DNS record type (either {{A}} or {{SRV}}
> ** If the record type is {{SRV}}, it should also allow parting port
> The implementation might be based on Oracle DNS tutorial: http://docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-dns.html
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2139) Implement DNS-based PING
by Sebastian Łaskawiec (JIRA)
Sebastian Łaskawiec created JGRP-2139:
-----------------------------------------
Summary: Implement DNS-based PING
Key: JGRP-2139
URL: https://issues.jboss.org/browse/JGRP-2139
Project: JGroups
Issue Type: Enhancement
Environment: * OpenShift and Kubernetes (service discovery is done using SRV records)
* Any other environment that use {{A}} or {{SRV}} DNS records
Reporter: Sebastian Łaskawiec
Assignee: Sebastian Łaskawiec
DNS Discovery might be very useful in Cloud environments (such as Kubernetes or OpenShift). They expose Services (which act as Load Balancers and Clustered Virtual IPs for Pods (Docker Containers)) with DNS {{SRV}} entries using the following scheme: {{_port._proto.ENDPOINT.service.namespace.sv.cluster.local}} (see [this issue|https://github.com/kubernetes/kubernetes/issues/29420] for more information).
The implementation should also allow the following:
* Change the DNS Server address
* Change or override TTL values
* Change DNS record type (either {{A}} or {{SRV}}
** If the record type is {{SRV}}, it should also allow parting port
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months