Same for me.
Subbu
Rich Thompson wrote:
>
> The system is refusing to recognize the published password ... has it
> changed?
>
> Rich
>
>
> *Michael Freedman <>*
>
> 08/31/2004 09:18 PM
>
>
> To
> interfaces <>
> 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.
