Re: [wsrp-interfaces] Protecting producer registrations

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 <>

12/29/2003 05:49 PM

To

wsrp-interop <>,
interfaces <>

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-