In this post, we will go over the steps involved in creating an iView from scratch. The detailed description of what all options you have when creating an iView are out of scope for this discussion as typically a security administrator is not likely to be asked to create iViews for a productive system. However, like most other posts on this blog there is enough information to get you started and help you understand what all options are available for a portal developer.
The first step while creating new content (iview/workset/role/page) for Portal is to decide the folder in the PCD where your custom development is going to be stored. On right clicking on the appropriate directory you get the option of creating new content. We chose the option of creating a new iview.
The create iview screen gives you a few options – Create iview from template or for a java webdynpro or for an ABAP webdynpro. Each of these options will have their own configuration options.
In our case we chose the option of creating an iview from an iview template. This in turn opens up a new page with lots more options. For example iview templates are available for BEX queries, SAP transactions, etc.
In the next post we go through the individual steps for creating an iview based on a SAP transaction
Security for Enterprise Portal is based on Portal Roles. Portal Roles are created in the Portal Content Studio and are meant to structure the content displayed to a user on the Portal. Portal Roles are assigned to users through the identity management component of the portal just like UME roles. Multiple Portal roles can be assigned to a user which will impact the display of the enterprise portal for him. We look at structure one of the standard portal roles below
Content in a Portal Role is organized in a hierarchy of folders as shown above as worksets, iViews and pages. The folders in a portal role are called worksets. Worksets can be used across many portal roles. Also there can be multiple worksets under a workset. The lowest level of content are iViews. The screen above gives an example of Portal role in the PCD and the role structure showing both worksets and iviews. Also the same role “Content_Admin” is also assigned to my user id in the system. The top level navigation showing the different tabs like Content Administration > Portal Content> Multiple Property Replacement gives an idea of how a role looks when assigned to a user.
The behaviour of the role or workset can be changed by modifying the property editor settings shown on the far right. Also important is the permissions that can be modified in the property editor settings. An example of the permissions that can be set on the property editor for Content Admin role is copied below.
SAP Enterprise Portal (EP) as a component can only be installed on AS Java. Till now our discussion on AS Java security has exclusively dealt with security using the User Management Engine. We have talked about UME users, roles and groups. However, in addition to UME roles, we can also create roles for Enterprise Portal. Before we start our deep dive into security for the enterprise portal lets take a brief tour of the Enterprise Portal solution.
To a large extent the Enterprise Portal to support display of content on the various corporate intranets (portals) of SAP customers. Thus the security framework for EP is also geared towards display of static or dynamic content rather than on granular security. To look. To get an idea about the look and feel of the Enterprise Portal just log in to the SAP Service Marketplace which is also built on EP.
To create content for Enterprise Portal, you need access to the Portal Content Studio shown below. You would also need access to the content_admin portal role.
Most of the Employee Self Service, Manager Self Service Applications are based on the Enterprise Portal. In addition, EP developers also can create portal applications for displaying BI dashboards, BW reports, webviews for SAP transactions and just simple static pages.
Most clients have a dedicated portal team instead of having security develop applications for portal. But I still feel that having some knowledge of portal is always helpful. Portal development normally starts by accessing the Portal Content Studio through the Portal Content Directory (PCD). Double clicking any content – iViews, Worksets, Roles opens the content in the right hand window for modification.
Unfortunately the UME doesn’t provide as comprehensive reporting capabilities as provided by SUIM. The best bet for a security in such a case is to refer to the security log files generated by the UME and stored at the OS level. The files can off-course be checked at the OS level by someone with the appropriate permissions for the AS Java application server. More easily, they can also be viewed in the Netweaver Administrator (NWA) with the appropriate UME roles. The NWA is available at the following URL, “http://:port/nwa” or can be accessed from the app server launchpad.
Within the NWA, you can access the security log by following the menu path System Management > Monitoring > Logs and Traces > Expert View > Security Log. The security log can be show actions like user creation, deletion, role assignment, password lock etc.
Since the security log stores all security related log entries you can use the filters option to selection from the category that you need from the same screen.
The Identity Management application allows mass creation of user, roles and groups instead of creating them individually. For mass creation we use the “Import” tab under Identity Management. The screenshot below shows the data for creating a few users in the UME.
For the import to work we first have to prepare a text file with the correct format. Once prepared we can either paste the text in the box as shown above or import the text file by clicking the browse button. We now click the upload button. If our data format is correct, identiy management shows a log for the actions and the user are created in the UME. Checking the “Overwrite Existing Data” checkbox ensure any existing user data is overwritten by the new data being loaded.
There are numerous parameter combinations that can be used while loading users, roles and groups. Many of the options will actually replace existing data with the new mapping data. Please look up the sap help before using any other parameter combinations.
Last but not the least of the UME Objects are Groups. Again we follow the same process for creating groups as for creating roles or users. We start by selecting Groups from the dropdown and click the “Create Group” button.
We start by adding a name and description for the new group. Groups don’t carry any permissions themselves but can be mapped to any number of roles. A user assigned to a UME group will inherit all the roles and the permissions contained in them. Groups also can be a part of a hierarchy of parent and chid groups.
Groups serve a special purpose when the UME uses an ABAP system as its data source. In this case, any new role created in ABAP is available in AS Java as a user group. Also assigning the backend role would assign the UME group and any role mapped to it in the java system. Many a time, a UME role contains java applications accessing backend SAP data. This is specially the case when an Enterprise Portal is installed on the AS Java system. A case in point are ESS and MSS applications used in SAP HCM. For these applications, we can create a backend role and assign the needed java role(s), either UME or portal roles, to the corresponding group. Any user getting the backend role would automatically get the correct Java access.
So for a AS Java system with an ABAP datasource, the entire user-role administration can be carried out from the ABAP backend. For a UME with Active Directory server as its user source, groups can be mapped to a AD group such that a user getting a AD group automatically gets the UME group and all roles mapped to it.
The process of creating a role is technically similar to the process of creating a user. We select “Roles” from the drop down in the initial screen and click the “create role” button. At this point a subscreen opens where we add the details for the role.
UME roles are a bit different from ABAP roles as they don’t contain either transactions or authorization objects. The corresponding concept for AS Java are “Actions”. The UME ships with many Actions already defined. The Assigned Actions tab allows us to search for existing actions in UME and also for actions already assigned to the role. We have the option of adding or removing actions from roles. Actions themselves are themselves composed of “permissions”. Permissions are defined by the creators of AS Java applications and checked in Java code before allowing users access. Unfortunately or fortunately we don’t create Permissions or Actions in Identity Management.
The Create Roles application also allows us to assign the role to Users and to UME groups via the respective tabs.
Like AS ABAP, a user would need an account to be created in the UME to log in. We create a new user by selecting “user” from the drop down in the initial identity management screen and clicking the “Create User” button. We also have options of searching for existing users, copying users, deleting users or locking/unlocking users.
On clicking the “Create User” button, a subscreen for “user details” opens up. The user details screen has a few sub tabs like General Information, Roles, Groups, etc. In the General Information tab, we would be specifying the login id, user first and last names, email address, deafult language and initial password. The obligatory fields are marked with a red asterisk.
Even though filling up the first General Information tab is enough to create a user, it would not give the user any access. For access on AS Java, we would need to assign roles or groups to the user in the respective tabs under user details.
Before we can start building roles or creating users on AS Java we have to start with configuring the UME. The configuration options are available under the configuration tab of the Identity Management application. Even under the configuration there are a number of sub tabs allowing different features to be configured. We look at a few of the more important options below.
Probably the most important configuration option is to set the data sources for the UME. This determines the data sources from where the UME reads the user information. We can set the data source as an AS ABAP SAP system, a LDAP system, an Active Directory server or a AS Java Database. The example screenshot below shows data source to be a set to a Active Directory Server.
Though setting the data source value is part of the Identity Management configuration but many a time the actual choice is determined by your network infrastructure and overall access structure. For example, its quite common that all users would have access to the corporate portal of an organisation but not everyone would be expected to work in SAP. As a result all employees will not a SAP account and in such a case, setting the UME database to a ABAP system would not work.
Identity Management configuration allows us to specify password parameters, like minimum and maximum length, use of special characters and validity dates, user id length, locking of accounts on using wrong password. The names of the parameters are quite self explanatory and appear under the “Security Policy” tab page. The screenshot below show an example configuration.
We also have a way of changing Notification Email settings as part of our configuration activities. Again the screenshot below shows some typical settings. I am not describing all the remaining tabs. Just explore them as the need arises. The configuration steps that are performed on the UME are basically one time activities. It would be very rare that you need to change these once the system is set up and running.