[unisog] LDAP access for 3rd parties

[Gary Flynn]

Oscar Knight wrote:
> Hello Everyone,
> 
> If you give a 3rd party access to your ldap for the purpose of 
> authenticating your users then they have access to your user's raw 
> password.  To me this is a serious general controls issue.
> 
> We have other methods but are getting complaints from users that want 
> 3rd party applications and their vendor only seems to know ldap.  In 
> part I'm getting a lot of "well, site A, site B,...  are all allowing us 
>   to use their ldap service".

We've heard the same arguments here.

We have thus far not allowed outside access to our LDAP servers
though, as someone else mentioned, the same effect could be
obtained by proxying requests to any exposed LDAP authenticated
service. Of course, if a vendor is doing that to their customer
in an unauthorized manner, the problem does not require a
technical solution. :)

Also, as others have mentioned, there are alternatives:

1) A web authentication proxy
2) A federation scheme like Shibboleth
3) A certificate based system
4) Saying no to the use of university accounts and passwords
    by third parties.

If 1-3 are not feasible, saying yes or no to option 4 is a business 
decision. Management may decide to assume the risk in the interest
of enabling convenient business processes. All you can do is provide
your opinion and/or a risk assessment.

Issues involved in external use of university credentials:

1) As Pete mentioned, access to the same-signon credentials used at
    many universities may give the vendor access to data and services
    completely unrelated to and far above the level of sensitivity
    needed for the vendor's service.

    For example, they may have access to self-service student and
    employee administration systems, e-mail, access to licensed
    software and research material, remote access through firewalls
    and VPNs, certificates, and many other things that are probably
    not related to the vendor's business. Some accounts may be
    associated with elevated access rights compounding the problem.

    How much access to sensitive, personal, and operational data
    do they need? How much trust can be justified? How trustworthy
    is the vendor and its employees? How competent their desktop,
    system, and network administration? Enough to provide them keys
    to the organization's and constituents' kingdom?

2) Can account credentials protecting data covered by FERPA and
    HIPPA legally be provided to third parties for unrelated
    purposes? What happens if the vendor experiences a breach?

3) Should an individual assigned an account protecting personal
    information have a say in whether a third party should be
    given access? How are privacy policies and disclosures
    affected?

4) Precedent. Not only for future vendors but what about
    individuals providing their own credentials to Facebook and
    Email providers to allow things like Blackboard and
    E-mail "mash-ups". How does the practice affect university
    appropriate use policies covering the use and sharing of
    university account passwords?

5) Direct exposure of the LDAP server to outside parties. Simple
    exposure has risk separate from its legitimate use. Is the
    LDAP server dedicated to public operations with limited data
    stored or is it a more general server that has lots of unrelated
    data in it that may be inadvertenly exposed. If the server
    is compromised, what are the effects to stored data and
    adjacent and dependent systems?

6) How does it affect Certificate Practices Statements or Levels
    of Assurance?




-- 
Gary Flynn
Security Engineer
James Madison University
www.jmu.edu/computing/security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3229 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.sans.org/pipermail/unisog/attachments/20080213/757cb639/attachment.bin