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

https://<erp-host>/sap/bc/webdynpro/sap/HRMSS_A_CATS_APPROVAL?<params>&<etc.>

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.

wda_nosso.JPG

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

e.g.

https://<portal>/<sso-web-app>/redirect.html?target=https://<erp-host>/sap/bc/webdynpro/sap/HRMSS_A_CATS_APPROVAL?<params>&<etc.>

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.

The target HTML page in this application will contain a Javascript that does the reassembly and redirection to the WDA/BSP URL, something like:

<script>

var wdaurl = “https://<erp-fqdn>” + location.pathname + location.search;

window.location = wdaurl;

</script>

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

Are you loving your SAP Web Dispatcher enough?

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:


/<sso-web-app>/redirect.html


If the session isn’t authenticated yet, the browser will SSO via Kerberos; once authenticated the page will then be redirected to the target WDA/BSP page by the Javascript.

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:


https://<erp-fqdn>/sap/bc/webdynpro/sap/HRMSS_A_CATS_APPROVAL?<params>&<etc.>


Setting that parameter will generate something like

https://<portal-fqdn>/sap/bc/webdynpro/sap/HRMSS_A_CATS_APPROVAL?<params>&<etc.>

Because of the Web Dispatcher URL rewriting rule (i.e. any path which starts with /sap* will open the /<sso-web-app>/redirect.html). The Kerberos SSO happens, and then the URL will then redirected back to the actual ERP WDA by the Javascript. The original URL which is

https://<erp-fqdn>/sap/bc/webdynpro/sap/HRMSS_A_CATS_APPROVAL?<params>&<etc.>

This time, the browser already has the MYSAPSSO2 cookie and thus will no longer be prompted for logon 😉

To report this post you need to login first.

3 Comments

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

  1. Donald James Elemento Post author

    It dawned on me that the more elegant solution will be to manipulate the Web Dispatcher or ICM of the backend ABAP.

    – using URL mod, capture /sap/bc/webdynpro/sap/* traffic

    – check if MYSAPSSO2 is present, if not call Portal /irj/portal to do Kerberos signon

    – then redirect to original URL

    This blog needed revision as soon as I posted it 😛

    (0) 
  2. Xuan Chen

    Hi Donald,

    nice blog and thanks for sharing. I currently have similar requirement in my project and would consider your solution. 

    But just one more question: why don’t you just configure SPNego for the backend ABAP server so that the user could authenticate directly with Kerberos regardless whether he has a MYSAPSSO2 cookie or not? Isn’t it a more simple and native solution? This is indeed the first solution comes in my mind. Maybe there are some “limitations” which prevents you using this solution?

    Cheers

    Xuan

    (0) 
    1. Donald James Elemento Post author

      Sure you can configure SPNego if you are willing to implement and use the extra NW SSO product.

      This solution is really for existing customers who already have established their SAP NW Portal with SSO to their backend SAP systems

      (0) 

Leave a Reply