[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)
7 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)
7 years, 5 months
[JBoss JIRA] (JGRP-2137) JGroups: one slow/stuck node slows/freezes entire cluster
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2137?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2137:
--------------------------------
If you do that, please don't forget to create a JIRA for 3.6.12, so we keep track of this.
> JGroups: one slow/stuck node slows/freezes entire cluster
> ---------------------------------------------------------
>
> Key: JGRP-2137
> URL: https://issues.jboss.org/browse/JGRP-2137
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Multi node cluster. Uses TUNNEL mode with GossipRouter, TCP.
> Reporter: Bharad S
> Assignee: Bela Ban
> Attachments: replication-server.xml
>
>
> We have a multi node cluster with one node (say Node A) running the gossip router. We use TUNNEL mode, i.e., other nodes in cluster can talk to each other only via Node A. If one of the nodes in the cluster (say Node B) is slow in reading or gets stuck while reading from the channel, it affects the entire cluster. Inter node gossip also gets stuck and the nodes fall out of cluster.
> Thread dump on Node A indicate that 'ConnectionHandler' for node B stuck (at SocketOutputStream.socketWrite) while it is holding on to a lock, thus blocking ConnectionHandlers for all other nodes.
> --snip (from thread dump on Node A) --
> "gossip-handlers-129" #1088 daemon prio=5 os_prio=0 tid=0x00007f65d20ce800 nid=0x2353 runnable [0x00007f6557efd000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
> at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
> at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
> at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:857)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:828)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> - locked <0x00000005f2445028> (a sun.security.ssl.AppOutputStream)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> - locked <0x00000005f248a210> (a java.io.BufferedOutputStream)
> at java.io.DataOutputStream.flush(DataOutputStream.java:123)
> at org.jgroups.stack.GossipRouter.sendToMember(GossipRouter.java:607)
> - locked <0x00000005f248a1f0> (a java.io.DataOutputStream)
> at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:590)
> - locked <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap)
> at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487)
> at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706)
> at java.lang.Thread.run(Thread.java:745)
> --snip end--
> Other gossip-handler threads (meant for other nodes in the cluster) on Node A wait for acquiring lock on the ConnectionHandler map at following place: GossipRouter.java, method: sendToAllMembersInGroup
> --snip--
> "gossip-handlers-128"
> #1078 daemon prio=5 os_prio=0 tid=0x00007f65d20ce000 nid=0x2343 waiting
> for monitor entry [0x00007f654c258000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:583)
> - waiting to lock <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap)
> at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487)
> at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706)
> at java.lang.Thread.run(Thread.java:745)
> "gossip-handlers-127"
> #1073 daemon prio=5 os_prio=0 tid=0x00007f65d01a6800 nid=0x233c waiting
> for monitor entry [0x00007f6697afb000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:583)
> - waiting to lock <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap)
> at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487)
> at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706)
> at java.lang.Thread.run(Thread.java:745)
> --snip end--
> If node B were to go down, JGroups quickly takes it out of the cluster and
> there is no problem. But if it stays in the cluster and is slow/stuck, is
> there a way to avoid rest of the cluster getting affected? We'd
> appreciate any help/pointers. Thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JGRP-2137) JGroups: one slow/stuck node slows/freezes entire cluster
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2137?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2137:
--------------------------------
If you can backport use of the SocketFactory from 4.0 to the 3.6 branch, all the better. I think this would be of general interest, so I'd accept a pull request for the 3.6 branch should you decide to do that!
> JGroups: one slow/stuck node slows/freezes entire cluster
> ---------------------------------------------------------
>
> Key: JGRP-2137
> URL: https://issues.jboss.org/browse/JGRP-2137
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Multi node cluster. Uses TUNNEL mode with GossipRouter, TCP.
> Reporter: Bharad S
> Assignee: Bela Ban
> Attachments: replication-server.xml
>
>
> We have a multi node cluster with one node (say Node A) running the gossip router. We use TUNNEL mode, i.e., other nodes in cluster can talk to each other only via Node A. If one of the nodes in the cluster (say Node B) is slow in reading or gets stuck while reading from the channel, it affects the entire cluster. Inter node gossip also gets stuck and the nodes fall out of cluster.
> Thread dump on Node A indicate that 'ConnectionHandler' for node B stuck (at SocketOutputStream.socketWrite) while it is holding on to a lock, thus blocking ConnectionHandlers for all other nodes.
> --snip (from thread dump on Node A) --
> "gossip-handlers-129" #1088 daemon prio=5 os_prio=0 tid=0x00007f65d20ce800 nid=0x2353 runnable [0x00007f6557efd000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
> at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
> at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
> at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:857)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:828)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> - locked <0x00000005f2445028> (a sun.security.ssl.AppOutputStream)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> - locked <0x00000005f248a210> (a java.io.BufferedOutputStream)
> at java.io.DataOutputStream.flush(DataOutputStream.java:123)
> at org.jgroups.stack.GossipRouter.sendToMember(GossipRouter.java:607)
> - locked <0x00000005f248a1f0> (a java.io.DataOutputStream)
> at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:590)
> - locked <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap)
> at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487)
> at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706)
> at java.lang.Thread.run(Thread.java:745)
> --snip end--
> Other gossip-handler threads (meant for other nodes in the cluster) on Node A wait for acquiring lock on the ConnectionHandler map at following place: GossipRouter.java, method: sendToAllMembersInGroup
> --snip--
> "gossip-handlers-128"
> #1078 daemon prio=5 os_prio=0 tid=0x00007f65d20ce000 nid=0x2343 waiting
> for monitor entry [0x00007f654c258000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:583)
> - waiting to lock <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap)
> at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487)
> at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706)
> at java.lang.Thread.run(Thread.java:745)
> "gossip-handlers-127"
> #1073 daemon prio=5 os_prio=0 tid=0x00007f65d01a6800 nid=0x233c waiting
> for monitor entry [0x00007f6697afb000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:583)
> - waiting to lock <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap)
> at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487)
> at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706)
> at java.lang.Thread.run(Thread.java:745)
> --snip end--
> If node B were to go down, JGroups quickly takes it out of the cluster and
> there is no problem. But if it stays in the cluster and is slow/stuck, is
> there a way to avoid rest of the cluster getting affected? We'd
> appreciate any help/pointers. Thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Tadayoshi Sato edited comment on WFCORE-2061 at 11/30/16 7:47 AM:
------------------------------------------------------------------
Thanks [~dlofthouse] for the clarification. I totally understand it.
However, if we don't want to lose the entire RBAC by avoiding the {{Subject.doAs(...)}}, do you think adding a {{RealmUser}} principal manually like below can be an acceptable temporary workaround at application side? This seems to be working just fine.
{code:java}
subject.getPrincipals().add(new RealmUser("admin"));
{code}
was (Author: tadayosi):
Thanks [~dlofthouse] for the clarification. I totally understand it.
However, if we don't want to lose the entire RBAC by avoiding the {{Subject.doAs(...)}}, do you think adding a {{RealmUser}} principal manually like below can be an acceptable temporary workaround? This seems to be working just fine.
{code:java}
subject.getPrincipals().add(new RealmUser("admin"));
{code}
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha14
>
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Tadayoshi Sato commented on WFCORE-2061:
----------------------------------------
Thanks [~dlofthouse] for the clarification. I totally understand it.
However, if we don't want to lose the entire RBAC by avoiding the {{Subject.doAs(...)}}, do you think adding a {{RealmUser}} principal manually like below can be an acceptable temporary workaround? This seems to be working just fine.
{code:java}
subject.getPrincipals().add(new RealmUser("admin"));
{code}
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha14
>
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ]
Jan Kalina edited comment on WFLY-7322 at 11/30/16 6:05 AM:
------------------------------------------------------------
This issue can be set as Resolved when ELY-804 and WFLY-7705 will be resolved.
Throw support was added too.
was (Author: honza889):
This issue can be set as Resolved when ELY-804 and WFLY-7705 will be resolved.
> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
> Key: WFLY-7322
> URL: https://issues.jboss.org/browse/WFLY-7322
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7322:
----------------------------------
This issue can be set as Resolved when ELY-804 and WFLY-7705 will be resolved.
> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
> Key: WFLY-7322
> URL: https://issues.jboss.org/browse/WFLY-7322
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ELY-804) LdapRealm - referral mode: direct verification + THROW mode
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-804?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved WFLY-7706 to ELY-804:
--------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-804 (was: WFLY-7706)
Component/s: Realms
(was: Security)
> LdapRealm - referral mode: direct verification + THROW mode
> ------------------------------------------------------------
>
> Key: ELY-804
> URL: https://issues.jboss.org/browse/ELY-804
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> *1) Log in as referral user is still not possible.*
> Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
> There are two possible ways how to authenticate user in ldap realm:
> using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
> not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
> Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
> *2) Elytron does not handle THROW referral mode*
> In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
> [1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
> ( Requested in https://issues.jboss.org/browse/JBEAP-6450?focusedCommentId=13323387#comm... )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months