portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Le Strat <dlest...@yahoo.com>
Subject Re: [J2] RFI: Security implementation
Date Thu, 15 Apr 2004 21:48:16 GMT
Hello Ate,

See comments below.

> As far as I can tell all the basic functionality is
> in place. Whats missing is the possibility to
> login from the portal; maintenance portlets for
> users, groups, roles and permissions; and
> authorization based on role and permission
> definitions.
None of the portlets on top of the security layer have
been developed yet.  We need some help with that.  Any
volunteers?  The tests provide great examples on what
the portlets would need to do.
> In particular, programmic security through
> Request.isUserInRole(RoleName) must be supported
> (PLT.20.3).
> Role restrictions for one or more portlets can be
> defined in portlet.xml as a role reference to a
> security role defined in web.xml.
> Therefore, to be able to perform
> isUserInRole(RoleName)  for an authenticated user
> the portlet
> container has to lookup the real role name as
> defined in web.xml as referenced by the RoleName
> defined in portlet.xml. The already implemented
> RoleManager.isUserInRole(username,rolename)
> can then be used to resolve the question.
> This part (besides a required login) is currently
> fully absent. Once this would be available the
> full role based security would be almost trivial to
> implement I think.

> Looking at the deployer implementation parsed
> portlet.xml security definitions are not used yet
> and
> the web.xml isn't really parsed at all.
> As I have already mentioned earlier (some months
> ago, but then I didn't yet fully grasp the
> J2 codebase) the Pluto portal implementation is
> already ahead of J2 in this regard (maybe part of
> there portal codebase can be used for the J2
> implementation?).
> I would very much appreciate it if someone (probably
> David or David :-) as the main implementors
> of the security component) could acknowledge my
> interpretation of the required functionality.
> If so, can you give any time line when this can be
> expected to be implemented?

You are absolutely correct. I am going to start
looking into this.  Regarding a timeline, I provide
guaranties.  I guess I would reverse the question. 
When would you need this completed by?
> Finally, I think the current
> o.a.j.security.impl.RoleManagerImpl.isUserInRole()
> implementation is
> missing a required feature.
> A User can be part of a Group which can have Roles
> just like the User itself.
> The isUserInRole() method currently only checks if
> the specified role is assigned to the user, not
> if it is assigned to one of the groups the user
> belongs to.
> The Role definition in Servlet 2.3 SRV.12.4 (which
> according to portlet PLT.20.2 also applies for
> portlets) specifies that a user is in a specific
> role either when assigned directly to the user or
> when assigned to a group the user belongs to.
> Thus according to this definition the
> RoleManagerImpl.isUserInRole() should also check the
> roles
> assigned to any group to user belongs to.

You are correct.  This needs to be fixed.

Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message