Skip to main content

Portal::Runtime pattern and Access Integration::Web Single Sign-On application pattern

Overview

Runtime patterns define functional nodes that underpin an Application pattern. The Application pattern exists as an abstract representation of application functions, whereas the Runtime pattern is a middleware representation of the functions that must be performed, the network structure to be used, and the systems management features.

A portal implementation leverages the concept of personalization, multi-device type access, a presentation rendering mechanism, and a business rules engine. These are combined with the ability to search and index content (of various types and formats), provide collaboration, and manage content via a workflow to provide both content aggregation and a collaborative environment.

The Portal composite runtime pattern represents a starting point for most portal implementations, providing a way to identify those functional areas that will likely need to be addressed when considering this type of implementation.

Consequently, the Portal composite runtime pattern represents a preliminary step towards an operational architecture that can be implemented in a target environment to provide secure data aggregation, multi-client access and collaboration.

The original Portal composite::Runtime pattern has been enhanced with additional features which are becoming more common. This is shown in the Portal composite::Runtime pattern variation below.

Access Integration::Web Single Sign-On runtime patterns

The Access Integration pattern describes those recurring designs that enable access to one or more Business patterns. In particular, this pattern enables access from multiple channels (devices) and integrates the common services required to support a consistent user interface.

From the business perspective this will enable the portal implementation to provide information to a variety of end user groups that need targeted information by allowing multiple channels now and in the future to be supported with a minimum of overall system modification. Allowing the other parts of the portal system (e.g. security mechanisms, data sources, business logic) to be protected from modification in order to support new end user channels saves in time, people and money.

Access Integration::Web Single Sign-On=Homogeneous Application Servers

The homogenous application server design illustrates how, in a Web tier environment, all applications implemented on the same application server can exploit that application server's security mechanisms for single sign-on functionality.

The benefits of this design are that it enables a simple, effective security model for applications built within the same application server environment. The disadvantage is that it does not support applications outside the application server domain.

Access Integration::Web Single Sign-On=Homogeneous App. Servers Browser Application Server Application Server Directory and Security Services
Design Last Updated: 12-07-2004
(Click a node to get a detailed explanation.)


Applying it to the Portal composite::Runtime pattern

The Portal composite runtime pattern supports the Access Integration::Web Single Sign-on=Homogeneous Application Server runtime pattern. The Web Single Sign-on application pattern overlays the Portal composite runtime pattern as shown in the figure below.

Single Sign-On application pattern and Portal composite runtime pattern Public Key Infrastructure Domain Name Server Protocol Firewall Web Server Redirector Domain Firewall Application Server Exisiting Applications Wireless Gateway Reverse Proxy Content Management Search and Indexing Collaboration Portal Server Personalization Server Directory and Security Services

The three zones contain the following nodes:

  • Outside World
    • Public Key Infrastructure
    • Domain Name Server
    • Browser User
    • Wireless Gateway
    • Pervasive User
  • Demilitarized Zone
    • Reverse Proxy
  • Internal Network
    • Web Server Redirector
    • Search & Indexing
    • Content Management
    • Portal Server
    • Collaboration
    • Directory and Security Services
    • Personalization Server
    • Existing Application and Data
    • Application Server

Additionally between the Outside World and the DMZ is a Protocol Firewall and between the DMZ and the Internal Network is a Domain Firewall.

Design Last Updated: 12-07-2004
(Click a node to get a detailed explanation.)

This Runtime pattern is supported since it treats the concept of the application server node as the central mechanism where data is pulled from multiple data sources and, if user display is required, passes that information to the presentation server. In this type of implementation this centrality would also include an integrated security mechanism which could leverage an external LDAP directory source. Thus, the Portal composite runtime pattern can apply to this type of implementation by treating the Security Services part of the Directory and Security Services node as actually being integrated into the application server. However, the key point is that the functionality that needs to eventually be implemented remain the same. Only the implementation is modified.

Access Integration::Web Single Sign-On=Heterogeneous Application Servers

In this pattern, a Web tier with multiple different vendor application servers can only implement Single Sign-On with the deployment of a separate security server. The external security server provides an authentication proxy that intercepts requests to map or transform user credentials into the appropriate credential format for that application server.

Access Integration::Web Single Sign-On=Heterogeneous App. Servers Browser Application Server Application Server Directory and Security Services Application Proxy
Design Last Updated: 12-07-2004
(Click a node to get a detailed explanation.)

The advantages of this design is that it provides a unified, secure authentication model, and supports multiple vendors/platforms. Its disadvantages include:


Applying it to the Portal composite::Runtime pattern

The two characteristics that are leveraged in the Portal composite runtime pattern are the ability to have different vendor application servers and the separated security server.

The Portal composite runtime pattern indicates a single node for the application server; however, this can represent more than one physical application server instance. In fact, because of the separated security mechanism, the impact of having application servers from multiple vendors versus a single vendor is mitigated. In addition, this allows for adding more application servers as load and/or performance demands increase. The Portal composite runtime pattern supports this component based architecture which isolates functionality (e.g. business logic vs. data sources vs. security vs. presentation) allowing the enhancement of specific areas of functionality with minimal affect on the whole system.

The use of a separated security server allows for the upgrade of user and organization profile management without affecting the rest of the system. For example, a modification to the hierarchy between user types and group types in the LDAP server can take place, as long as backward compatibility is maintained, without requiring a shut down of other components in the system (e.g. the application server, database server, firewalls, etc.). This represents a best architectural and implementation practice in having a component based systems architecture where there is separation of concerns between the presentation, business logic, security, and data source tiers.

Access Integration::Web Single Sign-On=Central Authorization Service

Another alternative for extending the security context to back-end systems is to allow the same security service that controls the Web tier to control the back-end applications. The security server provides the role-based authorization for controlling back-end resources. No credential mapping or transformation is required. The security context is preserved all the way through to the back-end system.

Web Single Sign-On=Central Authorization Service runtime Browser Application Server Application Server Application Server Directory and Security Services Application Proxy
Design Last Updated: 12-07-2004
(Click a node to get a detailed explanation.)

This use of a common security mechanism is important from an architectural best practices perspective. Wherever possible is makes the best strategic sense to have a single mechanism. This allows central management of users and groups at the enterprise level and also mitigates the risk of enterprise level security policies not being followed. Additionally, if there needs to be an upgrade to the capabilities of the security model and/or technology implementation, this can be done without having to modify the other components of the portal implementation. The reality is that this is often impractical other than in an environment where an almost total re-architecture of existing systems is undertaken.


Advantage

The benefits of this solution is that it simplifies user management across all applications, and unifies user profile information and reduces redundancy.


Disadvantage

Its main disadvantage is that it requires all applications to support the chosen security proxy and may require complex modification and migration. Many organizations prefer to leverage the existing multiple security mechanisms and synchronize these mechanisms with the understanding that, at least initially, this will require less time, people and people resources. In addition, if existing systems are in place and there is an identified need to move a central mechanism, more up front re-architecture will need to be performed to consolidate the existing data. This is a common scenario.


Applying it to the Portal composite::Runtime pattern

The Portal composite runtime pattern supports this Runtime pattern since the Portal composite runtime pattern is based on a physical and logical separation of concerns between the view, logic, security, and data sources systems. When this separation of concerns occurs, there can be a single security mechanism that handles credential authentication and user authorization for all applications and data sources.

Note that this is an ideal situation and, unfortunately, is not practical in environments where there are existing IT systems (which is most environments). Consider this when there is an opportunity to re-architect the existing infrastructure in an end-to-end manner.

What's Next

If you would like to review additional Application patterns, and their corresponding Runtime patterns, return to the Portal: Select Application pattern page.

For a mapping of products that support the Runtime nodes shown above, review the Portal product mapping.

Browser

A Browser is the process, running on a user device, that provides 'thin client' function to the user.

Authentication Proxy

In a system environment where the Web tier employs multiple different vendor application servers, a separate security server must be used to implement Single Sign-On . The external security server provides an authentication proxy that intercepts requests to map or transform user credentials into the appropriate credential format for that specific application server.

Public Key Infrastructure (PKI)

