Howard Chu wrote:
For Bind caching I want to specify some additional parameters, and they all need to be associated to a given pcacheTemplate: search base, scope, and TTR. Given that we already have 7 positional parameters for pcacheTemplate I'm not keen to make it 10 now.
I added a pcacheBind keyword. It has 5 positional parameters (sigh) with a little overlap. Because the Bind parameters must be associated to an existing pcacheTemplate, you must provide a <template_string> and <attrset_index> which correspond to the pcacheTemplate directive. However, this <template_string> is not a completely bare template like for pcacheTemplate: It is allowed to have some assertion values filled in. This is necessary to allow the Bind operation to generate a filter that matches the form that a DN-search lookup would use.
Upon receiving a Bind request, pcache will first perform a search using the template's filter and attrset, with the configured base and scope. (Yes, we could just do a base-scope search on the Bind DN, but that would isolate it into its own cached query. By using the same base and scope as e.g. an NSS lookup uses, the results will go into a cached query that will also satisfy the anticipated NSS lookup.)
For example, an NSS lookup would search for ou=people,dc=example,dc=com?<some attributes>?sub? (&(objectClass=posixAccount)(uid=joe))
On a Bind request all we have is the DN: "cn=Joe User,ou=people,dc=example,dc=com"
So the pcacheBind base, scope, and template_string are used to create a search query identical to the NSS lookup: We parse the template for a list of attributes to extract from the target entry. We then do a base scope search on the Bind DN to obtain the entry, and extract the values to substitute into the filter. We then provide this new filter to the Search response callback, before it saves the query into its cache. (So, even though we performed a base scope search on this DN, we tell the cache that it was base ou=people, scope=sub, filter=xxx)
If the query was not already cached, or the cached query has exceeded its TTL, then this will cause a remote search to occur, and the results of that should get cached. (Unless some entry limit got exceeded, etc.) Otherwise, this should just retrieve the cached result.
If the cached result has a hashed userPassword and it is within the TTR age, then the Bind will be validated against the cached userPassword. If the hash is older than the TTR, or there is no hash, the Bind will be passed thru to the remote target and if it succeeds, it will be hashed and cached.
So, actually implementing the Bind caching is pretty straightforward. Cleaning up the config syntax, not so much...
I suppose the next step is to add some tests to test020...