# Implementing the Portal Security Scenario

This topic walks you through the Portal Security Scenario, highlights the security touch points in the scenario, and points to the tools and information for implementing security.

Scenario | Security Touch Points
Avitek needs two types of portal-based Web presence: an internal site for its employees and partners called "Inweb," and a public portal for its customers called "Outweb." It needs authentication for both sites. Inweb must live behind a firewall. Outweb is set up on a server cluster for load balancing and failover. | Because one site must reside behind a firewall and the other outside the firewall, two servers are needed. See Using WebLogic Server Clusters in the WebLogic Server documentation, especially the section on Security Options for Cluster Architectures.
For Inweb, Avitek needs to cater to three different types of users: managers, regular employees, and partners. | The three different audiences can be identified by their user profile settings. For example, you can create a user profile property called "user_type" that has three possible values: manager, employee, and partner. Each user is assigned an appropriate value. While user profile properties are not a direct security feature, you can use the properties to define the roles that determine secure access to resources. See Creating User Profile Properties in this help system. For information on creating visitor entitlement roles and mapping those roles to portal resources to secure the resources, see the WebLogic Administration help system. Users will use VPN to gain access through the firewall.
For the three types of users, Avitek wants to create only two portals: one for managers and employees and one for partners. Since there are five different partners, each partner must have a separate view of Inweb. | This requirement is easily solved by the flexibility of the WebLogic Portal architecture. When you create a portal file with the WebLogic Workshop Portal Extensions, you can add books, pages, and portlets to that file. The portal file serves as a template with which portal administrators can create multiple portal instances, or desktops. Each desktop can contain any combination of books, pages, and portlets provided by the template, and those portal resource instances can be assigned their own visitor entitlement and delegated administration roles for security. To meet this requirement, then, only one portal is required. That portal can be used as a template to create separate desktops for managers, employees, and for each of the five partners. When any user logs in, the system knows which type of user they are (based on user profile properties), and they are shown only the desktop(s) they can access (based on visitor entitlement and delegated administration roles that are tied to the user profile properties). There are two other options for meeting this requirement: creating two portal files within a single Web application (project), or creating two projects with a portal in each. A decision to create two portal files is simply an organizational decision. Both portal files serve as templates for portal administrators to construct portal desktops, and the same mechanisms for applying visitor entitlements and delegated administration apply. If Avitek created separate projects for the portals (Web applications), they could secure the J2EE resources (such as JSPs) in each separately, since Web applications have separate security scopes in WebLogic Server. However, since you can secure individual resources in a single Web application, you can secure J2EE resources for different audiences in that application using WebLogic Server security. Using separate Web applications for each portal means Avitek might have to implement single sign-on as a convenience for partners who can access the employee portal and employees who can access the partner portal. Users will be able to see all desktops they are entitled to in both Web applications. See Assembling Portal Applications in this help system for instructions on creating portals. See Securing WebLogic Resources in the WebLogic Server documentation, especially the sections dealing with securing URL (Web) resources such as JSPs and Enterprise Java Beans (EJBs). The Portal Samples contain an example implementation of single sign-on.
Some of the partners also perform contract work for Avitek, so they must also be able to access the employee portal desktop. | Because you need to identify someone by certain characteristics, you could again use a user profile property to identify a user as both a partner and an employee. Instead of making the property a "choose one value" type (single, restricted), you could make the property a "choose multiple values" type (multiple, restricted). You can handle security access to portal desktops and other resources with visitor entitlements. If the employee and partner portals are located in separate Web applications, you can provide single sign-on for partners as a convenience, then handle security access to portal desktops and other resources with visitor entitlements. See Creating User Profile Properties in this help system. For information on creating visitor entitlement roles and mapping those roles to portal resources to secure the resources, see the WebLogic Administration help system. The Portal Samples, especially the Tutorial Portal, contain example implementations of authentication, including single sign-on.
Avitek wants all Inweb users to authenticate before seeing any view of the portals. | You can set up the Intranet portal to use a front-end login JSP. After successful login, users are taken to the portal desktop to which they have access. Designation of a login JSP occurs in the WebLogic Administration Portal. When creating a portal, enter the name of the login JSP file in the optional Portal URI field of the portal properties window. For information on creating portals, see the WebLogic Administration Portal help system. You can also secure J2EE resources, including specific URL patterns, using your application's deployment descriptors. See Securing WebLogic Resources in the WebLogic Server documentation, especially the sections dealing with securing URL (Web) resources. The Portal Samples, especially the Tutorial Portal, contain example implementations of authentication.
For Outweb, Avitek provides information and services on a subscription basis, so it wants to provide a portal that lets all users see unsecured company information and log in to see secure information. | Unlike the previous requirement in the scenario where a separate login JSP was required to access the portal, this requirement lets users access a portal without authenticating. The only time they must authenticate is when they want to view the protected information. Providing authentication based on whether or not users are subscribers is another instance where user properties are useful. For example, you could create a "subscriber" property and set it to "true" or "false." You could create a "subscriber" role that allows only subscribers view protected information at login. A best practices way of providing secure information is by putting secure portlets on a dedicated page. The page itself could even be secured (entitled). See Creating User Profile Properties in this help system. The Portal Samples contain a Login to Portal Portlet you can reuse in your portals. The samples also contain example implementations of authentication. For information on creating pages and adding portlets to them, see Assembling Portal Applications in this help system and the Portal Management topics in the WebLogic Administration Portal help system.
Avitek has a staff of two to administer all portals, and it wants to grant limited administrative access to certain partners to let them maintain their partner portal. | Delegated administration for WebLogic Portal is set up in the WebLogic Administration Portal. A system administrator or super portal administrator can set up other administrators and delegate different levels of access to them. Delegated administration for tools and portal resources in the WebLogic Administration Portal can be defined by roles, users, and groups. In this part of the scenario you could create an administrator role based on user properties and define delegated administration accordingly. Or you could create two groups: "local administrators" and "partner administrators," add users to those groups, and set up delegated administration with those groups. With delegated administration roles set up, you can apply those roles to individual portal resources, giving the staff administrators full access and the partner administrators access to only their portal resources. For information on creating users and groups and setting up delegated administration, see the WebLogic Administration Portal help system. See Creating User Profile Properties in this help system.
There are two JSP-based administration portlets that can never be seen by anyone other than Avitek's in-house administrators. | Securing portlets is simple, straightforward, and powerful using visitor entitlements. In this requirement of the scenario, there may be a need for backup security assurance. This can be accomplished by securing the JSPs in question with WebLogic Server security policies. Security policies are server-level global roles that are applied to J2EE resources. See Securing WebLogic Resources in the WebLogic Server documentation, especially the sections dealing with securing URL (Web) resources such as JSPs and Enterprise Java Beans (EJBs).
Avitek also wants to use its existing content management system for delivering content to its portals. The content management system vendor has created an interface to connect to BEA's Virtual Content Repository. | By adding compatible third-party content management systems into the Virtual Content Repository, content security in those third-party systems is maintained in the Virtual Content Repository. WebLogic Portal's Virtual Content Repository also provides limited content security beyond the security provided by compatible third-party content management systems. See To control user access in the My Content Portlet topic. See the Content Management topics in the WebLogic Administration Portal help system.
Avitek will use two user databases: The Intranet site will use an existing user database, and the public site will use the default WebLogic Server LDAP user database and is gradually adding users to it. | Inweb - Uses existing RDBMSRealm in the existing domain. This can remain the authentication provider/user database or Avitek can migrate the user database to the WebLogic Server LDAP user database. Outweb - Uses WebLogic Server's default LDAP user database. WebLogic Server's default LDAP user database provides all the power and functionality of the WebLogic Server security architecture. See Managing WebLogic Security in the WebLogic Server documentation.

## Summary

Following is a summary of the configuration Avitek will use for its Inweb and Outweb portal sites:

Inweb | Outweb
Inweb can experience minor down time, so it can be set up on a single server. Because there are many existing internal users Avitek wants to retain, it will use its existing RDBMSRealm for user storage and authentication. Inweb is set up behind a firewall, so users will use VPN to gain access from outside the firewall. Because of the flexibility of the portal framework, only one portal is needed. Multiple desktops can be created and entitled based on that single portal. Avitek will use BEA's Virtual Content Repository to connect to its BEA-compatible third-party content management system. | Outweb cannot experience down time, so it must be set up on a cluster. It will use the default WebLogic LDAP user database and authentication provider. Because of the flexibility of the portal framework, only one portal is needed. Multiple desktops can be created and entitled based on that single portal. Avitek will use BEA's Virtual Content Repository to connect to its BEA-compatible third-party content management system.

## Samples

Portal Samples

Login to Portal Portlet

Related Topics

Securing Portal Applications

Portal Security Scenario