Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

In the past few months I have been working with several ISVs to help them port their J2EE application to the SAP Web Application Server 6.40 (WebAS), develop iViews for SAP Enterprise Portal 6.0 on WebAS 6.40 (EP), and eventually obtain the “Powered By SAP NetWeaver” (PBNW) certification.

                                                                                                   

Along the way, I have noticed some areas that have not been well documented yet, and have picked up some tips and tricks, which I am going to share with you in this and subsequent blogs.

 

One topic of interest to many is single sign-on (SSO).   SSO is a very useful feature of the EP, and many people have asked, “How can I implement SSO?”

 

The answer is, obviously, “It depends.”   There could be many different scenarios in which SSO needs to be and can be implemented, using various techniques.

 

Generally speaking, there are two common ways to implement SSO in a portal landscape:

- Using SAP logon ticket

- Using Account Aggregation (User Mapping)

 

(Another option is to use X.509 client certificate, but you will need to deploy a complete PKI infrastructure to do so.   Yet another option is to use some third party Web Access Management software.   SAP is in the process of rolling out certifications of such software.   So, make sure you ask your vendor smart questions such as “Are you SAP integration certified?”)

 

In this first installment, I will focus the discussion on implementing SSO with SAP logon ticket.   I will discuss user mapping in the next blog.

 

To implement SAP logon ticket-based SSO, the first thing you need to do is to look at your content-providing application (a.k.a. data source, or backend).   How can you make the backend accept SAP logon ticket?   There are many possibilities here.

 

Enabling your backend to accept SAP logon ticket

 

If your backend is an ABAP application running on SAP WebAS ABAP (or even earlier versions of SAP BASIS), you can find instructions on configuring WebAS ABAP to accept the logon ticket here.

 

If your backend is a SAP J2EE application running on the SAP WebAS Java, you can easily configure the WebAS Java to accept the logon ticket by following these instructions.

 

If your backend is a non-SAP J2EE application running on the SAP WebAS Java, you can still follow the same above steps to have the non-SAP J2EE application take advantage of the SAP WebAS Java’s ticket accepting and verification capability.   (Of course if the J2EE application specifically uses the Form-based logon, then the ticket-based SSO won’t work.)

 

If your backend is a Java application running on a non-SAP application server, you can insert some code into your application so it can accept the SAP logon ticket, retrieve the user id from the ticket, and grant access basing on the user id.   Tim Mullé and Stephan Boecker have discussed how to do so here.

 

If your backend is an ASP.NET application running on Windows Server 2003, then this document written by André Fischer and Michael Sambeth of SAP/Microsoft Collaboration Technology Support Center (CTSC) should help you.

                                                                                                                                 

If your backend ASP.NET application is not running on Windows 2003, then this document, written by Reiner Hille-Doering and Stephan Boecker, should still be able to help you.

 

Now, assume that you’ve configured your backend to happily accept the SAP logon ticket, let’s look at the different ways to integrate the content provided by the backend to the portal, and enable logon ticket-based SSO for the portal iViews.

 

Integrate content to the portal and enable logon ticket-based SSO

 

As you know, there are many different ways to integrate backend contents to your portal.   We will look at the most common ones and see how to enable logon ticket-based SSO for them.

 

URL iView

It’s the easiest way to integrate content to the portal.   You create URL iView in the portal Content Studio: Content Administration -> Portal Content.   Detailed instructions can be found here.

 

For URL iView, there is an interesting propertycalled “Fetch Mode”.   It controls who, the client browser or the portal runtime, will do the fetching.   Since the logon ticket issued by the portal to the already-authenticated portal user is technically stored in a session cookie called MYSAPSSO2 on the client browser, to take advantage of the logon ticket, you will have to set the fetch mode to “Client-side” (which is the default).   When the URL iView is accessed, the client browser automatically presents the ticket cookie in the HTTP request header, (Of course your backend application has to reside on the same domain as the portal server for this to happen; otherwise, please see this document on how to “Perform Cross-Domain Single Sign-On with SAP Logon Tickets”).   If your backend application has been configured to accept the logon ticket, then, bingo, you have implemented SSO!

 

Application Integrator

If for some reason that the basic URL iView can not satisfy your needs, you may want to have a look at using a so-called “Application Integrator”.

You can create iViews based on the SAP-delivered generic application integrator sap.portal.appintegrator.sap.Generic, which is very flexible and can be used to integrate most HTTP-based web applications.   In some rare cases, you can also write your own custom application integrator component and then create iViews based on it.

 

Documents of “Application Integrator” can be found at: Java Development -> User Interface Development -> Application Integrator, after you’ve installed PDK 6.0.6.0.

 

If you are using the generic application integrator sap.portal.appintegrator.sap.Generic, since the fetching is always done by the client browser, you don’t have to do anything extra (such as worrying about the “URL template fraction for SSO2”) to have the browser submit the logon ticket along with the HTTP request to the backend.   So, if your backend application has been configured to accept the logon ticket, then your SSO is all set!

 

When you create your custom integrator, if in the end you still rely on HTTP redirect to instruct the client browser to fetch the content from the backend web application (as the SAP-delivered HTTPRenderLayer does), then the same would apply: client browser will automatically send the logon ticket cookie in the HTTP request, and if your backend application has been configured to accept the logon ticket, then SSO is ready to go!

 

Custom Java iView

Sometimes you may want to write your own custom Java iView to integrate contents from your backend application to the portal, e.g., in order to take advantage of some portal features, such as unified rendering (look and feel), portal eventing, etc.

 

