1 / 37

Dartmouth’s Directory and Authentication Infrastructure

Dartmouth’s Directory and Authentication Infrastructure. …and how to use it from an Oracle application. DND vs. LDAP - what's the difference?. #1 point: DND is a custom interface on underlying LDAP directory DND does flexible, standardized name/nickname matching

Sophia
Télécharger la présentation

Dartmouth’s Directory and Authentication Infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dartmouth’s Directory and Authentication Infrastructure …and how to use it from an Oracle application http://dev.dartmouth.edu/projects/softdev/webAuth

  2. DND vs. LDAP - what's the difference? • #1 point: DND is a custom interface on underlying LDAP directory • DND does flexible, standardized name/nickname matching • LDAP is the open standard for Enterprise directories • Greater range of data storage & access control possible with LDAP • Best practice is to resolve name using DND, then use LDAP

  3. What about DNDPERSON? • A "shadow" Oracle table replicating the data visible through the DND interface • May be more convenient for a native Oracle app to query against DNDPERSON instead of doing an external DND or LDAP operation • Also used in the feed of HR/Banner info to DND/LDAP directory

  4. Who's in the directory? • all students, faculty, staff (sourced from HR and Banner) • "sponsored" accounts (contractors, non-paid research assistants,...) • departmental & organization entries • DHMC courtesy accounts

  5. What information is stored • Name (full name, and broken-out parts) • nickname • Dept/Class • email address (name@dartmouth.edu or name@tuck.dartmouth.edu) • hinmanaddr, phone • Affiliation (DART, SPON, DEPT, DHMC, etc.) • eduPersonAffiliation (Student, Faculty, Staff) • uid, dartid (dctsnum), dieboldnum • SSN is present but not released to any application

  6. Passwords • Same password used for DND, LDAP and Active Directory • No password expiration enforced by LDAP, but applications can query the "pwchanged" attribute and enforce their own policy • Password is not stored in DNDPERSON - strict policy of not exporting passwords

  7. Options for authentication: • webAuth (authenticateV3) • Kerberos/Sidecar (authenticatev2) • Direct LDAP authentication • Direct DND authentication • Radius • PKI

  8. webAuth • web-based single-sign-on • AuthenticateV3 uses webAuth • All Dartmouth web apps are encouraged to migrate to webAuth • webAuth = CAS+Dartmouth-specific attributes, PKI support • any standard CAS client can be used http://dev.dartmouth.edu/projects/softdev/webAuth/wiki

  9. webAuth - overview • to authenticate, browser is redirected to login screen (unless user is already signed in) • User authenticates to webAuth using PKI cert, or name/pw • webAuth redirects browser back to theWeb application • webAuth support is built in at web server (apache) level; application developer doesn’t need to do authentication directly http://dev.dartmouth.edu/projects/softdev/webAuth/wiki

  10. WebAuth - pluses… • ++ application developer no longer has to do authentication directly • + single sign-on • + can support multiple authentication methods • + also checks against Alumni directory, DHMC http://dev.dartmouth.edu/projects/softdev/webAuth/wiki

  11. WebAuth - … and minuses • - also checks against alumni directory, DHMC • - browser-based only (limited to web apps) • - redirection involved in a webAuth login can be problem with HTTP POST (solution is to webAuth just your "login" page, then use a session) http://dev.dartmouth.edu/projects/softdev/webAuth/wiki

  12. Kerberos/Sidecar • Older web-based single-sign-on solution • AuthenticateV2 uses Kerberos • not recommended for new applications

  13. Kerberos/Sidecar overview • to authenticate, server process makes an out-of-band connection to the user's machine to Sidecar listener (port 913) • Sidecar listener obtains Kerberos ticket, returns it to server for validation

  14. Kerberos/Sidecar issues • firewalls and NAT devices (home routers) may block port 913 • No support for current (Intel) Mac hardware • DBMS pipe listener has sometimes had problems; not yet available on Linux • Not recommended

  15. Direct LDAP authentication • application prompts for password, makes direct LDAP call to validate • MUST use an SSL connection

  16. LDAP authN pluses and minuses • + may be supported by commercial apps that can't do CAS (webAuth) • - application has access to user's password • - no single-sign-on • - no nickname matching (unless app does a DND query first)

  17. Direct DND authentication • application prompts for password, makes direct DND call to validate • MUST use an SSL connection or DND pw encryption https://dev.dartmouth.edu/projects/softdev/dnd/wiki/dndIntegration

  18. DND authN pluses and minuses • + better name matching • - application has access to user's password • - no single-sign-on • - non-standard protocol https://dev.dartmouth.edu/projects/softdev/dnd/wiki/dndIntegration

  19. Radius Authentication • Radius is a standard protocol for using an external authentication server, especially for network access control (VPN, dialup) • Requires Radius client library for your platform • Application prompts for name/pw; passes them on to Radius server • Radius server uses DND to validate name/pw • Because DND is used, doing Radius automatically gets you DND-style name matching

  20. PKI authN - overview • User has a software cert or eToken • Application examines the cert, grants access based on that

  21. PKI - pluses and minuses • + 2-factor authentication • - can be difficult for roaming users (need to install a cert or eToken driver) • - can be complex for applications to implement (limited adoption)

  22. The Bottom Line • webAuth is the recommended authentication mechanism for all Dartmouth web-based applications

  23. Options for querying the Directory • LDAP query • DND query • SQL query against DNDPERSON • Attributes from webAuth

  24. Querying LDAP • ldap.dartmouth.edu port 636 (SSL) or 389 (non-SSL) • search base: dc=dartmouth,dc=edu • can query based on any combination of LDAP fields, use wildcards, etc. • limit of 100 entries returned (w/o special permissions) • anonymous searches allowed

  25. Querying the DND • Hostname = dnd.dartmouth.edu; port 902 or 904 (SSL) • Requires DND client library (available for C, java, perl, php,…) • Query by name, uid, or dctsnum only • Fuzzy name matching is automatic • Anonymous queries allowed, although a few attributes are visible only to user herself

  26. Querying DNDPERSON • native Oracle view DND.DNDPERSON • requires DBAs to grant you access • Includes inactive accounts, so typically include “DUP is NULL” clause in query to see only active users

  27. Using attributes from webAuth • webAuth login always returns: name, uid, dartid(dctsnum), affiliation • Sometimes, these attributes are enough and no further query is needed • If more are needed, can use uid or dartid to query against LDAP

  28. Choice of Identifiers • In many places (log file entries, ACLs, on-screen prompts, …) you’ll want to identify the authenticated user. There are several possible identifiers: • Name • (dnd)uid • (dctsnum)Dartid

  29. Using the Name as your identifier • + user-readable • + known to the user • - can change • - includes spaces (trouble for some apps) • With webAuth, be aware that you may see users from different realms (Alum, DHMC); always use name@REALM • Better data quality on full name vs. First/initials/Last

  30. Using the (dnd)uid as your identifier • + stable for life of the LDAP entry • + all entries have one • - not likely to be known to user • - typically can't match against other databases

  31. Using dartid (dctsnum) as your identifier • + can match against HR/Banner • + user may know it (printed on ID card) • - not all entries have one • NOTE: THIS IS A PUBLIC FIELD, NOT A "SECRET"

  32. dn: cn=Richard I. King, dc=dartmouth, dc=edu dndGid: 45939 46170 62446 67313 80885 userCertificate;binary::MIIEgDCCA2igAwIBQYJcNAQEFBQA... dndDieboldnum: 003252017 ctCalOperatingPrefs: 0:0:0:0:0:0:0:1:0:727:0:420:960:360:1020:0:420:960:360:0: 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 dndBlitzserv: newvixen.Dartmouth.EDU@BlitzServ dndDeptclass: Admin Comp ctCalTimezone: 0 ctCalNotifMechanism: 1 ctCalRefreshPrefs: 1:30 ctCalDisplayPrefs: 4:420:1080:1:15:190:2 ctCalDefaultTaskReminder: 1:20 ctCalDefaultReminder: 1:15 ctCalDefaultNoteReminder: 1:10 ctCalPasswordRequired: 1 ctCalSysopCanWritePassword: 1 ctCalLanguageId: 0 ctCalSMSTimeRange: 0:0 ctCalPublishedType: 0 ctCalXItemId: 00001:00790 initials: I givenName: Richard sn: King eduPersonOrgDN: dc=dartmouth, dc=edu displayName: Richard I. King krbName: Richard I. King@DARTMOUTH.EDU dndUid: 45796 dndPotluckserv: Strongbox telephoneNumber: 603-646-1602 nickname: Rik cn: Richard I. King dndMailaddr: Richard_I._King@Mac dndHinmanaddr: HB 6209 mail: Richard.I.King@Dartmouth.EDU dndDctsnum: HD32520Q dndDatasource: HRS dndDartfilesquo: 30720000 dndBullserv: newshost.dartmouth.edu@internet dndAffiliation: DART objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: eduPerson objectClass: dndEntry objectClass: kerberosSecurityObject objectClass: ctCalUser eduPersonAffiliation: Staff eduPersonPrimaryAffiliation: Staff eduPersonEntitlement: urn:mace:incommon:entitlement:common:1 dndBlitzinfo: /vixen4 LDAP Exampleldapsearch -x -b 'dc=dartmouth,dc=edu' -h ldap.dartmouth.edu cn="richard*king"

  33. dn: cn=Richard I. King, dc=dartmouth, dc=edu cn: Richard I. King nickname: Rik dnddctsnum: HD32520Q dnduid: 45796 dnddeptclass: Admin Comp LDAP Example (asking for specific attributes)ldapsearch -x -b 'dc=dartmouth,dc=edu' -h ldap.dartmouth.educn="richard*king” cn nickname dnddctsnum dnduid dnddeptclass

  34. Richard I. King, HD32520Q, Rik, 45796, Admin Comp Command-line “dndlookup” tool is part of libdnd (http://dev.dartmouth.edu/projects/softdev/dnd/wiki/cLib) Note automatic use of nickname in the lookup. Contrast this with the LDAP query, where an explicit wildcard (*) was needed in the query string, and it checked only the name, not the nickname. Note differing field names (“cn” vs. “name”, “dnddeptclass” vs. “deptclass”) between LDAP and DND. DND fields are mapped onto standard LDAP attributes when possible, otherwise the LDAP attribute name will have a “dnd” prefix. DND query exampledndlookup -f name -f dctsnum -f nickname -f uid -f deptclass rik king

  35. Questions? • This presentation is archived at: • http://dev.dartmouth.edu/projects/softdev/webAuth

More Related