332 Enterprise Business Portals with IBM Tivoli Access Manager
15.2 Functional requirements
In this paragraph we detail the technical implications of the business model and
what they mean for security from a high-level perspective. In our scenario, the
bank has some main categories inside the application space. Although some of
them interact with each other, they can be considered independent applications
under the same framework:
The customers need to perform one login (authentication) in order to have
access to the system functions. Query transactions are all available for
customers without requiring any additional password while the session is
alive. For money transactions the customer needs to type a second
(authentication) password as a confirmation for every money transfer. The
business logic may control specific operations, values, or destination
The customers can switch between the pages and the system will maintain
proper session controls about what the user is doing. Pop-up menus are
available as quick entry points for the whole site.
All applications are visible to customers. There is no limitation on customer
access for any given application. The access control subsystem needs only to
validate whether there is a valid customer session in place. Account
restrictions apply to only show data that belongs to that particular user or any
other joint account where he/she also participates.
An integration with the existing infrastructure such as Web servers,
application servers, firewalls, authentication and authorization subsystems,
and their security features is to be pursued wherever possible.
Figure 15-1 on page 333 summarizes the functions available for users
(customers and the general public). Figure 15-1 on page 333 defines the name
of the category, as well as the specific functions that are available for users.
Those functions are either independent Web objects (pages, EJB, and so on) or
complete Web pages. For simplicity’s sake, we use the same functional names to
define the site map layout.