Its always good to see if we can get a more concise definition of
UserContext and its potential uses.
In 1.0 we generally [seemed to have] accounted for 3 uses:
- The need for the producer to index [key] user specific persistent
state [aka the UserContext key]
- The need for the producer to adjust the user experience based on
application level "roles".
- The desire for the consumer/producer to limit the function of
most portlet management functions based on application level "roles".
Note: by application level roles I mean a system where the
consumer/producer mediation of the role is entirely at the application
level and hence only has application level semantics. I.e. these are
NOT security roles.
You note correctly that some consumer/producer pairs have extended the
semantics of the UserContextKey by knowing that the consumer is
actually passing its representation of the user identity as the user
context key. The knowledge and use of this is an extension from the
point of view of the specification and hence entirely outside its scope.
I think the primary debate concerning UserContext comes down to the
usefulness/applicability of application roles for item (3) above
[limiting function]. As we have seen from Subbu's reply he is
conservative in his approach preferring not to allow producers this
capability/feature. I however am more liberal. I believe application
roles are quite useful to many/most Producers for limiting function.
In my view UserContext usercategories can be used effectively to
provide weak authentication. Weak authentication is when one
[producer] proceeds assumes user identity/roles without the security
system formally acting/authenticating. A classic example/use of weak
authentication is portals/other apps that place cookies on clients to
identify users so that when reattached after sessions expired the
portal/application can still provide a directed context [though it will
generally still restrict access to any data requiring strong
authentication]. We are probably all familiar with the web application
paradigm used on many e-sites that say things like "Welcome back Mike
-- if you aren't Mike click here". In our consumer/producer example
weak authentication likely takes more of a role-centric perspective.
I.e. if the consumer says this request/user is in user category
"manager" thats good enough for me to return a list of portlets
available to "managers". This in turn applies to the other
PortletManagement methods. It however doesn't really apply to register
as this is the method used to establish the relationship between the
consumer and the producer. I.e. using such weak authentication
requires a degree of trust between the producer and the consumer hence
its not useful on an operation that initiates that relationship/trust.
-Mike-
Atul Batra wrote:
Thanks for bringing up approach/possibility (c). I should have
included that.
A related question here - so when looking at (c), would we not
consider clonePortlet() in that bucket as well? Since it is the
explicit
cousin of the implicit clone in pbia() and now handleEvent(), it may
make sense to include since presumably the Consumer may call
this operation upfront triggered via a user action, instead of going
the implicit route. (then some may well argue that why leave behind
copyPortlet(), and so on and so forth). Perhaps, something to
discuss.
Atul
Subbu Allamaraju wrote:
This is a good catch, and it is definitely
worth reviewing this before V2 is finalized.
Strictly speaking, only those operations that personalize the user
experience ought to have userContext, which IMO, are getMarkup, pbia,
and handleEvents.
Subbu
Atul Batra wrote:
In reviewing the new v2 operations (draft 11), I noticed that
we may have some inconsistency in terms of some operations
including userContext as part of their arguments, and some not.
Just as an example
- register() does not include, but setRegistrationLifetime() does
- destroyPortlets() does not include, but clonePortlet() does
- getPortletLifetime() does not include, but setPortletLifetime() does
- etc
The key point here is that userContext is being included in
operations beyond those that pertain to only end-user triggered
invocations, and so, they should be done so in a uniform
manner.
I think we've had this inconsistency even in v1, and that the scope
becomes broader with the added operations in v2.
I recall that we have broadly revisited the rational behind having
userContext itself in the post-v1 timeframe, so perhaps it's time to
review once more before we send v2 out.
In terms of potential approaches, I can think of two at the moment
a) we completely remove userContext from all operations. I'm
listing this for the sake of completeness and realize that this is
probably not doable/appropriate at this point.
b) we consider adding userContext to almost ("almost" since,
for example, it may not make sense for initCookie() to have this,
or perhaps it does and this would map/default to an "admin" user
for implementations?) all the operations for the sake of consistency.
We have discussed prior that true "identity propagation"
will take place outside the umbrella of WSRP (for example, via
the WS-Security Usernametoken profile 1.0 standard, etc), but
that there may be implementations that may rely on the userContext
mechanism to differentiate invocations from different end-users.
Particularly, for operations in the markup port. Additionally, some
Producer implementations may even use this facility to track for
audit trails, etc (hence consistency may be even more important).
(note that although I am calling out userContext on the whole,
this boils down to userContextKey; userCategories are more
relevant to the markup oriented operations).
Comments?
Regards,
Atul
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|