[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]
