1 / 54

David Salbego Unix and Operations Manager Computing and Information Systems

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. Agenda. Before the Portal Strategic Directions

Download Presentation

David Salbego Unix and Operations Manager Computing and Information Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related