Filtering Portal Content Based on User Attributes

Transcription

1 Filtering Portal Content Based on User Attributes Applies To: SAP Enterprise Portal EP6 SP2 SAP Enterprise Portal 6.0 SP9 and above Article Summary This technical paper will cover how to implement a filtering mechanism of portal content based on user attributes. It uses concepts and base code from the article, Filtering Role and Workset Content by Eckart Liemke and Meinolf Block, which is available at: Please refer to this article for detailed technical information on filter factories and how they operate. This paper will extend the functionality presented in the referenced SDN article to include portal content at all levels including pages and portal catalog folders. Please note that this article presents custom code and is NOT an officially SAP supported solution. The code should be implemented with extreme caution, as bad code could have serious side effects and implications. By: Marty McCormick marty.mccormick@sap.com Title: Technical Consultant SAP America Date: 20 September 2005 Scenario Outline In this scenario, we ll assume that iviews on certain pages within the portal must only be displayed and/or be accessible via personalization when users are a member of a specific country. Typically, customers would create different roles, worksets and pages to a deliver content in a secure manner, however filter factories can eliminate the need for different content structures in the portal catalog and the requirement for multiple pages, worksets and iviews. In this example, the administrator and content teams wish to create one end user role with a page that hosts 4 iviews a Germany only iview, a US only iview, an iview to be seen by all users and an iview to show only members of the super admin role. This means that if the user is from Germany they should see a specific set of iviews based on their country value in their user profile versus that of a user in the US. The code will also implement a mechanism to allow a super administrator to see all content at all times. As shown in the screen shots below, there is one role that contains a page with 4 iviews on it. Based on attributes placed on the iviews themselves, they should be displayed according to their user s country. Here s how the content was created and set up (before any filtering mechanism).

2 Figure 1: Content Catalog View of Sample Scenario Figure 2: Default iviews on the Country Page Filter Expressions A filter expression is the string returned by the filter factory that is used by the portal to determine whether or not the child object should be displayed. These filter expressions can use standard AND/OR logic to accommodate complicated expressions. Filter expressions can also contain wildcards. For example,!(com.widgets.country=*) would allow everything that is not tagged to be rendered. It is important to remember that pages contain items that may need to be seen by the whole user community, such as page layouts. If the filter factory is placed on a page, the page layout values are checked and if it does not pass the check, the whole page will not be displayed (since iviews require a layout). For this specific case (among others), it is

3 wise to implement an ALL value for your filtering attribute(s) that is returned in every filter expression. You can see this logic implemented in the filter factory below. Creating the Filter Factory Component There were some slight modifications to the code provided in the SDN article referenced above. In this scenario we are going to implement an override mechanism that allows users who are a member of the super admin role to override the filtering mechanism regardless of the admins country setting. The filter factory will check children for the attribute com.widgets.company in order to compare to the filter expression. Code Implementation The following section provides the code necessary in order to implement the example. Figure 3: Project Structure in NetWeaver Developer Studio CountryFilterFactory.java package com.widgets; import javax.naming.spi.objectfactory; import java.util.hashtable; import javax.naming.context; import javax.naming.name;

