With the integration of Enterprise Security, Portal Studio allows users to see only those objects for which they have the necessary roles. For example, if Portlet_1 is protected by Role_A, and a user is not assigned Role_A, when the user selects Build | Portlets, Portlet_1 does not display in the Portlet Manager list of portlets.This prevents Portal Studio users from bypassing the security policy for portal content by trying to preview a portlet they would not normally be allowed to see in Portal Interface.
Enterprise Portal’s basic security infrastructure consists of:
Users (accounts) – users are created by the Portal Security Officer (PSO) and administered in Enterprise Security, which allows EP to use container (application server) authentication.
To create a Portal Studio user, the PSO grants a new user a role that authorizes access to some of the Portal Studio assets. When that user logs in to Portal Studio, he or she is prompted to select a resource (by default, Portal or Japan, Inc.). After the user selects a resource, he or she becomes a Studio user, then appears in the Manage | Studio | Users list.
Resources – users are grouped under resources. Each resource corresponds to an EP co-brand. Co-brands can represent companies, divisions, departments, and so on. The first time a user logs in to Portal Studio, he or she is prompted to choose a resource.
Assets – any object to which you want to restrict access. There are security domain assets and portal assets. Security domain assets (also known as controlling assets) control access to the default organization’s object (user, groups, roles, and so on). Portal assets control access to the portal’s objects (pages, portlets, catalogs, and so on).
Roles (permissions) – roles are created and administered in Enterprise Security. Portal Studio objects (pages, portlets, catalogs, and so on) are mapped to corresponding assets in Enterprise Security. Each asset has its own set of access permissions, mapped to the operations (create, edit, manage, and so on) a Portal Studio user can perform on a Portal Studio object. Assign role access permissions on specific assets, then assign these roles to a user.
Company – the concept of “companies” is supported only in the Enterprise Portal version 6.0 Demo installation. EP Enterprise Edition comes with a default company, but the company does not appear in the Portal Interface or Portal Studio user interfaces.
To set up role-based security in the portal, an administrator logs in to Portal Studio using the PSO account and creates the appropriate assets, roles, and users in the security organization. For example, the PSO might create the StudioDeveloper, StudioDesigner, and PortalUser roles, and give the StudioDeveloper role “create” permissions on the Enterprise Security “portlet” asset.
Once the identity of a user has been verified, the security system controls the information the user is allowed to see, modify, or the applications this user is allowed to execute. Controlling access to a data source is called access control; assigning permissions to users or groups of users to access secured assets is called authorization.
The PSO creates the user accounts and assigns each user the appropriate role. For example, the administrator assigns the StudioDeveloper and PortalInterfaceUser roles to a user named “Smith.” User Smith logs in to Portal Studio and creates a portlet, which is allowed because he is assigned the StudioDeveloper role that has that access right.
When Smith creates the portlet, he assigns the portlet the roles that a user must have to access that portlet. Smith sees all of the roles defined in Portal Studio, including those roles that he does not have This allows him to assign roles he does not have to protect the portlet. Smith then assigns All users that have the roles assigned to the new portlet can access that portlet.
Although Smith sees all J2EE roles when creating an
object, he sees only he sees only the Portal Studio objects that
the StudioDeveloper and PortalUser roles have permission to see.
In summary, roles are assigned permissions to view and act on specified assets. User access to assets is controlled by the roles the user is assigned.
Figure 2-1: Portal Security role-based security
Suppose you are a Studio developer for an executive portal and your assignment is to create a new portlet that shows projected financial results for the next quarter. You know that only one group of portal users (financial officers) are allowed to see this information. Additionally, you are not allowed to see the portlet content. First, build a new portlet based upon some dummy data of the right general format (for example, a PDF document). Actual content replaces this data when the portlet is deployed to the production system.
Next, assign the correct role to protect this portlet. You do not need to know the EP role that will be used on the production portal. In Portal Studio, select Manage | Studio | Roles to see if any existing roles meet your needs. If not, create a new role (for example, CFO). Using Jaguar Manager, create a new role mapping from CFO to PortalUser (or any other role that you have). Next time you log in to Portal Studio, you have that role.
Finally, create the portlet with the dummy data, assign the CFO role to it, and save it. At this point, if you have not created the CFO role mapping to a role you do have, the portlet disappears from your view in Portal Studio. Assuming you do have the appropriate role, you continue with testing, debugging, and so on, and eventually export the content and send it to the administrator to import into the production portal.
When the portlet is imported to the production portal, the administrator creates the correct mapping of the J2EE role reference CFO to the actual FinancialOfficer security role.
