David Jencks wrote:
On Jul 17, 2007, at 4:31 PM, Ate Douma wrote:
<giant snip>
- review and redesign our portal security model and implementation
I'd very much like to help with this and might even have enough time
:-)
The last time I looked (1.5 years ago) I wanted to go for a security
model that worked entirely on Permissions. IIRC the objection at
that time was that the non-Permission scheme could deny as well as
grant permissions: I think that we can do that with Permissions as well.
There's a apache directory subproject called Triplesec that I'm also
trying to find enough time to work on and I think may have some
useful ideas on how to organize permissions and possibly other
aspects of this.
Please bring them up, I'm open to discuss this again and properly so now.
This may take a few days to get organized...
Sure, I don't expect we will come to a resolution overnight either :)
As its been a long time, can you also please describe why you think we
can/should base our security model (entirely) on Permissions?
Our current Constraints based model has served us well, so would we be
able to maintain that too (possibly on top of a Permissions based
scheme)?
Its been about 18 months :-((((( but IIRC the only functional difference
between the constraints model and the permissions model was the ability
to deny permissions in the constraints model. There's nothing
inherent in mapping users/roles to permissions that keeps you from
denying permissions to users/roles, it's just that the "standard" jacc
model doesn't talk about it. So my idea is very roughly that the portal
code will construct a suitable permission at appropriate places and
submit it to the security system for checking. The security system
could be jacc in a javaee server, or it could be a jetspeed component
that matches the behavior of the current constraints model. My hope is
that the authorization system can be easily pluggable and have only one
set of code inside the portal.
Sounds good to me if feasible.
What I remember from our discussion back at ApacheCon US 2005 was some
confusion (from my side at least) how jacc can accommodate our dynamic
configuring and
modifying roles at runtime. I think at that time my impression was that jacc really is a declarative model which expects (that part of) the security
configuration to be set/fixed at runtime.
Maybe I was wrong, I'm definitely still not very familiar with jacc, and maybe
the jacc specs has extended/improved since then.
If not though we need to make sure we can keep this functionality some how.
For a portal application which supports plugging in new or replacement portlet applications as well as setting up new sites and user communities with
corresponding security configurations at runtime this is a quite an important feature.
I didn't do any profiling or serious investigation but it also looked to
me as if there was a a lot of redundant security checking going on: of
course this might have been cleaned up since I looked at it.
Maybe (and hopefully) it has, but I'm not sure.
It certainly would be great if we can improve our security system and
management such that it becomes much clearer where and when we need to hook
into it and
when not (anymore).
- multiple authentication/authorization schemas to support truly
separated access & maintenance of "communities" in one portal
I'm not quite sure what you mean here, but it sounds interesting.
Being able to "deploy" multiple sites in one portal, each with their
own set of users and security scheme.
This will allow to use a single portal instance (although possibly
clustered) for different (set of) groups/users/customers, e.g.
"communities", each with their own personal/separated "site".
Either I forgot something or I don't understand some important bits of
what's there now. Why can't we do this now?
Right now, our higher level API and security management doesn't support using
multiple security schema's with separated/isolated configurations at the
same time. I think technically at the lowest level we might already be able to
do so, but neither the JAAS LoginModule nor the higher level
security admin api and corresponding portlets are capable of handling that.
What we need to be able to do is supporting separate authentication and authorization
configurations for different "sites" served by one portal.
Like using different users and role definitions for a preview.myportal.org and
live.myportal.org site hosted by the same portal installation.
Ate
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
