Re: [wsrp-interfaces] Protecting producer registrations

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

I understand the question to be how
a Producer can relate the WSRP scoping concept of a registration handle
to the security concept of authenticating the source of an invocation supplying
that handle. I think you are on the right track for how v1 addresses this
via the following  invocation sequence:

1. Consumer registers with the Producer
and establishes what client certificate(s) are allowed to use the registration.
   - Out-of-band: The Producer
may use any technique they want for establishing what client certificate(s)
are allowed to use the generated registration handle. 
  - In-band: The Producer requires
the register() invocation to be at an SSL port using client-auth. It captures
the client certificate used as the certificate authorized to use the new
registration handle.

2. Later invocation (e.g. getMarkup())
... Producer compares the client certificate used to those allowed to use
the supplied registration handle.

I think there is also a larger scoping
question that we had explicitly deferred last year regarding moving portlet
handles from one registration to another. Eilon had raised this for exactly
the scenario you have been considering. His key point was the need for
a means to take a customized portlet from a Consumer development environment
and move it to production. I'm not sure if the OASIS TC working on general
deployment issues will be producing a solution we could leverage to provide
a std means for such a migration.

Rich

Michael Freedman <Michael.Freedman@oracle.com>

12/29/2003 05:49 PM

To	wsrp-interop <wsrp-interop@lists.oasis-open.org>, interfaces <wsrp-interfaces@lists.oasis-open.org>
cc
Subject	[wsrp-interfaces] Protecting producer registrations

Folks,
    During our last concall I asked what if anything is a consumer
able 
to do with regards to sharing or migrating a producer registration.  The
response on the phone was producers shouldn't use registrations contexts
to establish relationships with a particular consumer.  Rather a 
registration context merely defines/establishes a scoping for portlets.
 A consumer, in this case is a logical entity, it may be a single 
physical entity or many physical entities.  Producers shouldn't try
to 
use any information it received with the registration call to restrict
which physical consumer it is valid to receive this context from.  It
was said that the management of that relationship is left up to lower 
levels of the web services [security] protocol stack.

Since that call I have done some thinking about what was said  and
don't 
fully understand/disagree with the sentiment.  Basically I don't 
understand how the producer implements the following common use case:

Use Case:
Producer wants to ensure that only authorized consumers can use a 
specific registration.  I.e. a producer wants to make sure that the
registrationContext it receives is not only valid but came from a 
consumer that was authorized to send it.  The peculiar thing here
is 
that set of authorized callers is defined by the consumer and is on a 
per registration scope. In the simple case its just the consumer itself.
 However, when you consider other real world use cases it can encompass
a development consumer, a stage consumer, and a production consumer.  At
a high level I understand how lower layers of the web services stack 
could be used to control the domain of all consumers that can talk to a
given producer.  However, I don't understand how, if its used 
exclusively, it can be used to control the domain of specific consumers
for a specific registration.  And more specifically, how this could
be 
done without manual administration on the producer to set it up.  Can
someone write a high-level explanation of how this would work?

Ultimately, what I had expected to be the case was that the register 
call is used to establish both the set or valid consumers and/or the 
validation method for a given registration.  In some[all?] cases the
validation method could rely on low layer web services [security] 
mechanisms.  i.e. this registrationContext is only valid for a given
certificate [is this feasible?]. ....  Or are most folks in the camp
that any producer that wants to isolate / secure consumers to a given 
registration will [always] require manual producer side administration
and therefore a level of out-of-band registration?  I.e. A valid 
position might be that WSRP doesn't want to deal with this -- any 
producer that wants such function will have to rely on lower layer web
services and home grown [out-of-band] registration techniques.  

FYI, the use case I am beginning to worry about is the develop, stage,
production environment portal developers typical design within/deploy 
on.  In such an environment there is a need to migrate/share some
portlets [those that correspond to base, all user, configurations to the
stage and production environments.
    -Mike-