Skip to Content
h2. Introduction   In many portal installations I have seen so far, administrators rely on the portal’s role concept for defining and securing access to applications running on EP. But unfortunately it’s not that easy: Roles with iViews included and their assignment to users form one important part of the portal’s security concept. But: It’s not the only one and a mis-configuration of the remaning ones can leave big holes in your portal open for the unwanted. This blog gives information about safeguarding portal components using security zones. h2. Definitions   First, allow me some definitions for clarification: A portal component is a piece of Java code that runs on the portal (more preciseley the portal runtime container on SAP J2EE Engine) and has a user interface. A portal service is again some Java code running on the portal but without a user interface. They are always grouped to portal applications and bundled in a single file – the well-known PAR file. Thus, a PAR file is essentially a portal applications and consists of (at least one) portal component(s) and/or portal service(s). Now, what is an iView? If you think of portal components as templates, an iView is an (typically parametrized) instance of this template (just as classes vs. objects in object oriented progamming). iViews are always based on portal components (via thier code link attribute). h2. Defining access permissions   Now, as this is clear, let’s take a lot how the portal’s access control to contents actually works like:  You can assign “use” rights to individual iViews by maintaining their ACLs in the portal content studio. As you certainly don’t want to mark all iViews individually for your users, SAP implemented some automatisms for your convenience: Whenever you add iViews to a role (directly or indirectly via pages and worksets) and assign this role to a user, he will automatically be granted end user access to all iViews contained.  But you not only can call portal components via iView instanciations but also directly. This is performed using the so-called prtroot-access. If for instance you want to open a KM navigation iView, simply try this: _http://servername:port/irj/servlet/prt/portal/prtroot/com.sap.km.cm.navigation_ (try this at home!).  You may ask here: How does the portal decide if I am a legitimate user of this portal component. The iView ACLs don’t apply as this is not an iView but a “raw” portal component. Thus, there must be some means to setting permissions on the components themselves. Actually, there is! It’s the security zones (ta-DA!). h2. Security zones   Security zones are used to define the security level for an individual portal component or service. They form a hierarcical set (i.e. a tree) and can hold permissions. A portal component can be assigned to a security zone. If a user now tries to access a portal component directly (using the prtroot-access mentioned above), the portal looks for the security zone assignment and for the user’s permissions to that zone. Again, “use” right will be needed for successful execution of the request. The assignment of a security zone for a portal component or service is done in the PAR’s deployment descriptor portalapp.xml.  (…)     (…)       (…)      However, the assignment of security zones for components and services is not mandatory. If no security zone has been defined for a component then prtroot access is not possible.   h2. So why do I have to bother?   You might ask about the importance of security zones for your portal installation. For this, keep in mind that many SAP components have security zone definitions in their portalapp.xml and thus can be called directly. This holds especially for sensitive components such as the KM configuration, user management or other administration tools. Thus, even if you are not a member of the user administration or content administation role (and thus do not have access to the iViews included) you might be able to call these components directly. For clarification: A sophisticated role concept is worthless in security zone permissions are not adequately configured, too. Especially on older portal versions (SP2 in particular), the default permissions on security zones are rather loose and allow every authenticated user mostly everthing to do in the portal (check this out for your own by calling on of these URLs: ** _http://servername:port/irj/servlet/prt/portal/prtroot/com.sap.portal.runtime.admin.logviewer.default_ **   ** _http://servername:port/irj/servlet/prt/portal/prtroot/com.sap.portal.runtime.system.console.ClusterAdminConsole_ **   ** _http://servername:port/irj/servlet/prt/portal/prtroot/com.sap.portal.runtime.system.console.ArchiveUploader_ **   ** _http://servername:port/irj/servlet/prt/portal/prtroot/com.sap.portal.usermanagement.admin.UserAdmin_ **   ** _http://servername:port/irj/servlet/prt/portal/prtroot/com.sap.km.cm.cmconfig_ **    This means, knowledge and proper configuration of security zones is critical for your portal’s overall security.  h2. Action!   For custom devlopments you should ask yourself if prtroot access will be needed. If not, then the best idea would be not to include any security zone properties at all. Otherwise, you are strongly encouraged to use SAP’s naming convention for security zones (see: SAP help portal  (http://help.sap.com/saphelp_nw04/helpdata/en/25/85de55a94c4b5fa7a2d74e8ed201b0/frameset.htm) for details). Of course, do not forget to set permissions on these security zones, too, after deployment of your PAR.  For SAP components and 3rd party business packages, you should review which components can be called directly and who is able to do so. For the first, I had some good success in using some free tools for this (namely grep and wget). I first got myself a list of all portal components including their URLs (_http://servername:port/irj/servlet/prt/portal/prtroot/PortalAnywhere.Go_). Then I used grep for extracting only the URLs and storing them in a text file. This file served as input for wget for trying to fetch all these URLs. Be warned though that the later analysis will be a time consuming issue.  If you find a component that the user in question should not have been able to call, you need to identify the security zone that controls access control. For this, the component inspector inside the “Java Development” role is most convenient. It allows you to peek into a PARs deployment descriptor and thus identify the correct security zone. With this information you can then go to System administration – Permissions – Portal Permissions and configure the security zone in question. Using the permissions editor
To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply