SCHAECK
Sat, 24 Feb 2001 07:46:56 -0800
I don't think Java 2 would really fit our needs. Currently, Java 2 provides
code-source based access controls (access controls based on where the code
originated from and who signed the code), but it lacks the ability to
additionally enforce access controls based on who runs the code.
We need to protect portlet instances based on the identity of the user from
whom a request to display them or perform other actions on them originates.
There may be lots of portlet instances that share the same portlet code and
can have different customizations for different users.
I think the right thing to do is to specify an interface in JetSpeed that
defines what we need and let the PortletInvoker use this interface. This
will allow to plug whatever seems appropriate to a portal implementer - be
it JAAS or some code that directly uses a policy database or policy files
(see Figure below).
+---------+---------+---------+ +---------+
| Portlet | Portlet | Portlet |...| Portlet | +----------------+
+---------+---------+---------+---+---------+ | Portlet Access |
| Portlet Invoker |->| Control I/F |
+-------------+---------------+-------------+ +----------------+
| Aggregation | Customization | Other Views | |
+-------------+---------------+-------------+ v
+----------------+
+| Access Control |
|| Provider |
+|+----------------+
|+----------------+
+----------------+
The portlet access control interface in JetSpeed needs to allow the
PortletInvoker to find out whether a given Subject (User) may perform a
given Action (display, edit, config, ...) on a given Object (Portlet).
Using the Turbine groups, roles, permissions etc to determine whether the
access is allowed is just one special case. Often, customers have their own
user / group / access control management databases and tools, so often
custom Access Control Providers will be required.
Best regards,
Thomas
Thomas Schaeck
Portal Architect
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
Santiago Gala wrote:
--------------------------
Jon Stevens wrote:
> on 2/22/01 4:17 PM, "Santiago Gala" <[EMAIL PROTECTED]> wrote:
>
>
>> All of the java.security.* framework is interface based.
>
>
> So is Turbine's.
>
> I really don't see a need to use java.security.* when Turbine has a
*MUCH*
> more complete implementation of a security framework than just
> java.security.
>
> -1 on java.security.*
>
The need to use java.security framework comes from:
- being able to reuse security support very well studied and engineered
(java.policy, doPrivileged(), checkPermission() ) inside the VM and get
fine grained support for cehcking permissions or specifying privileged
actions.
The java code is already there. It is a matter of using it. Now that java2
is our target,
the effort is more than justified.
- being able to integrate in J2EE framework servlet containers simply (EJB,
JDBC, ...)
- being able to integrate in a given corporate environment.
java.security.Principal is
the standard way to deliver privileges. I think TurbineUser should
implement Principal.
- surviving in a securityManaged servlet container. As an example of this,
the admin portlet in Jetspeed will throw a SecurityException if standard
security
is on (ReadPropertyPermission on). It the turbine framework is based on
these objects,
it will get cached in the proper level and treated as a security exception.
If not,
it will be processed as a standard error. Also, the thread pool will have
problems with calls
trying to set thread priority or stopping threads.
I'm not saying that you drop turbine security. I agree it is cood (nice
typo=cool+good :). What I'm saying is that turbine should use the
interfaces and methods there, for instance as a way to handle users (
java.security.Principal user.getPrincipal() ) or as a way to check for
permissions (doPrivileged() and checkPermission() ). Also that we use
the standard exceptions for security based exceptions, so that try-catch
is simpler to program and we can survive when a SecurityManager is in
effect in the servlet container.
Don't you think that ignoring java security will bring problems in the
future?
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]