adding applications to the enterprise authentication system robert banz, umbc tom barton, university...

36
Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

Upload: arron-price

Post on 18-Dec-2015

223 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

Adding Applications to the Enterprise Authentication System

Robert Banz, UMBC

Tom Barton, University of Chicago

Page 2: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 2

Copyright Tom Barton and Rob Banz 2004. This work is the intellectual property of the authors. 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 authors. To disseminate otherwise or to republish requires written permission from the authors.

Page 3: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 3

Outline

• Rob: Synchronization vs. integrated authN architectures

• Tom: Two case studies from U Chicago

Page 4: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 4

Synchronization

• Simplest method to understand and implement, in most cases.

• AuthN & AuthZ information is copied from the enterprise system, and placed into the target application.

• Password changes are captured and pushed to consuming applications

Page 5: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 5

Synchronization

• Pros:– Users get the benefits of a single password

scheme.– No “hacks” required to get an uncooperative

application to accept authentication information from another source.

Page 6: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 6

Synchronization

• Cons:– AuthN data must be kept in sync

(never as easy as it seems)– Replicated data -- more to manage, back up, etc.

• Caveats:– Password changes must be disabled at the application level,

or, some arrangement must be made to push them back to the enterprise level

– Does the application place an acceptable level of security on storage and transport of authentication secrets?

Page 7: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 7

Synchronization Example

• Enterprise MIT KDC, andMS Active Directory

• Why?– Cross-Realm Kerberos Authentication works for

some applications.– Others require non-Kerb Windows authentication,

password must be verifiable by the MS AD server.

Page 8: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 8

Synchronization Example

• Enterprise KDC -> MS AD communication– “kadmind” sets passwords in MS AD via LDAP

calls when a user changes their enterprise password.

• MS AD Concerns– “self password change” disabled

…all password changes through MIT KDC– Old “NTLM” hashes/authentication disabled

…storage and transport trivial to comprimise, not an acceptable risk

Page 9: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 9

Direct Integration

• Minimize replication of data• Best user experience

No synchronization problems here!• Less work for the application and enterprise

administrator!

Page 10: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 10

Common Authentication Store

• Enterprise authentication service used as source for verifying authentication credentials.

• Common technologies:– MIT KDC– LDAP Server– MS Active Directory

Page 11: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 11

Common Authentication Store

• Pros:– Users benefit from single username/password

scheme.– Application administrators don’t have to manage

an authentication store.– LDAP & Kerberos are supported by many

applications (OS & Proprietary), but, YMMV…

Page 12: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 12

Common Authentication Store

• Cons:– Users still have to “log in” to multiple applications.– While applications may support LDAP & Kerberos,

they may not support them the way you expect, or want, or should. (the YMMV part.)

• Ever *actually* get Kerberos 5 working with Oracle?

Page 13: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 13

Common Authentication Examples

• Corporate Time / Oracle CalendarEasily configured to use LDAP as an authentication source

• UNIX systemsCan use LDAP or Kerberos via PAM for authentication

• PeopleSoftCan be configured to use LDAP as an authentication source

Page 14: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 14

Common Authentication Examples

• Hybrid Models– Authentication store in KDC– LDAP “plugin” verifies passwords against KDC

Page 15: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 15

Single/Reduced Sign-On

• For Web Services, this is usually a WebISO system…– There was a panel about this a few minutes ago…

but a quick summary• User authenticates to a web service that issues them a

credential via a cookie • That credential is used to authenticate the user to other

web applications, in some way or anothe

Page 16: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 16

Single/Reduced Sign-On

• Kerberos is also a “single sign on” technology– But very few applications support using Kerberos

in it’s designed fashion

• User authenticates to KDC, receives a credential

• That credential is used to obtain other credentials to authenticate them to applications

Page 17: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 17

PKI

• Certificates are another method to implement an enterprise-wide authentication architecture.

• Applications are finally beginning to catch up to technology– You can actually USE PKI now!

• WAKE UP EARLY TOMORROWPKI session at 8:30am!

Page 18: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 18

Proxy Authentication

• The “Dirty” way to do it.• A front-end application presents a stored

authentication credential to a backend application.

• Storing someone’s primary authentication credentials, and using them in their place, is bad bad bad, and you shouldn’t ever ever do it.

Page 19: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 19

Proxy Authentication

• SquirrelMail– WebISO stores user’s password as an attribute in their