PKI is a system for verifying the authenticity of each party involved in an Internet transaction, protecting against fraud or sabotage, and for nonrepudiation purposes to help consumers and retailers protect themselves against denial of transactions. Trusted third-party organizations called certificate authorities issue digital certificates -- attachments to electronic messages -- that specify key components of the user's identity. During an Internet transaction, signed, encrypted messages are automatically routed to the certificate authority, where the certificates are verified before the transaction can proceed. PKI can be embedded in software applications, or offered as a service or a product. e-business leaders agree that PKIs are critical for transaction security and integrity, and the software industry is moving to adopt open standards for their use.

Domain name server

The domain name server (DNS) node assists in determining the physical network address associated with the symbolic address (Web address) of the requested information. The DNS on the node diagram is that of the Internet service provider (ISP), although DNS is implemented on the accessed site also.

Protocol Firewall Node

A firewall is a hardware/software system that manages the flow of information between the Internet and an organization's private network. Firewalls can prevent unauthorized Internet users from accessing private networks connected to the Internet, especially intranets, and can block some virus attacks -- as long as those viruses are coming from the Internet. A firewall can separate two or more parts of a local network to control data exchange between departments. Components of firewalls include filters or screens, each of which controls transmission of certain classes of traffic. Firewalls provide the first line of defense for protecting private information, but comprehensive security systems combine firewalls with encryption and other complementary services, such as content filtering and intrusion detection.

Firewalls control access from a less trusted network to a more trusted network. Traditional implementations of firewall services include:

  • Screening routers, (the Protocol Firewall)
  • Application gateways (The Domain Firewall)

A pair of Firewall Nodes provides increasing levels of protection at the expense of increasing computing resource requirements. The Protocol Firewall is typically implemented as an IP Router.

See Also

Additional Resources

  • (in English) ESS

Domain firewall node

A firewall is a hardware/software system that manages the flow of information between the Internet and an organization's private network. Firewalls can prevent unauthorized Internet users from accessing private networks connected to the Internet, especially intranets, and can block some virus attacks -- as long as those viruses are coming from the Internet. A firewall can separate two or more parts of a local network to control data exchange between departments. Components of firewalls include filters or screens, each of which controls transmission of certain classes of traffic. Firewalls provide the first line of defense for protecting private information, but comprehensive security systems combine firewalls with encryption and other complementary services, such as content filtering and intrusion detection.

Firewalls control access from a less trusted network to a more trusted network. Traditional implementations of firewall services include:

  • Screening routers (the Protocol Firewall)
  • application gateways (The Domain Firewall)

A pair of Firewall Nodes provides increasing levels of protection at the expense of increasing computing resource requirements. The Domain Firewall is typically implemented as a dedicated server Node.

See Also

Additional Resources

  • (in English) ESS

Web Server Redirector Node

In order to separate the Web server from the application server, a so-called Web Server Redirector Node (or just redirector for short) is introduced. The Web server redirector is used in conjunction with a Web server. The Web server serves HTTP pages and the redirector forwards servlet and JSP requests to the application servers. The advantage of using a redirector is that you can move the application server behind the domain firewall into the secure network, where it is more protected than within the DMZ.

App Server/Services

Applications rely on services provided by their hosting server to interact with other applications. These are modeled using the application server/service node. Some examples of services provided by this node include:

Application server node

The application server node provides the infrastructure for application logic and can be part of a Web application server. It is capable of running both presentation and business logic but generally does not serve HTTP requests. When used with a Web server redirector, the application server node can run both presentation and business logic. In other situations, it can be used for business logic only.

Existing Applications and Data Node

Existing applications are run and maintained on nodes, which are installed in the internal network. These applications provide for business logic that uses data maintained in the internal network. The number and topology of these existing application and data nodes is dependent on the particular configuration used by these legacy systems.

Wireless Gateway Node

This node serves the information from the portal via alternative protocols to wireless devices.

Reverse Proxy

A reverse proxy accepts inbound requests on behalf of the actual target of the request, applies rules to determine where the request should be directed to (that is, it hides the actual physical address and location of the target of the request, making it less vulnerable to breaches of security), and can also check to see if the requestor is authorized to make such a request. In addition, a reverse proxy can be part of an overall scheme to develop a consistent enterprise-wide approach to security administration.

Content Management Node

