[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
>
>