Greetings, @Janne
CookieAuthenticationLoginModul is quite close to my needs except I need to get values of 3rd-party cookies and verify them in an external data source. #2: OK, I will provide a patch later if it still will be useful. #3: OK, created: https://issues.apache.org/jira/browse/JSPWIKI-681 Apache Shiro is totally different story from JAAS. I'm not sure if JSPWiki migration to Shiro will help to fix my problem. It's totally depends on JWPWiki specific implementation. @Andrew WebContainerLoginModule can support authentication but I can't use it to tell JSPWiki about user's roles because I can pass only one Principal object trough getUserPrincipal() method of HttpServletRequest. So I can pass WikiPrincipal (with user's login) but can't pass Role (com.ecyrd.jspwiki.auth.authorize.Role) with it. Should my custom filter redefine isUserInRole() of HttpServletRequest to specify roles? Will JSPWiki understand that? @Christophe Not really what I need but I'm on the way on making my custom filter too. @All Thanks to everybody for your help. 2010/12/28 Christophe Dupriez <[email protected]> > Hi! > > I can say I just messed to modify JspWiki to add data coming from Active > Directory (name, e-mail) to an implicit Tomcat authentication done through > Waffle (NTLM). > I found it not so easy (more than one place where information must be > collected and managed). > I will redo it now using a Filter: as you say the result will be much > better: > http://waffle.codeplex.com/workitem/10034 > > The request filter approach is independent from JspWiki versions but also > from applications. > > Good evening! > > Christophe > > Le 28/12/2010 22:15, Andrew Jaquith a écrit : > > Alex: >> >> Thanks for your message. In general, WebContainerLoginModule isn't >> meant to be replaced. Its primary job is to allow container-managed >> credentials to be picked up automatically by JSPWiki. >> >> The best solution for you would be to add a servlet filter upstream >> from JSPWiki that wraps the current HTTPServletRequest. It would >> ensure that the return value of getPrincipal() returns the value you >> want. JSPWiki will then dutifully retrieve the user principal you >> supply and regard the user as logged in. >> >> @Janne: I hadn't seen Shiro before. Conceptually it does pretty much >> everything our own system does, and more. It looks like it's well >> designed, too. The design choices they made seem to be pretty similar >> to the ones I made: e.g., the use of annotations for protecting >> methods, custom permission schemes, separation of authN and authZ, >> etc. And the "remembered" login feature is more or less what we call >> "asserted" logins. Were I building a webapp from scratch, I'd probably >> take a good long look at Shiro. >> >> Andrew >> >> On Tue, Dec 28, 2010 at 2:06 PM, Harry Metske<[email protected]> >> wrote: >> >>> I don't have experience yet with Shiro, but looking at the documentation >>> (which is good), it looks promising, especially it's web filtering >>> capabilities, and the ini-file and bean-style configuration. >>> >>> I see quite a few similarities with security concepts we currently have >>> in >>> JSPWiki, like the default set of web filters that are similar to our >>> login >>> modules, and Shiro permissions similar to WikiPermissions. >>> >>> >>> regards, >>> Harry >>> >>> >>> 2010/12/28 Janne Jalkanen<[email protected]> >>> >>> Hi! >>>> >>>> I think this is solely in Andrew's domain. We have automatic login >>>> using >>>> CookieAuthenticationLoginModule; do you need something else there? >>>> >>>> For #2 I think we could use a patch, if you can write one. Sounds like a >>>> good addition. >>>> >>>> #3 is an oversight; I don't think it should be declared as final. Can >>>> you >>>> open up a JIRA issue and contribute a patch? >>>> >>>> Actually, I've been using Apache Shiro lately, and it's a very well done >>>> AAA library which does a lot of the same stuff as we do. It would be a >>>> lot >>>> lighter for us to use that rather than our own system (even though our >>>> system is pretty awesome). Does anyone have (esp. Andrew) an opinion on >>>> how >>>> well Shiro matches up with our stuff? >>>> >>>> /Janne >>>> >>>> On 16 Dec 2010, at 05:13, Alex Tracer wrote: >>>> >>>> Greetings, >>>>> >>>>> I'm trying to link JSPWiki to an existing application. I need make a >>>>> user automatically (i.e. without explicit login through Login page) >>>>> logged in JSPWiki if he already logged in the another application. All >>>>> I >>>>> need to do on JSPWiki side is to get some cookies from request and pass >>>>> them to my application. >>>>> >>>>> I've expected that my task will be quite simple because I knew that >>>>> JSPWiki provides "jspwiki.loginModule.class" property that allows to >>>>> use >>>>> custom JAAS authentication. Also I've seen that >>>>> WebContainerCallbackHandler is able to give me an HttpRequest (via >>>>> HttpRequestCallback) so I can grab my cookies from the request and do >>>>> my >>>>> dark deeds with them... >>>>> >>>>> However I've met some serious obstacles: >>>>> >>>>> 1. "jspwiki.loginModule.class" property is used only for authentication >>>>> thought Login.jsp. There no way to specify a custom JAAS LoginModule >>>>> that will be used in the same place as WebContainerLoginModule in >>>>> AuthenticationManager.login( HttpServletRequest request ). So I can't >>>>> use my custom LoginModule here so I can't make "automatic" login. >>>>> >>>>> 2. Login.jsp uses AuthenticationManager.login( WikiSession session, >>>>> HttpServletRequest request, String username, String password ) and >>>>> supports customizable LoginModule but WikiCallbackHandler in this >>>>> method >>>>> is unable to handle HttpRequestCallback. So I can't use my custom >>>>> LoginModule even for explicit login because I can't cookies from >>>>> JSPWiki. >>>>> >>>>> 3. There is no way to replace AuthenticationManager with implementation >>>>> that matches my needs because AuthenticationManager is final so I can't >>>>> redefine it in classmappings.xml. >>>>> >>>>> I know that I can modify JSPWiki sources and build my own version of >>>>> JSPWiki but I hope that there a way to avoid that because it will add a >>>>> lot of extra work on merging with future versions of JSPWiki. >>>>> >>>>> Could anybody please advise on my problem? At least just point out >>>>> where >>>>> is right place to ask ;) >>>>> >>>>> Best regards, >>>>> Alex Tracer. >>>>> >>>>> PS: Sorry for my bad English, I'm still not very good in it. >>>>> >>>> >>>> >> >
