Vic ,
In my project authentication and authorization are performed by
certificates. Help me, please, to find right way to define WHos is
logged on and What they are doing by JMX .
regards,
Sergey .
> Craig McClanahan wrote:
>>
>>
>> http://weblogs.java.net/blog/gmurray71/archive/2005/07/got_servlets.html
>>
>> My particular question (well, questions :-) for the Struts community:
>>
>> * What technology do you currently use for authentication and authorization
>> in your web applications?
> I used JDBC relms in at least 3 large struts projects. (including 1up,
> the last one, 10mm memebers)
>> * If you use the container managed security faciities of your container,
>> does it completely meet your needs? If not, what else would you like to
>> see?
> I think it should let me use my own DAO(iBatis, EJB), so that SQL
> queeries are cached. The spec should address it at least in words that
> containers are expected to cache the querry.
> I allwaysed added row based security. So a sales guy from NY could see a
> table (dispay tag) where he could edit NY customer but only read TX
> customers.
> The spec might make it easier to use applets (or JSF) for the login page
> If somone clever could come up with a light/simple BRE for security. (if
> this you can see that in this mode but not that unless rare_condition
> isTrue).
> It should allow us to use DB security (ex: create user). Or "Exchange"
> security (so when they fire somone and remove mail... poof)
> It should "timeout" and have to refresh. For example if I upgrade somone
> to "moderator".... they have to log out now. Maybe a remote "JMX" to
> send message to time out.
> Did I say JMX? Everything shold be JMX. WHos is loged on? What are they
> doing? EVERYTHING!
>> * If you don't use container managed security (i.e. the facilities
>> defined in the
>> servlet and J2EE, err, Java EE specifications), what capabilities would you
>> need to have available before you'd consider using the container
>> facilities?
>>
> It be great to be within the spec and pass the login autehtincation each
> request.... so you do not have to realy on the session.
> It be great if it allowed for "coporate Liberty", meaning a global
> security standard, or single logon to mutiple servers and app types.
> Servlet should not assume htpp/htmlServlet! (or
> httpRequest/httpResponse)I can't belive I did not list this 1st ;-)... I
> think of html/http as Gopher, gohper used to be 90% of internet
> traffic.). For example RMIServlet should be implemented, AxisServlet,
> RSSServlet... More about serializing objects(including collections) in
> binary. (So they can be sent over the wire)
> (also ... single coporate security should work on more protocols)
> ALso.. something about encrypting objects sent accross the wire to
> either comunicate results or to keep scope.
> Soemthing about audit logs. Everyone has simple weblogs, it could be
> standardized.... and spec should use a word "asyncronous write in
> another thread". (So when a log audit trail of a users use does not
> dealy the response). Managers LOVE audit trail of what was used by home
> for how long... not to mention that we can invoice on it.
> We may need a "disconcecet" way to manage the session. It should still
> time out, but I should be able to managed it from applets. Like what is
> my session in each request and expicit about how it would die.
> Here is a hint for JSF 3.0:
> http://www.jaxfront.org/pages/overview_introduction.html (Sun should
> provide a conversion path from JSP to JDNC XML)
> J2EE should include JDBC and not J2SE! Becuase! It encourages people to
> use J2EE.jar and makes rt.jar smaller. It discourages Swing newbies from
> not doing DAO or VO/DTO. rt.jar needs a native JDBC driver anyway. (I
> think same about CROBA, just move it up).
> Mail api is important. It should be in J2EE.jar, if not rt, 80% of time
> we need it.
> j2ee spec shoud talk to junit and ant. I used to go to clients to
> work... and they did not have it installed. [EMAIL PROTECTED]
> In general... servlet => services, SoA. If not sure on how to implement
> some idea, just leave as api/interface, wait for best O/S implementation
> and put in J2ee.jar on next go arround.
> hth, my invoice is in the mail ;-)
> .V
> (I did not post it on his blog :-( )
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
regards,
Sergey mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
