[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re^2: Security extension: first announcement + RFC
> 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
Client side doesn't mean client-idl! Instead it's an api in the clients
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
> - Language neutral setup (what about a Python or a C++ client)
> How would xmlBlaster.idl look like after the changes?
serverIdl::Server login(in string loginName, in string passwd,
in serverIdl::XmlType qosClient)
* 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)
void logout(in serverIdl::Server xmlBlaster) raises
* 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
* Returns information about the used plugin and its requirements
(password, certificates ...)
* <plugin type="KERBEROS" version="4"></plugin>
* <plugin type="PUBKEY"><KEY type="IDEA"
> - 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 ...
org:doubleSlash Net-Business GmbH
adr:;;Müllerstraße 12/1 ;Friedrichshafen;Baden-Württemberg;88045;Deutschland
email;internet:Wolfgang.Kleinertz at doubleSlash.de