[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] Wedesdays agenda
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 <email@example.com> > 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.