I think we will run into the same problems again.
People want to do something/integrate with something that just isn't
possible/easy to do with the interfaces we have made.
Like integrating with JAAS (which we should do anyway), windows NT
domains/.... what ever.
So how about generating all the security classes/interfaces/services using
the TDK.
So if all people needed was a security model with users (no roles, no
domains, nothing else) they would set a variable in newapp.properties
SecurityModel=UserOnly
and when compiling your application for the first time, all the needed
classes/services/sql scripts would be created.
(you would get a )
com.somedomain.appname.security.SecurityService
com.somedomain.appname.security.User
com.somedomain.appname.security.DBUser
.....................
There is really no need to have 4 tables in your database if all żou need is
one.
By setting it
SecurityModel=UserRole
you would get an additional role table and the Security service would have
additional methods, and so on.
you would get a hold of a user object this way (could be put in a static
method)
SecurityService service=(SecurityService)
someregistry.lookup("securityservice");
User user=service.getUser(rundata); or service.getUser(some HttpSession)
this way it could be easily used in other servlet applications.
Even if we don't use the 'user' generated security service, I would prefer
if turbine wasn't directly coupled to the security implementation like it is
now (some rundata).getUser(), but forcing people to look up the service.
- Kasper
----- Original Message -----
From: "Gonzalo A. Diethelm" <[EMAIL PROTECTED]>
To: "Turbine Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, January 08, 2002 1:52 PM
Subject: First ideas for new security model
> I'm attaching my first ideas on the new security model. The archive
> is supposed to be expanded under org.apache.fulcrum.security.
>
> [Jason, I'm sending this to your personal address in case the list
> doesn't like attachments].
>
> These are my ideas up to now:
>
> * Five interfaces Permission, Role, User, Application and Session
> (package entity). These have no data except for a unique String
> id, and each has some basic operations related to security queries.
> There are no administrative functions at this level.
>
> * Five classes Fulcrum{Permission,Role,User,Application,Session}
> (package entity.fulcrum), that have a basic implementation of the
> above interfaces.
>
> * Five interfaces {Permission,Role,User,Application,Session}Factory
> (package factory). These define the operations to load, save and
> remove their respective objects from a back-end.
>
> * Five classes Fulcrum{Permission,Role,User,Application,Session}Factory
> (package factory.fulcrum), that have a basic (mostly comments)
> implementation of the above interfaces.
>
> * The idea is that Fulcrum code uses ONLY the Permission, Role, User,
> Application and Session interfaces, NEVER referring to a concrete
> extension of them.
>
> * I include a sample properties file where the programmer will specify
> what concrete entity and factory classes she whishes to use.
>
> * There is a SecurityManager class, a facade for all the factory classes
> that reads the configuration file and uses the configured factories to
> manipulate security objects.
>
> * A programmer could create new classes implementing the basic interfaces
> if she wanted to have:
>
> a) Security objects with other information.
> b) Different back-ends.
>
> I'm sure there are a lot of loose ends, but I really wanted to send this
> to the list ASAP, for its discussion and trashing. In particular, I think
> it could be useful to define more administrative functions in the factory
> interfaces, trying to foresee massive operations that could be implemented
> more efficiently directly by the factory.
>
> Best regards,
>
>
> --
> Gonzalo A. Diethelm
> [EMAIL PROTECTED]
>
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
