David, Before I jump on this thread, I'd like to thank you for your interest and continued research in how J2 security can be modified to work and play well with Geronimo. Hopefully, we can wrestle this issue to the ground in short order!
On Fri, 2005-12-23 at 22:03 +0100, Ate Douma wrote: > David Jencks wrote: > > > > I'd like to understand a lot more about the use cases here, and if > > there are any docs please point me to them :-) Some of my questions are: A document that covers page/portlet level security constraints can be found here: http://portals.apache.org/jetspeed-2/guides/guide-security-declarative-psml.html This document describes how J2 uses its PSML based security constraints to make authorization decisions based on the user, role, and group principals stored in the "fake" J2 Subject. Here is a common use case for changing J2 Subjects for a given user: 1. A new user is created by their request that carries only the new user principal. This allows the user to "see" a subset of the site that allows all users, (i.e. publicly accessible pages/portlets). 2. At some point, it is decided that the new user is to be a granted access to some pages associated with an existing group and role, (for example, say group is 'accounting' and role is 'officer'). An admin then would add the group and role to the user. 3. Immediately after the user has been added to the group and role, the portions of the portal that require either or both authorizations would be available to the user. A common use case for changing J2 roles and groups: 1. A new portion of a corporate portal is created by adding pages and portlets to access a new client's detailed billing information. The various portlets and pages are developed and deployed in the portal. 2. Access to this information needs to tightly controlled. To do so, a new group is created to segregate this information in a secure fashion from all of the other clients served by the portal. All of the new portlets and pages are constrained to require users be a member of this group. 3. In addition to the coarse grain client access rules, some information can only be seen by individuals with certain roles in the client's organization. For example, only officers are allowed to view contracts and disputed charges, but anyone with access is allowed to view the current billing account status. New role constraints are assigned to the more sensitive pages/portlets. 4. An administrator then assigns all the registered users of the portal from the client to be a member of the client group. In addition, some users are granted certain roles to give authorization to protected pages/portlets within new client's portion of the portal. We assume that the portal provider would like to perform these operations without having to interrupt the portal application as a whole since potentially only a small segment of the portal users are being served by these activities. > > > > - do the portal/portlet permissions apply to the portal app or the > > portlet app deployed in the portal? > Both: we have portlet permissions (portlet app) and also something like page > permissions > (portal app). > > - Where do new portlet pages come from (and are they portlet pages or > > portal pages)? Can they be added to a running system or do they > > require (re)deployment of a portlet application? Are they additional > > portlets or servlets that should be represented in the portlet.xml or > > web.xml deployment descriptor or are they representable as additional > > parameters to an existing portlet or servlet? > "Portlet" pages as such do not exists, although we support a specific > invocation for > only one portlet output in a request (a jetspeed specific feature). > A "Portal" page is deployed to/managed by the portal. > Currently, there is no formal deployment model or dd for it and the portlet > spec > says really *nothing* about a page other than it can contain/represent one or > more > portlets (which may originate from different portlet apps). Currently, pages can be added using an administrative portlet application, by adding PSML page documents in the file system, and/or by adding PSML page definitions in the Page Manager DB. One can certainly package a set of pages for initial deployment in the portal, but adding pages dynamically is one of the primary ways the portal is extended and customized per user. > > > > - In the existing jetspeed implementation, what kind of "transactional" > > behavior is there to allow applying a set of security changes at once? > We control this ourselves through Spring configured transactions. Can be a > single or multiple > changes, depending on our configuration. > Changes to a user's principals, (groups and roles in the J2 sense), occur with the first new session following modification by the administrator. IIRC, we do not attempt to clear session based "fake" J2 Subjects as part of the admin transaction. Page and portlet constraints are evaluated per request. So, changes to security constraints would be relatively immediate. > > > > - Are the contents of the request needed to make authorization decisions? > I'm not sure I understand what you mean here. > Request/query parameters? > In that case, I think not, but maybe Randy Watler and/or David Sean Taylor > should respond > to this one. > Through the use of the J2 Profiler Component, just about any part of a request, (host, path, parameters, HTTP headers, etc.), can be used to address a set of portal pages. Session state can also be used. Any given request combined with the session state will unambiguously "select" a given page. Then, the security constraints in and related to the page are checked against the "fake" J2 Subject principals to make an authorization decision. Success results in the portal presenting the page and the portlets on the page the user is authorized to "see". Hope that explains what we are doing with the Subject/principals. Randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
