<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That would have to happen on every request though.<br></blockquote><div><br></div><div>Yes, that's correct and intentional.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That would only work for a limited and relatively undefined subset of the flow. I wouldn't expect it to be there by the time LDAP authentication ran, for example, since by then it's gone back to the client.<br></blockquote><div><br></div><div>I think I need to clarify our use case a little more because that's not correct afaict. I need to do the following around every ResolveAttributes action for some subset of authenticated subjects:</div><div><br></div><div>1. Grab an LDAP connection from the pool</div><div>2. Grab the principal from the PRC using the lookup function I mentioned.</div><div>3. Bind as that principal using the SASL authorization ID</div><div>4. Resolve attributes</div><div>5. Restore the original security context of the pooled connection</div><div>6. Return connection to the pool</div><div><br></div><div>It may be helpful to explain _why_ we need this. We have ACLs in our directory that allow some principals to see attributes only on their own entry, thus the security context when the pool initializes is not sufficient. We have service principals that are authenticating and we need to be bound in that security context to resolve attributes. I believe our implementation sketch would work beautifully with the patch I suggested.</div><div><br></div><div>M</div><div><br></div></div></div>