Skip to Content

SSO is one of the most important functions of the portal

When I talk to users of various portals, one of the major plbenefits of a portal is that they can access  information from various sources, without having to log on to each of them. In fact, most of them do not know that the portal is seamlessly signing them in to different IT-system.

Problems from a user perspective

However, most users are used to creating bookmarks and sending links with important information to colleagues. This is not very easy to do in SAP EP and, in my humble opinion, this is one areas SAP need to improve in future versions. Albeit I have to admit that it is a difficult task to solve due to independent iframes containing inter-related iViews.

Direct links into the portal

At the moment you can use the NavigationTarget property to link to pages in the portal. But this is not very intuitive for the average user as they do not know what a PCD url is. The introduction of the “address” tray option in EP 6 SP2 Patch 4 might help users a bit, but I think most people will be confused with this extra information.

Too little space for all the information in a portal

Another problem is that sometimes people feel that the portal framework is “stealing” too much space from the actual content, and would like to access the actual the information only. They could of course access the source of information directly(if it is not SAP EP content), but then they would not have the benefit of SSO.

The problems above were a small distraction from the “core” of this weblog, but it is something implementers of portals need to be aware of. You should make an effort into not placing too many iviews onto a page, and also remember that people have different screen resolutions.

Description of the core problem we would like to solve

Most companies have systems that have mail agents which regularly send out mail to users with direct links to relevant pages of an application. Since the links are direct, the SSO benefits of the portal cannot be used directly. The major contribution of this weblog is to describe a method that will circumvent this problem.

We assume that Windows Authentication is already setup, otherwise the users will have to manually log on to the portal before they can access the application, in which case they might as well log on directly to the application. The solution will however work without Windows Authentication configured, but then the user will have to log on to the portal before the request can be completed.

We also assume that SSO with SAP logon tickets is setup towards the applications you wish to connect.

Implementing the solution

The solution is in fact very easy. The main tasks to be done are:

  • Setup redirection on IIS so that SSO-links to external applications are routed to a different path than normal logons
  • Implement a redirector portal component which receives the SSO-links from the query string and redirects the user to the application

Note that the actions in point 1 might as well be done on the SAP J2EE directly.

The redirection page

We assume we the portal address is , and that if we wish to have a SSO-link we would like to use   .
Notice that the redirect property is URLEncoded (there is an online URLEncoder on ). However, this is not required in most browsers, as it’s done automatically before the HTTP request is sent. <b>Therefore, you can use the url</b>  .

Since we are using IIS as a webserver, it is natural to write the code in ASP. If we were placing the code on the SAP J2EE instead, it would be natural to write jsp code and place the file in the document root of the server.
<textarea rows=”10″ cols=”79″>
Dim loginURL
Dim ssoRedirectComponentURL

//URL to standard login page
loginURL = “irj/servlet/prt/portal/prtroot/”
//URL to redirection component
ssoRedirectComponentURL = “/irj/servlet/prt/portal/prtroot/com.bouvet.portal.redirect.default?redirect=”

Dim redirectURL, doSSORedirect
//get the HTTP GET parameter
redirectURL = Request.QueryString(“redirect”)

if redirectURL <> “” then
end if

//if we do SSO-link, redirect to the component, if not redirect to the login page
if doSSORedirect then
    response.redirect (ssoRedirectComponentURL & redirectURL)
   response.redirect (loginURL)
end if

<p>This asp page could either be placed as the root page for the Default website or as a separate page. The last choice is preferred as normal logons to the portal would not get the extra overhead of the asp page processing.

The redirection component

The redirection component is built in the PDK, but contains very little code. We utilize the doOnNodeReady method of the AbstractPortalComponent to do a redirect. If we would have called the redirect in the doContent method, the redirect would have been ignored (the HTTP headers are already written at this point and therefore cannot be changed).

In the portalapp.xml we define one component, default, which uses this class.

Now, just deploy the par file on the portal and you are ready to go. Since we are calling the component directly through the /irj/servlet/prt/portal/prtroot/com.bouvet.portal.redirect.default we do not even need to make an iview!

So what happens when the user uses a SSO-link via the portal?

Let us do a run-through of the different actions done when the user tries to use an URL of the type .

  1. The request comes to the IIS server, which triggers the execution of the ASP redirection page. As the redirect parameter is set, IIS sends a HTTP 302 with redirection URL .
  2. The client request the redirection url
  3. The IIS performs Windows Authentication of the user since the IIS proxy is used for all irj/ calls. (This will produce some HTTP traffic back and forth between the client and IIS server).
  4. Once the user is authenticated against IIS, the IIS proxy connects to the portal. Since the user is not logged on to the portal, the authentication process through the JAAS login components is triggered. Once this process is complete and the user is logged into the portal, the code of the redirection component is executed. The result is a new HTTP 302 redirect, but this redirect includes the MYSAPSSO2 cookie which is the SAP logon ticket.
  5. The client follows the redirect and sends the SAP logon ticket along (since the “application” server is in the same sub-domain as the portal server).
  6. The “application” server performs SSO using the SAP logon ticket and afterwards returns the requested data to the user.

Possible extensions

There are lots of possible useful extentsions to the code described above, some of them are described here:

    1. Use of aliases instead of full redirection URLs, so that the users could use This should be easy to implement in the redirection component, so that it reads redirect alias and their matvhing URLs from a database or file system
    2. SSO with usermappings as well as logon tickets.
    3. Let the component create an iframe at the top of the page which allows the user to easily get back to the portal. The application content is displayed in another iframe below.
    4. If the connecting system is on another domain, and the portal has a DNS alias for this domain, the ASP page could redirect to the correct DNS alias by looking at the redirect url.

Finally, I would like to thank Oliver Nocon from SAP for his valuable input to the forum thread /message/113531#113531 [original link is broken]

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply