]
RH Bugzilla Integration commented on WFLY-3072:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug
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.CR2, 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.