portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma" <...@douma.nu>
Subject Re: [J2] RFI: Security implementation
Date Thu, 15 Apr 2004 22:44:41 GMT
David Le Strat wrote:
> 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.
> 

I've now actively been working with J2 for two months now and initially I thought
of starting out helping out with the security implementation but a lot of my time
has gone into developing a Struts Portlet Framework (which I'm about to submit
to J2 probably this weekend: once David Sean Taylor is back who promised to
help me with that).

But, I'm running out of time (my current contract with the client I'm working for will be
over at the end of this month) and have lots of other tasks to do now.
The project isn't over though and I'll most likely get a new contract (but no 
final word is out on it yet and there may be some competition of other contractors). 
So, officially I can't help out much right now. Which doesn't mean I don't want to do
personally but my private time is much more limited. I'm quite involved already
though so you can count on me putting in some.

>> 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?
> 

Well, I (or better said my client) really depends on it.
I made the selection for J2 based on the assumption that at least a beta version
(which should contain all these features, right) would be available somewhat before
the start of the summer ( David Sean Taylor indicated he would be in trouble, just like
me, otherwise :-).
Real portlet development based on J2 is planned to start real soon and I'm
busy right now specifying the development environment and requirements for this.

You're acknowledgment of my findings already helps me quite a bit as I can now base
functional specifications on the (eventual) availability of these features.

During the development of our business portlets at least a bare minimum feature set
should be available like being able to login and check authorization access on pages
and portlets (based on security roles that is).
The concrete security maintenance portlets (and also page configuration to be able
to define security permissions and/or role restrictions) might become available
somewhat later as we could insert security configurations temporarily in the database
directly. But once we need to get into production (I'll will check tomorrow if an
indication for that is set already) these definitely need to be in place. Just from cvs
would even be acceptable for a while I think, at least if I get a new contract which will
then be for a full year period but only part time. If someone else gets that contract, well,
I'll depend on that person how to proceed then...
If I get the contract, I probably get some official time for J2 support and certainly for
testing and feedback as we are dependent on it.

One particular aspect I've already asked a bit about earlier concerns the definition and
handling of user attributes. I know the usages of the preferences api allows for a really
flexible  definition, but a user maintenance portlet would have to be based on a predefined
set.
To be able to extend the user definition (we have a few non-standard attributes to store)
at least this portlet would have to be pluggable or extendable itself. Do you already have
any idea how this might or will be done?

>> 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.
> 
Great to hear. If nobody gets around doing it soon I'll probably will look into myself
personally after next week or so (it won't be hard to implement).

Thanks for the response David.

Regards,

Ate


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


Mime
View raw message