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
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
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
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.
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
This has been making some waves today on social media:
For now, it's only a novelty. Just like perfect hash functions. It assumes a
static data set being used in read-only fashion, so it's unsuitable for a
directory or database that serves ongoing modifications. It also assumes an
entire data set fits in RAM, which is generally not true for database
applications. In particular, the "fast" case of using highly parallel GPUs
assumes everything fits inside GPU RAM, which is even more tightly constrained
than server main memory.
It's axiomatic that if you have advance knowledge about the
shape/characteristics of a dataset, you can construct a dedicated mapping
function for that dataset that is perfectly optimal, and outperforms any
general-purpose mapping. That's kind of the point of general-purpose mappings
- they are general. There are plenty of use cases where this fact may be
useful. In LDAP and any database system ingesting data in realtime, these
findings are irrelevant since advance knowledge of the dataset doesn't exist.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/