cosign at penn
TRANSCRIPT
WebSec
• Developed at Penn
• Three ISC-provided components:
• SSL-protected web login page (Rosetta)
• Out-of-band C client (websec_client)
• Apache module (mod_websec)
2
How it works
User
WebApp
Rosetta
KDC
Redirect
Redirect
Okay!
3
How it doesn’t work
• Timeout on login page grants no benefit
• Tokens easily hijacked in many apps
• Home-grown code bears a high burden for Penn: security analysis and maintenance
• Application provisioning requires technical ISC staff time
• Injection attacks possible via custom login pages
4
CoSign
• Developed by University of Michigan
• http://www.weblogin.org
• Components:
• SSL-protected web login page
• Apache, Apache 2, IIS filter module
• Authenticators for Java, Drupal, Plone
• Has no standalone C-client like websec
5
CoSign
• Allows for 2-factor authentication
• SSL-protected out-of-band communication
• Uses SSL to protect session cookies
• Each application has its own cookies, protecting SSO in the event of a compromise
6
7
8
9
How it works (A)
• User visits web app
• Web App redirects to CoSign
• CoSign handles login (SSO)
• CoSign redirects to WebApp with cookie
• WebApp validates cookie out-of-band
10
How it works (A)
User
WebApp
CoSign
KDC
Redirect
Redirect
Okay!
11
How it works (B)
• User visits CoSign single sign-on
• User visits WebApp
• WebApp (Apache/IIS plugin) validates cookie via its own SSL connection
12
How it works (B)
User
WebApp
CoSign
KDC
Okay!
13
CoSign @ Penn
• Internal ISC pilot is underway
• Roll-out starting October 2008
• Websec will be retired in June 2009 (one year from the announcement of Websec’s retirement)
14
Websec vs. CoSign
• Timeout on login page grants no benefit
• Tokens easily hijacked in many apps
• Home-grown code bears a high burden for Penn: security analysis and maintenance
• Application provisioning requires technical ISC staff time
• Injection attacks possible via custom login pages
15
Websec vs. CoSign
• CoSign: no login timeout
• CoSign: all pages protected by SSL
• Home-grown code bears a high burden for Penn: security analysis and maintenance
• Application provisioning requires technical ISC staff time
• Injection attacks possible via custom login pages
16
Websec vs. CoSign
• CoSign: no login timeout
• CoSign: all pages protected by SSL
• Home-grown code bears a high burden for Penn: security analysis and maintenance
• Application provisioning requires technical ISC staff time
• Injection attacks possible via custom login pages
17
Websec vs. CoSign
• CoSign: no login timeout
• CoSign: all pages protected by SSL
• CoSign: vetted and maintained by a larger audience
• Application provisioning requires technical ISC staff time
• Injection attacks possible via custom login pages
18
Websec vs. CoSign
• CoSign: no login timeout
• CoSign: all pages protected by SSL
• CoSign: vetted and maintained by a larger audience
• Application provisioning requires technical ISC staff time
• Injection attacks possible via custom login pages
19
Websec vs. CoSign
• CoSign: no login timeout
• CoSign: all pages protected by SSL
• CoSign: vetted and maintained by a larger audience
• CoSign: ...
• Injection attacks possible via custom login pages
20
CoSign provisioning
• ISC developing a self-provisioning application
• PennKey-protected
• Identifies owners of services
• Generates SSL certificates for out-of-band service identification/communication
• Registers your application with the CoSign servers
21
CoSign provisioning
22
CoSign provisioning
• Your server must have CoSign’s Apache or IIS module (or related) compiled and installed
• All web services must be SSL-protected (*)
23
Websec vs. CoSign
• CoSign: no login timeout
• CoSign: all pages protected by SSL
• CoSign: vetted and maintained by a larger audience
• CoSign: ISC developing a self-provisioning application
• Injection attacks possible via custom login pages
24
Websec vs. CoSign
• CoSign: no login timeout
• CoSign: all pages protected by SSL
• CoSign: vetted and maintained by a larger audience
• CoSign: ISC developing a self-provisioning application
• CoSign: ...
25
Websec Login Pages
User
WebApp
Rosetta
Get custompage
KDC
26
Websec On A Bad Day
User
WebApp
Rosetta
Get custompage
Compromised
KDC
Hacker
27
CoSign login pages
• Separating “splash” pages from AuthN
• Removes all injection attacks; the login page is completely hosted on the new “Rosetta”
• Single sign-on means we can’t force an app to a specific login page if the user is already authenticated
• Applications set an “entry point” to a particular page on their site instead
28
Websec vs. CoSign
• CoSign: no login timeout
• CoSign: all pages protected by SSL
• CoSign: vetted and maintained by a larger audience
• CoSign: ISC developing a self-provisioning application
• CoSign: no custom login pages
29
Websec vs. CoSign
• CoSign: no login timeout
• CoSign: all pages protected by SSL
• CoSign: vetted and maintained by a larger audience
• CoSign: ISC developing a self-provisioning application
• CoSign: no custom login pages
30
CoSign configuration
31
CoSign: Apache config
CosignProtected on CosignHostname weblogin.upenn.edu CosignService scts.seas.upenn.edu CosignRedirect https://weblogin.upenn.edu/login CosignPostErrorRedirect https://weblogin.upenn.edu/post_error.html CosignCrypto /etc/apache2/ssl/cosign-scts.seas.upenn.edu.key \
/etc/apache2/ssl/cosign-scts.seas.upenn.edu.crt \/etc/apache2/cosign-certs/
CosignRequireFactor UPENN.EDU
32
CoSign Factors
• Each “factor” is defined by the central installation and enforced by the application
• Right now, we only support one factor (UPENN.EDU)
• The ISC implementation will ultimately support two factors (UPENN.EDU + OTP)
33
CoSign: Apache AuthN
• .htaccess or Apache httpd.conf <Directory>
CosignProtected OnAuthType Cosignrequire user jorj perch chip andersonCosignRequireFactor UPENN.EDU
34
CoSign: Application View
• The web application sees some new environment variables (set by Apache)
REMOTE_USER jorj
REMOTE_REALM UPENN.EDU
COSIGN_SERVICE cosign-scts.seas.upenn.edu
COSIGN_FACTOR UPENN.EDU
AUTH_TYPE Cosign
35
CoSign: Apache AuthZ
• Not CoSign, but mod_authz_ldap
AuthLDAPURL ldap://directory.upenn.edu/ \ou=people,dc=upenn,dc=edu?uid
AuthzLDAPAuthoritative onAuthLDAPCompareDNOnServer on#Require ldap-dn uid=jorj,ou=people,dc=upenn,dc=eduRequire ldap-user jorj
• DON’T DO THIS. You really want Penn AuthZ LDAP servers, not Directory
36
Shibboleth
• Internet2 Middleware Initiative project
• http://shibboleth.internet2.edu
• Provides federated single-sign on
• Do you want CoSign or Shibboleth?
• ISC’s Shibboleth project builds on top of CoSign
• More on Shibboleth next month...
37
CoSign: single sign-OFF
• Applications may destroy their own tokens to log-out
• CoSign also has a global logout page which destroys the master cookie
• Applications may still function for up to two minutes after global logout
38
Impact on LSPs
• In June 2009, WebSec will cease to function
• LSPs will have to self-provision and configure CoSign for all of their WebSec applications
• CoSign has no custom login pages
• Advertised entry points through “rosetta.upenn.edu” will need to be updated
• Applications with external focus may want Shibboleth instead of CoSign
39
Any Questions?
• More documentation will be available as the pilot starts
• As usual, help can be requested via Prodesk
• Until this goes into production, you can mail me directly <[email protected]>
40
Any Questions?
This presentation is on the web at:
http://www.jorj.org/isc/cosign.pdf
41