Skip to Content

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.

 

 

To report this post you need to login first.

17 Comments

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

  1. Former Member
    This has to be one of the most valuable blogs on SDN. It covers most of the SSO topics in a very good way.

    PS You seem to have used a non-SDN-standard stylesheet. Maybe you should do a quick review so it looks like the other blogs

    (0) 
  2. Not only provide information about the sso, but also give an overview of EP and SAP JAS’s typical application.Very good.
    (0) 
  3. Former Member
    This is by far the best ever article I have read in the SAP portal space. It delivers a clean framework and step-by-step guide on how to implement Portal SSO in different scenarios. Every person who want to do SSO in SAP Portal should read this article first.
    (0) 
  4. Former Member
    Hi Robert

    I read your blog long ago and implement the SSO for Non-SAP JAVA Based applications hosted on external APP Server. Everything was working (i tried in SP2) and we were planning to implement this solution for all the backend Java Based application which we are pointing in EP.

    But now when we are trying to implement this in SP11 and even the simple example code of yours is not working. and giving exceptions while reading the ticket. (The domain is correct and the SSO cookie is also getting passed).
    Can you please help me in sloving this error. My personal mail-id is “gauravfeb10@gmail.com“. Kindly mail me so that i can tell you the exaact problem i am facing.

    Regards
    Gaurav Gandhi

    (0) 
  5. Former Member
    First of all, excellent article. A very useful step-by-step for SSO. My only complaint is that the resource for config of apps running on non-SAP webapp server (Tim Mullé and Stephan Boecker’s discussion) is missing! Help! =)

    Thanks,
    Matt

    (0) 
  6. Former Member
    I’m trying to find a way to obtain two SAP login tickets, one from the primary issuer and one from a secondary issuer.  Imagine I have two portals, A & B.  I want B to accept A’s tickets, then issue it’s own which could be cached and used later, have a different validty time, etc.  Know of any way to acheive this?  It seems that the CreateTicketLogonModule doesn’t issue a new ticket if one already exists.

    Help would be greatly appeciated!!

    (0) 
  7. Former Member
    Great blog.  Quick question though.  Has the link to “Perform Cross-Domain Single Sign-On with SAP Logon Tickets.”  This link does not appear to be working any longer on this site.

    Thanks.

    (0) 
  8. Former Member
    Your blog is very interesting. But it is missing of the follow scenario:

    An external WebSphere Web Application calls SAP BSPs (on abap stack). How to implement SSO in this case?

    I really haven’t find nothing regarding this.

    Regards,

    Vito Palasciano

    (0) 
  9. Former Member
    I cannot open the link associated with the  below article.

    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.

    Any suggestions will be helpful. As a novice   these type of articles help me out to start  my Task.

    Thanks,
    Naveen

    (0) 
  10. Former Member
    I have a situation where SSO needs to be implemented between 3 WEB AS servers, Portal should not be used at all.

    I have figured out that following steps to implement SSO need you to verify it for me.

    Pre-requisities – User ID should be same in all systems.

    Issuing server:

    1. Configure a single Web AS server for issuing tickets by chnaging the system parameters. Lets say this Server has “A”
    2. Replace the Servers SSO PSE.

    Accepting server:

    1. Configure the remaining Web AS server for accepting the logon tickets using the system parameters. lets say these servers has “B & C”
    2. SAP Library needs to be installed.
    3. create an RFC destination to the issuing Web AS.

    Now the configuration is over & system is ready for the SSO testing.

    So now if the user just logons into a system “A” using SAP GUI with the correct user id & password then logon ticket is created.
    Now to login to Server “B or C” the user just clicks in the SAP GUI, the menu screen appears using already created logon ticket.

    My Questions.
    1. Is my implementation steps correct or needs some thing else also.
    2. What if the Users password is different in other systems, will the logon into Server “B or C” be successfull.
    3. What if another user needs to login from the same computer which has already got a logon ticket created by another user.

    Your answers will greatly help me in leading this project.
    Will surely reward you for any light you can throw on this post.

    Best wishes
    Naveen Murthy

    (0) 
  11. Former Member
    After log on to EP with English username, I can use the issued MYSAPSSO2 to log on to other systems.

    However, if the username contains Chinese or Japanese characters, log on failed with error message “Logon ticket could not be validated by system R35CLNT800. Message: USER_OR_PASSWORD_INCORRECT”.

    Is there any special logic for such scenarios that user name contains Chinese characters?

    If you know – better also send it to alarm_ray@hotmail.com

    Thanks.

    (0) 
  12. Diego Petrone

    Link to “instructions on configuring WebAS ABAP to accept the logon ticket”

    and link to “easily configure the WebAS Java to accept the logon ticket by following these instructions” it doesn’t work.

    Thanks.

    (0) 

Leave a Reply