Erik,
i don't quite understand what you call a hand-rolled
java component (maybe because of my english).
Anyway, it seems to me that you're not using JAAS to
completely control application's security, are u?
I don't know if it possible, but if so, would you post
your setup and basic classes?
I'm very very new at security stuff...
Anyway, i cleared out a lot of things for me.

Thanks,
Leandro.


 --- Erik Weber <[EMAIL PROTECTED]> escreveu: 
> I don't really consider myself an expert here, but I
> dare say that there 
> are a lot of webapps deployed out there using
> programmatic (hand-rolled) 
> security successfully. I have used the approach with
> success. What 
> exactly the advantages are to using
> container-managed security I am not 
> able to fully deduce (except for the obvious -- it's
> nice to declare 
> stuff in web.xml in a standardized way -- and that
> perhaps it might make 
> Servlets a *little* more portable if you wanted to
> use them among 
> different apps). But then again, I haven't had to
> take on a project yet 
> where the environment was extremely complicated,
> when it came to how 
> users and permissions were managed (typically I see
> the same tried and 
> trusted setup -- USER, GROUP, ROLES and PERMISSIONS
> tables in some 
> central database, and some hand-rolled Java
> component, used to authorize 
> the current request, that is invoked in some
> "common" area, such as a 
> Servlet Filter -- or, in Struts, a base Action class
> or a custom 
> RequestProcessor). It seems like JAAS is still at an
> immature stage 
> perhaps, or at least the state of documenation about
> it is.
> 
> The other route it seems you could go is to use a
> container-managed 
> login as you suggest, and enjoy using the methods
> such as 
> request.isUserInRole instead of invoking security
> methods on a 
> hand-rolled component, but I think you will have to
> give up the 
> JBoss/Tomcat stack to do this for now (someone
> please correct me if I am 
> wrong), because I think there is a security
> integration problem there, 
> as I described earlier. I'm guessing Tomcat as stand
> alone might be a 
> good way to go though. I have not done this and
> couldn't say whether it 
> is "common and usual".
> 
> I have tried to write my role-checking methods so
> that in the future if 
> I port an application to JAAS I can just refactor
> them to invoke the 
> standard methods instead of my own. But like I say,
> I'm far from an 
> expert in this area.
> 
> Hope that helps,
> 
> Erik
> 
> Leandro Melo wrote:
> 
> >So Erik, is it a common and usual aproach to do
> login
> >outside of Struts (ordinary jsps), and then use
> Struts
> >afterwards???
> >
> >
> > --- Erik Weber <[EMAIL PROTECTED]>
> escreveu: 
> >  
> >
> >>Leandro, search the archives of this List for
> >>"JAAS". I participated in 
> >>a thread about this within the last two months.
> >>
> >>I'm not sure if I understand exactly what you want
> >>to do, but if you 
> >>want to use container-managed security, I don't
> know
> >>of a way to have 
> >>your login screen be part of Struts. As far as I
> >>know, you have to let 
> >>the container process the request that results
> from
> >>the login screen's 
> >>form submittal (I tried having an Action intercept
> >>this request and then 
> >>attempt to login with the JBoss JAAS module
> manually
> >>but gave up when I 
> >>realized problem # 2 -- below).
> >>
> >>Another problem you are probably going to run into
> >>is that the JBoss 
> >>security context is not propagated to Tomcat, and
> >>vice versa, as far as 
> >>I know. So if you authenticate using JBoss JAAS,
> >>Tomcat won't know about 
> >>it, and the methods such as request.isUserInRole
> >>aren't going to do you 
> >>any good (although you would presumably be able to
> >>use the similar 
> >>methods on EJBs, because they are running within
> the
> >>JBoss security 
> >>context).
> >>
> >>I found JAAS to be a nightmare, though a couple
> >>people gave me possible 
> >>solutions to the problems I mentioned in the
> thread
> >>(one would be 
> >>intercepting the login screen request and then
> >>manually logging in with 
> >>both JBoss JAAS as well as Tomcat JAAS modules --
> >>but I don't know if 
> >>this has been done). I presume it's a much easier
> >>endeavor if you are 
> >>just using Tomcat stand alone, but I'll let Craig
> >>address that if he 
> >>wants, because I've never tried it.
> >>
> >>Erik
> >>
> >>
> >>Leandro Melo wrote:
> >>
> >>    
> >>
> >>>Or i just extend the DatabaseServerLoginModule
> >>>      
> >>>
> >>class
> >>    
> >>
> >>>and leave an empty class????
> >>>
> >>>
> >>>
> >>>--- Leandro Melo <[EMAIL PROTECTED]>
> >>>escreveu: 
> >>> 
> >>>
> >>>      
> >>>
> >>>>Just complementing my question...
> >>>>
> >>>>Would it be fair if i copy JBoss'
> >>>>DatabaseServerLoginModule code and place it
> inside
> >>>>an
> >>>>Action???
> >>>>
> >>>>This way, i'll have an Action (for example,
> >>>>MyLoginAction) that does exactly what
> >>>>DatabaseServerLoginModule does.
> >>>>
> >>>>
> >>>>
> >>>>--- Leandro Melo <[EMAIL PROTECTED]>
> >>>>escreveu: 
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>Please help me out here!
> >>>>>I'm very new with jaas, so i need some help.
> >>>>>
> >>>>>I got a simple login that is working fine for
> me,
> >>>>>here
> >>>>>it is:
> >>>>>
> >>>>>...
> >>>>><FORM action='<%=
> >>>>>response.encodeURL("j_security_check")%>' 
> >>>>>     method="get">
> >>>>>     <!-- esses  nomes tem q ser assim ->
> >>>>>j_username
> >>>>>-->
> >>>>>      NOME:<INPUT type="text" name="j_username"
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>/>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>      
> >>>>>      <!-- tem q ser j_password -->
> >>>>>      SENHA: <INPUT type="password"
> >>>>>name="j_password"
> >>>>>/>
> >>>>>      <INPUT type="submit" value="Login" />
> 
=== message truncated === 


        
        
                
_______________________________________________________
Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! 
http://br.acesso.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to