Directory-Enabling Applications: Techniques from the Trenches Brendan Bellina Senior Systems Engineer University of Notre Dame This presentation is available.

Directory-Enabling Applications:Techniques from the Trenches

Brendan BellinaSenior Systems EngineerUniversity of Notre Dame

This presentation is available for download or online viewing at: <http://www.nd.edu/~bbellina>

Copyright © Brendan Bellina, 2004. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

About Notre Dame

• 33,000 active enterprise accounts• Single campus• Affiliation with other CSC Higher-Ed Institutions• No medical school• Systems of Record “integrated” into Person Database• No WebISO implementation• No PKI implementation

AuthN/AuthZ Models

• Application-level

• Application-specific Directory

• Enterprise Directory

System of RecordSystem of

Record

Application-level AuthN/AuthZ

Decision Maker

System of Record

User Info

Application AuthN+Z

DB

Application“In-Bounds”

App Administrator“Out-of-Bounds”

Filter“In-Bounds” Path:

Based on Policy and/or Data in System of Record

“Out-of-Bounds” Path:

Discretionary

Used to address limitations of Policy and/or Data in System of Record

Some of the many problems:Proprietary interface

Hard to know who is allowed to do what across the institution

High overhead costs

Not scalable architecture

Can be slow to revoke access

Proprietary interface

Application-specific Directory AuthN/AuthZ

Decision Maker

User InfoApplication

“In-Bounds”

Directory Administratoror App Administrator

“Out-of-Bounds”

Filter Less proprietary and therefore more compatible with delegated administration, which can reduce administrative overhead and “out-of-bounds” requests.

Without delegated administration there is little to no benefit over the application-level model.

When vendors say “LDAP-enabled” this is often what they mean... But they rarely provide tools for delegated administration.

LDAP protocol

orProprietary Interface

ApplAuthN+Z

LDAP Directory

System of RecordSystem of

RecordSystem of Record

Groups

Internally developed

orProprietary Interface

Enterprise Directory AuthN/AuthZ

Decision Maker

User Info

Application

“In-Bounds”

Directory Administrator“Out-of-Bounds”

Filter

Because the Enterprise Directory contains all people who use all applications, filtering must be done between the application and the directory. Directory Access Controls are an effective means of doing this and are external to the applications.

Easier to delegate, but proprietary interfaces may not be usable.

LDAP protocol

Enterprise

LDAP Directory

Internally developed

web interface

using LDAP

System of RecordSystem of

RecordSystem of Record

Application

Application

ApplicationGroups

Strategic Direction:

Wherever practical applications use central authentication/authorization services, rather than maintaining their own password/credential stores.

EDS Architecture Layer,

ND Strategic Technology Draft, 2002

ND Enterprise Directory Service

Decision Maker

User Info

Application

“In-Bounds”

Directory Administrator“Out-of-Bounds”

LDAP-enabled applications:

-AuthN/AuthZ via bind to LDAP

-AuthZ via LDAP groups

-Attribute retrieval

Active Directory applications:

-AuthN via AD

-AuthZ via AD groups inherited from the LDAP directory

LDAP protocol

Enterprise

LDAP Directory

Internally developed web apps

using LDAP

System of RecordSystem of

RecordSystem of Record

ApplicationApplicationApplication

Groups

Microsoft Active

Directory

Groups

accounts

groupsMy EDS Groups

Groups, Rules, and Exceptions

User Info

System of RecordSystem of

RecordSystem of Record

EDS Account

s

Rule-basedGroups

Decision Maker

My EDS Groups EDS Groups

ExceptionGroups

EnterpriseGroups

(1) ApplicationDirectoryService

User IDPassword

(7) Return success or fail

(2) Search by User ID

(3) Return dn or fail

(4) Bind with dn & psswrd

ApplicationAuthN

database

(9)Success

orFail

(8)FallbackTo Appl

DB

Kerberos v5

(5)PassTo

Kerberos

(6)Success

orFail

Authentication Flow

Application Authentication Techniques

• LDAP protocol using Service dn bind over SSL (search rather than construct dn)

• Fallback to local account database (primarily for isolated accounts)

• AuthN credentials can be in directory or external store such as Kerberos

• Authentication to Enterprise Microsoft Active Directory possible due to password synchronization

Application Authorization Techniques

• LDAP protocol using Service dn bind over SSL – limit user space by directory ACI

• Mapping to LDAP groups

• Mapping to Microsoft Active Directory groups

Attribute Retrieval Techniques

