Re: [wsrp-interfaces] Wedesdays agenda

[Subbu Allamaraju <subbu@bea.com>]

Same for me.

Subbu

Rich Thompson wrote:

> 
> The system is refusing to recognize the published password ... has it 
> changed?
> 
> Rich
> 
> 
> *Michael Freedman <Michael.Freedman@oracle.com>*
> 
> 08/31/2004 09:18 PM
> 
> 	
> To
> 	interfaces <wsrp-interfaces@lists.oasis-open.org>
> cc
> 	
> Subject
> 	[wsrp-interfaces] 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:
> 1.        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.
> 2.        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?
> 3.        If (2) defines an inband set, then define the needed meta data 
> to support.
> 4.        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.
> 1.        Plain text Username token establishes runtime identity in 
> receiving system.  
> 1.        token contains the actual user name
> 2.        token contains the text-based key that represents this user in 
> the shared identity system [LDAP entry, etc.].
> 2.        Binary username token establishes the identity in receiving 
> system.
> 1.        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].
> 3.        Plain text Username + password establishes runtime identitiy 
> in receiving systems
> 1.        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.
> 2.        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.
> 4.        Binary Username + password  establishes runtime identity in 
> receiving system.  [needs further work -- if it even exists]
> 5.        Same as scenario (1) except the Username token is carried in a 
> SAML assertion
> 6.        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.