April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3072) Support Referrals for security realms using LDAP for authentication or group loading.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3072?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3072: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1066488|https://bugzilla.redhat.com/show_bug.cgi?id=1066488] from ASSIGNED to POST > Support Referrals for security realms using LDAP for authentication or group loading. > ------------------------------------------------------------------------------------- > > Key: WFLY-3072 > URL: https://issues.jboss.org/browse/WFLY-3072 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.1.0.Final > > > I see the following scenarios to cover for this: - > - Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct. > Group loading then has a couple of issues, firstly where the user was a referral. > The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both. > Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there. > And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection. > The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading. > * Connection Settings * > We are going to need to support two different modes in relation to the 'java.naming.referral' property, follow and throw. > - *follow* - In this mode when the InitialDirContext encounters a referral during a search it will automatically follow it, this means automatically connecting to the server in the URL. This is fine if the remaining connection settings are valid for the alternative server e.g. same bindDN and credential. We however need to take the following into account for subsequent operations such as password validation or further queries. > - *throw* - When a referral is encountered and exception will be thrown instead, this mode should make it easier to have some more advanced referral handling logic that allows us control of which connection we subsequently use, e.g. we could not use a completely different host name to the one in the referral or use a different bind DN / credential pair. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3270) Clustered support for HTTPSession sharing between wars delivered in an EAR

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3270?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3270: ------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6182) > Clustered support for HTTPSession sharing between wars delivered in an EAR > -------------------------------------------------------------------------- > > Key: WFLY-3270 > URL: https://issues.jboss.org/browse/WFLY-3270 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.CR1 > > > WAS and WL have this feature, and its been requested for several earlier versions of AS. Having this capability will ease the migration of users from WAS and WL to WildFly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3270) Clustered support for HTTPSession sharing between wars delivered in an EAR

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3270?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3270: ------------------------------- Fix Version/s: 9.0.0.CR1 > Clustered support for HTTPSession sharing between wars delivered in an EAR > -------------------------------------------------------------------------- > > Key: WFLY-3270 > URL: https://issues.jboss.org/browse/WFLY-3270 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Paul Ferraro > Assignee: Stuart Douglas > Fix For: 9.0.0.CR1 > > > WAS and WL have this feature, and its been requested for several earlier versions of AS. Having this capability will ease the migration of users from WAS and WL to WildFly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3270) Clustered support for HTTPSession sharing between wars delivered in an EAR

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3270?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-3270: ---------------------------------- Assignee: Paul Ferraro (was: Stuart Douglas) > Clustered support for HTTPSession sharing between wars delivered in an EAR > -------------------------------------------------------------------------- > > Key: WFLY-3270 > URL: https://issues.jboss.org/browse/WFLY-3270 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.CR1 > > > WAS and WL have this feature, and its been requested for several earlier versions of AS. Having this capability will ease the migration of users from WAS and WL to WildFly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3270) Clustered support for HTTPSession sharing between wars delivered in an EAR

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-3270: ---------------------------------- Summary: Clustered support for HTTPSession sharing between wars delivered in an EAR Key: WFLY-3270 URL: https://issues.jboss.org/browse/WFLY-3270 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Web (Undertow) Reporter: Paul Ferraro Assignee: Stuart Douglas WAS and WL have this feature, and its been requested for several earlier versions of AS. Having this capability will ease the migration of users from WAS and WL to WildFly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3270) Clustered support for HTTPSession sharing between wars delivered in an EAR

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3270?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3270: ------------------------------- Component/s: Clustering (was: Web (Undertow)) > Clustered support for HTTPSession sharing between wars delivered in an EAR > -------------------------------------------------------------------------- > > Key: WFLY-3270 > URL: https://issues.jboss.org/browse/WFLY-3270 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Paul Ferraro > Assignee: Stuart Douglas > > WAS and WL have this feature, and its been requested for several earlier versions of AS. Having this capability will ease the migration of users from WAS and WL to WildFly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1829) Failing to connect to an unavailable member blocks all message sending

