I came across (again!) with the requirement to enable SSO on links contained in emails that are generated by the Extended Notifications for Business Workflow.
e.g. for Timesheet Approval the WDA link contained in the email be something like
The generated links/URLs point directly to WDAs in the backend ERP system, and by clicking on the link(s) the WDA page prompts for logon.
I can see this as a big inconvenience to end-users especially if SSO (e.g. kerberos) is already enabled in the SAP Portal.
I have seen the need for SSO for such links in emails (e.g. in Outloook) over and over, and searching SDN yields no simple solution.
(Worth mentioning the work-around which isn’t guaranteed to work all the time, that is for the end-user to open an existing IE window which is already logged on to the Portal; and by clicking on the WDA link in Outlook, the link will open in the same IE session and thereby inheriting the SSO cookie, then opening the WDA without prompting for logon. This method doesnt work all the time and end-users just wont remember and understand)
A couple of solutions to this problem that already suggested by SDN members are the following
– Single-sigon to BSP pages Single Sign On to BSP pages
– Using X509 certificates
Another solution which I authored in my previous customers is to
– create a Portal web application which has Kerberos SSO set; containing a target JSP/HTML page that will redirect to the original URL. The original URL is passed as a parameter
The redirect.html will authenticate against the Portal using Kerberos SSO if the user didnt have the MYSAPSSO2 cookie yet, once authenticated the browser will then be redirected to the the target ABAP web page
Applying this solution to the original requirement of Extended Notifications require a bit of ABAP coding to generate the URL in the mentioned URL format
i.e. email link will contain
https://<portal>/<sso-web-app>/redirect.html?target=<url to WDA or BSP>
What if there is an easier way? With no changes or nor custom code to the Extended Notifications (SWN_SELSEN)?
Here is my simple and if you agree, elegant solution.
1. Create and deploy a web application with active Kerberos SSO. Details of this application I will write in a separate blog.
var wdaurl = “https://<erp-fqdn>” + location.pathname + location.search;
window.location = wdaurl;
Note: You can also use KM page to host the HTML file instead of creating and deploying a custom web application. I will share the details of activating the SSO on KM, as by default KM documents have “basic authentication” as the default authentication method.
2. This is where the magic comes in. I’ve grown to appreciate the role of Web Dispatcher as I wrote in this blog
My solution still utilises the Web Dispatcher but I don’t see why the following steps cannot be implemented on any ICM (e.g. the ICM of the Portal)
In your SAP Portal Web Dispatcher, you activate the HTTP modifications (URL rewriting) parameter. The mod file will contain the following rule
RegIRewriteUrl ^/sap(.*) /<sso-web-app>/redirect.html
Note, this has to be the Web Dispatcher fronting your Portal so that traffic will to go to your Portal first and by having the above URL rewrite rule, any URL with path starting with /sap* (for any WDA and BSP) by default will pass by the SSO Web App:
Now that we have the SSO and redirection mechanism in place, what then do we do with the Extended Notification?
Well not much apart from setting the WD_HOST parameter to point to your Portal.
To explain why, lets go back to our original URL. The original email link will be like:
Setting that parameter will generate something like
This time, the browser already has the MYSAPSSO2 cookie and thus will no longer be prompted for logon 😉