"Eric Pugh" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] +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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
