[J2] RFI: Security implementation

[Ate Douma <at...@douma.nu>]

This is a request for information concerning the current en future implementation of security in J2.

I've been reading the docs and reviewing the current codebase to get a good picture how security is
about to be implemented and whats available already and whats not.

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.

My primary focus for now is the implementation of role based security, not (yet) the policy based
security.

As far as I have understood the portlet specification (PLT.20) security must be supported
like it is specified in Servlet 2.3 specification SRV12.

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?

I have to give *some* prediction about the availability of authorization and role based
authentication as well as for maintenance of users, roles and groups in J2 to my project lead.

If this is NOT to be implemented as I think or if no implementation time line what so ever can be
given for it please let me know that as well!

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.

Can someone acknowledge this as well?

Regards,

Ate



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

Re: [J2] RFI: Security implementation (2)

[Ate Douma <at...@douma.nu>]

David Le Strat wrote:
> Ate,
> 
> I agree with you that this could be an interesting
> feature.  I was not planning on implementing this
> initially.  Be we should be able to incorporate this
> easily though.  Anyone want to take this on?

Great to hear. 
I think the required changes for implementing this could be relatively
small.
Adding a boolean disabled attribute to o.a.j.security.BasePrincipal
would do it (and of course BasePrincipalImpl and the object
model behind it). The LoginModule, UserManager, GroupManager
and RoleManager then can decide on this attribute if the Principal may
be used (in isUserInRole(), isGroupInRole(), etc.)

Maybe I'll can spend some personal time on this in a few weeks time.
If somebody beats me to it, well I won't mind :-)

Ate

> 
> David.
> 
> --- Ate Douma <at...@douma.nu> wrote:
>> One more think I like to know about the (future)
>> security implementation:
>> 
>> I have the requirement to be able to disable a user,
>> a role and/or a group.
>> In J1 a user can be disabled but not a role or a
>> group.
>> I guess disabling users will be supported by J2 to
>> allow migration from J1
>> but what about roles and groups?
>> 
>> It would allow for really advanced access management
>> in J2 without it
>> getting in the way for who doesn't need it (could
>> even be *hidden* through
>> configuration if needed).
>> 
>> To have this standard available in J2 would be very
>> nice, not only for me
>> but I think for most large J2 implementations.
>> Implementation itself would
>> be quite easy and the gain enormous.
>> 
>> Is this something which I may expect to be
>> implemented, must I create a
>> feature request for it first, or will this never be
>> part of the default J2
>> (in which case I will be required to change J2 to be
>> able to implement
>> it).
>> 
>> Regards, Ate
>> 
>> 
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> jetspeed-dev-help@jakarta.apache.org
>> 
> 
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online by April 15th
> http://taxes.yahoo.com/filing.html


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

Re: [J2] RFI: Security implementation (2)

[David Le Strat <dl...@yahoo.com>]

Ate,

I agree with you that this could be an interesting
feature.  I was not planning on implementing this
initially.  Be we should be able to incorporate this
easily though.  Anyone want to take this on?

David.

--- Ate Douma <at...@douma.nu> wrote:
> One more think I like to know about the (future)
> security implementation:
> 
> I have the requirement to be able to disable a user,
> a role and/or a group.
> In J1 a user can be disabled but not a role or a
> group.
> I guess disabling users will be supported by J2 to
> allow migration from J1
> but what about roles and groups?
> 
> It would allow for really advanced access management
> in J2 without it
> getting in the way for who doesn't need it (could
> even be *hidden* through
> configuration if needed).
> 
> To have this standard available in J2 would be very
> nice, not only for me
> but I think for most large J2 implementations.
> Implementation itself would
> be quite easy and the gain enormous.
> 
> Is this something which I may expect to be
> implemented, must I create a
> feature request for it first, or will this never be
> part of the default J2
> (in which case I will be required to change J2 to be
> able to implement
> it).
> 
> Regards, Ate
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
> 



	
		
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html

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

Re: [J2] RFI: Security implementation (2)

[Ate Douma <at...@douma.nu>]

One more think I like to know about the (future) security implementation:

I have the requirement to be able to disable a user, a role and/or a group.
In J1 a user can be disabled but not a role or a group.
I guess disabling users will be supported by J2 to allow migration from J1
but what about roles and groups?

It would allow for really advanced access management in J2 without it
getting in the way for who doesn't need it (could even be *hidden* through
configuration if needed).

To have this standard available in J2 would be very nice, not only for me
but I think for most large J2 implementations. Implementation itself would
be quite easy and the gain enormous.

Is this something which I may expect to be implemented, must I create a
feature request for it first, or will this never be part of the default J2
(in which case I will be required to change J2 to be able to implement
it).

Regards, Ate

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

Re: [J2] RFI: Security implementation

[Ate Douma <at...@douma.nu>]

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

Re: [J2] RFI: Security implementation

[David Le Strat <dl...@yahoo.com>]

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
http://taxes.yahoo.com/filing.html

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