SCHAECK
Mon, 26 Feb 2001 12:35:47 -0800
Santiago,
I agree that it is possible to implement the PortletAccessControl interface
based on JAAS, JAAS provides the Subject.doAs() method that allows to
execute code under the identity of a particular user (I know the details of
how to do this). There are cases and environments where it is more
advantageous to use an authorization mechanism other than JAAS.
The PortletAccessControl interface does not mean to reinvent things, it is
just to provide an abstraction of what the PortletInvoker needs (decision
whether a given user may perform a given action on a given portlet
instance) and allows pluggable implementations to meet this need.
+---------+---------+---------+ +---------+
| Portlet | Portlet | Portlet |...| Portlet | +----------------+
+---------+---------+---------+---+---------+ | Portlet Access |
| Portlet Invoker |->| Control I/F |
+-------------+---------------+-------------+ +----------------+
| Aggregation | Customization | Other Views | |
+-------------+---------------+-------------+ v
No-op +----------------+
Custom +| Access Control |
J2EE/JAAS +|| Provider |
||+----------------+
|+----------------+
+----------------+
The AccessControlProvider implementations can map the simple
checkPermission(user, action, portletInstanceID) call to JAAS/J2EE calls or
to other authorization mechanisms.
In a J2EE/JAAS provider, of course all the J2EE/JAAS functionality can be
used as you say.
For service projects, it should be possible to write custom
AccessControlProviders implementing the PortletAccessInterface which might
for example do database querys against the customer's policy databases;
that was the main reason to define the PortletAccessControl I/F.
Probably, there also should be a no-op implementation of the
PortletAccessControl interface that has a checkPermission method that
always returns true to avoid imposing the JAAS access control runtime and
configuration overhead on portals that only have public content.
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:
[EMAIL PROTECTED] wrote:
>
>
> 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.
That is true. You get this with JAAS standard extension. Your previous
sentence
reminded me of the Pistoia book, who says (page 670):
"The Java 2 SDK provides a mean to enforce access controls based on
*where code came from* and *who signed it*. The need for such access
controls
derives from the distributed nature of the Java platform, where , for
instance, a
remote applet may be downloaded over a public network and then run locally.
"The Java 2 SDK, however, still lacks the means to enforce similar access
controls based on *who runs the code*. To provide this type of access
control,
the security architecture of the Java 2 SDK requires additional support for
authentication (determining who's actually running the code), and requires
extensions to the existing authorization components to enforce new access
controls based on who was authenticated.
"The Java Authentication and Authorization Service (JAAS)(see
http://java.sun.com/security/jaas/) extends the
security architecture, providing mechanisms to authenticate subjects,
execute
code on behalf of subjects, and grant permissions to subjects. The result
is
that access control policies can be based on both what code is being
executed and who is executing that code.
(IBM Java 2 Network Security, Prentice Hall)
>
> 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.
That is precisely my point. We should use code in java.security. to ensure
that the
Principal on behalf of which the request is being run has the right
permissions to run
the code. Or, we may need to use doPrivileged() to ensure that actions can
be performed
even if the portlet code executes with less privileges than Jetspeed code
itself.
There is plenty of code there for doing these things, and it would be a
pain to
reimplement it, specially since I seriously doubt that we can do a better
job that they have already done. I point specifically to the Principal and
Group
implementations, and also to java.security.acl.Owner,
java.security.acl.ACL.
In JAAS, the classes in javax.security.auth.* could be useful again.
>
> 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,
>
The framework in Java 2 offers interfaces for doing this kind of things,
allowing easy integration in J2EE code.
What I'm trying to say is that we should not reinvent wheels. We have
code for permissions, access control, privileged code, guarding (or
sealing)
objects, and the Principal interface for authentication purposes. (+
Subject and others in JAAS).
I just refer you to the example in tomcat 3.2 (jsp/security) to show how we
already
have:
request.getUserPrincipal()
request.isUserInRole(String role)
already implemented, working and (supposedly) integrated in J2EE security
(EJB containers, etc.)
This API is part of servlet 2.2, and I think we should build on top of
it. Authentication is a matter of the Application server, and we should
assume that we have those mechanisms in effect already.
We could write interfaces wrapping those, but I don't think we should
redesign them, specially if we are going to loose compatibility.
--
--------------------------------------------------------------
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]