Skip to Content
author's profile photo Former Member
Former Member

Using single sign on with an existing Java web application

Hi.

We are currently developing a Struts based application which will be hosted on WebAS, and accessed via several iViews in the EP.

We need to use single sign on but are faced with the problem of session management across several iViews.

Has anyone else faced this problem - or does anyone have any ideas how best to resolve this problem?

Thanks in advance!

John

Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on May 03, 2005 at 03:32 PM

    Hi,

    I played around with SSO and Struts. It worked well except the creation of a "Principal" which can be used by the build in Struts role management.

    But starting from the first step.

    Afte the successful portallogon a sessioncookie is stored on Your PC. You can see the cookie with tools like HTTPMonitor... or by using firefox.

    Cookie cookies[] = hreq.getCookies();

    You have to read out this cookie an try to decrypt it with the EP certificate. If this works well Your the logonname for the user is given.

    I hope I point in the right direction. If yes, post back. There are also some examples....

    Walter

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Dear John,

      from my point of view, we have to seperate the problem in two parts:

      1.) The automatic logon to the struts application via SSO.

      2.) The session sharing via some J2EE mechanism.

      For the SSO (1.) You have to logged on to the portal - with a cookie on the clientside. This cookie can be used for SSO by Your Struts application as long as You share the same session (same browserinstance). This is not difficult examples are available.

      The sessionsharing between a J2EE aap - Struts and an iView is an intersting point. I hope I can get some time to try this out. One trick which is not too clever is to store the session data serialized in a database and privide the sessionid in the url which calls the iView or Struts. Sessionsharing between iViews is no problem as long as You use the HTTPSession.

      Walter

  • author's profile photo Former Member
    Former Member
    Posted on May 04, 2005 at 08:43 AM

    Walter.

    I agree the SSO shouldn't be a problem using existing portal features.

    Also - I tried to share a session between two iviews and this seems to be straightforward. I have one JSP which creates a session, and one which picks up the session if it exists (but doesn't create one if it doesn't). These JSPs are accessed in the portal using URL iViews. When they are loaded the session is created in one iView and the second iView picks up the session created by the first JSP - if you see what I mean. It seems that the portal maintains the single session in the same way that a browser accessing the application would.

    We are making some progress!

    John

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hi,

      if You are in the portal and Your app runs an an iView, You can exchange session data via the HttpSession object. But if You have some other apps which are running in their own Context eg. http://myServer/strutsApp1 and http://myServer/strutsApp2 a dateexchange is not possible (as far as i know) in these apps You are trapped in Your Context irj-> Portal strutApp1 ... strutsAppn. For this You would have to implement Your own Sessionmanager.... which is def. not suitable.

      So I would recommend You implent some data exchange over a database. The Session id could be hooked to the JSP-url by an navigation iView which is displayed in the portal.

      Walter

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.