Blogs

How to .. Integration Non-SAP J2EE-based Web Applications into SAP Portal with SSO Part 2
Manuel Enrique Loayza Gahona
Business Card
Company: Celeritech Solutions
Posted on Oct. 31, 2009 11:46 AM in Application Server, Enterprise Portal (EP), Java Programming, Open Source, SAP NetWeaver Platform

Subscribe.Subscribe
Print. Print
Permalink Permalink

After we have configured our portal object, we must install the gateway application and modified the target application.

1. Deployment of the Gateway Web J2EE Application:

We must  to create an j2ee web application with the purpose to be a gateway from every application that want to validate the SAP Ticket Logon. I have created this application because of the problem with the sapssoext library provied from SAP, it can't be loaded from more than one classloader, then this new web application will be the unque application on the server that can load this library. 

This application could expose 2 or more services, it depends of you. I will mention 2 services:

  1. /SsoGatewayWeb/ssojson.dtx  :  under this URI will happen the vaidation of the SAP Ticket Logon sent by the SAP Portal, it returns a JSON string with the information retrieved from the ticket.
  2. /SsoGatewayWeb/sendsso2cookietest  :  this URI generates HTML content, it generates the string ACL of the certificate file.

Both only accept calls from HTTP POST method

The source code of the application can download from here. This application was developed with Spring MVC  2.0.8 and Json-Lib. Also it uses servelet technology.


This project also exports a client library that should be used for projects to integrate, this is called myssoext.jar.


Note: To test the latter URI(/SsoGatewayWeb/sendsso2cookietest ), an iView must be created as we seen in the first part of this blog, the only difference is that when you edit the iView should get in the attribute "URL Template" will have to go as follow: 

 
<System.protocol>: / / <System.server>: <System.port> <System.uri>? <Authentication> & X509 = /my_path/on/destination_server/verify.pse


Where x509 is the name of the parameter, by example, here is a file system path of the Unix platform. Another point to mention is that the file to test must be test into the SAP Portal that generated it, namely whether the file "verify.pse" was created on myserverX portal, then the iView must be in myserverX SAP Portal.

 

2. Changing the Target Application


This integration involves changing the destination of the application code. In our case is a Struts J2EE web applications using Spring Framework and Strut Framework.


This will import the library "myssoext.jar". Which contains the following claes and interfaces:

com.mysap.sso.ILogonConstants
com.mysap.sso.LogonTicketException

pe.com.mydomain.ssoenablerapp.integration.ISso2TicketClient
pe.com.mydomain.ssoenablerapp.integration.IValidateMySapTicketSso
pe.com.mydomain.ssoenablerapp.integration.Sso2TicketHttpClient


Based as it is developed the target applicaton is able to identify the URL to which you pass the SAP Logon Ticket, and this is where it performs the authentication of the application, the uri is:

/strutsdemoweb/autentificar.do

It will be directed by URI org.apache.struts.action.ActionServlet class of Struts Framework, and what direction, according to the struts-config.xml file, I have modified my customized class.


I haved followed the next steps to fit my application with the gateway web application.

1. Within base web.xml file, i have added a filter, i have used it for verification, it implements the interface pe.com.mydomain.ssoenablerapp.integration.IValidateMySapTicketSso.

 

The method "isValidateMySapSsoTicket", once implemented, should be called before any sentence in the filter class. This will validate the existence of the parameter "MYSAPSSO2" in the received implementation of the HttpServletRequest interface.
If successful, will put two variables in session:


IlogonConstants.TICKET_SESSION: it defines that the SAP Logon Ticket, in the request, was read and achieved successfully

IlogonConstants.PORTAL_USER: attachment containing the user in the SAP Logon Ticket, this should be the id of the user logged into the SAP Portal and will be used for validation against the target application.


Both constants are in the package "com.mysap.sso" within the library above.


For this case must include the following libraries and their dependencies.
a. Json-lib, in its version 2.2.3 (json-lib-2.2.3-jdk13.jar) and its dependencies
      1.Jakarta commons-lang 2.4
      2.Jakarta commons-beanutils 1.7.0 or higher
      3.Jakarta commons-collections 3.2
      4.Jakarta commons-logging 1.1.1
      5.Ezmorph 1.0.6

b.Jakarta Commons Http Client in version 3.1 (HTTPClient-commons-3.1.jar) and its dependencies
       1.Jakarta commons-codec 1.3.
      2.Jakarta commons-logging 1.1.1

 

2. After, we need to modify the customized struts action class. The most important thing here is to validate the presence of 2 previous variables in the scope "session" and executes the log-in of the user into the target application.

 

