OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: userContext usage across all ports/operations




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


   


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]