[Fulcrum] Security Service Thoughts

[Eric Pugh <ep...@upstate.com>]

First off,  I am aggregating my responses into one email so you can see
my
train of thought on the various response I recieved.

I agree with your points about the complexity. What I tried to do was
break
up the code into "model" and "implementation".  For example, Turbine has
a
model where users and groups and roles are all related together in one
table.  However, my use case  is for users to be related to groups who
are
related to roles.  I have another model I may need which is closer to NT
which is just users and groups.  And no concept of permissions.  The
model
will provide for these differences.

So at the root are basically degenerate marker interfaces:
User/Group/Role/Permission.  And the model is what extends and glues
them
together.  To extend the objects, you have for example
model.[modeltype].entity interfaces that describe beyound what the
degenerate User interface defines, what a user would look like.  In the
Turbine model, a user has a temp storage, a confirmed value, an email,
so on
and so forth.  But, in the simple model, a user only has a name and
password.  The hope is that this will make it simplier to extend you
objects
by simply providing a different model.

In the model.[modeltype].manager exists the interface defining how to
glue
the objects together.  For the "simple" model, a user has roles.
Therefore
there are the appropriate grant/revoke methods.  In the "turbine" model,
a
user has roles and groups.  So the grant/revoke methods definied for
that
model are quite different.

Now, each model may have multiple implementations.  Therefore the SPI
approach.  This way multiple Service Providers may be used for each
model.
And then you can mix and match your service provider with your model.
So I
want to use the "simple" model with Hibernate.  Fortunantly there is a
service provider, so I use that.  But maybe I am unit testing  my
application and don't want a database.  Then I can use the "simple"
model
with the Memory provider.  The homepage of the new code if you build the
site has a matrix of the models and SPI's.

As a demonstration of the mix and match, the unit tests for the Memory
and
Hibernate SPI's for the simple model are the exact same.

Now, I *think* this is all quite seperate from what Turbine wants.
Turbine
shouldn't care about any of that stuff.  I agree 100%.  The
SecurityServiceAdapter I wrote was purely to demonstrate backwards
compatibility between Turbine and Fulcrum Security.  Turbine has it's
own
concerns.  While they could be put into the "turbine" model (and
currently
are), I don't think they should be.  I think they are Turbine
specific things.

Going down you list, I think that:
 - get an explicit anonymous user object
Turbine
 - check whether the passed user object is an anonymous user	Turbine
 - get an user object
Security
 - add authentication ("Log In")
Turbine
 - authenticate the user by some passed information
Security
 - remove authentication ("Log out")
Turbine
 - get ACL for the user object
Security

Notice that remove authentication is Turbine, while authenticate is
Security.  The actual process of Logging In is a turbine concern.
Authentication belongs in the security framework.  And logging out is
part
of Turbine.  So, we are agreeing on this I believe.  So, what I think
Turbine needs is a security service that just provides those things.  No
granting/revokeing of permissions etc etc etc.  If you need to do that,
then
use your SPI! And, that lifecycle of user object can be nicely unit
tested
when backed up with the memory SPI.

As far as your email on the Role extension, the o.a.f.s.entity
interfaces I
think should be totally degenerate.  For instance, user has a password
field.  However, with NT security, a user doesn't have a password. Once
they
authenticate, that password is gone, it doesn't need to be related to
the
user at all.  I don't quite understand what you mean by yet another Role
extension.  I am guessing that something in the "simple" model strikes
you
as having an extra role like object?

As far as the ints/longs thing goes.  I agree that the identifier should
be
an Object.  I swapped from int's to longs because I had a usable use
case
for it.  But, if you have a use case, which you do, for using Object,
then I
am all for making that change.  I would recommend though that the LDAP
backend be put under FULCRUM/security/proposals instead, as part of the
objective would be to allow turbine to swap from using in memory to
hibernate to ldap as the SPI.  Send me the code and I will look to
integrating it.  The more SPI's and models we can think of now, the
quicker
the rough edges can be worked out.

On a somewhat seperate note, what are the reason's behind the "turbine"
models intersection of user/group/role?  I just don't quite grok why it
works that way.  Also, the torque code ONLY compiles.  I don't use
torque,
so until I know this code is going be ongoing, I don't want to spend a
lot
of time figuring the Torque build out etc just to see it scrapped.
Also, I
have a long past due need for the hibernate based simple model, hence my
focus on that.

I think the component approach is the way to go.  For instance, I added
authenticators that allow you to plug in what authenticator to use.  I
want
to authenciate my users against NT for example.  Someone else might wish
to
authenticate using the crypto service.

In the tasks page for the xdocs for security are a couple outher
ruminations
I have had, like naming, etc...

The build is working fine for me.  A couple jars are NOT in ibiblio,
namely
the tagish jar for NT and I think the mckoi jar for the inmemory
database.
However, as soon as I get access to jakarta.apache.org, I can upload
them to
the turbine repo.  I am working on getting them into ibiblio however.
There
are over 140 unit tests, so looking at them is the best way to
understand
how the pieces glue together.

Eric Pugh








> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Monday, August 25, 2003 9:51 AM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: [FULCRUM] Swap in commons-pool for pool service?
>
>
> "Eric Pugh" <ep...@upstate.com> writes:
>
> >So far, I have a SecurityServiceAdapter extending
> BaseSecurityService that
> >works quite well for adapting calls like
> >TurbineSecurity.getService().getInstance().getACL(user).
>
> This is already too complex.
>
> Look at what the Turbine core really needs from the Security Service
>
> - get an explicit anonymous user object
> - check whether the passed user object is an anonymous user
> - get an user object
> - authenticate the user by some passed information
> - remove authentication ("Log out")
> - get ACL for the user object
>
> everything above this is scope of an explicit security service
> implementation. If you start thinking group, role, permission, you've
> already lost. :-)
>
> The first two things are generic for a base service and is what IMHO
> some sort of dummy security service _must_ implement so that
> turbine runs
> even without security activated. Getting an user object,
> authenticating it
> and removing authentication (which is some sort of life cycle for the
> user object) is more or less user-object centric and the
> security service
> must only provide the means to get the user object (authenticating it
> can be called on the user object which then proxies back to
> the service).
>
> Getting an ACL might not strictly be necessary but is of course
> something that helps things like Secure Screens and Actions.
>
> Boiling this down a little further can only help. But I won't
> beat that
> half dead horse called security service any longer.
>
> 	Regards
> 		Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
> hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development  -- hero for hire
>
> "Dominate!! Dominate!! Eat your young and aggregate! I have
> grotty silicon!"
>       -- AOL CD when played backwards  (User Friendly - 200-10-15)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org