Embed Size (px)
Citation preview
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
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
51
Communications
Actively exploring alternative email/calendar solutions
– Zimbra
Forum integration
– FUDForum
Internal Instant Messaging
– Jabber
RSS Feeds
Stellent (Content Management)
52
Conclusions
53
Lessons Learned, Random Notes
Prepare yourself – read the JES documentation
– And Sun BluePrints
Consider consulting services
– Or someone who has done it before
Utilize Solaris 10 and zones
– Much easier to recreate a zone then a server
Load balancers
– Many times have been blamed, but rarely the cause
Test, test, test after each change
Document everything!
54
Questions
QUESTIONS?
and
THANK YOU!
David Salbego
Argonne National Laboratory
