Re: [wsrp] Differentiating between Application and Security roles

[Rich Thompson <richt2@us.ibm.com>]

Since there is no normative content,
I would favor this type of discussion in the Security Tech Note rather
than the spec, though it would need to take a more neutral stance (I think
this casts too negative of a view onto the security mechanisms and too
positive on the "weak authentication" mechanism).

What I had tentatively added to section
9.3 from the discussion on the last Interfaces SC call was
"It
should be noted that the security concept of access control is generally
controlled by subsystems/protocols operating at a lower layer than the
WSRP implementation/protocol and that this should not be confused with
the application level concept of user categories, despite an apparent overlap
in utility."

If we do add an expanded discussion
of this flavor to the Security Tech Note, it would also be appropriate
to add a reference to it.

Rich

Michael Freedman <michael.freedman@oracle.com>

07/12/05 07:02 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	[wsrp] Differentiating between Application and Security roles

We are discussing how to rework section 9 [Security] so
that it isn't as vague as it currently is.  One area I have proposed
improving is providing better clarification concerning security and UserContext;
in particular user categories and security roles.  Here is an initial
description to get discussion started -- it will need work but I am sure
there is enough here to get the sparks flying:

Identity Propagation and Authorizations:
Typically, user identity and authorization is managed
for the application by the underlying security system in the application's
operating environment.  In many circumstances this will also be true
for Producers.  However its important to recognize that because the
producer is a consumed resource an alternative whereby the consumer can
present this information to the producer in a non-secure though potentially
trusted manner exists.  Distinguishing between these various options
is important to implementing correct producer function especially where
security is paramount.

An operating environment's security system is responsible for establishing
the [authenticated] identity of the user and presenting this information
along with this user's authority to the running application.  Depending
on the complexity of the operating environment, such a security system
may need to rely on a whole range of mechanisms to ensure the application
can maintain a secure conversation with an authenticated individual.  However
because this behavior is rooted in the operating environment prior to the
execution of any application layer code, applications can be ensured that
the information presented to them is valid and trustworthy.  Web server
environments have defined and handled this well when there is direct communciation
between the end user and the resource.  But what about when there
is indirect communication such as is the case with a WSRP producer which
is controlled by an intermediate consumer?  In this situation the
consumer and producer environments must cooperate to propagate the information.
 The WSS standards and associated profiles define a wide range of
techniques that allows a consumer of a web service to propagate the user
identity and permissions to the web service's security system to allow
this operating environment to operate the service in a secure environment.
 WSRP relies on these standards/layers for implementing security.

The only drawback to this solution is that this requires the consumer and
producer environments to support the same portions/levels of the WSS standard
and that each is manually configured so they can work together.  Though
somewhat of a burden its certainly reasonable for any producer that wants
to ensure its securely operating on behalf of the user.  For example,
a portlet that deletes employees from an HR database wants to be sure that
it only allows properly and securely identified users with the required
permissions to do so.

However, there are many producer situations where strict security isn't
always necessary but receiving a notion of the user's identity and capabilities
is.  Examples include using the user's identity to construct a shared
key to coordinate data sharing between portlet's in the producer, restricting
the modes any user has access to based on the user's capabilities or likewise
altering the view of any given mode based again on the user's capabilities.
For these situations, WSRP provides a lightweight form of consumer propagation
that is managed at the application level and hence from a strict security
view point is insecure.  This is the purpose of the UserContext.  The
WSRP user context tells the producer 3 things:
1.        Whether
the consuming application has identified the current user.
2.        If
the consumer has identified the current user, then the producer is given
a key value that uniquely represents that user.
3.        What
WSRP user categories pertain to the user of this request.  [WSRP user
categories are producer declared values that the consumer is responsible
to mapping to somethign appropriate in its environment.  Typically,
when done so by the consumer, these user categories will reflect a mapping
between the consumers notion of application roles [not necessarily security
roles] and the producer's categories. ]
Though commonly some kind of trust relationship exists
between the consumer and producer, its important to note, that the producer
has no notion of how the consumer derived this information and hence it
can't be considered secure from a security system standpoint.  For
example there is no requirement that the consumer has authorized the user
[securely] before it identifies the user to the producer.  For example
the consumer may support weak authentication in addition to strong authentication.
I.e. we are all familiar with web sites that use a cookie to store the
identity of a user for longer then an immediate session so the site can
rertain a personalized view.  However once the the user tries to access
a function that requires full authentication, he is challenged.  Likewise,
there are no requirements for how a consumer will map producer user categories.
 Again, its perfectly valid for a consumer to randomly generate the
values or even merely say that all users are in all categories.

The key benefit of this mechanism is it requires no cumbersome out of band
setup in both the consumer and the producer.  Nor does it rely on
the consuming/producing operating environments supporting a consistent
portion of the WSS stack.

So what are the guidelines for using one mechanism over the other?

Consider using WSRP UserContext in those situations where weak authentication
is acceptable.  Again, weak authentication is defined as the presentation
of identity/capabilities without its having been securely authenticated.
 Examples include restricting access to descriptions or operations
of portlets, adjusting the available/supported modes, and altering the
type of content presented.  These aren't hard and fast examples as
there are many situations in which a portlet wants to control these functions
securely.  That's why the critical question to ask is can/should/
my function be controlled by weak authentication or not.  
---------------------------------------------------------------------
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