[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm) modified
|
I see access control of property
modifications being solved through our user identity propagation mechanisms. The
Producer can simply assert the current users role to determine if they can
modify a particular property. Is there a reason this would not be
sufficient? I do see a use case for sharing configuration
state across portlet boundaries within a portlet application. I’m
not sure, however, that it’s a particular use case that I would want to
solve within this feature proposal. How do others feel? Scott From: Andre
Kramer [mailto:andre.kramer@eu.citrix.com] On the config access
control suggestion, I was purposely being neutral on what scope the admin's
modifications would have. Hierarchy related changes are already proposed, but
administration "delegation" (i.e. for all users I manage) and Portlet
application scope (i.e. for all users of that application) seem very valid
re-occurring use cases to me. We have
"groupID"s for supporting JSR 168 in WSRP 1.0 but this still does not
seem well matched to such scopes. At the risk of confounding two 2.0 feature
discussions (sorry): We could leverage registrations and the newHandle =
copyPortlet(portletHandle, fromRegistrationHandle, toRegistrationHandle) to
scope the "sharing" of property modifications. Rather than building
in extra support (formal contracts) for shared customizations, this could
enable shared properties to be updated in a registration (per-Registration -
but never across registrations. And non-shared properties are just
per-Portlet/per-Registration). This does not state how properties are actually
shared within a registration (can have more complex inter-clone relationships
within registrations) or who may update shared properties, but this could
enable some very typical use cases: e.g admin changes settings for a Portlet
application. Here, the consumer would only allow an authenticated/authorized
Admin to effect such (audited) changes. And the fact that only producer admin is
allowed to change POPs is reflected by an implicit top level (default) scope. Again, I'm just thinking
aloud, ahead of next week's f2f. Regards, Andre From: I'm a little behind in
the discussion, so I'm going to try to cover all comments that I've seen thus
far. Let me know if I miss anything. First, Andre brought up
the notion of portlet properties. The feature proposal, as it stands,
talks about hierarchies in relation to portlet state. This was the use
case we had, and, therefore, that's what I modeled the feature proposal around.
However, when you start discussing CCP hierarchies, portlet properties and
inheritance of portlet properties is a feature which obviously must be
considered. In order to validate such a feature, we would have to come up
with an associated use case. Personally, I think you can adapt the one I
provided for portlet state fairly easy. The consumer could generate a
screen within an administration view to set portlet properties for a
"parent" CCP. These values could then be inherited to "child"
CCP's created as a result of additional end user customization of the
portlet. If necessary, the administrator could return to the
administration screen to change the value of the portlet properties on the
parent and affect all of the "child" CCPs due to the inheritance.
Secondly, Rich brought up
the notion of declaring a portlet property to be final or config level.
This involves the situation in which properties can be set on a particular
"parent" CCP, but not on child "CCPs". To understand
the use case, I would ask who can determine whether a particular portlet
property should be final or not? To answer this question, I think you
have to consider the following actors - Consumer, Producer, Consumer
Administration, Producer Administration, and Portlet Developer. 1. Consumer - Since a Consumer doesn't really understand the purpose
of a particular portlet property, it really can't make a determination whether
a particular portlet property is an administrative one or not. Therefore,
I would suggest that the Consumer isn't able to make this determination. 2. Consumer Administrator - In this case, the Consumer would
autogenerate a screen within an administrative context for setting portlet
properties on the "parent" CCP. Within the autogenerated
screen, next to each property, would be a check box to set whether or not end
users could override or customize the value of the property. By selecting
the check box, the portlet property can be set to be final, not allowing the
property to be set on "child" CCPs and, therefore, not allowing end
users to customize it. 3. Producer - I think this is the same case as the Consumer. It
doesn't understand the purpose of portlet properties and, therefore, can't make
a determination whether or not a property should be final. 4. Portlet Developers - When developing a portlet for general
consumption, a portlet developer wouldn't want to limit functionality. In
other words, the ultimate goal would be to make the portlet as configurable as
possible, allowing it to be reused in multiple environments with varied
requirements for access control. I do imagine a scenario in which they
may want to suggest a default behavior based on the function of the portlet,
but they wouldn't want to make the final determination. 5. Producer Administrator - If a particular property affected a back
end system or required knowledge of a back end system, I could see the case in
which you would want, as a Producer Administrator, to limit access to those
properties to admin users only. Therefore, it would make sense that a Producer
Administrator would want to declared properties final. However, I would
argue that it would be difficult to determine on which CCP to declared the
property final. It depends on the Consumer implementation and how CCPs
are used. What you could do, I suppose, is declare a property to be final
within a POP as a suggestion to the Consumer. However, this really
wouldn't provide any hard control. The question would be, is there a use
case for having the ability to provide only a suggestion? Given the above, I can
see #2 being a possible reason for having the ability to set a portlet property
to be final. #5 is also a possibility, but questionable. Rich and
Yossi - You both seems to be interested in this feature. What are your
thoughts on the above? Do you agree? Would your use cases fall into
#2 and #5 or is there a scenario that I'm missing? Thirdly, the question
came up as to why you would want to declare a CONFIG mode within the WSRP
specification. This is related to the difference between portlet state
and portlet properties. In item #2 above, the consumer provides a check
box to declare what properties an end user should be able to edit. It's
possible, however, for usability reasons, that an autogenerated screen isn't
ideal for configuring a particular portion of portlet state. For
instance, in the use case I've given, the config mode of the portlet generates
an expandable folder tree representing the directory structure of the content
repository. I can't think of a standard XSD data type which would lead a
consumer to autogenerate such a tree, much less one with the exact contents of
a back end repository. Therefore, it makes more sense for the portlet to
generate the screen and set the state through a pbia(). However, as a
portlet developer, ideally you still want to provide the flexibility to the
Consumer Administrator to declare what an end user should/shouldn't be able to
customize. This is where CONFIG mode comes in. It would contain a
checkbox for configuring whether or not end users could change the
folder. You then have an option of, near the checkbox, rendering the
folder tree allowing the admin to specify a default, or rendering this tree
within another mode which correlates to the jsr 168 EDIT_DEFAULTS mode. I would also argue that,
due to lack of time or prior knowledge of the deployment environment (company
intranet), a portlet developer would decide to simply not provide a checkbox.
In other words, they would make the decision that selecting a content
repository folder for the portlet is purely an admin function that end users
shouldn't be exposed to. They can achieve this, by only displaying the
folder tree within a CONFIG mode. A final reason would
simply be interoperability with JSR 168 portlets. Considering that JSR 168
is a large source of the portlets to be produced, it makes sense to try to
align as much as possible with this specification. Fourthly, Subbu brought
up the fact that a Producer could implement hierarchies on it's own, without
the use of the protocol. I would argue that this isn't sufficient.
First, since a Consumer could never know if a producer provides this
functionality, it would never predict when property/state inheritance would
occur. Secondly, I would argue that it's the Consumer implementation/feature
set that determines if properties/state should be inherited or not. Where
one consumer would desire the inheritance behavior, another might not.
Therefore, you need support in the protocol for the consumer to request that
inheritance be utilized. Lastly, Andre brought up
the notion of using access control for authorization rather than a config
mode. The issue I see with this, is that config mode is more than simply
the properties which only an admin can see. It also provides a mean of
setting portlet state which applies to all users. It just happens to be
the case that, in most if not all scenarios, the responsibility of setting
state for all users is given to an administrator. I think that covers all
of the comments which I saw. Some of this information probably need to be
rolled into the use cases in the feature proposal. Before doing that,
though, I'll wait to see what everyone agrees/disagrees with. Scott From: Andre
Kramer [mailto:andre.kramer@eu.citrix.com] Just an attempt at an observation: When we think of
this ("config") as a mode it seems never to be very compelling but
when we view it as something an admin does (versus a normal user) we tend to
see a valid use case. Maybe re-casting this in terms of "access
control" or "authorization" would be an approach? The portlet
would declare and enforce edit authorization based on user / role
authentications. The consumer would need meta-data (WS Policy) in order to also
act as a policy enforcement point. Here "config" is not so much a mode but a
special role that we recognize? Regards, -----Original Message----- I think that's the way JSR168 tried to define this
mode. However, is Here is an example. Assume that a CCP1 and CCP2 are
cloned from CC0, and In this case, both the hierarchies and configuration
are not exposed in Extending this argument further, I think such
configuration belongs to Christopher, could you elaborate on the motivation (or
specific issues Regards, Subbu Richard Jacob wrote: > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]