Trying to get SASL bind support into the Load Balancer now and a bit stuck when it comes to figuring out what the resulting authorisation identity is (SASL or LDAP say it's backend specific) for use with the proxyauthz control.
Passing the binds on is the simple one, we can just send an LDAPWhoAmI after a successful result and we're set.
If the backends support the VC extended operation, we want to use that, since that doesn't necessarily tie up a connection for each active bind. In that case, there is no way to get the authzId out.
What is the best way to amend the VC spec?
I would think adding another optional boolean field "return authzid" might be preferable. Setting it would have the server return a new field in the response containing the authorisation identity (maybe letting the server return it anyway, but that mightn't do good things to backward compatibility).
A new control might be another option, that control could then be attached to bind requests as well I guess to obviate the need to send LDAPWhoAmI afterwards.
This might be of use for applications that have a similar usecase: use VC Exop and then attach the proxyauthz control to operations performed on each of its client's behalf.
On Fri, Nov 24, 2017 at 01:16:47PM +0100, Ondřej Kuzník wrote:
Trying to get SASL bind support into the Load Balancer now and a bit stuck when it comes to figuring out what the resulting authorisation identity is (SASL or LDAP say it's backend specific) for use with the proxyauthz control.
Passing the binds on is the simple one, we can just send an LDAPWhoAmI after a successful result and we're set.
If the backends support the VC extended operation, we want to use that, since that doesn't necessarily tie up a connection for each active bind. In that case, there is no way to get the authzId out.
What is the best way to amend the VC spec?
A new control might be another option, that control could then be attached to bind requests as well I guess to obviate the need to send LDAPWhoAmI afterwards.
Just found the Authorization Identity control (RFC3829). So another, much cleaner solution would be just to define that interaction between the VC exop and this control similarly as its interaction with the Bind request. This should preserve full compatibility with existing implementations.
Master branch also seems to have an overlay implementing this, I will have a look what is needed to get support for this in the VC overlay.
This might be of use for applications that have a similar usecase: use VC Exop and then attach the proxyauthz control to operations performed on each of its client's behalf.
-
Ondřej Kuzník