3. I have modified the application-context file of the spring framework to inject the HttpClient class.

 
<bean name = "httpClient"  class =
 "pe.com.mydomain.ssoenablerapp.integration.Sso2TicketHttpClient">
    <property name="strUri" value="${sso2ticket.verifier.uri}"/>
    <property name="strScheme" value=
            "${sso2ticket.authentication.scheme}" />
    <property name="strCharacterEncoding" value =
            "${sso2ticket.url.character.encoding}" />
</bean>



the propertyConfigurer bean.

    <bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="locations">
            <list><value>classpath:configuration.properties</value></list>
        </property>
    </bean>

4.We need to add configuration.properties at the root of the classpath. It contains the following lines :

sso2ticket.url.character.encoding = UTF-8
sso2ticket.authentication.scheme = basicauthentication
sso2ticket.verifier.uri = /SsoGatewayWeb/ssojson.dtx

the variable sso2ticket.verifier.uri contains the URI of the gateway application that validate the SAP Logon Ticket.

the variable sso2ticket.authentication.scheme is used by the UME API.

the variable sso2ticket.url.character.encoding is used to create the cookie.

 

Note. The most important in the code is after you have retrieved the user from the JSON string in the target application we must authenticate with the UME API like that:

 

Subject objSubject = UMFactory.getLogonAuthenticator().logon(request, response, strSchemeAux);

 

This code line allows to bypass the default login screen.

You can download here the java code with the mentioned previous code.

I hope than you can find useful the information on this blog.

 

Bye, see you later.

 


 

 

 

Manuel Enrique Loayza Gahona is a SUN Certified Enterprise Architect and SAP NW Java Developer for Celeritech Solutions in Lima, Peru


Add to: del.icio.us | Digg | Reddit


Comment on this article
Comment on this weblog
Showing messages 1 through 3 of 3.

Titles Only Main Topics Oldest First

  • facing the class loading issue
    2010-01-29 14:19:08 Abhijeet Dey Business Card [Reply]

    Hi Manuel,


    We have deployed our java application in NetWeaver 7.0. To decrpyt the logon cookie we are using the library libsapssoext.o. When we are tying to load this library it fails with the following exception.


    ERROR SSO2Ticket.<clinit>() - Error during initialization of SSO2TICKET:
    libsapssoext.o (Library is already loaded in another ClassLoader)


    This had actually worked first time when we deployed the app but after that when we redeployed the application..it throws this error and any native calls fails after this point.


    Below is the java code snippet which we are using to load this library.


    static {
    try {
    logger.debug("java.library.path - "+System.getProperty("java.library.path"));
    System.loadLibrary("libsapssoext.o");
    System.out.println("SAPSSOEXT loaded.");
    logger.debug("SAPSSOEXT loaded.");
    } catch (Throwable e) {
    System.out.println("Error during initialization of SSO2TICKET:\n"+ e.getMessage());
    logger.error("Error during initialization of SSO2TICKET:\n"+ e.getMessage());
    }
    }


    The only workaround we fond is to bounce the DPO server, it works without the classloader issue.


    I found your blog very similar to this problem. You have mentioned of having a separate module. Could you please elaborate on how this independent module can talk with other deployed projects. I know you have mentioned about having some services but since our project is not using spring,JSon,structs etc I am looking for other ways to refer to load/refer to this library.


    Also Is there any different way of loading the libraries instead of loading them in the static block of SSO2Ticket.java ?


    It would be of great help if you could advise on this situation.


    Thanks,
    Abhijee

    • facing the class loading issue
      2010-02-02 13:16:52 Manuel Enrique Loayza Gahona Business Card [Reply]

      Hi Abhijeet.


      I had the same problem, it is because of the JVM only allows one Classloader to reference to the library (dll or so). It works fine the first time, but when you tried to deploy again, the current classloader isn't finished, and another classloader is start-up for the new deployment task. Then the JVM can't reference the library because other Classloader are using it.


      To resolve this problem, I created an centralized application that I have mentioned in this blog.


      If you're following with my blog, and you have problem with the centralized application, you will need to restart the App. Server(to start a new web classloader) and test your changes again.


      Warm regards.

      • facing the class loading issue
        2010-02-02 21:54:20 Abhijeet Dey Business Card [Reply]

        Hi Manuel,


        Thanks for the response. I follow your blog but really would not be able to use the implementation of it since we are not using spring,json etc. our application currently just using servlets and jsps.


        Could you please elaborate on the different ways applications can communicate with the centralized app. You have mentioned of having some services..but seems like it uses spring/json. could you explain other ways of interacting/referring to this app. Again keeping in mind that our app just has plain servlets.


        Really appreciate your inputs on this.


        Thanks,
        Abhijeet


Showing messages 1 through 3 of 3.