Lester Ward <[EMAIL PROTECTED]> writes:
>I've been looking at Turbine's security system. We need it to do some things
>that it does not appear to do currently, and am looking to see if there is a
>"standard" approach to adding the modifications we want (as I suspect they
>would be common).
>1) Licensing
>We run a service company, and only expose certain features of our web site
>to people who have purchased a license for those services. Meaning, when a
>user hits a page, we only show them that page if the group they belong to
>has a license for that feature. My understanding is that Turbine has no
>native support for this kind of licensing. Is this correct?
Create a Permission. Let's call it "USE_FEATURE". Create a Role for
this. Let's call it "FEATURE_USER".
Assign the Permission "USE_FEATURE" to the role "FEATURE_USER".
Now create Groups. FEATURE_1. FEATURE_2. FEATURE_3
Assign your users a Role in one of the groups if he may use the feature:
FEATURE_1 FEATURE_2 FEATURE_3
User 1 FEATURE_USER FEATURE_USER
User 2 FEATURE_USER FEATURE_USER
User 3 FEATURE_USER
User 4 FEATURE_USER FEATURE_USER
... you get the basic idea.
Then ask in isAuthorized : "Does the current user has the Role "FEATURE_USER"
in the GROUP <xxx>".
(data.getUser().getAcl().hasRole("FEATURE_USER", "<xxx>"))
and react on the answer.
>Assuming it is, how would you model this? Would you build it external to
>Turbine's security system or try to tack it into the middle somewhere? I
>considered creating a permission of "has license", but this doesn't really
>work, because you really want the license to be attached to the group and
>permissions only attach to roles. Likewise, implementing a license as a role
>isn't really correct, as roles attach to users, not groups.
>2) Exclusions
>We often find ourselves in situations where we want to restrict access to a
>specific feature for a particular user (or group) temporarily. So, for
>example, say a user has a role for a specific group that allows permissions
>a, b, c and d. For a week, we want to take away permission c, but only for
>that one group. In other words, we don't want to change the role, but
>override it for a specific user and/or group (for a short time).
>As far as I can tell, Turbine doesn't support the idea of an "exclusion
>list", so the only way to do this would be to build a new role containing
>just a, b and d and alter the user record to point to the new role. Then,
>when the week was up, reconnect to the original role and delete the other
>role. Is this an accurate assessment of Turbine?
Map single permissions to roles. Then assign multiple roles to your user
in a group.
Remove and add roles according to the access rights. Then use
hasPermission(<permission>, <group>)
Yes, this is cumbersome and leads to Role Inflation. No, Turbine does
not support any concept of "exclusion lists".
What you actually need is a direct mapping of permissions to users in
a group. We must go through the roles, though.
>Has anyone had much success with implementing an exclusion list onto
>Turbine's existing security? That is, Turbine seems to currently validate
>permissions by saying "allow the user to act if they have a role for this
>group that contains permission X." We'd like to change this to something
>like "allow the user to act if they have a role for this group that contains
>permission X, unless X is specifically denied for this user and/or group."
>Has anyone overridden Turbine to provide such functionality?
Don't know. The security service isn't too deeply coupled with the
rest of Turbine (it mainly must have a facility to supply an "unknown"
user and allow querying whether the current user can do (or not do)
something. All the rest (access controller and stuff) is encapsulated
in a few simple classes. The lack of a generic interface is the
biggest obstacle to make the Security Service completely pluggable
(think JAAS here). And the lack of docs how to do this, of course. ;-)
It can be done but there seems to be not enough pain with the current
service to do it.
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
--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
