Hi Tony:
By "out of band" did you mean WS-MetadataExchange or the
mechanism that the WS-Addressing
folks have devised to get metadata or did you mean
telephone?
All the best, Ashok
From: Anthony Nadalin
[mailto:]
Sent: Saturday, April 01, 2006 7:56
AM
To: Ashok Malhotra
Cc: Tony Gullotta;
Subject: RE: [ws-sx] Issue 48: more
background
Hey Ashok, one minor point, WS-Policy does not say "exchange policies" as
the premise is that the end-point states policy and entities that want to
communicate with the end-point get the policy out of band.
Anthony
Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Ashok Malhotra"
<>
"Ashok Malhotra"
<>
03/31/2006 04:02 PM
To
"Tony Gullotta" <>,
""
<>
cc
Subject
RE: [ws-sx] Issue 48: more
background
Tony:
Your
usecases correspond to what we have been calling, internally, the
Gold/Silver/Bronze policy usecase.
Essentially, different classes of customers (Gold/Silver/Bronze)
get different policies.
What this requires is that the Policy that is applied to a Web
Service depends on a value in some
part of a message or a property of some identifier in some part
of the message.
Insofar as WS-Policy spells out a processing model, it says
exchange policies before starting interaction,
selects alternatives (one in each direction) and then follow the
policies for the rest of the interaction.
There is no mention of different policies for different classes
of users, etc. No mention of policy changing
during an interaction, etc.
Do you mind if I forward your
note to our internal folks?
All the best, Ashok
From: Tony Gullotta [mailto:]
Sent: Friday,
March 31, 2006 10:44 AM
To:
Subject: [ws-sx] Issue 48: more
background
Here are a few
customer scenarios we've encountered. They are pretty similar in concept.
1. One customer has a a
consumer profile service front ended by a portal. The consumers themselves are
allowed to make certain changes to their profile. The operations invoked take
a username token. Some other changes can only be made by internal operators.
These operators have been given certificates. The operations they use take
X.509 tokens. Its one consumer profile service, just that some operations are
more privileged and are available to only a smaller audience. They don't
believe its feasible to issue certificates to their consumers.
We have another customer with the same set
up except the service has to do with financial transactions.
2. Another customer has a service that is
only used within a controlled environment in the intranet. Its provides some
CRUD operations for some data that is used by several other apps in the
environment. There are a lot of reads and so performance is critical. Since
the environment is controlled the read operations don't require any
authentication at all, so no token needed. However the CUD operations do
require authentication, a username token, mainly for
non-repudiation.
We have
multiple customers with the same set up.
3. A utilities company has a metering
service that was initially set up for internal use only requiring only
usernames. They then decided to open up a couple of the operations to some
partners. They used SAML for them. So only some of the operations accepted
SAML tokens in addition to username tokens.
Although these are not the majority of our
customers we do run into these requirements very often in POC environments. A
lot of companies have still not gone production so they are still evaluating
what their security architecture will be. For this reason a great many of them
have voiced concerns about the inflexibility of only being able to define the
use of tokens at the service level.
Tony
