340 likes | 349 Views
This article discusses the current state of authentication at Penn State University, including definitions, account types, and the use of authentication technologies such as Kerberos and LDAP. It also explores future directions for authentication at the university.
E N D
Authentication at Penn State:The Present State of Affairs and Future Directions James A. Vuccolo, Manager, Software Technologies Group Phil Pishioneri, Manager, UNIX Systems and Technical Solutions Group Advanced Information Technologies (AIT) in Academic Services and Emerging Technologies (ASET), a unit of Information Technology Services (ITS)
Agenda • Introduction • Current State of Affairs • Future Directions • Wrap Up
Introduction • Definitions • Account Types
Definitions • Authentication (AuthN) • The process of validating that a user is who he or she says they are • Is the user’s Userid and Password correct? • Authorization (AuthZ) • The process of deciding if a user is allowed to have access to a service • Is the user allowed to view a specific Web page? • Single Sign-On (SSO) • The process by which a user logs on to a site and then can visit other “protected” sites without the need to re-authenticate
Account Types • Access Account • A digital identity and password that enables Penn State students, faculty, and staff to use the full range of services either on or off campus • Provides: Authentication, E-mail, PASS and an LDAP Entry • Friends of Penn State Account • A digital identity and password that enables users outside of Penn State to access applications within Penn State. (Most likely for Web-based applications). • Provides: Authentication
Current State of Affairs • Penn State Infrastructure • Web Access Methods
Penn State Infrastructure • Distributed Computing Environment (DCE) • Based on Kerberos V • Provides Authentication and Authorization • Distributed File System (DFS) • Enterprise-wide file system • Also known as PASS (Penn State Access Account Storage Space)
Demise of DCE/DFS • IBM’s DCE/DFS, which is at the core of Penn State’s infrastructure no longer will be supported after April 2006 • ASET/ITS is looking for replacement options • DCE = Kerberos V + LDAP • DFS = ???
Future Directions • Kerberos (Authentication) • LDAP (Authorization) • CoSign (SSO)
Kerberos • What is Kerberos? • Kerberos Configuration Files • Things to Know
What is Kerberos? • Kerberos is: • “…a network authentication protocol. It is designed to provide strong authentication for client/server applications using secret-key cryptography” • http://www.mit.edu/kerberos/www/ • Components • Key Distribution Center (KDC) • Masters (located in Computer Building) • Back-ups (located off-site) • Clients • Application Servers
Access Accounts [libdefaults] default_realm = dce.psu.edu default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc [realms] dce.psu.edu = { kdc = fido.aset.psu.edu:88 kdc = sparky.offsite.psu.edu:88 kdc = scooby.aset.psu.edu:88 default_domain = .psu.edu } [domain_realm] .psu.edu = dce.psu.edu psu.edu = dce.psu.edu [logging] default = FILE:/var/log/krb5/krb5lib.log Friends of Penn State Accounts [libdefaults] default_realm = fops.psu.edu default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc [realms] fops.psu.edu = { kdc = fps.aset.psu.edu:88 kdc = rover.offsite.psu.edu:88 default_domain = .psu.edu } [domain_realm] .psu.edu = dce.psu.edu psu.edu = dce.psu.edu [logging] default = FILE:/var/log/krb5/krb5lib.log Kerberos Configuration Files
Things to Know • Our Access Account Kerberos KDCs are fully synced with DCE using Kerberos propagation • A full copy of the Kerberos database is dumped • kprop command is used to sync the back-up KDCs • This done is every 15 minutes, so password changes are not immediate • Using MIT Kerberos solves a number of problems using tools such as Java for authentication
LDAP • What is it? • Authorization Mechanisms • Roles • Groups • Examples • DCE vs. LDAP ACLs
What is it? • Lightweight Directory Access Protocol (LDAP) • Is a standard technology for network directories • Network directories are specialized databases that store information about devices, applications, people and other aspects of a computer network • At Penn State, LDAP is the replacement for Ph • Usage Info • Server: ldap.psu.edu • Port: 389 • Search Base: dc=psu,dc=edu
Roles • Are attribute/value pairs • Examples (from my entry) • eduPersonPrimaryAffiliation=STAFF • eduPersonEntitlement=URN:PSU.EDU:MUSIC • Users • Penn State Portal • Shibboleth • Napster • Physics Class • PHEAA (Future application)
Groups • DN containing a list of member DNs • Types • Static • Dynamic • Hybrid • Nested • Rich set of Access Control Lists (ACLs) features
Static Group Dn: cn=AIT Staff,dc=psu,dc=edu objectClass: groupOfNames Cn: AIT Staff Member: psDirIdn=4,dc=psu,dc=edu Member: psDirIdn=5,dc=psu,dc=edu Dynamic Group Dn: ITS Staff,dc=psu,dc=edu objectClass: groupOfURLs Cn: ITS Staff memberURL: ldap:///dc=psu,dc=edu??subtree?(psAdminArea=ITS) Group Examples
DCE R = Read W = Write X = Execute C = Control I = Insert D = Delete LDAP R = Read W = Write S = Search C = Compare A = Add D = Delete DCE vs. LDAP ACLs
CoSign • WebAccess • WebAccess Adopters • Supported Web Servers • Overview of Process • Sample Configurations • WebAccess Login Page • WebAccess in Action…
CoSign • Technology behind the WebAccess service • Scheduled to be available this summer • Initially only Access Accounts – FPS to be added • Developed by the University of Michigan
WebAccess • Provides Single Sign-On for Web-based services • Cf. FPS API • One login per session/timeout • No application coding • Password never on your Web server • Can be combined with other functions to provide authorization (LDAP, local groups, etc.)
WebAccess Adopters • Initial ITS Services converting to it • Penn StatePortal • Penn State WebMail • eLion • ANGEL
Supported Web Servers • Apache (1 & 2) • IIS (5 & 6) • Tomcat
Overview of Service Login • Case of person browsing to the service Web page (e.g., https://service.psu.edu/) • Similar flow if starting from the WebAccess login page • Based on documents written by University of Michigan
Sample Configurations • Apache • IIS
Apache LoadModule cosign_module libexec/mod_cosign.so CosignProtected On CosignHostname webaccess.psu.edu CosignRedirect https://webaccess.psu.edu/ CosignPostErrorRedirect https://webaccess.psu.edu/post_error.html CosignService webconf-test CosignCrypto /psuopt/conf/ssl.key/my.key /psuopt/conf/ssl.crt/my.crt /psuopt/conf/ssl.crt
IIS <Cosign> <CAFilePath>C:\Program Files\IISCosign\SSL\ASET-CA.pem</CAFilePath> <ChainFilePath>C:\Program Files\IISCosign\SSL\testsys.aset.psu.edu.cert</ChainFilePath> PrivateKeyFilePath>C:\Program Files\IISCosign\SSL\testsys.aset.psu.edu.key</PrivateKeyFilePath> <LogFilePath fileSizeInKB="4096">C:\Program Files\IISCosign\Logs</LogFilePath> <CookieDBPath>C:\Program Files\IISCosign\CookieDB</CookieDBPath> <CosignServer port="6663">webaccess.psu.edu</CosignServer> <RedirectURL>https://webaccess.psu.edu/?</RedirectURL> <ConnectionPool size="4" /> <CookieDBExpireTime seconds="60" /> <WriteDataToEventViewer>FALSE</WriteDataToEventViewer> <CheckIPAddress>FALSE</CheckIPAddress> <Service website=“testsys.aset.psu.edu">cosign-testsys-its Protected>/protected.htm</Protected> </Service>
Wrap Up • Questions?