The content management node provides for the management of digital assets (e.g. images, documents, pieces of text) and applies a workflow and security rules (e.g. access control) to each discrete asset. Note that assets can also be referred to as ‘resources’ (as they are in WebSphere Content Publisher).Content Management node will commonly include and/or leverage these functions:

  • Content Type / Category Identification
  • Workflow (based on a user’s role and/or the type of content)
  • Versioning (including rollback to previous versions)
  • Handling of static or dynamic content
  • Transcoding / Reformatting of Content (more recently added to handle multiple end-user channel device types)
  • Storage of content to multiple data source types (e.g. DBMS, file system)

Search and Indexing Node

A search and indexing node provides a function to catalog and/or index the content data sources. This will provide the capabilities to locate specific content (e.g. product or catalog information) and to update this search capability when updates are added (via indexing). In addition, this information can be indexed in a manner that provides the Presentation and Personalization server an ability to find information that is associated to the actions taken by the end-user. For example, this could provide for cross-selling or up-selling on a commerce site which is a specific form of Implicit Personalization.

Collaboration

Doing business is a series of Collaboration processes. It requires interaction between employees, vendors, suppliers and business partners. While e-mail is one example of an indispensable communication tool used by companies around the world, a number of other collaborative applications are increasingly coming into play. These applications enable local workgroups, or even geographically dispersed teams, to work together using real-time information sharing and distribution across the Internet. The applications include e-mail, group calendaring and scheduling, shared document libraries, discussion databases, newsgroups, and so forth.

Portal Server

The portal server node provides services to enable a unified user interface. It is responsible for all presentation-related activity. In its simplest form, it serves HTML pages and runs servlets and JSPs. For more advanced patterns, it acts as a portal and provides the access integration services (single sign-on, for example). It interacts with the personalization server node to customize the presentation based on the individual user preferences or on the user role. It also provides some productivity functions such as document manager and editors. The portal server node manages the presentation of data extracted from multiple sources. Through the use of user profile information, business rules (personalization), and a mechanism for aggregating different information sources (static editorial data, content managed data, data from remote systems), an aggregated view of data can be displayed. This aggregated view can be tailored for different device types based on information known about the current user accessing the portal.

Personalization Server (Rules Engine)

The personalization server node works with the presentation server node to customize the presentation with data that matches a user’s interest. The personalization server identifies the type or class of the user based on information available about the user. Based on this classification, data taken from a content datastore either in the Personalization tier or from back-end sources is selected for presentation to the user. It provides the mapping function of user classification to content data.

The personalization server contains the rules that determine what types of user’s can have access to certain type of information. These are also referred to as access control rules and are directly related to business rules and processes. This is referred to as the Personalized Delivery::Prescriptive runtime pattern. The personalization server also allows the user to design the content and the layout of the content that they see by explicitly choosing from a selection of options. This is referred to as the Personalized Delivery::Participatory runtime pattern. You can use either or both of these patterns for the Portal composite pattern.

Directory and security services node

The directory and security services node supplies information on the location, capabilities, and attributes (including user ID/password pairs and certificates) of resources and users known to this Web application system. This node can supply information for various security services (authentication and authorization) and can also perform the actual security processing, for example, to verify certificates. The authentication in most current designs validates the access to the Web application server part of the Web server, but this node also authenticates for access to the database server.

See Also

Additional Resources

  • (in English) ESS

Database server node

This Node's function is to provide persistent data storage and retrieval in support of the user to-online buying transactional interaction.

Customer related data that is stored is relevant to the specific business interaction, for example, the shopping cart and shipping address information. Some sites are registering users and storing customer profile data such as address, clothing sizes, preferences, and gift wish lists that others can access when buying presents. Most sites today do not store credit card information on this server for security reasons.

Also stored here is the product and catalog information used to dynamically build HTML pages for presentation during the shopping process.

The mode of DB access is perhaps the most important factor determining the performance of this Web application, in all but the simplest cases. The recommended approach is to collapse the DB accesses into a single or very few calls. This can be achieved using coding and invoking Stored Procedure Calls on the database. Typically many commerce servers share only one database server in a high volume site, so the technology to implement this node must be able to scale vertically.