From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Saturday, April 01, 2006 7:56 AM
To: Ashok Malhotra
Cc: Tony Gullotta; ws-sx@lists.oasis-open.org
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@oracle.com>
03/31/2006 04:02 PM |
|
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:tony.gullotta@soa.com]
Sent: Friday, March 31, 2006 10:44 AM
To: ws-sx@lists.oasis-open.org
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