adding applications to the enterprise authentication system robert banz, umbc tom barton, university...
TRANSCRIPT
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.
18 Nov 2004 AuthN CAMP 3
Outline
• Rob: Synchronization vs. integrated authN architectures
• Tom: Two case studies from U 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
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.
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?
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.
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
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!
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
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…
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?
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
18 Nov 2004 AuthN CAMP 14
Common Authentication Examples
• Hybrid Models– Authentication store in KDC– LDAP “plugin” verifies passwords against KDC
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
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
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!
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.
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…
A Peek Under U Chicago’s Kimono
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
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
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
18 Nov 2004 AuthN CAMP 24
Option 1 for Gargoyle authentication
• Migrate garg.local into UCAD, UofC’s primary AD forest
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
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
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
18 Nov 2004 AuthN CAMP 28
Option 3 for Gargoyle authentication
•Use a forest trust, garg.local trusting ad.local, UCAD’s forest root
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
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
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
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
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
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
18 Nov 2004 AuthN CAMP 35
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