Re: [wsrp-interop] Protecting producer registrations

["Richard Jacob" <richard.jacob@de.ibm.com>]

see my comments in tagged with <rj>

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


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.

<rj> it's more than this. In addition it also contains technical and
perhaps business aspects of the relationship.
This can be the consumer name, methodGetSupported, consumer modes/window
states etc.
</rj>

 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.

<rj>
Basically I think I understand what you're saying.
We should clearly distinguish the concepts here.
The RegContext is not an authentication method, rather then this it is an
identifier for the relationship.
Here we may run into further trouble if the context is shared between
various Consumers and the the Producer chooses to push registration state
back to the Consumer - but this is a side discussion.
Currently I can't see how a Producer can assure the set of authorized
callers, i.e. can make sure that a Consumer is allowed to pass the
regHandle it passes with the calls the way you are claiming it (if I
understood you correctly).
1. regHandles could be stolen/copied
2. Identifying on Consumers IP-Address? Bad idea, can be spoofed easily.
3. Identifying on Consumers MAC-Address? can also be spoofed.
4. using TPM - possible
5. using lower level authentication mechanisms? yes, this should be the way
to go (WS-Security tokens or SSL Client Certificates).
The question of control:
The Producer can of course verify if a passed regHandle is being allowed to
be sent from a distinct Consumer using well known authentication mechanisms
(like SSL/TLS).
However a Producer can not prevent that the identity is shared among
Consumers.
Typical example: ID/Password can be shared, no way to distinguish from the
Server side point of view.
Even certificates can be shared, the only thing a Producer can tell is: "is
the regHandle I received with that request valid given the received
certificate?".
Things might change with TPM, where certificates are bound to the hardware.
Or did I misunderstand you or miss something here?
</rj>

 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.

<rj>
As said above it can't since the RegContext is an identifier rather then an
authentication mechanism.
</rj>
 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?
<rj>

I think this is a good question we haven't looked into yet.
In my opinion we are talking about two things here. Here I'm leaving safe
ground and need to look into security more deeply here, so please don't
beat me.
First we are talking about authentication.
The Producer must estabish some way to able to check which Consumer
(authenticated by any means like WS-Security or SSL) can pass what
regHandle.
This has to be done at the Producer side and will require administration
(like maintaining the certificates).
Second we talk about trust relationships.
The Producer trusts a Consumer (authenticated) and allows it to "pass
access rights" (perhaps not the correct term here) to another Consumer.
Imagine the following scenario:
1. Consumer A (authenticated) registers with Producer
2. Producer generates a regHandle and stores the regHandle-Consumer A
certificate relationship.
3. Producer trusts Consumer A or better the certicate issuer from
Consumer's A domain.
4. Consumer A's certifate issuer (could be the Consumer to make things
easy) provides certificates to Consumer B and C.
5. Consumer B (authenticated) accesses Producer with regHandle from A,
since the Producer trusts the certificates issued by Consumer A it allows B
to pass the regHandle from A.
However as said need to explore here far more deeply and see what is
already there.
</rj>

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.
<rj>
Well this would be an extension, which for instance allows the consumer to
pass certificates.
This is the kind of trust I tried to describe above ommiting the existing
environments which are there.

</rj>
  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?]. ....
<rj>
I think this is very feasible.
</rj>
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?
<rj>
Trust relationships/trust domains could solve our problems here.
</rj>

 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.

<rj>
My position is that we should carefully explore the concepts we want to
have and verify them with security concepts that are already there.
I think we shouldn't try to bring up security solutions to the level of
wsrp, they should be handled in lower levels for us.
And in fact I think there are already there.
</rj>

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-


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
.