Wedesdays agenda

Agenda for tomorrows concall:

1) Security:  Where do we go from here?  

Last we met I had started/suggested we begin to look at the "generate
security interop use cases" task we assigned ourselves by first looking at
what types/meaning of user identity Producers wanted.  Once having these
we could derive various use cases to describe how the security techniques
could be used (and therefore the user cases we would like to see).  After
our conversation I have soured somewhat on this approach.  And am unsure
of how best to proceed. 

  

Richard can you describe what our current tasks are?  I remember the following:

  
    
Describe a set WS-Security interop use cases involving identity propogation
to test/verify the variety of envrionments we expect our consumers/producers
to work in.

    
Define whether and how much we value (in 2.0) supporting in-band
use/registration of a producer that use mechanismnts involved in ideity propogation
described in (1).  Basically should all producers, for the time being, that
want identity propogation  be forced to use some level of out of band registration/configuration?
 If not what types of producers are we willing to (temporarily) support inband?

    
If (2) defines an inband set, then define the needed meta data to
support.

    
Potentially, write a white paper that discusses how typical producer
scenarios can be provided using WS-Security.

  
To give us a headstart on (1) describing the use cases I generated this list:

WS-Service interop use cases:

 

 In the following the use case test that the runtime identity is established 
in the receiving system.  What this means is that the receiving service running 
in a .NET, Java/J2EE, etc environment will merely call that environment's 
getSecurityIdentity API to receive the information.  I.e. the test should 
write a service with a single method that returns the name of the user by 
calling the runtime platforms standard API for getting the user name.

 
  
    
Plain text Username token establishes runtime identity in receiving
system.  

    
      
token contains the actual user name

      
token contains the text-based key that represents this user in
the shared identity system [LDAP entry, etc.].

    
    
Binary username token establishes the identity in receiving system.

    
      
basically this is the same as the second scenario above except
the token used to represent the user in the shared identity system is in
binary form vs. text.  [e.g. SSO].

    
    
Plain text Username + password establishes runtime identitiy in receiving
systems

    
      
token contains the actual username as if submitted by the end user, 
likewise its the actual password.  The receiver's environment shares the authentication/user
domain with the sender.

      
token contains the actual username as if submitted by the end user,
 likewise its the actual password.  The receiver's environment is in a different 
authentication/user domain from the sender.  The sender however is providing 
a credential store facility for the receiver, so it can map from its user 
identity and send theexpected receiver's crendtials.

    
    
Binary Username + password  establishes runtime identity in receiving
system.  [needs further work -- if it even exists]

    
Same as scenario (1) except the Username token is carried in a SAML
assertion

    
Same as scenario (2) except the binary Username is carried in a SAML
assertion [does this exist]?

     

   

 Do scenario (3) and (4) also have SAML equivalents? 
  
  

2) ImportExport:

I  have uploaded a modified Feature Proposal the finally expands
description of use cases to cover the variation in network environments of
the target and the source.  Is this sufficient?  Can I go back to working
on the Import/Export strawman?  If we have time we will discuss how to handle
some of the current open issues int he strawman.