Re: [wsrp-interfaces] Wedesdays agenda

[Rich Thompson <richt2@us.ibm.com>]

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.