Universal Certificate Authentication to Key Applications at Argonne National Laboratory

1. Universal Certificate Authentication to Key Applications at Argonne National Laboratory Presented at 6th Annual PKI R&D Workshop April 18th, 2007 Doug Engert, Rich Raffenetti, David Salbego, John Volmer

3. Introduction • In 2003, Argonne set out to re-architect its operations web presence • Primary issues: • Key web resources and applications spread far and wide • No central employee web site • Poor search engine • Weak security due to multiple authentication back-ends • Multiple development platforms • Few standards • No redundancy

4. Technical Solutions • Implement Sun Java Systems product suite • Portal Server • Access Manager and Policy Agents • Directory Server • Application Server • Use F5 BigIP load balancers for redundancy • Use Google Search Appliances for search engine • Develop an internal Portal to centralize information • Standardize Java development • Link password authentication to Active Directory • Investigate widespread use of other authentication methods, especially user certificates … this talk focuses on the bolded items!

5. Policy Agents Overview • Provide single sign-on capability for external applications and services • Supported on most major web and application servers • Utilizes SSO cookie token provided by Access Manager • Cookie must be protected • Cookie can be made “restricted” to prevent unauthorized use • Cookie can be tied to specific agent and application • Policy agents do not directly accept user credentials • They rely on SSO tokens provided by Access Manager • Access Manager performs actual validation of credentials

6. Policy Agent Flow Diagram

7. Policy Agent Flow Description • User accesses application through a web browser. Agent intercepts and checks for a valid SSO token (browser session cookie) • If not valid, redirect to Access Manager Authentication Service. Agent also provides its identity. • After successful authentication, redirects user back to target application with SSO token as part of URL query parameter. • Agent receives SSO token and sets it as session cookie for the host. • Agent validates SSO token with Session Service. • Agent checks permissions against Policy Service. • User is allowed to access application. • Same SSO token cannot be used to gain access to another application since SSO token is unique to each application and may not be shared or reissued to other agents or applications.

8. Policy Agent Usage Example – Web Server • Convert existing application which relies upon HTTP “basic” authentication to use Access Manager Policy Agent • Assumes web server owns access control • Assumes simple application that relies upon REMOTE_USER • Simplified outline of steps to convert application: • Install policy agent on SSL-protected web server • Adds a few lines into web server configuration to load the module • Agent uses a separate configuration file • Modify agent configuration file to protect resource • https://myserver.gov:443/my/protected/URL • Create policy on Access Manager for web server and URL • https://myserver.gov:443/my/protected/URL • Remove original web server access control

9. Policy Agent Usage Example – continued • Common problem: • Many applications include their own authentication mechanisms • Form-based logins instead of HTTP “basic” authentication • Examples: Forum software, Stellent, Wikis, … • Such applications require more work to convert • Level of difficulty depends upon how code is structured • However… • Many enterprise application vendors are learning to accept the growth of SSO within infrastructures • A number of vendors claim to integrate with such solutions, usually with a bit of consulting services • Simple LDAP-based mechanisms to tie into enterprise authentication/authorization services are not enough anymore

10. Policy Agents – Supported Software • URL Agents for web servers • Sun • Microsoft IIS • Apache • J2EE Agents for Java Application servers • Sun Application Server 7, 8, BEA WebLogic, IBM WebSphere • Red Hat JBoss 4, Oracle • Many others exist, including: • Tomcat, Domino, SAP Portal

11. Access Manager Overview • Provides single sign-on capabilities in conjunction with Policy Agents • Centralizes authorization services • Integrates with many external authentication providers if desired • Component of larger “Identity Manager” product suite • Open-sourced at http://www.opensso.dev.java.net/

12. Access Manager - Authentication Modules • All Argonne employees and on-site users have Active Directory accounts • About 8,000 total • Argonne uses two authentication modules: • X.509 User Certificates • Smartcards • ~100 users in pilot test • Includes PIV smartcards for use in Windows and Unix • Microsoft Certificate Authority • for all Active Directory users • Kerberos Certificate Authority (KCA) • KX509 – for use on any platform • LDAP • For those not using certificates (usernames/passwords)

13. Access Manager - Authentication Chaining • An authentication chain is a list of possible user authentication modules • Preference to particular modules can be given • Multiple modules can be required • Modules can be given an ‘authentication level’ • Benefit as a transition technology – multiple authentication techniques can be used simultaneously • At Argonne: • Look for user certificate • If not available or not accepted, request username and password • Password checked against Active Directory • Provides ability to bypass certificate authentication!

14. Access Manager – Module Diagram

15. Access Manager - Certificate Notes • The certificate issuers’ certificates must be imported and trusted by the Access Manager web server • Client-side certificates must be defined as “optional” by the web server • Must allow username/password logins • Access Manager must be able to map a certificate to an Access Manager profile • This is not a requirement in general, but it is enforced at Argonne • The certificate subject CN is used to map to an Access Manager profile

16. Benefits • ~600 users daily rely on their browser certificate to reach key applications • Goes up dramatically during key times (appraisals, benefits) • Applications rely upon Policy Agent for authentication and authorization information – do not have to code for authentication • Developers can code to the same standards • Applications do not have to be re-written to conform to new or changing security standards – changes isolated to Access Manager • Using certificate authentication instead of passwords did not require any application re-writing, for example • Non-web-based applications can be integrated using standard API

17. Ticket Ticket Ticket Auto-Enroll Log in user name password user name password Win XP Portal Server Non AD Log in Access Manager Content Web Servers Domain Controller CA Directory Server Policy Agent Java App Servers Unix Policy Agent Win XP KCA Smart Card Log in Fig.7: Authentication Communication From Logon to Application Credentials Diagram

18. Access Manager Diagram

19. Site Map