Re: authentication and authorization

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

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.



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

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,

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/