• Retrieval of attributes via LDAP protocol

• Provisioning via batch feed (LDIF)

ND Directory-Enabled Non-Internal ApplicationsLDAP AuthN+Z via Bind

LDAP AuthZ via Groups

AD AuthN AD AuthZ via Groups

Attribute Retrieval

Vendor Applications

Websphere

WebCT

Luminus

Webmail -IMP

Business Objects

FreeRADIUS

Roving Planet

Websphere Business Objects

FreeRADIUS

Cisco VPN

Roving Planet

Microsoft VPN

Citrix Metaframe

Microsoft VPN

Citrix Metaframe

Network Appliance Filers

Sendmail

Clarify

ASP Applications

Higher Markets

LMS

OPAC website

NACELink

LMS

Operating Systems

MacOS10.2

MacOS10.3

AD 2003 MacOS10.2

MacOS10.3

Red Hat Enterprise Linux

Integrating with Internally Developed Applications

• myLibrary (Perl)• Rector application (Websphere, Java)• Career Center Services website (PHP)• Campus White Pages (Cold Fusion)• MCOB Faculty Work Application (CF)• Homepage Web Services• Athletic Department• Food Services• EDS Website – self-service personal information editing,

email options, privacy settings (Perl cgi) (http://eds.nd.edu)

Integrating with Operating Systems:Microsoft Active Directory

• Active Directory Service 2003 (ADS)– Accounts synched nightly via metadirectory processing

(developed in-house in Perl)– Accounts use dn based on ndPVid as does EDS– sAMAccountName & userPrincipalName mapped to

EDS uid– cn (MS canonical name) mapped to EDS ndPVid– Enterprise groups automatically synched with EDS with

dn based on cn which maps to EDS cn– AD administrator accounts for delegated OU

management

Integrating with Vendor Applications:Sendmail, Inc.

• Authenticates directly against Kerberos• No directory-based authorization• Nightly retrieval of email quota attributes from EDS• Real-time retrieval and and processing of sieve filter to control

forwarding, auto-reply, spam filtering• Real-time retrieval of email aliases for routing• All email aliases defined in the directory, allows rejection of

20K+ bad emails per day• Email options maintained real-time self-service via EDS Website• Ability for end users to create their own email aliases real-time

Integrating with Vendor Applications:SCT Luminus Portal

• Searching Bind to EDS using Service dn• Authorization managed by automatically

populated groups and delegated exception groups

• Nightly batch feed from EDS published to allow provisioning to PDS directory and attribute usage

Integrating with Vendor Applications:IBM Websphere

• Binds to EDS using Service dn at the environmental level not per application

• Support for application roles– Current: Websphere admin creates Websphere

groups to store dn’s of privileged members– Planned: LDAP groups with membership

maintenance delegated to application administrators and map to Websphere groups

• No attribute retrieval or provisioning required

Integrating with ASP Applications:eProcurement – Higher Markets

• Searching Bind to EDS using Service dn over SSL

• Authorization managed by LDAP group membership managed by department using web interface

• Account provisioning managed manually by Higher Markets admin

Aids for Developers

• EDS Developers’ Guide: http://eds.nd.edu/docs/edsdevguide.shtml

• EDS Service DN Request Form http://eds.nd.edu/docs/eds_dnrequest.shtml

• EDS Schema documentation http://eds.nd.edu/docs/current_schema/EDS_ModelDoc.htm

• Internet2 Middleware standards: http://middleware.internet2.edu

Summary

• LDAP and LDAPS are widely adopted

• Authentication AND Authorization

• Authorization attributes in entries

• Authorization groups

• Rules are your friend

• Exceptions are a reality of life in higher-ed

• Delegation and self-service are good

Your turn to…

• Ask the speaker your questions

• Ask yourself why isn’t your institution using central authorization

Links

• ND EDS Website: http://eds.nd.edu

• ND EDS Documentation: http://eds.nd.edu/docs

• ND EDS Search Page: http://eds.nd.edu/search

• EDS Schema documentation: http://eds.nd.edu/docs/current_schema/EDS_ModelDoc.htm

Contact Information

Brendan Bellina

Office of Information Technologies

University of Notre Dame du LacEmail: [email protected]

Website: <http://www.nd.edu/~bbellina>

Directory Entry:

<http://eds.nd.edu/cgi-bin/nd_ldap_search.pl?ldapfilter=uid=bbellina>

vCard: <http://eds.nd.edu/cgi-bin/ldapvcard.pl?uid=bbellina>