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...
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.
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.
- 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?
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
