David Salbego Unix and Operations Manager Computing and Information Systems

1. How to Deploy a Centralized Web Portal for Accessing all Business, Communications, and Back-Office Applications David Salbego Unix and Operations Manager Computing and Information Systems Argonne National Laboratory dsalbego@anl.gov

2. Agenda • Before the Portal • Strategic Directions • JES 4 Overview • JES 4 Installation • Post-Installation • Work in Progress • Conclusions

3. About Argonne National Laboratory • Chartered in 1946 as the nation’s first national laboratory • Operated by the University of Chicago for the Department of Energy • About 3000 employees – over 1000 scientists and engineers • About 25 miles southwest of Chicago’s Loop • Occupies 1500 wooded acres • Supports upwards of 200 research projects

4. Pre-Portal Environment • Information, resources, and applications spread across over 150 internal and external web sites • Majority of servers are scientific, not business systems • Two primary web sites – one internal, one external • Lots of information shared between both sites • Netscape Compass search engine

5. Types of Applications • Web content and applications spread across multiple servers • Microsoft IIS • Apache • Sun • Java applications spread across multiple servers • JBoss • JRun • Sun • Client/server applications • Locally installed • Citrix farms • Remote desktop

6. Issues • Information scattered across many sites • Multiple user accounts and passwords • Difficult to support • Expertise spread across multiple environments • No clear technology direction • Lack of solid search engine

7. STRATEGIC DIRECTIONS

8. Strategic Directions • Centralize information • Account management • Application development • Highly available and secure • Product selection

9. Centralize Information • Create internal-only Portal for employees • Collect and organize resources, services, applications, gateways • Provide ability for delivering custom content • Implement world-class search engine

10. Account Management • Provide a single username and password where reasonable • Accept alternative forms of authentication beyond username/password • Provide strong authentication mechanisms where needed • Provide single sign on (SSO) where possible

11. Application Development • Redefine strategy for application development and deployment • Large/complex applications: Java • Smaller applications: PHP and related • Standardize on a Java application server environment

12. Highly Available and Secure • Environment should be architected around high availability • Systems providing content should be highly available • Standardize environment for content managers • High availability should not get in the way of publishing information • Products should have a track record of security • Product architecture should allow for security

13. Production Selection • Sun Java Enterprise System – site-wide license • Uses standard protocols • Long product history for many components • Used by peers • Attractive price • Existing expertise • Sun Fire SPARC servers • Natural fit in our environment • F5 BigIP application switches (load balancers) • Industry leader • Google GB-1001 search engine appliances (two)

14. Original Install: Java Enterprise Server 1 • Original deployment used Sun JES 1 across multiple servers • A number of issues and limitations existed • Did not isolate certain components • Provided a good learning experience • Later product improvements provided clear reason to re-architect

15. Sun Java Enterprise System 4 2005Q4

16. JES 4 Components Implemented • Directory Server • High-performance, scalable LDAP server • Access Manager + SDK • Provides authentication, authorization • Portal Server • Additional components include remote access, instant messaging … • Web Server • Contains JVM and JSP support • Application Server • J2EE • Policy Agents • SSO support • Message Queue • Java Message Service implementation

17. JES 4 Layers • Portal server requires: • Directory server • Access Manager • Web or Application server • Access Manager requires: • Directory server • Web or Application server • Access Manager session failover requires: • Message Queue • Policy Agents require: • Access Manager

18. JES 4 Layer Diagram

19. Environment Strategy • Deploy Portal, Access Manager, and Directory on two physical servers • Utilize Solaris 10 zones to provide component isolation • Deploy Application servers on two separate physical servers • Create development environment • Utilize load balancers to create virtual services for major components • Directory • Access Manager • Portal • Application servers • Back-end web servers

20. Load Balancers/Application Switches • Provide a ‘virtual service’, creating separation between physical servers and the services they provide • Typically act as a gateway between public and private networks • Can route data for incoming requests based on a wide variety of factors • Can provide persistence to back-end servers • Can offload SSL processing for performance gains • Can be pricey • Installed in pairs for redundancy

21. Solaris 10 and Zones • Zones are ‘virtual servers’ running on the operating system • Have their own IP address • Can be rebooted independent of global zone • Provide isolate between other zones • Can be CPU-limited • Are easy to create and destroy (quick rebuilds) • Zones provide nearly complete isolation within the same server • Software is not aware it is running in a ‘zone’

22. Solaris 10 and Zones Diagram

23. Installation

24. Operating System - Portal • Servers providing Directory, Access Manager, and Portal services • Two Sun Fire V240 servers • 2 x 1.2 GHz UltraSPARC IIIi CPUs • 3 GB RAM • Global plus two zones per server • Zone 1 • Directory server, Access Manager, Web Server • Zone 2 • Portal server, Web server, Access Manager SDK • Solaris 10 • Behind load balancers

25. Operating System – Java • Servers providing Java application services • Application Server 8.1 • J2EE Policy Agent • Two Sun Fire V240 servers • 2 x 1.5 GHz UltraSPARC IIIi CPUs • 4 GB RAM • Global zone installation • Solaris 10 • Behind load balancers

26. Operating System – Web • Servers providing general web services, including back-end content for Portal servers • Web Server 6.1 • URL Policy Agent • Two Sun Fire V240 servers • 2 x 1.2 GHz UltraSPARC IIIi CPUs • 4 GB RAM • Global zone installation • Solaris 9 • Behind load balancers

