Results 1 to 2 of 2

Thread: Remote application using Burlap + ACEGI

  1. #1
    Join Date
    Sep 2004
    Posts
    1

    Default Remote application using Burlap + ACEGI

    Hi,

    Now I'm writing remote client application to communicate with server by Burlap. Web services are protected by the ACEGI security framework. As the sample Contacts client application, each time I have to provide the username and password for authentication.

    Questions 1: Will the acegi authenticate the request each time when I calling different services even I have already authenticated? If not, is acegi just use the user id and the Authentication object in the server side to determine the user already login? If not, how to avoid the server to authenticate the user in each service call?

    Question 2: Can I get back the session ID information after login in the client side? Then, can I present it(session id) instead of providing login information again on the next burlap request call like the web browser application?

    Question 3: In my application, we need to implement session management such as we have to force user logout. How can we do it with ACEGI? Do we only need to remove the Authentication object from the Httpsession and remove it from the ContextHolder?

    Thanks

    brgds

  2. #2
    Join Date
    Aug 2004
    Location
    Sydney, Australia
    Posts
    2,768

    Default

    Acegi Security essentially re-authenticates on every Hessian/Burlap request based on the BASIC authentication header. This is because these protocols do not provide a stateful session management solution, so we really have little option. There might be a way, but I am unaware of it. There is negligible performance implication with doing this, as Acegi Security uses caching to avoid hitting expensive (ie AuthenticationDao) backends to evaluate subsequent authentication requests.

    You might prefer to approach the login/logout sequence at an application level. ie not at a security level. At the start of the business application, a "session establishment" method is called, which gives you a workflowId that can be presented on subsequent method invocations. At the end, it calls a "session termination" method. That way all the operations in your business workflow can be associated.

    Now, if you'd really like to use HttpSession etc, my recommendation is to look into Hessian/Burlap at the lower-level of headers and responses. Acegi Security will be only too happy to honour a subsequent jsessionid. Indeed the BASIC authentication model drops the Authentication into HttpSession, so the jessionid representation on a subsequent request will be honoured.

    Alternatively, look into HttpInvoker. There's a good thread, http://forum.springframework.org/showthread.php?t=12248, which demonstrates how flexible HttpInvoker is. In my own experience I have found the Resin protocols have serialization issues and HttpSession does not, although you should of course test with your own application.
    Last edited by robyn; May 19th, 2006 at 05:45 AM.

Similar Threads

  1. Replies: 2
    Last Post: Oct 10th, 2005, 05:12 PM
  2. Webservices + web application + swing - acegi
    By amit_shah25 in forum Security
    Replies: 3
    Last Post: Jun 26th, 2005, 09:13 PM
  3. Use acegi in a standalone application
    By Tud in forum Security
    Replies: 4
    Last Post: Apr 8th, 2005, 06:39 PM
  4. Questioning the core component
    By Martin Kersten in forum Swing
    Replies: 6
    Last Post: Feb 21st, 2005, 03:45 AM
  5. Using CAS in remote application
    By Seasons in forum Security
    Replies: 5
    Last Post: Sep 19th, 2004, 12:05 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •