Re: authentication and authorization

[Konrad Krafft <konrad.krafft at doubleslash.de>]

Marcel Ruff wrote:
> 
> Konrad Krafft wrote:
> >
> > hi,
> >
> > I have seen that the authentication and authorization implementation
> > is in work.
> >
> > As you can see on the architecture plan this functionality is part
> > of the xmlBlaster.
> > Surely, the authentication ist nessecary for the xmlBlaster but wouldn't
> > it
> > be better to implement an extra process or server.
> > In this case you are able to put authentication on an extra hardware.
> > The authentication and authorization server should communicate with
> > the xmlBlaster and vice versa via IIOP.
> >
> > What do you think about it?
> Yep, you are right.
> 
> Our plans are (up to now):
> 
> 1) Authentication service:
> ==========================
> 
> The authentication service does serve the basic
> question 'who may access xmlBlaster', using
> login/logout and public/private key schemas.
> 
> The authentication service is a new instance
> of xmlBlaster, running as a new thread in the
> xmlBlaster serving the user messages or as a
> standalone xmlBlaster process (on a different server).
> 
> So we don't need to implement a new authentication
> service, since the normal xmlBlaster is the
> authentication service as well.
> 
> If there is some funtionality missing for this
> task, this will be added to the xmlBlaster engine
> and extend xmlBlaster generally.
> 
> Note that every client in the authentication service
> is in reality a MessageUnit in xmlBlaster, so
> you can query client attributes with XPath (e.g client
> groups or client roles),
> subscribe on client changes, use it for broadcasts etc.
> 
> The authentication service should be possible
> to play a proxy for existing user databases like LDAP.
> LDAP access is possible through JNDI with XML based LDAP
> access. See http://www.dsml.org/about.html for more informations.
I think that this is the right and important way. In every
larger and heterogenous system you have existing account databases.
It should be possible to integrate them.
> 
> 2) Authorization service:
> =========================
> 
> The authorization service does serve the basic
> question 'who may do what with which data in xmlBlaster', using
> a XML based ACL (access control list).
ACL's are also supported by Directory-Servers. Access to this
information should also be supported in the same way like authorization.
 
> 
> The authorization service (same as the authentication service)
> is a new instance of xmlBlaster,
> running as a new thread in the
> xmlBlaster serving the user messages or as a
> standalone xmlBlaster process (on a different server).
> 
> So we don't need to implement a new authorization
> service, since the normal xmlBlaster is the
> authorization service as well.
> 
> If there is some funtionality missing for this
> task, this will be added to the xmlBlaster engine
> and extend xmlBlaster generally.
> 
> Note that every access control entry in the authorization service
> is in reality a MessageUnit in xmlBlaster, so
> you can query client authorization with XPath,
> subscribe on client authorization changes etc.
> 
> Authorization entries may look like this:
> 
> WHO : WHAT-ACTION : WHICH-DATA
> 
> for example:
> 
> Jimmy   : read   :  top-secret-document-12345
> Joe     : write  :  pricing-of-computers
> Heidi   : erase  :  top-secret-document-1299
> 
> This should be based on XML, to allow XPath
> queries for access decisions.
> 
> just my 2 euros,
??? what does this mean?

Konrad
> 
> Marcel
> 
> I'll go skiing now, see you in 5 days again :-)
> >
> > Greetings
> > Konrad
> 
> --
> Marcel Ruff
> ruff at swand.lake.de
> http://www.lake.de/home/lake/swand/

-- 
  doubleSlash
  Net-Business GmbH
  Müllerstrasse 12/1
  88045 Friedrichshafen

  email: konrad.krafft at doubleslash.de
  fon  : 07541 6047 104
  fax  : 07541 6047 111