27. Directory Server • Installed on separate zone • Implemented multi-master replication (MMR) • Allows any back-end server to accept writes • Servers keep each other in sync • Utilizing SSL with MMR requires special certificate • Created virtual service TCP 389 on load balancers • Install on second server requires some initial steps to get MMR working properly

28. Directory Server Diagram

29. Access Manager • Installed in same zone as Directory • Ideally, installed in own zone • For smaller installations, not a big deal • Deployed in web container (web server) instead of J2EE server • Configured to use ‘virtual service name’ for directory services • Created virtual service TCP 80 on load balancers • Not using SSL yet – installing against SSL causes problems • Install on second server requires some configuration changes to get both instances recognized

30. Access Manager Session Failover • Session information shared between Access Managers • Eliminates single point of failure – any Access Manager can provide session information to clients • Session information also stored on disk instead of memory – can stop and start web container without losing session information • Configuration setup provided by script – very straightforward • Sessions on each Access Manager viewable through single console

31. Access Manager Session Failover Components • Message Queue • Provides communication mechanism between Access Manager instances • HADB • Used by Message Queue/Access Manager to provide on-disk session information • Setup script • Provided by Sun to easily configure above components

32. Access Manager Diagram

33. Portal Server • Installed in its own zone • Deployed in web container (web server) instead of J2EE server • Utilizes Access Manager SDK to communicate with Access Manager • Configured to use virtual service name Directory and Access Manager • Created virtual service TCP port 80 on load balancers • Not configured with SSL – yet

34. Portal Server Diagram

35. Web Servers • Pre-existing load-balanced web server farm • Provide content to Portal as well as many standalone web sites • Utilizes Policy Agent for Access Manager integration • Utilizes shared back-end filesystem for content • Andrew File System (AFS) • Replicated volumes for redundancy • Web developers have direct access to filesystem on their Windows, Macintosh, Linux, and Solaris desktops • Developers deploy to development volumes used by development web servers, then push to production

36. Web Server Diagram

37. Post-Installation

38. Enabling SSL • Request, install certificate on first server • Copy certificate to second server, rename as needed • Directory server • Must keep TCP 389 enabled for MMR • Access Manager • Must change a number of configuration files • This one is the most difficult • Portal • Straightforward • Load balancer virtual services created

39. Disabling non-SSL • Directory server • We must keep TCP 389 enabled for MMR unless special certificate was used (with ‘AltName’ field) • Access Manager • We do not want authentication information going across unencrypted • Portal • Some sites do not feel comfortable with non-SSL Portal • Appropriate load balancer virtual services removed

40. Application Tuning • Sun provides tuning scripts for a number of components • Tuning scripts focus on: • web and application server containers • directory server • operating system • Scripts use user-provided parameters to help make intelligent guesses regarding settings • Best to perform tuning BEFORE enabling SSL! • Scripts use commands that are not SSL-aware

41. Access Manager Authentication Modules • LDAP • Any compliant LDAP server, including Active Directory • X.509 User Certificates • Smartcards • Automatically-deployed/generated certificates • KX509, MS CA for IIS • RADIUS • SAML • SecureID • Unix • SPNEGO (Windows Desktop SSO) • Others

42. Access Manager Authentication Chaining • An authentication chain is a list of possible user authentication methods • Preference to particular methods can be given • Multiple methods can be required • Methods can be given an ‘authentication level’ • At Argonne: • Look for user certificate • If not available or not accepted, request username and password • Password checked against Active Directory • Provide ability to bypass certificate authentication!

43. Policy Agents • Provide single sign-on capability for external applications and services • Straightforward implementation on major software (web and app servers) • Highly flexible, especially with custom code • Utilizes SSO cookie token provided by Access Manager • Policy Agents are only one way to utilize Access Manager services from remote • Other methods, including SAML, are available

44. Policy Agents • URL Agents for web servers • Sun web server • Microsoft IIS • Apache • J2EE Agents for Java Application servers • Sun Application Server 7 • Sun Application Server 8.1 • JBoss 4 • Many others exist, including: • BEA WebLogic • IBM WebSphere • Oracle

45. Account Management • Access Manager account synchronization with Active Directory • Flat DIT versus hierarchical • Organizational moves • Utilize Access Manager SDK • Non-SSO-Enabled applications • Utilize same name/password • Role/group creation based upon HR information • Cyber security representatives • Managers • Telephone coordinators • Employees vs contractors

46. Work in Progress

47. Recent Completions • JBoss Java Application server migration • Completed • Sun Java Application server 7.0 migration • Sun provides helpful tool for move to 8.1 • Completed • JRun Application server migration • Completed

48. Legacy Applications • Powerbuilder client/server applications • Oracle usernames and passwords • No web access • Accounts are disconnected from rest of world • Solutions • Custom Access Manager code • Rewrite applications for web • Enterprise identity management solution

49. SSO • Apache • Agents available for v1 and v2 • Limited testing has been successful • Looking to deploy to production soon • OpenSSO project == Sun Access Manager • Microsoft IIS • Agents available for v5 and v6 • Used to have issues with multiple web sites on same server • Have not tested yet for IIS 6 • Both utilize Active Directory accounts today • Apache via LDAP module • IIS natively • Not a top priority – main advantage is SSO

50. Identity Management • Exploring Sun’s Enterprise Identity Management solution • Sophisticated product has come a long way • A number of peers are testing it • Argonne will be piloting the product in the next month or three • Part of Java Enterprise Server package – already licensed! • A consulting engagement is highly recommended for larger installs