You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Alex Tracer <al...@gmail.com> on 2011/01/04 19:05:10 UTC

Re: Is there possibility to implement custom automatic authentication? (not web-container based)

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 <ch...@destin.be>

> 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<ha...@gmail.com>
>>  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<ja...@ecyrd.com>
>>>
>>>  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.
>>>>>
>>>>
>>>>
>>
>