On Thu, 2001-10-18 at 05:04, Jacopo Cappellato wrote:
> Hi,
> I'm trying to design a standard way for the definition of security features
> related to modules (e.g. actions and screens) at DEPLOY time.
> In fact , IMHO, Turbine's security framework (users, groups, roles,
> permissions, acls and flux with some enhancements) is a beautiful and
> powerful system but it lacks in the definition of a standard way of
> configuring modules' security at deploy time.
I agree with you
> This freedom could be dangerous mainly for two reasons:
> 1) the temptation of writing modules' with security features set at DESIGN
> time
> 2) without a standard protocol, managing a great amount of modules' security
> stuff in a properties file could be difficult
> Example:
> a module with security features set at DESIGN time, VERSUS a module with
> security features set at DEPLOY time:
> ****DESIGN*****
> ..
> if (acl.hasPermission("viewinvoice")) { <----BAD
> setTemplate(data, "Invoice.vm");
> }
> ...
> *****DEPLOY***********
> ...
> if (acl.hasPermission(TurbineResources.getString("ThisModule.permission")))
> { <---GOOD but not standard
> setTemplate(data, "Invoice.vm"); <--- GOOD?
> }
> ...
> where in TurbineResources there is the following entry:
> ThisModule.permission=viewinvoice
> QUESTION: do you think that also the "Invoice.vm" should be taken from TR?
I don't know. I think it should be taken from TR.props or another kind
of resource. I think that every service could have it's own kind of
resources manageable through MyServiceResources that would extend
TurbineResources
> Maybe something similar is done in Struts... I really don't know if it could
> be useful...
> **************
>
> In the second example I have used the non-standard key
> "ThisModule.permission".
> A better solution could be the adoption of a standard way of coding
> security, for example :
>
> security.MODULE_NAME.groups = groupA <-- i.e. module "MODULE_NAME"
> belongs to group "groupA"
> security.MODULE_NAME.roles = role1, role2 <-- i.e. access is granted to all
> the users that in "groupA" have the role "role1" or the role "role2"
> security.MODULE_NAME.permissions = perm1, perm2 <-- i.e. access is granted
> to all the users that in "groupA" have the permissions "perm1" and "perm2"
>
> If all the modules, with security needs, adopt this standard, we could
> create a class, for example, ModuleSecurity with a constructor:
> public ModuleSecurity(String moduleName) {
> // reads alla the keys of TR beginning with "security." + moduleName and
> initializes its maps: groups, roles, permission
> }
> and some methods like:
> public boolean hasAccess(AccessControlList acl) {
> // checks if the user can access the module
> }
>
> and the module of the preceeding example could become:
> ...
> ModuleSecurity ms = new ModuleSecurity("MyName");
> if (ms.hasAccess(acl))
>
> setTemplate(data, "Invoice.vm");
> }
> ...
> I'm working on something similar and I would greatly appreciate your
> comments, suggestions...
> Sorry for the very long message and the very bad english!
> Best regards,
> Jacopo
I have implemented something like this. But it only accepts 1 group
and/or 1 hole and/or 1 perm :
public abstract class BaseIntranetSecureAction extends
VelocitySecureAction
{
public static final String AUTHORIZATION_KEY =
"services.SecurityService.action.";
protected boolean isAuthorized( RunData data )
throws Exception
{
try
{
String groupName =
((IbUser)data.getUser()).getGrupo().getName();
/* group name in IbUser -> extends TurbineUser */
AccessControlList acl = data.getACL();
String requiredPerm = TurbineResources.
getString(
AUTHORIZATION_KEY+"perm."+this.getClass().getName(),null);
String requiredGroup = TurbineResources.
getString(
AUTHORIZATION_KEY+"group."+this.getClass().getName(),null);
String requiredRole = TurbineResources.
getString(
AUTHORIZATION_KEY+"role."+this.getClass().getName(),null);
Log.debug("security","role["
+ requiredRole
+"] perm["
+ requiredPerm
+"] group["
+ requiredGroup
+"]");
boolean allowed = true;
if (acl != null && data.getUser().hasLoggedIn())
{
allowed = (requiredPerm != null) ?
acl.hasPermission(requiredPerm,groupName) : allowed ;
Log.debug("security","Has Perm ??["+allowed+"]");
allowed = allowed && (requiredRole != null) ?
acl.hasRole(requiredRole,groupName) : allowed ;
Log.debug("security","Has Role and Perm
??["+allowed+"]");
allowed = allowed && (requiredGroup != null) ?
requiredGroup.equals(groupName) : allowed ;
Log.debug("security","Has Role and Perm and Group
??["+allowed+"]");
}
Log.info("security","Is
user["+data.getUser().getUserName()+"] allowed to process ACTION
"+data.getScreen()+"["+allowed+"]");
if(allowed)
{
return true;
}
}
catch(NullPointerException e)
{
/* if the user doesn't have a group associated with it */
Log.info("security","user not allowed to process ACTION (not
logged or not associated with a group)");
}
data.getTemplateInfo().setScreenTemplate(TurbineResources.getString("template.access.denied"));
data.setMessage("Acess denied");
return false;
}
All my Action modules extend this class.
There is a class similar to this one to be used by Screen modules.
I think my ideas are similar to yours. But I know I have to spend more
time on this to get a general solution.
I hope we can use feedback from other to get this job done.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
