Políticas de efectivo y activo circulante

This section describes the technical requirements that support the business requirements in the previous section. They are broken up into functional and non-functional requirements.

Note: Security requirements, usually described within the non-functional

requirements of an overall enterprise architecture, are given their own section to highlight the security focus of this IBM Redbook.

6.3.1 Security requirements

This set of technical requirements support business requirements BR3 and BR4. As is usually the case, the technical requirements draw out many more facets than the often innocuous business requirements.

򐂰 SR1: Authentication to the Web service

Whether the route to the Web service originates within the ITSOBank organization or from a IBM Business Partner location, users accessing the service should be positively identified. No reliance should be placed on system or application identities. For example, it should be known that it is user

Joe

the portal application at ITSOTelco

򐂰 SR2: Authentication to CICS Transaction Gateway

Users must authenticate to RACF using their own user identity, and not a shared service/application login. The user’s RACF password should only be stored in RACF itself, and not in any intermediate identity stores.

򐂰 SR3: Identity mapping

The user’s external user ID and their RACF user ID may not always be the same, but a one-to-one mapping between them has to be possible.

򐂰 SR4: Authorization

Access to the services is only granted to resource consumers that have been granted authority to use them.

򐂰 SR5: Centralized policy management

All security policies should be stored in a centralized policy store for ease of management and demonstration of compliance.

򐂰 SR6: Transport level security

The communication channel between service consumers outside the ITSOBank enterprise over the (untrusted) Internet must be encrypted using transport level security, such as SSL/TLS.

򐂰 SR7: Message integrity

In order to assure the integrity of communications, the content of Web service messages (requests and responses) must be signed.

򐂰 SR8: Message confidentiality

In order to guarantee the confidentiality of communications, the content of Web service messages (requests and responses) must be encrypted.

򐂰 SR9: DMZ termination of inbound requests from partners

For Web service requests originating outside of ITSOBank, a termination point is required in the DMZ before requests are proxied to the network where

the Web service is deployed. At a minimum, the DMZ termination point should perform content validation, authentication, coarse-grained authorization, and audit.

򐂰 SR10: Auditing

Each component of the solution has to be enabled for auditing. A mechanism has to be available to submit, persistently store, and report on audit data submitted as events.

򐂰 SR11: Use of standards

The solution should employ applicable open standards for security

management in SOA environments. This assures maximum interoperability with minimal customization.

򐂰 SR12: Account recertification

The accounts of every employee have to be recertified every three months.

򐂰 SR13: Security token standards

The SOA Governance board has provided a guideline for use of signed SAML 1.1 assertions for identity assertions from external service consumers. They have also provided a guideline to use SAML 2.0 security tokens for identity assertions within the enterprise.

6.3.2 Other functional requirements

This section describes the other functional requirements that have been identified.

򐂰 FR1: Expose CICS transactions as a Web service.

Service-oriented architecture supports the business and technical objectives of this project.

򐂰 FR2: Create sample Web service client for internal use.

Enable internal applications to use the services. This provides an initial delivery and test scenario before exposing the applications to business partners.

򐂰 FR3: Expose selected Web services to an external partner.

Expose selected Web services to external partners to enable them to use the services of the banking application. ITSOTelco is the first potential consumer of this service.

򐂰 FR4: Create a template Web services client application to demonstrate to external partners how to consume these services.

6.3.3 Other non-functional requirements

This section describes the non-functional requirements that have been identified. They cover a broad range of themes, such as:

򐂰 Performance

򐂰 Scalability

򐂰 Availability

򐂰 Maintainability

򐂰 Monitoring

These non-functional requirements define the design and development of the operational environment of the system. They also define the way the system is configured and managed.

򐂰 NFR1: The response time of this service should be no more than three seconds.

Feedback from business partners indicate this is an acceptable latency for integration with their customer portals.

򐂰 NFR2: 50% of the ITSOBank employees will use the ITSOTelco portal per day.

This leads to a usage of the Web service of 10,000 times a day.

򐂰 NFR3: No server in the solution should be more than 60% utilized. This allows for future growth.

򐂰 NFR4: The overall architecture should be able to achieve availability close to 99.9%.

It is recognized that the first phase is a proof-of-technology, and that

availability requirements are less critical at this time. Availability requirements will likely change as services become more critical to the business.

򐂰 NFR5: The maintenance of the security component of the system must have a reasonable and predictable cost.

This concludes the description of the business context for our customer scenario.

Important: This example primarily focuses on the security requirements so