Proxy Authentication

LDAP provides mechanisms for one account to act on behalf of (and with the access rights of) another.

Threats

  1. In real life, people occasionally need to delegate their powers to others (e.g. when they are on holiday). In IT systems this is often done by giving the delegate the principal's password, which breaks most organisations' security policies and makes proper auditing and accountability very difficult. Password sharing must be avoided.

Controls

  1. Use the SASL authc/authz mechanism: the session is bound using the delegate's ID and password, but is authorised to act as if bound as the principal.
  2. Use the LDAP\xA0Proxied\xA0Authorization\xA0Control\xA0[RFC4370]
  3. LDAP servers can be configured to allow specific accounts to act with the access rights of other accounts. Make use of the mechanisms available to control who may act for whom.

Application

Apply this control when any user needs to act on behalf of another. Consider using the same mechanisms where a portal service needs to act on behalf of many users, but be aware that giving wide power to such systems has risks of its own.

-- AndrewFindlay - 07 Oct 2011
Topic revision: r1 - 07 Oct 2011, AndrewFindlay - This page was cached on 08 Aug 2023 - 11:13.

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback