# Presentation: 916001

## 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
- JES 4 Overview
- JES 4 Installation
- Post-Installation
- Work in Progress
- Conclusions

## 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

## 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

## 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

## 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

**STRATEGIC DIRECTIONS**

## Strategic Directions

- Centralize information
- Account management
- Application development
- Highly available and secure
- Product selection

## 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

## 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

## 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

## 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

## 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)

## 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

**Sun Java Enterprise ****System 4 **
**2005Q4**

## 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

## 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

## JES 4 Layer Diagram

## 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

## 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

## 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’

## Solaris 10 and Zones Diagram

**Installation**

## 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

## 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

## 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

## 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

## Directory Server Diagram

## 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

## 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

## 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

## Access Manager Diagram

## 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

## Portal Server Diagram

## 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

## Web Server Diagram

**Post-Installation**

## 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

## 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

## 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

## 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

## 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!*

## 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

## 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

## 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

**Work in Progress**

## 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

## 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

## 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

## 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

## Communications

- Actively exploring alternative email/calendar solutions
- Zimbra
- Forum integration
- FUDForum
- Internal Instant Messaging
- Jabber
- RSS Feeds
- Stellent (Content Management)

**Conclusions**

## 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!

## Questions

**QUESTIONS?**
**and**
**THANK YOU!**
**David Salbego**
- _[dsalbego@anl.gov](mailto:dsalbego@anl.gov)_
**Argonne National Laboratory**