“TGT”– WebISO will issue a credential containing the user’s

password as an attribute only to very special applications… like SquirrelMail

– SquirrelMail then uses the user’s password to initiate an IMAP session on behalf of the user

…there have also been some very creative alternatives to this technique…

Page 20: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

A Peek Under U Chicago’s Kimono

Page 21: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 21

Scenario 1: Student Registration

• Nearing end of a messy multiyear conversion of student systems to SCT’s Matrix

• Known locally as Gargoyle, Matrix runs in a single-domain AD forest, garg.local.

• Undergrad students will need to access the “ARM” Matrix app in order to register.

• IIS mediates web access to ARM• Membership in a garg.local domain local

group authorizes appropriate access to ARM

Page 22: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 22

Scenario 1: Student Registration

• Garg.local has domain local accounts for administrative users only

• It’s desired that students be able to use their CNetID and password to register for classes

So it’s either sync or swim …

… we chose to swim

Page 23: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 23

One-Slide Primer• Realm trust from UCAD forest root, ad.local, to MIT

KDC for uchicago.edu realm• Name translation occurs by user objects with random

passwords sync’d into forest root domain– [email protected] namespace used for authorization

Page 24: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 24

Option 1 for Gargoyle authentication

• Migrate garg.local into UCAD, UofC’s primary AD forest

Page 25: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 25

Option 1 Cons

• Disruptive, and the messy conversion has already made people anxious about reliability of the student system

• Complex rules for firewall and associated test & pre-production domains make it harder

• Organizationally difficult, requiring cooperation and coordination of 4-5 directorates

Page 26: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 26

Option 2 for Gargoyle authentication

• Sync user objects with random passwords into garg.local, just as for ad.local

Page 27: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 27

Option 2 Cons

• Make existing “metadirectory” operation into more of a real metadirectory operation

• Quite a lot of work to prepare garg.local to receive automatically sync’d accounts, but less than that required for Option 1

• Not feasible for the 2nd scenario presented a few slides hence – prefer one solution for both

Page 28: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 28

Option 3 for Gargoyle authentication

•Use a forest trust, garg.local trusting ad.local, UCAD’s forest root

Page 29: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 29

Option 3 Cons

• None, theoretically• It’s just that we couldn’t make it work …

Until yesterday!• Turns out that “name routing” for the

uchicago.edu realm was default disabled in garg.local’s ad.local Trusted Domain Object– Dunno why

Page 30: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 30

Scenario 1 Denouement

• The IIS servers hosting the ARM app will need to be configured to know about the uchicago.edu realm– Basic auth over SSL on the wire– IIS impersonates the user– IIS defaults user domain to “uchicago.edu”

• Populate authorizing domain local group in garg.local with [email protected] namespace references

Page 31: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 31

Scenario 2: Unified AuthN with UC Hospitals

• UC & UCH are formally separate with separate IT operations and infrastructure, but we’re thoroughly intermeshed in terms of clinical and research org structure and activities

• Number of specific needs for UCH people to access UC offered services and vice-versa

• Tons of account crud built up over years of wormholing around this structural problem presents potential liability

Page 32: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 32

Scenario 2: Unified AuthN with UC Hospitals

• UCH already made a strategic choice of AD and MS infrastructure generally– UCH operates a single-domain forest, UCHAD

• Application authN capability requirements entail need to handle both kerberos (for AD-integrated resources) and LDAP

Page 33: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 33

Federate or Coordinate?

• Shibboleth and MS style of federating technologies – might be feasible

• Complex technical requirements • IT organizations not prepared for that• More to be gained by coordinating IdM

operations of UCH IT and UC central IT– Many people’s activities straddle the line between UC

and UCH– Infuse account and access management processes

with info about people’s combined UC/UCH affiliations

Page 34: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 34

UCH-UC Coordinated IdMS

UCH-HR

UC Person Registry

UCHADaccount mgmt

processes

UC CNetmgmt

processes

UCHAD

Common registry identifier & username spaces

All things CNet

All things CNet

Page 35: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 35

Page 36: Adding Applications to the Enterprise Authentication System Robert Banz, UMBC Tom Barton, University of Chicago

18 Nov 2004 AuthN CAMP 36

Misc Discussion Topics, Time Permitting

1. Credential converters

2. TACACS is dead, yes?

3. webISOs, LDAP, & shib: pros & cons of policies & procedures associated with combinations of these serving intracampus apps