Before your Java iView code could access the data or functionality provided by your backend application, the backend may require the Java iView code to authenticate.   Depending on the requirement, occasionally you can authenticate with some generic “service” user, but most of the times you may need to pass along the credentials associated with the portal user who is accessing your Java iView.

 

If the backend has been configured to accept the logon ticket, then the Java iView simply needs to pass along the logon ticket to the backend for authentication.

 

SAP User Management Engine (UME, which is used by both SAP WebAS Java and SAP EP) provides APIs to do just so.   UME API JavaDoc can be found at Java Development -> Javadocs -> User Management Engine, if you have installed PDK 6.0.6.0.

 

You can use UME API to “enrich” an HttpURLConnection object or a SOAPMessage object with the logon ticket cookie.   The following code snippet shows how to do so:

 

import com.sap.security.api.IUser;

import com.sap.security.api.UMFactory;

import com.sap.security.api.umap.IUserMappingData;

 

HttpURLConnection httpUrlConnection = ...;

 

// request is the IPortalComponentRequest object

IUser iuser = request.getUser();

IUserMappingData iumdata = UMFactory.getUserMapping().getUserMappingData(null, iuser);

 

// enrich the HttpURLConnection object with the logon ticket cookie

iumdata.enrich(httpUrlConnection);

 

// httpUrlConnection.connect();

 

What if you are not using HttpURLConnection or SOAPMessage?   Well, try to use them if you can.   Otherwise let SAP know what you are using, and SAP may eventually provide an enrich() method for that.   (Of course this may take a long time to happen 🙂

 

If you really want to use your own ways to connect to the backend, and want to pass along the logon ticket, then the following code snippet might give you some hints.   Please be warned that generally you should use UME enrich if possible.

 

String MYSAPCOOKIENAME = "MYSAPSSO2";

javax.servlet.http.Cookie ticketCookie = null;

 

// request is the IPortalComponentRequest object

javax.servlet.http.Cookie[] cookies = request.getServletRequest().getCookies();

if (cookies == null) {

  // Error handling: request does not contain cookies

} else {

  for (int i = 0; i < cookies.length; i++) {

    javax.servlet.http.Cookie cookie = cookies[i];

    if (cookie.getName().trim().equals(MYSAPCOOKIENAME)) {

      ticketCookie = cookie;

      break;

    }

  } // for

 

  // logon ticket cookie value

  String cookieValue = ticketCookie.getValue();

 

  // Now you can access the backend application with the logon ticket

  // E.g., use Apache HTTP Client

}

 

Web Dynpro iView

 

Some of you may want to use the latest and greatest SAP Web Dynpro technology to write a Web Dynpro web application, and incorporate it to the portal as a Web Dynpro iView.

 

Documents of Web Dynpro development can be found as part of the SAP WebAS Java Development Manual available here, and instructions of creating Web Dynpro iViews can be found here.

 

To develop Web Dynpro application, you need to follow a strict programming model.   You essentially treat some flexibility for the other greatness of Web Dynpro, such as its neat MVC model, almost what-you-see-is-what-you-get interface designing, minimum coding, and development productivity.

 

Since Web Dynpro applications run on the Web Dynpro container (which is part of SAP WebAS Java, in parallel to the portal runtime), to achieve single sign-on, as a first step you need to configure the WebAS Java system on which your Web Dynpro application runs to accept ticket issued by the portal system (as described earlier, by following these instructions).

 

Your Web Dynpro application, as a front-end web application, may also need to access some kind of backend application (business logic, etc.), and may be required to authenticate to the backend.   So, the next step to achieve SSO is to figure out how to authenticate from the Web Dynpro application to the backend.

 

If the backend is a SAP ABAP system which is accessed through the Web Dynpro adaptive RFC technology, then SAP has already done the pumping for you.   You only need to use the Web Dynpro Content Administrator to configure the RFC connection to use the logon ticket as authentication method.   (Of course you still need to configure the backend ABAP system to accept the ticket.)   Detailed instructions are available here.

 

If the backend that your Web Dynpro application tries to access is not an ABAP system, but you are using HttpURLConnection or SOAPMessage to access the backend, then the fore-mentioned UME enrich API can still be used.   The following code snippet shows how to do so:

 

import com.sap.security.api.IUser;
import com.sap.security.api.UMFactory;
import com.sap.security.api.umap.IUserMappingData;
import com.sap.tc.webdynpro.services.sal.um.api.IWDClientUser;
import com.sap.tc.webdynpro.services.sal.um.api.WDClientUser;

HttpURLConnection httpUrlConnection = ...;

IWDClientUser user = WDClientUser.getCurrentUser();
IUser iuser = user.getSAPUser();
IUserMappingData iumdata = UMFactory.getUserMapping().getUserMappingData(null, iuser);

iumdata.enrich(httpUrlConnection);

 

However, if you are not using HttpURLConnection or SOAPMessage to access the backend, then it gets a little tricky.   At the time of writing, Web Dynpro does not provide any public API for the Web Dynpro application to directly retrieve the SAP logon ticket cookie from the HTTP request.   Although technically it’s possible to use Web Dynpro’s internal API to access the original HTTP request object and then retrieve the logon ticket cookie, officially it’s not supported.   If this is something you absolutely have to do, talk to you SAP support person (not me though :-).

 

Alternatively you can also first use the UME enrich() to have the logon ticket cookie set in, say, a HttpURLConnection object, then retrieve the logon ticket cookie from it, and subsequently use it in your own connection.   But, unfortunately, this is not really a neat workaround.

 

 

17 Comments