Re: [wsrp-interfaces] Wedesdays agenda

[Subbu Allamaraju <subbu@bea.com>]

Few comments below.

>     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.].

Sharing is not necessary. The consumer could do some sort of mapping and 
send a token known to the Producer. The details should not matter for 
the protocol.

>        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].

I presume, by binary you mean some token returned by a security system 
(e.g. Kerberos).

>        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]

Not sure if such a combination is required or even possible. Except for 
the token, the consumer may not have any credentials (username and/or 
password), and the password does not serve any purpose since the token 
already represented an authentication.

>        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? 

Subbu