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

[Darran Lofthouse (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3072:
-----------------------------------

    Description: 
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.


  was:This also needs to take into account compatibility with caching.


    
> 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.0.1.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.

--
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