Re: What I'm looking for

Hi Bill,

Here's some feedback on the points you listed:

1. We have been talking about how nice it would be to have a re-usable solution for persistent sign-ins. However, at this point in time, neither container-managed security or SecurityFilter provides this feature. It may be available in future versions of SecurityFilter.

2. SecurityFilter solves this problem. You can link directly to your login page, or even put a login form on every page in the site. SecurityFilter will process these "spontaneous" or "unsolicited" login submittals and send the user to a configurable default page. I would like to improve the filter to send you back to the page you were on. Or at least something more flexible than the current implementation of a single default page. But at least you can login without being forced, and until we have something better, the single default page might meet your needs, or at least allow you to write your own system where the default page would send you somewhere else.

3. I think you can create your own Principles with container-managed authentication on most app servers, and you can definitely do it with SecurityFilter. The realm interfaces for Tomcat and SecurityFilter allow you to return whatever kind of Principal you want. I believe other app servers let you do this, too.

Some of these features are under development now with SecurityFilter. If you can't afford to wait, you might consider extending SecurityFilter to add your features. There will be a bug fix release in the next week, so it might be worth waiting for that if you want to stay up-to-date and not deal with merging your extensions in.

The issues you raised are ones that have been a problem for others. The persistent cookie issue (#1) is one that was discussed earlier this week on this list, though I must admit I hadn't thought about it as a feature for SecurityFilter before. #2 is one of the major reasons SecurityFilter was created. WebLogic actually allows you to send unsolicited login submittals, but it sends you to a weird place. Tomcat rejects the request with an error. #3 might not turn out to be a problem, but I am not really sure without doing some experimentation.

-Max
  ----- Original Message ----- 
  From: Bill Ataras 
  To: (securityfilter-user 
  Sent: Saturday, December 14, 2002 10:55 AM
  Subject: [securityfilter-user] What I'm looking for


  Should have posted this here instead of the forum. Sorry.

   

  My problems with container security (I'm new to servlets, but an experienced programmer) are below. I'm using tomcat 4+. 

   

  1. No portable way to make the jsessionid cookie persistent across browser sessions on the user's machine. Why the hell did the servlet spec people do that? 

   

  2. No way force-sign on a user without sending him to a protected resource. 

   

  3. No portable way to create your own user principle which carries info beyond name/roles. 

   

  I could be wrong about the above. But does this sound right? I'm thinking of writing my own session manager, using my own cookies and using a servlet filter to a) protect a tree of resources b) control the user session cookie c) 'signon' users when and how I like. 

   

  Am I the 1st person to encounter this, or the 50,000-th?