You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by "Steve Dahl (JIRA)" <ji...@apache.org> on 2009/03/09 04:19:56 UTC

[jira] Commented: (JSPWIKI-473) Authorizers not consulted at login

    [ https://issues.apache.org/jira/browse/JSPWIKI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680043#action_12680043 ] 

Steve Dahl commented on JSPWIKI-473:
------------------------------------

Sorry for the delay.

I don't understand how much of this is my own unfamiliarity with compiling JSPWiki from source and how much is a real problem in the code, but things seem to have gotten worse. I downloaded the sources from:

http://svn.eu.apache.org/repos/asf/incubator/jspwiki/branches/JSPWIKI_2_8_BRANCH

...and the ChangeLog file in my download says that the version is 2.8.2-svn-9.

When I build and install this, it *seems* to disable all access controls. I have one page whose ACL reads:

[{ALLOW modify TechD}]
[{ALLOW view Authenticated}]
[{ALLOW rename TechD}]

But when I visit this page without logging in, I am allowed to view it and edit it. If I log in as a user that does not belong to the TechD role, I am also allowed to view and edit it.


> Authorizers not consulted at login
> ----------------------------------
>
>                 Key: JSPWIKI-473
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-473
>             Project: JSPWiki
>          Issue Type: Bug
>          Components: Authentication&Authorization
>    Affects Versions: 2.8, 2.8.1
>         Environment: All
>            Reporter: Andrew Jaquith
>             Fix For: 2.8.2, 3.0
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> From the jspwiki-dev list:
> Steve Dahl wrote:
> Under JSPWiki 2.6.4, we've replaced WebContainerAuthorizer with an LDAPAuthorizer which implements JSPWiki roles in terms of LDAP groups.
> When I compile this for JSPWiki 2.8.0, and modify the jspwiki.properties file to use it, our custom LDAPAuthorizer gets initialized, and is sent findRole(), but it never seems to get sent isUserInRole().
> If it's useful information, LDAPAuthorizer implements Authorizer (not WebAuthorizer), and it implements isUserInRole() with this signature:
> public boolean isUserInRole( WikiSession session, Principal role )
> Is there anything that has changed in Authorizers between 2.6.4 and 2.8.0 that might explain this?
> Looking deeper, it seems that in JSPWiki 2.6.X, WikiSession implemented injectRolePrincipals(), which initialized the session with whatever groups and roles the user belongs to. Groups are read from the group database, and Roles are read from the Authorizer.
> In JSPWiki 2.8.X, injectRolePrincipals() has been replaced by injectGroupPrincipals(), which reads groups from the group database but doesn't use the Authorizer. What is the Authorizer used for now?
> As a side note, I originally implemented LDAPAuthorizer as LDAPGroupDatabase. I ended up rejecting this approach because GroupManager assumes that the members of a Group can be read once when the Wiki is started, and that the Group's membership will only be modified by the Wiki. The problem with LDAP is that the group membership can be modified from outside, and the only way to update the wiki would be to manually restart it. The Authorizer was a better solution for our purposes, because if a user was added to the LDAP group, the Authorizer would reflect that change as soon as the user logged out and back in. Restarting the wiki is not necessary.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Re: [jira] Commented: (JSPWIKI-473) Authorizers not consulted at login

Posted by Andrew Jaquith <an...@gmail.com>.
Steve, I don't know how to help you with this. In 2.8.1-build 5, I
added in some extra code to make sure that Roles returned by custom
Authorizers were added to the user's Subject. I also added in some
unit tests to make sure it behaved as expected. So, from my
perspective the function is working as expected.

What I can't control for in my tests are your environment, security
policy or custom Authorizer. So at this point I need your help to nail
down the problem. If you are handy with a debugger, I'd recommend you
to place a breakpoint in AuthorizationManager.checkPermission and see
what you find.

In particular, I'm interested in knowing what Principals each user's
Subject contains. That should tell us most of what we need to know.
Test the "anonymous" user, and an authenticated user. The Subjects'
Principal sets should be different.

Andrew

On Sun, Mar 8, 2009 at 11:19 PM, Steve Dahl (JIRA) <ji...@apache.org> wrote:
>
>    [ https://issues.apache.org/jira/browse/JSPWIKI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680043#action_12680043 ]
>
> Steve Dahl commented on JSPWIKI-473:
> ------------------------------------
>
> Sorry for the delay.
>
> I don't understand how much of this is my own unfamiliarity with compiling JSPWiki from source and how much is a real problem in the code, but things seem to have gotten worse. I downloaded the sources from:
>
> http://svn.eu.apache.org/repos/asf/incubator/jspwiki/branches/JSPWIKI_2_8_BRANCH
>
> ...and the ChangeLog file in my download says that the version is 2.8.2-svn-9.
>
> When I build and install this, it *seems* to disable all access controls. I have one page whose ACL reads:
>
> [{ALLOW modify TechD}]
> [{ALLOW view Authenticated}]
> [{ALLOW rename TechD}]
>
> But when I visit this page without logging in, I am allowed to view it and edit it. If I log in as a user that does not belong to the TechD role, I am also allowed to view and edit it.
>
>
>> Authorizers not consulted at login
>> ----------------------------------
>>
>>                 Key: JSPWIKI-473
>>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-473
>>             Project: JSPWiki
>>          Issue Type: Bug
>>          Components: Authentication&Authorization
>>    Affects Versions: 2.8, 2.8.1
>>         Environment: All
>>            Reporter: Andrew Jaquith
>>             Fix For: 2.8.2, 3.0
>>
>>   Original Estimate: 0h
>>  Remaining Estimate: 0h
>>
>> From the jspwiki-dev list:
>> Steve Dahl wrote:
>> Under JSPWiki 2.6.4, we've replaced WebContainerAuthorizer with an LDAPAuthorizer which implements JSPWiki roles in terms of LDAP groups.
>> When I compile this for JSPWiki 2.8.0, and modify the jspwiki.properties file to use it, our custom LDAPAuthorizer gets initialized, and is sent findRole(), but it never seems to get sent isUserInRole().
>> If it's useful information, LDAPAuthorizer implements Authorizer (not WebAuthorizer), and it implements isUserInRole() with this signature:
>> public boolean isUserInRole( WikiSession session, Principal role )
>> Is there anything that has changed in Authorizers between 2.6.4 and 2.8.0 that might explain this?
>> Looking deeper, it seems that in JSPWiki 2.6.X, WikiSession implemented injectRolePrincipals(), which initialized the session with whatever groups and roles the user belongs to. Groups are read from the group database, and Roles are read from the Authorizer.
>> In JSPWiki 2.8.X, injectRolePrincipals() has been replaced by injectGroupPrincipals(), which reads groups from the group database but doesn't use the Authorizer. What is the Authorizer used for now?
>> As a side note, I originally implemented LDAPAuthorizer as LDAPGroupDatabase. I ended up rejecting this approach because GroupManager assumes that the members of a Group can be read once when the Wiki is started, and that the Group's membership will only be modified by the Wiki. The problem with LDAP is that the group membership can be modified from outside, and the only way to update the wiki would be to manually restart it. The Authorizer was a better solution for our purposes, because if a user was added to the LDAP group, the Authorizer would reflect that change as soon as the user logged out and back in. Restarting the wiki is not necessary.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>