Introduction
For enabling end users to process BPM tasks, you might have created an SAP UI5 application. You can do this with the SAP UI5 generation feature in SAP BPM Process Composer, or you can do this manually by building the UI from scratch.
This blog post explains that securing your Web development components (DCs) containing SAP UI5 applications for BPM tasks also solves a log-on issue. It provides you with an example for the deploy descriptors web.xml and web-j2ee-engine.xml.
Some basic security is already there
The SAP UI5 based UI is implemented in JavaScript and the related files are located in a Web DC. By default, the Web DC does not contain any security constraints. This results into the fact, that the UI as such is visible to users with low or even without permission on the system. As the data is originated from an OData stream which is secured as it requires the SAP_BPM_ODATA role, only users having that role are able to consume the data service. In addition, the requesting user also needs to have permission on the particular task instance.
The log-on issue with the link
Assuming a given user has the SAP_BPM_ODATA role, we could expect that he/she is able to see the task UI containing the task-related data when requesting a task where he/she is a potential owner for:
Instead of using for example the BPM Inbox (where this problem does not exist), the end user might want to click on this link received through a notification email:
http://<server-name>:<port>/demo.sap.com~demo~ui/LeavesRequestComponent/index.html?taskId=4e7818f10d...
By clicking on the link, unfortunately the user gets an unexpected error message:
The reason for this error message (although it contains “200 OK”) is that in the first step, the SAP UI5 application as such could be loaded successfully, but something wrong happens thereafter: the data fields are empty, so we can assume that utilizing the OData Service is not working.
But why “200 OK”?
The reason is visible through the “200 OK” string: the OData Service has sent a log-on form successfully to the browser because the user was not yet authorized on the system. But the SAP UI5 application expected the requested OData stream as response instead. This leads to the confusing error message.
Let’s log-on already upfront, then OData stream will work!
To solve this issue, the trick is that we should enforce the user’s log-on to the system prior to accessing the OData service. This is by the way the reason why accessing the task through the BPM Inbox does not run into the same issue: when initially loading the BPM Inbox, the user gets already authenticated on the system.
In our case, the solution is to trigger the authentication already when accessing the task UI application provided by our Web DC. This can be achieved by enriching the SAP UI5 hosting web DC configuration with additional security constraints.
This provides us with two benefits: Firstly, the UI itself is then also secured, so attackers are further limited to gather information about the type of applications on the server. Secondly, if the web DC already enforces the logon, the OData Service will take up the existing user session and will not request a further logon by sending a logon form (unexpectedly).
Example: /WebContent/WEB-INF/web.xml
The following web.xml defines a login configuration with an authentication “FORM”. This later satisfies our OData Service, which will accept the form-based authentication that is already done. Then, we define a security role (to be mapped later in web-j2ee-engine.xml), and that security role gets access to the whole web application with the asterisk. Please double-check whether you would like to be so generous in your case…
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID" version="2.5">
<display-name>LocalDevelopment~demo~ui~demo.sap.com</display-name>
<login-config>
<auth-method>FORM</auth-method>
</login-config>
<security-role>
<description>TaskProcessor</description>
<role-name>TaskProcessor</role-name>
</security-role>
<security-constraint>
<display-name>TaskProcessorConstraint</display-name>
<web-resource-collection>
<web-resource-name>TaskUI</web-resource-name>
<url-pattern>*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>TaskProcessor</role-name>
</auth-constraint>
</security-constraint>
</web-app>
Example: /WebContent/WEB-INF/web-j2ee-engine.xml
In the web-j2ee-engine.xml, you need to map the role name to the name which should occur in the UME as server role. In addition, you need to specify a list of login-modules.
<?xml version="1.0" encoding="UTF-8"?>
<web-j2ee-engine xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="web-j2ee-engine.xsd">
<spec-version>2.4</spec-version>
<security-role-map>
<role-name>TaskProcessor</role-name>
<server-role-name>TaskProcessor</server-role-name>
</security-role-map>
<login-module-configuration>
<login-module-stack>
<login-module>
<login-module-name>EvaluateTicketLoginModule</login-module-name>
<flag>SUFFICIENT</flag>
</login-module>
<login-module>
<login-module-name>BasicPasswordLoginModule</login-module-name>
<flag>REQUISITE</flag>
</login-module>
<login-module>
<login-module-name>CreateTicketLoginModule</login-module-name>
<flag>OPTIONAL</flag>
</login-module>
</login-module-stack>
</login-module-configuration>
</web-j2ee-engine>
Not to forget: Assign the new server role your users
After having re-build and re-deployed the DC, directly when opening the task URL from the email notification, the users are forced to do a log-on already in point in time when loading the Task UI. Please remember to assign the defined server role (in our example: “TaskProcessor”) to the relevant end-users in /useradmin; otherwise they will receive an HTTP 403 error from beginning on. Permitted users, however, can see the task UI, now also including the task data.
Conclusion
The provided examples of deploy descriptors are a good starting point. But of course, security aspects are matter of individual considerations and should be planned for your application individually.
The given example here, at least, gives you also a solution that end users can work with links originating from notification emails.
- SAP Managed Tags:
1 Comment
