[juddi-Users] RE: User Auth

[Steve Viens <sv...@steveviens.com>]

Anou,
 
Great question. I'm going to cc the juddi-developers & juddi-users lists
to my reply so that the answer is shared & saved as I'm sure it will
come up again.
 
Authentication is designed to be modular and a simplistic implementation
of the Authenticator interface has been provided (SimpleAuthenticator -
a very poor implementation since passwords are not even encrypted.) One
of the early goals of the jUDDI architecture was that it would be
designed to be more of a UDDI server "framework" made up of a handful of
modules that conform to specific interface. To make it work more
effectively in your environment you would simply (or not-so-simply)
implement a new Authenticator 'module' that would work best for your
situation or your organization (i.e. LDAP, NT Authorization, etc).  The
hope is that others would create these 'module' implementations and
donate that work back to the jUDDI project.
 
Initially the areas that were identified that modularization would
benefit most were"
 
  Authenticator (it's done differently in every organization a simple
implementation provided)
  DataStore (ANSI SQL is not the most performant of options but works on
most RDBMS)
  Configuration (not used yet - ask me about it later)
  Logging (we scrapped this idea ad stuck with Log4j)
  UUID Generation (several implementations already available in the
org.juddi.uuidgen package)
 
We had even decided not to make Axis the only SOAP transport we'd
support which is why the code is not very closely married to Axis -
although there may be some work there that needs to be revisited. (I
think this answers one of your earlier questions.)
 
We're just now approaching a fairly stable 'beta' build of jUDDI so
there really hasn't been a reason anyone would have created new modules
to donate yet. The supplied modules are extremely easy to work since
they do not require the setup or installation of any external resources.
If someone wanted to take jUDDI for a test drive or simply get a UDDI
server up and running (in minutes) all they would have to do is download
the latest "juddi.war" file from SourceForge, drop it into Tomcat's
webapps directory and restart.
 
Steve
 
Steve Viens
jUDDI Project Manager
sviens@users.sourceforge.net
 <http://www.juddi.org/> http://www.juddi.org
 
-----Original Message-----
From: Anou Manavalan [mailto:anou@openbiz.biz] 
Sent: Thursday, November 07, 2002 4:32 PM
To: steve@inflexionpoint.com
Subject: User Auth


Steve,
 
Questions about the user authorization,
 
1) Why is jUDDI not storing the users in the db ?
2) Why is separate auth needed instead of normal HTTP basic auth ? why
can't we use that ?
3) Since it is a webapp, can't we use the container security like JAAS ?
 
 
thanks,
-Anou

[juddi-Developers] RE: User Auth

[Anou Manavalan <an...@openbiz.biz>]

MessageSteve,

Delete Binding was failing with ForeignKey constraints.

In the deleteBinding(String bindingKey) method in JDBCDataStore  -- I had to
move "TModelInstanceInfoTable.delete"  below the instance details -- delete
to make it work.


regards,

-Anou

// delete the immediate dependents of BindingTemplate

BindingDescTable.delete(bindingKey,connection);

TModelInstanceInfoDescTable.delete(bindingKey,connection);

InstanceDetailsDocDescTable.delete(bindingKey,connection);

InstanceDetailsDescTable.delete(bindingKey,connection);

TModelInstanceInfoTable.delete(bindingKey,connection);

  -----Original Message-----
  From: Steve Viens [mailto:sviens@steveviens.com]
  Sent: Thursday, November 07, 2002 3:24 PM
  To: anou@openbiz.biz
  Cc: juddi-developers@lists.sourceforge.net;
juddi-users@lists.sourceforge.net
  Subject: RE: User Auth


  Anou,

  Great question. I'm going to cc the juddi-developers & juddi-users lists
to my reply so that the answer is shared & saved as I'm sure it will come up
again.

  Authentication is designed to be modular and a simplistic implementation
of the Authenticator interface has been provided (SimpleAuthenticator - a
very poor implementation since passwords are not even encrypted.) One of the
early goals of the jUDDI architecture was that it would be designed to be
more of a UDDI server "framework" made up of a handful of modules that
conform to specific interface. To make it work more effectively in your
environment you would simply (or not-so-simply) implement a new
Authenticator 'module' that would work best for your situation or your
organization (i.e. LDAP, NT Authorization, etc).  The hope is that others
would create these 'module' implementations and donate that work back to the
jUDDI project.

  Initially the areas that were identified that modularization would benefit
most were"

    Authenticator (it's done differently in every organization a simple
implementation provided)
    DataStore (ANSI SQL is not the most performant of options but works on
most RDBMS)
    Configuration (not used yet - ask me about it later)
    Logging (we scrapped this idea ad stuck with Log4j)
    UUID Generation (several implementations already available in the
org.juddi.uuidgen package)

  We had even decided not to make Axis the only SOAP transport we'd support
which is why the code is not very closely married to Axis - although there
may be some work there that needs to be revisited. (I think this answers one
of your earlier questions.)

  We're just now approaching a fairly stable 'beta' build of jUDDI so there
really hasn't been a reason anyone would have created new modules to donate
yet. The supplied modules are extremely easy to work since they do not
require the setup or installation of any external resources. If someone
wanted to take jUDDI for a test drive or simply get a UDDI server up and
running (in minutes) all they would have to do is download the latest
"juddi.war" file from SourceForge, drop it into Tomcat's webapps directory
and restart.

  Steve

  Steve Viens
  jUDDI Project Manager
  sviens@users.sourceforge.net
  http://www.juddi.org

  -----Original Message-----
  From: Anou Manavalan [mailto:anou@openbiz.biz]
  Sent: Thursday, November 07, 2002 4:32 PM
  To: steve@inflexionpoint.com
  Subject: User Auth


  Steve,

  Questions about the user authorization,

  1) Why is jUDDI not storing the users in the db ?
  2) Why is separate auth needed instead of normal HTTP basic auth ? why
can't we use that ?
  3) Since it is a webapp, can't we use the container security like JAAS ?


  thanks,
  -Anou