Re: Security extension: first announcement + RFC

[Marcel Ruff <ruff at swand.lake.de>]

Wolfgang Kleinertz wrote:
> 
> Hello!
> 
> Two weeks ago Marcel, Konrad and I met to exchange our views regarding
> the topic: xmlBlaster and security.
> 
> Meanwhile I was preoccupied with this first draft.
> 
> The major goal of this project is to provide a mechanism to be able to
> write and use plugins. The purpose of such a plugin is to satisfy the
> requested security level.
> This way, it should be possible to add real authentication and
> authorisation (e.g. using kerberos or a2blaster), to make use of digital
> signatures or encrypt the data on a per message level. Adapters to
> different apis like Suns JAAS, JCE, etc. or GSS are also conceivable.
> 
> Interfaces:
>   1. I_Subject
>      subject related information and actions (e.g. public key)
> 
>      + String init(String qos);
>      + boolean isAuthorized(String key);
> 
>   2. I_UsrSessionSecurityContext
>      contains session related things like a kerberos "Service Ticket"
> 
>      + String init(String qos);
>      + I_Subject getSubject();
>      + boolean isValid();
> 
>   3. I_SecurityManager
>      servs as factory for the objects behind these interfaces
> 
>      + I_SecurityManager getInstance(); // singleton
>      + I_UsrSessionSecurityContext creatUsrSessionContext();
>      + I_Message createMessage();
>      + I_Subject createSubject();
> 
>   4. I_Message
>      used to sign and encrypt messages
> 
>      + void setTarget(I_UsrSessionSecurityContext s);
>      + I_UsrSessionSecurityContext getTarget();
>      + void setSource(I_UsrSessionSecurityContext s);
>      + I_UsrSessionSecurityContext getSource();
>      + void setContent(String xmlMsg);
>      + String getContent();
>      + void setQoS(String xmlQoS);
>      + String getQoS();
>      + void seal(); // i.e. sign + encrypt
>      + void unseal();
>      + boolean isSealed(); // is the message sealed?
>      + boolean isTrustworth(); // was it sealed while transmission?
>      + boolean isValid; // is the signature correct?
> 
> To reduce the necessary changes, it's recommended to introduce helper
> classes. Example for the message flow and the intention of such a
> helper:
> 
> net  protocol helper xmlBlaster
>      handler         (blackbox)
>      .------- ------ ---------.
>      |  key | |    | |        |
>      |     / /    / /         |
> ---> |    | | -> | |          |
> <--- |     \ \    \ \         |
>      |  QoS | |    | |        |
>      |     / /    / /         |
>      |    | | <- | |          |
>      |     \ \    \ \         |
>      |  msg | |    | |        |
>      `------- ------ ---------ï
>                ^  |  .--------.
>                |  `->| I_Msg. |
>                `-----|        |<--- (I_UsrSessionSecurityContext)
>                      `--------ï                 ^
>                                                 |
>                                            (I_Subject)
> 
> ---
> 
> Additional facts:
> + the old I_Authenticate interface etc. is deprecated
> + changes in the external (client) interfaces are not necessary, except:
>     login( ... ): deprecated
>     qos init(String qos): replaces login
>   wrappers are recommended for compatibility
> 
> + all security features are optional xmlBlaster extensions
> + clients need extensions, too
> 
> + plugins are bound via xmlBlaster.properties
> ---
> 
> Next steps:
> 
> + design, discussion, prototyping
> + implementation + implementation of a dummy plugin
> + implementation of a plugin to integrate the a2Blaster
>   authentication and authorisation system (www.a2blaster.org)
> 
> Okay, that's all for the first time. Further information will follow.
> 
> Cheers,
> Wolfgang Kleinertz
> 
> PS: Comments are welcome!!!

Hi Wolfgang,

thanks for your proposal.

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

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

 - Extensible (generic interfaces) to allow future
   extensions without braking the contract of older
   clients with xmlBlaster

 - Simple approach (as simple as possible - but not simpler)

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?

cu,

Marcel


-- 
Marcel Ruff
mailto:ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org