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

The way this deployment works is the portal 
is designed so that consumers are given a portal page that invokes the 
different operations than the operator's page. The portal displays the correct 
pages based on the user login.

 

Tony

From: Ashok Malhotra 
[mailto:] 
Sent: Friday, March 31, 2006 3:15 
PM
To: Tony Gullotta; Gene Thurston; 

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

OK.  Perhaps I misunderstood but consider your 
usecase:

 

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

 

So, these would be 2 different operations on the same 
service?

How would you ensure that a consumer gets one operation and internal 
operators get a different

operation.  You need to select on the user type at some 
level.

All the best, Ashok 

 

  

  
  From: Tony Gullotta 
  [mailto:] 
Sent: Friday, March 31, 2006 2:47 
  PM
To: Gene Thurston; Ashok Malhotra; 
  
Subject: RE: [ws-sx] Issue 48: more 
  background

  

  
Yea. Gene's interpretation is more accurate. The 
  Gold/Silver/Bronze policy use case, although feasible, is different than what 
  my issue was about.

  
 

  
Tony

  

  
  From: Gene Thurston 
  [mailto:] 
Sent: Friday, March 31, 2006 2:13 
  PM
To: 'Ashok Malhotra'; Tony Gullotta; 
  
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:] 
Sent: Friday, March 31, 2006 2:03 
  PM
To: Tony Gullotta; 
  
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