by David Hotham (JIRA)

[ https://issues.jboss.org/browse/JGRP-1829?page=com.atlassian.jira.plugin.... ] David Hotham commented on JGRP-1829: ------------------------------------ What's the expected timetable for JGroups 4.0? I suppose that it's behind JGroups 3.5 - of course! - and so some way off yet. I had hoped that you'd want to make a fix to this one before that. I guess I'd had in mind something like: - if we need to get a new connection while trying a send() then put the the message that we're sending onto a queue - continue opening the connection in a new thread (so the original thread is unblocked) - while the queue for some destination is non-empty, queue all messages to it so as to preserve ordering - when the connect completes (either successfully or not) process the queued messages I understand that this is a bit vague and the devil is in the details - but something along these lines should be possible, shouldn't it? Your suggestion to use UDP is interesting. I think we're probably using TCP only because I'd assumed that TCPPING would need TCP transport. But I can't immediately see why TCPPING wouldn't work fine with UDP transport. Is that right? Still, I'd prefer to explore a fix. A change in transport feels like a much bigger change for us and would require quite a bit more testing than a targeted fix. Also, a fix would make JGroups better - and that must be good, right? > Failing to connect to an unavailable member blocks all message sending > ---------------------------------------------------------------------- > > Key: JGRP-1829 > URL: https://issues.jboss.org/browse/JGRP-1829 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4.2 > Reporter: David Hotham > Assignee: Bela Ban > > Hi, > We're seeing a problem which appears to be caused by the TransferQueueBundler thread being blocked while it fails to connect to an unavailable member. > The setup we have is a cluster split across two sites: say, members 0 through 4 in site A and members 5 through 9 in site B. Initially the cluster is complete: everyone has the same view. The case that we're testing is: what happens when connectivity is lost between the sites? NB we're using TCP transport. > Obviously the expected result is that we'd get two sub-clusters, one in each site. But this doesn't always happen. Instead we sometimes see some members become singletons (that is, with only themselves in view). > What seems to be happening is something like this: > - When the cross-site link is cut, members in site A suspect members in site B (and vice versa). > - So in each site there's a broadcast of SUSPECT messages > - Now each of the members in site A tries to VERIFY_SUSPECT each of the members in site B > - Each such attempt blocks the TransferQueueBundler for two seconds (TCP's default sock_conn_timeout), because we can't contact any member in the other site > - But that introduces a delay for _all_ messages, not only for messages to the 'other' site > - If there are enough members in the 'other' site, we can easily get a large enough delay that HEARTBEAT (and then VERIFY_SUSPECT) messages start timing out between members in the same site > - At this point, members that ought to be able to see one another start to report that they cannot do so. > We've seen cases where a member becomes completely isolated - forming a singleton cluster - and does not recover. Unfortunately we don't have full trace from that run, so it's not clear why the cluster didn't eventually recover. I suspect that we're hitting something like JGRP-1493, in which delays sending messages (in that case, a delay when failing to get a physical address) caused the MergeKiller always to prevent merging. > It is highly undesirable that when a cluster contains several unavailable members, as in a partition between two sites, this should cause problems for members that can see one another. > Should all message sending really be blocked while failing to connect to an unavailable member? > This issue seems related also to JGRP-1815 which raises a similar question: should all message sending really be blocked while failing to find a physical address? > What do you think? > - do you agree that blocking message sending while attempting to connect to an unavailable member is undesirable? > - if so, what do you think the right fix is? If it's not too hard, we may be able to find time to take a look at implementing this ourselves. > - is there anything else we can do to help progress this issue? > We're using JGroups 3.4.2. I've attached the code fragment with which we configure the stack below. > Thanks for your help > David > {noformat} > stack.addProtocol((new TCP) > .setValue("enable_diagnostics", false) > .setValue("logical_addr_cache_max_size", 70) > .setValue("logical_addr_cache_expiration", 10000) > .setValue("physical_addr_max_fetch_attempts", 1) > .setValue("bind_addr", localAddr) > .setValue("bind_port", basePort) > .setValue("port_range", 0)) > val tcpping = new TCPPING > val jhosts = initialHosts map { addr => new IpAddress(addr.getHostAddress, basePort) } > tcpping.setInitialHosts(jhosts) > tcpping.setPortRange(0) > tcpping.setValue("return_entire_cache", true) > stack.addProtocol(tcpping) > .addProtocol(new MERGE3) > .addProtocol((new FD_SOCK) > .setValue("bind_addr", localAddr) > .setValue("client_bind_port", basePort + 1) > .setValue("start_port", basePort + 101) > .setValue("suspect_msg_interval", 1000)) > .addProtocol(new FD) > .addProtocol((new VERIFY_SUSPECT) > .setValue("timeout", 1000)) > .addProtocol((new NAKACK2) > .setValue("use_mcast_xmit", false)) > .addProtocol(new UNICAST3) > .addProtocol(new STABLE) > .addProtocol(new MFC) > .addProtocol(new SEQUENCER) > .addProtocol((new GMS) > .setValue("max_join_attempts", 3) > .setValue("use_delta_views", false)) > .addProtocol(new FRAG2) > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1687) CastMessageWithFuture in MessageDispatcher

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1687?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1687: --------------------------- Fix Version/s: 3.5 (was: 4.0) Sent an email to the users mailing list. Pending any objection, I'll fix this in 3.5. The fix is in branch JGRP-1687, just need to rebase and merge if this is OK'ed. > CastMessageWithFuture in MessageDispatcher > ------------------------------------------- > > Key: JGRP-1687 > URL: https://issues.jboss.org/browse/JGRP-1687 > Project: JGroups > Issue Type: Bug > Reporter: shen kim > Assignee: Bela Ban > Fix For: 3.5 > > > When I used CastMessageWithFuture in MessageDispatcher. I found the following Method declared : > public <T> NotifyingFuture<RspList<T>> castMessageWithFuture(java.util.Collection<Address> dests, Message RequestOptions options, FutureListener<T> listener) throws java.lang.Exception > Is it the FutureListener<T> may be declared to FutureListener<RspList<T>> ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3258) Upgrade jboss-remote-naming to 2.0.1.Final or later

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3258?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-3258: ----------------------------------- Yeah that's the idea. I'm just waiting to see if any more bugs crop up before I tag. > Upgrade jboss-remote-naming to 2.0.1.Final or later > --------------------------------------------------- > > Key: WFLY-3258 > URL: https://issues.jboss.org/browse/WFLY-3258 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.Final > Reporter: Brad Maxwell > Assignee: David Lloyd > Priority: Blocker > > Upgrade jboss-remote-naming to 2.0.1.Final or later to resolve linked issues -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3124) JXM PluggableMBeanServerImpl assumes RealmUser principal

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3124?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3124: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1082072|https://bugzilla.redhat.com/show_bug.cgi?id=1082072] from POST to MODIFIED > JXM PluggableMBeanServerImpl assumes RealmUser principal > -------------------------------------------------------- > > Key: WFLY-3124 > URL: https://issues.jboss.org/browse/WFLY-3124 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX > Affects Versions: 8.0.0.Final > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Fix For: 8.1.0.CR1 > > > JXM {{PluggableMBeanServerImpl$LogAction}} assumes that {{RealmUser}} principal is present when Subject is not null. This condition is not always met and results into following exception: > {noformat} > Caused by: java.util.NoSuchElementException > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) > at java.util.HashMap$KeyIterator.next(HashMap.java:960) > at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.getCallerUserId(PluggableMBeanServerImpl.java:1250) > at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1233) > at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1158) > at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331) > at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.queryNames(MBeanServerAuditLogRecordFormatter.java:170) > at org.jboss.as.jmx.PluggableMBeanServerImpl.queryNames(PluggableMBeanServerImpl.java:871) > at org.infinispan.jmx.JmxUtil.findJmxDomain(JmxUtil.java:127) > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2014