| < Day Day Up > |
|
It is intended that the secure portal should be a basic solution that can be a start-off point to centralized security with WebSphere Portal Server. Both authentication and authorization of portal resources, such as portlets and pages, will be controlled by the centralized security mechanism. Authentication is the verification of the user identity. Authorization represents the permissions that a user or group has on a particular resource(s). We will use a simple portal application that uses a limited user repository. Since the solution is to be basic, the complete system will run outside of a DMZ. Network security is out of the scope of this solution. For more complete information on WebSphere security, please refer to the redbook IBM WebSphere V5.0 Security, SG24-6573.
In the following sections, we describe the functional and non-functional business requirements for the secure portal. Together, these provide the baseline for the design of the business system.
The use case model has been chosen to detail the functional business requirements. This model is a standard way of describing the system that is being built from the user's perspective. It uses text and graphics to show how users (actors) interact with the system in specific situations (use cases). This is done from the user's viewpoint and doesn't describe the system's own technical structure.
We have chosen these particular use cases since they highlight the various security aspects of the system. The use cases are as follows:
Business use cases
From the end user's perspective, we have Login, Update user profile and Customize the portal. Each of these three concentrates on a different security area.
Login shows the basic authentication.
Customize the portal displays authorization at work.
Update user profile shows how the user can update their profile inside the LDAP through the portal.
Administrative use cases
Create a user: we see the basic setup required for adding users so they can be authenticated in the system.
Manage security profiles operates on the authorization permissions for the portal.
These use case scenarios are walked through in detail in Chapter 6, "Sample use cases" on page 229.
This is a graphical overview of the main use cases and actors involved in the secure portal.
Figure 2-1: Secure portal use case diagram
A primary actor is the actor that initiates the use case.
Site Visitor: a user who visits the site but is unknown to the system.
Customer: a user who has logged on to the portal. This is a subclass of Site Visitor.
Customer Service Representative (CSR): an administration user who is responsible for providing user help. This is a subclass of Site Administrator.
Site Administrator: an administration user who is responsible for site operation, including authorization of resources.
Table 2-1 and Table 2-2 illustrate the Business and Administration use cases in a use case list.
Use case ID | Use case name | Goal in context | Primary actor |
---|---|---|---|
UC-01 | Login | For an actor to login to the site. | Site Visitor |
UC-02 | Update user profile | For an actor to update their user profile. | Customer |
UC-03 | Customize the portal | For an actor to customize their portal. | Customer |
Use case ID | Use case name | Goal in context | Primary actor |
---|---|---|---|
UC-ADM-01 | Create a user | Create a user in the site. | CSR (Site Administrator) |
UC-ADM-02 | Manage security profiles | Manage the authorization policies and customer privileges. | Site Administrator |
Table 2-3, Table 2-4 on page 18 and Table 2-5 on page 18 illustrate the Business use cases in more detail.
Use Case ID and name | UC01:Login |
Description | Primary use case for an actor to login to the site. |
Preconditions | None. |
Primary actor | Site Visitor |
Secondary actor | None |
Main scenario |
|
Alternatives |
|
Related information | Data Username, password. |
Use Case ID and name | UC02:update user profile |
Description | Primary use case for an actor to update their user profile. |
Preconditions | A logged on actor. |
Primary actor | Customer |
Secondary actor | None |
Main scenario |
|
Alternatives | |
Related information | Data User profile information. |
Use Case ID and name | UC03:Customize the portal |
Description | Primary use case for an actor to customize their portal. |
Preconditions | A logged on actor. |
Primary actor | Customer |
Secondary actor | None |
Main scenario |
|
Alternatives |
|
Related information | Data User profile information. Access policy data. |
Table 2-6 and Table 2-7 on page 20 illustrate the Administration use cases in more detail.
Use Case ID and name | UC-ADM-01:Create a user |
Description | Primary use case for an actor to create a user in the site. |
Preconditions | Actor is logged in with administrator rights. |
Primary actor | CSR |
Secondary actor | None |
Main scenario |
|
Alternatives |
|
Related information | Data User ID and password User profile information |
Use Case ID and name | UC-ADM-02:Manage security profiles |
Description | Primary use case to manage a customer's security profile. |
Preconditions | Actor is logged in with administrator rights. |
Primary actor | Site Administrator |
Secondary actor | None |
Main scenario |
|
Alternatives | |
Related information | Data User profile information Access policy data |
Non-functional requirements are business requirements that affect the operational aspect of the overall solution, for example the expected response times or hours of availability. In this section, we set out the non-functional requirements for the secure portal.
Scalability requirements
We are assuming that the secure portal will have the following scalability requirement which is a principle driver for centralized security.
A need to expand the system to provide the user with access to multiple systems using a common interface.
This can be done through the portal's own information aggregation functionalities but often access to multiple systems implies multiple logons and different user IDs, therefore implying the use of centralized security with SSO and a common access manager.
Security requirements
These security requirements relate to the identification and authentication mechanism.
All users who require access to secure portal resources must be identified.
Users are logged out after a defined period of inactivity.
Authorization/access control mechanisms
Securable resources in the portal application can be either pages or portlets.
Authorization control is always checked when a user accesses the portal application.
Access management
Access authorizations can be given to either users or groups.
There will be centralized management of access control and user accounts.
The system owner will grant/control all authorizations.
Customer sensitive data will be encrypted using SSL.
Other examples of common customer security requirements address the physical infrastructure of the system, such as protecting the internal IP addresses and site structure, denial of service defense and intrusion detection.
Other non-functional requirements which can be captured include availability, system management, service management, performance requirements, and usability.
| < Day Day Up > |
|