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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

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

Subject: 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.


Michael Freedman <Michael.Freedman@oracle.com>

12/29/2003 05:49 PM

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

   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.

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