RE: [ws-sx] Issue 48: more background

[Anthony Nadalin <drsecure@us.ibm.com>]

All policies don't make sense at all WSDL levels, WS-SecurityPolicy uses the WS-PolicyAttachment specification and appendix A of WS-SecurityPolicy points out where we thought certain policies made sense. Please see Calculating Effective Policy in WSDL 1.1 in WS-PolicyAttachment.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Gene Thurston" <gthurston@amberpoint.com>

"Gene Thurston" <gthurston@amberpoint.com>

03/31/2006 04:12 PM

To	"'Ashok Malhotra'" <ashok.malhotra@oracle.com>, "'Tony Gullotta'" <tony.gullotta@soa.com>, <ws-sx@lists.oasis-open.org>
cc
Subject	RE: [ws-sx] Issue 48: more background

Actually, I believe that Tony is not saying that policies to apply depend on something in the message. Instead, he is merely stating that different *operations* on the same *service* need to have different policies. In other words, we can’t treat all operations on a single service in the same way w.r.t. the policy they demand. Some operations (say, “transferFunds”) might require a higher level of security than others (say, “getInterestRate”).

In this regard, we see exactly the same thing, and agree completely with Tony that we need to handle policy at the operation level in some form. Limiting to a particular service is too restrictive.

- Gene Thurston -
AmberPoint, Inc.

---

From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] 
Sent: Friday, March 31, 2006 2:03 PM
To: Tony Gullotta; ws-sx@lists.oasis-open.org
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: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