306 Enterprise Business Portals with IBM Tivoli Access Manager
򐂰 First the user is authenticated by the WAP gateway using user ID and
password.
򐂰 The mobile user request is then routed to WebSEAL.
򐂰 WebSEAL is configured to receive an authenticated user from the WAP
gateway and will not re-authenticate the user but perform further authorization
if needed.
򐂰 WebSEAL uses the MPA support to connect to the WAP gateway
(Appendix F, MPA authentication flow on page 543).
12.6 Technical implementation
This section describes some specifics of this solution; common prerequisites
were mentioned in the previous scenarios already.
Authentication method
The authentication method used for the mobile WAP devices is basic
authentication. Due to the flexibility of our approach even upcoming technologies
based on wireless PKI (wPKI) and certificates can be easily integrated at a later
time.
Common LDAP directory
When using the IBM WebSphere Everyplace Wireless Gateway and its WAP
capabilities, WebSEAL and EWG can be set up to use the same schema in the
LDAP directory. They both can exploit a common inetOrgPerson entry for a given
user. IBM WebSphere Everyplace Wireless Gateway will attach a wlUser
auxiliary object to the inetOrgPerson, and WebSEAL will create a secUser object
under the inetOrgPerson.
Distributed environment
If the wireless gateway is placed in a trusted zone, and WebSEAL is physically
placed at a different trusted location, additional mechanisms like VPN should be
used to establish secure links.
Note: Non-repudiation is not addressed in this scenario, but as mentioned in
8.2.3, WAP security architecture on page 190, it can be achieved by using a
digital signature.
Chapter 12. Pay-As-You-Drive 307
High availability
In order to handle high traffic networks, IBM WebSphere Everyplace Wireless
Gateway can be implemented in a clustered environment. Clustering means that
several machines are running one instance of the IBM WebSphere Everyplace
Wireless Gateway software. Workload from one or more network connections are
distributed across them.
Load balancer and caching proxies should be used to achieve high availability of
WebSEAL and content servers.
12.6.1 Integration into existing infrastructure
The security infrastructure based on the Access Manager infrastructure and
WebSEAL is expanded by integrating the WAP gateway into the authentication
process.
Because of the lack of heavy transactional processing, transcoding of different
back-end content will not be used in the first step, so YRI decided to develop the
required WML coding (for example, WML forms) on its own. But YRI is already
thinking of deploying new services to its clients and of course integrating
pervasive computing models like intelligent cars. Therefore a transcoding model,
as discussed in Chapter 18, Wireless integration on page 477, is also suitable
for future services.
YRI already plans future enhancements like intelligent notification and
location-based services for its clients using WebSphere Everyplace Server as a
platform (see Appendix A, IBM WebSphere Everyplace Suite - An overview on
page 489).
12.6.2 Conclusion
We have shown in this scenario that a given infrastructure can be extended to
meet new business requirements. To assure secure access for mobile devices
todays WAP environment and its WTLS support is already suitable to provide a
certain level of wireless security.
The main requirement to use WebSEAL as the focal point for authentication and
authorization issues is met using the features of WebSEAL to connect to WAP
gateways in a secure way and to assure that no other back-end resources than
the required ones can be accessed.
308 Enterprise Business Portals with IBM Tivoli Access Manager

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.