[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Making the original authcid available to plugins
I've often thought it would be useful to keep the authcid around,
particularly to allow multiple proxy authorizations to occur over a single
session. It may also be useful for auditing purposes to log somewhere that an
operation was performed via a proxy vs the actual user. Beyond that, I
haven't really thought about the implications...
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Luke Howard
> A plugin we've developed needs access to the original authentication
> identity, because certain operations are handled differently if they
> come from a trusted entity acting on behalf of a user (for example,
> a replica proxying a password change) rather than the user itself.
>
> At present we're using the rather ugly hack of retrieving the SASL
> context (SLAPI_X_CONN_SASL_CONTEXT), retrieving SASL_AUTHUSER from
> that, and then applying analogous rules to the SASL regex transforms
> to turn it into a DN.
>
> It would be more efficient (avoiding an extra search, and alignment
> of code with SASL authorization policies) if the original authcid,
> after mapping to a DN, was not disposed of, and thus could be
> exposed through SLAPI.
>
> Thoughts?
>
> -- Luke
>
>