Re^2: Security extension: first announcement + RFC

[Wolfgang Kleinertz <wolfgang.kleinertz at doubleSlash.de>]

Hi Marcel!

> Some points i did not understand or i am concerned with:
>
>    - Which interfaces are on the client side, and which
>      are on the server side
Up to now, none of them. But it's conceivable to locate them on client
side, too.
Client side doesn't mean client-idl! Instead  it's an api in the clients
helper classes.
E.g. in case of private/public-key, it would be possible to use the same
plugin in the 
server and the client. Sure, it's up to the programmer to keep it
symmetrical.

>    - Language neutral setup (what about a Python or a C++ client)
>      How would xmlBlaster.idl look like after the changes?

module serverIdl
{

// ... 

module authenticateIdl
{
   interface AuthServer
   {
      // DEPRECATED
     serverIdl::Server login(in string loginName, in string passwd,
                              in serverIdl::XmlType qosClient)
                              raises (serverIdl::XmlBlasterException);
      /**
       * The successor of login
       *  at param qos The well known qos with additional information like:
       *            username, passwords, tickets, keys, certificates...
       * ...
       */
      serverIdl::Server init(in serverIdl::XmlType qos)
                              raises (serverIdl::XmlBlasterException);
      // DEPRECATED
      void logout(in serverIdl::Server xmlBlaster) raises
(serverIdl::XmlBlasterException);
	
      /**
       * The successor of login
       *  at param xmlBlaster 
       *  at param qos Security information which show the clients
identity, because the client
       *            doesn't want to be disconnected by anyone else.
       */
      void disconnect(in serverIdl::Server xmlBlaster, in
serverIdl::XmlType qos) 
                      raises (serverIdl::XmlBlasterException);

      /**	
       * NEW
       * Returns information about the used plugin and its requirements
(password, certificates ...)
       * Example: 
       *   <plugin type="KERBEROS" version="4"></plugin>
       * or
       *   <plugin type="PUBKEY"><KEY type="IDEA"
length="1024"/></plugin>
       */
      serverIdl::XmlType getPluginInfo();      
   };
}; 


>    - Extensible (generic interfaces) to allow future
>      extensions without braking the contract of older
>      clients with xmlBlaster
To be able to use older clients, the previous as deprecated marked are
not eliminated. Instead,
they must be wrapped to a standard plugin for user/password
authentication with no crypto extensions.

Using the new approach, the client has to ask which plugin is used by
the server ...
Changing the plugin may cause difficulties. Example: If the client has
been written for a username/passwd authentication a change to kerberos
will not work. -> No access for the client.

>    - Simple approach (as simple as possible - but not simpler)
Yepp. A more generic approach would have been GSS etc., but they are -in
my opinion- to komplex.
This seems to be the best compromise.

>   Can you provide a code snippet how a client would
>   access xmlBlaster with a simple login name/password approach
>   and as another example using public/private keys?
Okay, I will supply them later ...

cu,
Wolfgang

begin:vcard 
n:Kleinertz;Wolfgang
x-mozilla-html:FALSE
url:www.doubleSlash.de
org:doubleSlash Net-Business GmbH
adr:;;Müllerstraße 12/1	;Friedrichshafen;Baden-Württemberg;88045;Deutschland
version:2.1
email;internet:Wolfgang.Kleinertz at doubleSlash.de
x-mozilla-cpt:;-3360
fn:Wolfgang Kleinertz
end:vcard