4 import com.sap.security.api.*; import com.sapportals.portal.pcd.gl.ipcdcontext; import com.sap.portal.pcm.admin.pcmconstants; import com.sap.portal.directory.constants; import com.sapportals.portal.prt.logger.ilogger; import com.sapportals.portal.prt.runtime.portalruntime; ************************************************************************** * * CountryFilterFactory * Filter factory that returns a filter string filtering for the * attribute "com.widgets.country" * Marty McCormick SAP 9/15/ * ************************************************************************ public class CountryFilterFactory implements ObjectFactory { ILogger log = PortalRuntime.getLogger(); javax.naming.spi.objectfactory#getobjectinstance(object, Name, Context, Hashtable) public Object getobjectinstance(object arg0, Name arg1, Context arg2, Hashtable env) throws Exception { String countryaffiliation = ""; //do not filter by default String filterexpression = ""; env.put(context.initial_context_factory,ipcdcontext.pcd_initial_context_factory); env.put(constants.requested_aspect, PcmConstants.ASPECT_SEMANTICS); IUser user = (IUser) env.get(ipcdcontext.security_principal); boolean superadmin = false; // Get the role associated with the role name super_admin_role IRole role = null; String rolename = "super_admin_role"; IRoleFactory rfact = UMFactory.getRoleFactory(); try { role = rfact.getrolebyuniquename(rolename); catch (UMException e) { log.severe("country FILTER SERVICE: Error = " + e.tostring());

5 //check to see if the user is a member of the super admin role, if so, set superadmin = true if(user.ismemberofrole(role.getuniqueid(),true)) { superadmin = true; if (user!= null) { String country = user.getcountry(); if(country==null) { country="none"; //override to check if the user is a member of the super admin role if (!superadmin) { if ((country!= null) && (!country.equals(""))) { filterexpression = "( (" + CountryFilterService.COUNTRY_KEY + "=" + country + ")(" + CountryFilterService.COUNTRY_KEY + "=ALL))"; return filterexpression; CountryFilterService.java package com.widgets; import javax.naming.namingexception; import com.sapportals.portal.pcd.gl.ipcdattribute; import com.sapportals.portal.pcd.gl.ipcdattributes; import com.sapportals.portal.pcd.gl.ipcdglservice; import com.sapportals.portal.pcd.gl.ipcdobjectfactory; import com.sapportals.portal.pcd.gl.pcdruntimeexception; import com.sapportals.portal.prt.service.iserviceconfiguration; import com.sapportals.portal.prt.service.iservicecontext; import com.sapportals.portal.prt.service.iservice; import com.sapportals.portal.prt.logger.ilogger; import com.sapportals.portal.prt.runtime.portalruntime; import com.sapportals.portal.pcd.gl.ipcdutils;

6 ******************************************************************************* * * CountryFilterService * Service that creates schema entries and initializes the Country Filter Factory * * Marty McCormick SAP 9/15/ * ************************************************************************ public class CountryFilterService implements IService { private IServiceContext servicecontext; public static final String COUNTRY_KEY = "com.widgets.country"; private static final String FILTER_FACTORY_CLASS_NAME = CountryFilterFactory.class.getName(); public static final String SERVICE_KEY = "com.widgets.countryfilterservice"; private static final String FILTER_CLASS = "com.widgets.countryfilter"; * Generic init method of the service. Will be called by the portal runtime. servicecontext public void init(iservicecontext servicecontext) { this.servicecontext = servicecontext; try { this.setupschema(); catch (NamingException e) { throw new PcdRuntimeException(e); * This method is called after all services in the portal runtime * have already been initialized. public void afterinit() { * configure the service configuration public void configure( com

7 .sapportals.portal.prt.service.iserviceconfiguration configuration) { * This method is called by the portal runtime * when the service is destroyed. public void destroy() { * This method is called by the portal runtime * when the service is released. public void release() { the context of the service, which was previously set * by the portal runtime public IServiceContext getcontext() { return servicecontext; * This method should return a string that is unique to this service amongst all * other services deployed in the portal runtime. a unique key of the service public String getkey() { return SERVICE_KEY; * Initialization of the schema entry for the filter factory private void setupschema() throws NamingException {

8 //In NW04, the IPcdUtils interface can be used instead of the decprecated IPcdObjectFactory IPcdObjectFactory pcdobjectfactory = ((IPcdGlService) PortalRuntime.getRuntimeResources().getService(IPcdGlService.KEY)).getPcdObjectFact ory(); pcdobjectfactory.recreateschemaentry(filter_class, this.getfilterclassattributes(pcdobjectfactory), null); * IPcdAttributes private IPcdAttributes getfilterclassattributes(ipcdobjectfactory pcdobjectfactory) throws NamingException { IPcdAttributes attributes = pcdobjectfactory.createpcdattributes(); attributes.put( IPcdAttribute.OBJECT_CLASS, IPcdAttribute.OBJECT_CLASS_FILTERCLASS); attributes.put(ipcdattribute.application, SERVICE_KEY); attributes.put(ipcdattribute.filter_factory, FILTER_FACTORY_CLASS_NAME); return attributes; jndi.properties # # Provider resource file for JNDI service providers. # # # Initial Context Factory # java.naming.factory.initial=com.sun.jndi.ldap.ldapctxfactory # # # Object factories java.naming.factory.object=com.widgets.countryfilterfactory portalapp.xml <?xml version="1.0" encoding="utf-8"?> <application> <application-config> <property name="sharingreference" value="com.sap.portal.pcd.glservice,usermanagement"/>

9 <property name="startup" value="true"/> <property name="releasable" value="false"/> </application-config> <components/> <services> <service name="countryfilterservice"> <service-config> <property name="classname" value="com.widgets.countryfilterservice"/> <property name="classnamefactory" value=""/> <property name="classnamemanager" value=""/> <property name="startup" value="true"/> <property name="poolfactory" value="0"/> </service-config> </service> </services> </application> Once the component is created, simply deploy the portal service into your environment. Tagging Portal Content After the component has been deployed, the next step is to tag or label the content. All objects that should be filtered are children members, whereas pages and folders are parents that contain the filter factory listing. If you have not implemented an override mechanism, it is necessary to tag the children (iviews, layouts) first before placing the filter factory on the parent objects otherwise you would not be able to tag the children (iviews & layouts) because the content wouldn t pass the filter expression. It is important to remember that if you are trying to filter iviews on a page, you must tag the page layouts in addition to iviews or allow all not tagged content to render by default in your filter expression! The page used in this example contains layouts and iviews and looks like the following (notice the page layouts in addition to the iviews assigned to the page):

10 Figure 4: Page Components All page layouts are tagged with a com.widgets.country attribute and have a value of ALL like such: Figure 5: Sample Page Layout Tagging

11 The iviews are tagged in the following manner: US iview = US Germany iview = DE All User = ALL No Country = not tagged with attribute As the referenced SDN article states, objects that contain children to be filtered require a filter factory to be placed on them. You can add these attributes programmatically using the PCD GL API s. For filter factories, SAP requires the com.sap.portal.pcd.gl.filterassigment attribute along with the appropriate object factory class to be used. In this case, it would look like the following: Figure 6: Filter Factory Attribute on Page In addition to placing the filter factory on the page, it should also be implemented at the folder level in the portal catalog for two reasons: 1) Security the user should not see the iviews that don t belong to their country (as they can add it to a page that doesn t implement the filter factory and have it render) 2) Usability the user would be confused if they saw the iview in the catalog, but if they added it to a page it would not render As such, the same attribute and filter factory value that was placed on the page is placed on the iviews folder under Widgets Company. This ensures that all iviews underneath the folder are checked for proper permission before being listed.

12 Demo When a user with the country attribute US logs into the portal, he/she would see the following: Figure 7: US User Page View As expected, the Germany and not tagged iviews do not show up on the page-however the ones tagged US and ALL do render. In addition, when the US User tries to personalize any page and views the catalog, he/she would see the following: Figure 8: US User Personalization View

13 In addition to personalization, if the US User was a member of the content administrator role (super admin overrides), he/she would see the view shown above and not Germany and Not tagged iviews. This is good for security, but poses potential issues if the US user is an administrator for Germany content. Here s how the user with a country value of Germany (DE) would look: Figure 9: Germany User Page View

14 Figure 10: Germany User Personalization View Similar to the US User, the Germany user is seeing only content that is tagged ALL or DE. If the user is a member of the super admin role, he/she would see the following for their page view:

15 Figure 11: Super Admin Page View Figure 12: Super Admin Personalization View As you can see from the super admin screen shots, all content is being displayed because the filter factory is returning a blank filter expression which evaluates all content to true, including not tagged iviews. Conclusion It s useful to note that any user attribute (or other data pertaining to the user) may be used in the creation of the filter expression. For example, you could use a combination of many user attributes (i.e. country and employee type) including custom attributes from Active Directory or other LDAP source -- in order to generate the filter expression.

16 As you can see from this document, filter factories provide a great mechanism to increase security while reducing duplicate content such as roles, worksets and pages. It also provides security at the portal catalog level, which can significantly reduce the amount of folders and complexity in permissions on the folders. Disclaimer & Liability Notice This document may discuss sample coding, which does not include official interfaces and therefore is not supported. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing of the code and methods suggested here, and anyone using these methods, is doing it under his/her own responsibility. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of the technial article, including any liability resulting from incompatibility between the content of the technical article and the materials and services offered by SAP. You agree that you will not hold SAP responsible or liable with respect to the content of the Technical Article or seek to do so. Copyright 2005 SAP AG, Inc. All Rights Reserved. SAP, mysap, mysap.com, xapps, xapp, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product, service names, trademarks and registered trademarks mentioned are the trademarks of their respective owners.