2.1 Requirements analysis

 < Day Day Up > 



2.1 Requirements analysis

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.

2.1.1 Functional requirements

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.

Use case diagram

This is a graphical overview of the main use cases and actors involved in the secure portal.

click to expand
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.

Use case list

Table 2-1 and Table 2-2 illustrate the Business and Administration use cases in a use case list.

Table 2-1: Business use cases

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

Table 2-2: Administration use cases

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

Business Use case details

Table 2-3, Table 2-4 on page 18 and Table 2-5 on page 18 illustrate the Business use cases in more detail.

Table 2-3: UC-01:Login

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

  1. The system prompts for the actor to enter their user ID and password.

  2. The actor enters a user ID and password.

  3. The system verifies that the user ID and password are valid.

  4. The system acknowledges that it has accepted the user ID and password and logs the actor in.

  5. The use case ends successfully.

Alternatives

  • Invalid user ID or password.

    • The system determines the user ID or password is incorrect.

    • The system reports the user ID or password is incorrect.

    • The use case ends in failure.

Related information

Data

Username, password.

Table 2-4: UC-02:Update user profile

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

  1. The system displays for the actor their user profile and prompts for updates.

  2. The actor updates their user profile.

  3. The system verifies that the actor has the correct authorization.

  4. The system acknowledges that it has updated the user profile information.

  5. The use case ends successfully.

Alternatives

 

Related information

Data

User profile information.

Table 2-5: UC-03:Customize the portal

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

  1. The actor clicks to view a particular portlet.

  2. The system checks the actor authorization on that portlet.

  3. The system displays the actors portlet with the allowed permissions.

  4. The actor chooses to edit their portlet.

  5. The system displays the portlet customization view.

  6. The actor customizes their portal.

  7. The system stores the portal customizations.

  8. The use case ends successfully.

Alternatives

  • Incorrect authorization

    • The system determines the authorization is incorrect.

    • The system reports the authorization is incorrect.

    • The use case ends in failure.

Related information

Data

User profile information.

Access policy data.

Administration use case details

Table 2-6 and Table 2-7 on page 20 illustrate the Administration use cases in more detail.

Table 2-6: UC-ADM-01:Create a user

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

  1. The system prompts for new user data.

  2. The actor inputs the necessary data.

  3. The system verifies that the actor has the correct authorization.

  4. The system creates the new user in the site.

  5. The system acknowledges the new user has been created.

  6. The use case ends successfully.

Alternatives

  • User created exists already

    • The use case ends in failure

Related information

Data

User ID and password

User profile information

Table 2-7: UC-ADM-02:Manage security profiles

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

  1. The actor checks the authorization for a particular resource.

  2. The system returns the authorization details.

  3. The actor updates the authorization data for the particular resource.

  4. The resource is displayed with the updated information.

  5. The actor then verifies that the resource authorization update has occurred in Portal.

  6. The system returns the correct response and the use case ends successfully.

Alternatives

 

Related information

Data

User profile information

Access policy data

2.1.2 Non-functional requirements

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 > 



Secure Portal. Using Websphere Portal V5 and Tivoli Access Manager V4. 1
A Secure Portal Using Websphere Portal V5 and Tivoli Access Manager V4.1
ISBN: 073849853X
EAN: 2147483647
Year: 2003
Pages: 73
Authors: IBM Redbooks

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net