Chapter 16. Application integration 369
򐂰 Allow only authorized users to access any given Web application, regardless
of the source (entry point).
The idea of segregation for external and internal users creates a baseline
infrastructure for enforcing different access control enforcement points for
those entry channels, because there may be cases where you need to
enforce users to only use one specific channel (that is, internal users should
access the internal application server only).
򐂰 Control access to the application pages based on the users group
membership.
This can be accomplished either by application coding (that is, programmatic)
or by using WebSEAL (that is, independent). The ideal approach is to use
WebSEAL, keeping the access control functions transparent and independent
from the application.
򐂰 Allow transaction execution only for particular group members or individual
users.
This requirement is related to the way the application handles transactions
and how many internal back-end systems it needs to check in order to
execute a transaction. This is a more programmatic approach in the sense
that the application needs to combine different business logic to decide
whether a user is authorized for a particular operation, which can be different
for other users. This situation can even go to the limit of only allowing
operation for a user under a very special situation, such as allowing money
transfers only to predefined accounts.
16.5 Implementation architecture
We start from a working environment with Access Manager already configured.
The Access Manager Policy Server is installed in the production network,
WebSEAL machines are part of the external infrastructure, and all incoming
HTTP/HTTPS Web requests are directed to the WebSEAL servers in the DMZ.
The new system architecture also requires some additional component
installation, in particular new WebSEAL servers for internal access control. The
application may require some restructuring for some of the controls, especially to
transfer some of the WebLogic controls (as for roles) to Access Manager.
Although this is done without affecting the application code, it is worth mentioning
that any further control should now rely on Access Manager. Figure 16-2 on
page 370 shows the new system architecture that we use with additional
WebSEAL servers in the internal network, making the intranet path controlled by
370 Enterprise Business Portals with IBM Tivoli Access Manager
WebSEAL as well. The other system components stay exactly the same. The
internal users are not impacted since the transition keeps the same system
resources visible, but now with a secure and unique entry point provided by the
WebSEAL layer.
Figure 16-2 Internal access protection
16.5.1 Single sign-on for WebLogic with WebSEAL
One of the major security concerns has always been the multitude of passwords
and different login mechanisms. Web single sign-on (SSO) is the technical
response to the challenge of implementing some level of trust between Web
application components.
The Web server's trust relationship towards WebSEAL is maintained through the
junction defined between WebSEAL and the Web server. Figure 16-3 on
page 371 shows an example how WebSEAL accomplishes the trust concept by
using junctions.
Internet
Browser
External
Networks
External
Web
SEAL
Intranet
Internet
DMZ
Browser
Internal Production Network (core)
LDAP
Directory
(IPlanet)
Middleware
Server
(MQ Integrator)
External
Application
Server
(BEA WLS)
Wireless
Gateway
Clearing
System
Business
Partners
Customers
Temporary
Users
Public
(Guest)
No tes M ail
Calendar
Directory
Firewall
Firewall
Internal
Application
Server
(BEA WLS)
Internal
Web
Server
(IPlanet)
External
Web
Server
(IPlanet)
Firewall
Acess
Manager
Policy
Server
Security
Policies
Mobile
Devices
Technical
Staff
Back-
Office
Backend
database
(Oracle)
Statement
System
Account
System
CRM
Internal
Web
SEAL
Chapter 16. Application integration 371
These junctions can be configured for different levels of trust:
򐂰 They can use SSL encryption for data transfer between WebSEAL and the
back-end Web servers.
򐂰 When using an SSL junction, WebSEAL automatically verifies the server-side
certificate of the back-end Web server.
򐂰 Both WebSEAL and the back-end Web server can implement mutual
authentication using the SSL junction.
To learn more about the details of configuring junctions, refer to the
IBM Tivoli
Access Manager for e-Business WebSEAL Administration Guide Version 3.9
,
GC23-4682.
Figure 16-3 WebSEAL trust concept
The other essential aspect of trust is the WebLogic target application server's
trust of the requester. This requires WebSEAL to act as a front-end
authentication server while the WebLogic Server applies its own authorization
policy onto the user credentials that WebSEAL passes on. To learn more about
the different configuration options on how to pass on user credentials, refer to
Chapter 5, Authentication and delegation with Access Manager on page 97.
In our particular approach, both of the previously mentioned aspects of trust are
maintained. Additionally, all of the advantages of WebSEAL (high availability,
load balancing, state management, scalability, support for multiple identity
mechanisms, and so on) and of products that work with Access Manager apply.
WebSEAL
Internet Browser
Internet
Object/ACL
Database
User
Registry
Access Manager
Policy Server
WebSphere Application Server
Lotus Domino
BEA Weblogic Server
iPlanet Web Server
TRUST

Get Enterprise Business Portals with IBM Tivoli Access Manager now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.