OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interfaces] Wedesdays agenda



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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]