On "second blush", I wouldn't necessarily want to over-complicate the
Context with an inheritance hierarchy thats "role" based. Here are
all the "real" (i.e. non-static main) settings of
setIgnoreAuthorization:
> LDAPServlet 1328
> doDSPost(Context, HttpServletRequest, HttpServletResponse) (2 matches)
> RegisterServlet 1608
> processPersonalInfo(Context, HttpServletRequest,
> HttpServletResponse) (2 matches)
> Item 1727
> create(Context) (2 matches)
> X509Authentication 1328
> authenticate(Context, String, String, String, HttpServletRequest)
> (2 matches)
> LDAPAuthentication 1431
> authenticate(Context, String, String, String, HttpServletRequest)
> (5 matches)
In each case, its to escalate the privileges of the existing context
to do something "System" oriented (create a new user or update a new
Item).
Is it the case that the code should just be more powerful here?
Interestingly, we'd NEVER ever want to allow the real EPerson any
ability like this outside this small set of individual cases.
For now I would recommend
(1) that Item be slightly re-factored to have an internal method that
supports the necessary table changes that happen when "create" is
called. And that the actual case of setIgnoreAuthorization be removed
from that step.
(2) The other cases have to do with "automatic account creation", it
seems that, this is actually more of a "user driven" activity... If I
as Agent interacting with the system, create an EPerson object
capable of being authenticated/recognized as a member of a specific
"Group/Policy" with the "rights" to add "update/add" itself as a user
to the system. Then there is no reason to "escalate privileges".
Theres this legacy case where its assumed only "Admins" can create
users in the EPerson code:
> public static EPerson create(Context context) throws SQLException,
> AuthorizeException
> {
> // authorized?
> if (!AuthorizeManager.isAdmin(context))
> {
> throw new AuthorizeException(
> "You must be an admin to create an EPerson");
> }
This is clearly "Not" our actual applications policy... See the above
authenticators for example... So in terms of the delegated admin
patch, I think this is an important feature to hammer out more
clearly. EPeople should be capable of successfully navigating the
above authorization based on external credentials (LDAP, X509, etc)
and this should captured in the "Polices" and "Group" of the
Application. This will help immensely in providing the DSpace
Application Manager with control over the Authentication/
Authorization and Account Creation process.
This is sort of "Policy Driven" authorization will actually be a
focus of some of my work here at MIT in the future.
Number (2) may be future work, the escalation of privileges at that
point is fairly shallow, I vote to definitely deprecate the
setIgnoreAuthorization method... because its being abused in the
Architecture.
-Mark
On Mar 21, 2007, at 8:03 AM, Mark Diggory wrote:
> Andrea,
>
> I would recommend this is another patch outside the scope of the
> delegate admins patch. As the two are functionally different
> issues. I agree that its a problem, but the majority of the usage
> is in static main methods, I think that was its initial impetus. I'd
> like to see the methods deprecated and if the code requires some form
> of escalated privileges to complete, then we should write some
> internal form of the method that completes tat task without
> authorization restrictions. Also these calls are basically to alter
> the behavior of a "Context" Object, in such cases instantiating a new
> Context object, or having the Context subclasses have more explicit
> types like UserContext vs. SystemContext. would resolve some of this
> as well.
>
> -Mark
>
>
> On Mar 21, 2007, at 7:08 AM, Andrea Bollini wrote:
>
>> Well I'm putting myself at work...
>> I have some questions about the authorization system that I would
>> like
>> to share with the community:
>>
>> 1) in many points of the "DSpace core" code there are
>> setIgnoreAuthorization(true-false) blocks. I don't like them, many of
>> them are related to the creation of "stub" newly objects that are
>> not
>> yet related to other ones. If we introduce a "stub" flag in
>> DSpaceObject
>> abstract class, we can check for autorization only when this flag
>> is set
>> to false. Of course, the default of the flag will be false and it
>> will
>> be set to true only in create method where the check for
>> authorization
>> is responsibility of the container (community, collection, item,
>> bundle
>> and so...).
>>
>> 2) the bug fix 1480496 (Cannot turn off "ignore authorization" flag!)
>> has shown that the authorization method setIgnoreAuthorization() is
>> not
>> friendly. In fact if we have two blocks that require authorization
>> check
>> to false and these blocks are nested, as in the following example:
>> ...[some java code here]...
>> setIgnoreAuthorization(true) // start of first block
>> ---my first block without authorization check
>> ---my first block without authorization check
>> ---my first block without authorization check
>> ------setIgnoreAuthorization(true) // start of second block
>> ------my second block without authorization check
>> ------my second block without authorization check
>> ------my second block without authorization check
>> ------setIgnoreAuthorization(false) // end of second block
>> ---other code in first block
>> setIgnoreAuthorization(false) // end of first block
>> ...
>> the "other code in first block" is executed with authorization
>> check and
>> does not work. It will be really too easy to come up with this
>> situation
>> (actually possible for my patch automapper) with the new code
>> called by
>> the Event System, so it should be fixed.
>> A simple solution is to store the previous state of authorization
>> check
>> before changing it, and to restore it at the end of the "special"
>> block.
>> I can post a patch for this shortly, but I would like to know in
>> advance
>> if someone sees any problems with the following:
>> 1) add two methods: TurnOffAuthorizationSystem /
>> RestoreAuthorizationSystem, with some code that can also be useful
>> when
>> the debug is on to see "malformed" (XML-like) authorization blocks
>> (thanks to James Rutherford for some useful suggestions);
>> 2) set the setIgnoreAuthoritation methods to deprecated.
>>
>> Best wishes,
>> Andrea
>>
>>
>>
>>
>> Tim Donohue ha scritto:
>>> Andrea,
>>>
>>> You are correct that we have your "Authorization system: delegate
>>> admins
>>> patch" running in our production system here at UIUC (which was just
>>> recently upgraded to 1.4.1).
>>>
>>> Currently, unfortunately the code has become a little embedded
>>> into some
>>> of our other customizations here at UIUC. So, I could
>>> potentially try
>>> and pull it apart a bit. But, admittedly, I currently have a
>>> growing
>>> "to-do" list and I'm not sure that I'd get to it until at least
>>> the end
>>> of March or early April.
>>>
>>> I would like to see this continued though, Andrea! It'd be great
>>> to get
>>> this code into one of the upcoming versions of DSpace (even 1.5, if
>>> possible). I know UIUC loves the ability to be able to assign
>>> Community Administrators (which is what we use it for the most) as
>>> well
>>> as Collection Administrators.
>>>
>>> Let me know if you do want my input in an updated patch.
>>>
>>> - Tim
>>>
>>> Andrea Bollini wrote:
>>>
>>>> Hi,
>>>> I have insert in cc the dspace-tech mailing list where you can
>>>> found
>>>> more help about this and similar topics. I'm starting in a
>>>> couple of
>>>> days a review of my patch for make it compatible with the next
>>>> 1.5, I
>>>> know that Tim (also in cc) use it in his istitutional repository
>>>> and it
>>>> is a 1.4.x version but there are not a "public package" available
>>>> for
>>>> this version...
>>>> Tim can you provide it? if not don't worry ;-), I can make it for
>>>> the
>>>> end of march.
>>>>
>>>> Best wishes,
>>>> - Andrea
>>>>
>>>> Vlastimil Krejcir ha scritto:
>>>>
>>>>> Dear Andrea,
>>>>>
>>>>> I would like to use your patch "Authorization system: delegate
>>>>> admins patch" (1373613). Unfortunately this patch is a bit old
>>>>> and I
>>>>> cannost use it (or only with too much effort) for DSpace 1.4. Is
>>>>> there
>>>>> any newer version for DSpace 1.4? And is it publicly available?
>>>>>
>>>>> thank you for help
>>>>>
>>>>> best regards
>>>>>
>>>>> Vlastik Krejcir
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> ----------
>>>>>
>>>>> Mgr. Vlastimil Krejčíř
>>>>> Library and Information Centre, Institute of Computer Science
>>>>> Masaryk University in Brno, Czech Republic
>>>>> Email: krejcir (at) ics (dot) muni (dot) cz
>>>>> ICQ: 163963217
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> ----------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>> ---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> DSpace-tech mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
> ~~~~~~~~~~~~~
> Mark R. Diggory - DSpace Systems Manager
> MIT Libraries, Systems and Technology Services
> Massachusetts Institute of Technology
>
>
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> DSpace-tech mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
~~~~~~~~~~~~~
Mark R. Diggory - DSpace Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology
Office: E25-131
Phone: (617) 253-1096
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
