On 23/04/12 18:03, Marek Posolda wrote:
Hi all,
On 22.4.2012 19:27, Christian Kaltepoth wrote:
I prefer the method signature Shane suggested in his initial mail.
Providing a single method with an object parameter makes most sense to
me:
Identity.hasPermission(Object resource, String operation)
This way the developer is completely free to choose how to identify
the resource. I think in most cases the object itself will be used.
And the JSF example Shane showed is a very good example for this.
Of cause people may need other ways to refer to resources like in the
ResourceIdentifier concept Marek showed. But actually I see something
like this more as an usage pattern and I don't think it belongs
directly into the API. Perhaps we could provide something like
ResourceIdentifier as an utility class that people can use if they
want to refer to resources this way. But the API of Identity should be
as simple as possible. And the object parameter will allow people to
use any object they want. Even something like ResourceIdentifier.
That's the question. I think that API should be clear and using single
method:
Identity.hasPermission(Object resource, String operation)
is not clear enough. As in some cases, your argument is directly
secured object and in other cases it's only ResourceIdentifier for
this object. Also it would mean that you will need to ask for the type
of object in your PermissionResolver implementation:
if (resource instanceof ResourceIdentifier)
{
// compute permissions for ResourceIdentifier
}
else
{
// Argument is "resource" so compute permissions for this resource
}
On the other hand, using single method:
Identity.hasPermission(ResourceIdentifier resource, Operation operation)
may not be appropriate enough for some use-cases. Let's imagine that
you have Customer and CustomerResourceIdntifier objects:
public class Customer
{
private String ID;
private String customerName;
// getters and setters here
}
public class CustomerResourceIdentifier implements ResourceIdentifier
{
private String customerId;
// getters and setters
}
And you want to create PermissionResolver, which will compute
permission based on customer name. With the API method:
Identity.hasPermission(ResourceIdentifier resourceIdentifier,
Operation operation)
you can't manage to do it (unless you change implementation of
CustomerResourceIdentifier to encapsulate customerName)
Operation
I agree that big advantage of this approach is type-safety. On the
other hand, using String directly is more flexible as you have more
freedom. Let's imagine that you have some permission rules stored in
database and you want to add new type of operation like "ADMINISTER".
With using String as argument, you can directly create records in DB
and use this new "ADMINISTER" argument without doing any changes in
Java code. With the Operation approach, you would need to add this new
ADMINISTER operation into your Operation enum:
This is exactly why the operation cannot be an enum - permissions will
be stored in the database as string values, and if we use an enum value
there will be no way of knowing which enum class the operation(s) string
needs to be converted back into. I should have actually expanded on the
details of this a little bit earlier which would have made this more
obvious.
Another use case which I didn't mention is the ability to use bit flags
to set permissions. This is extremely important for a database with
millions of records - instead of using a String in the database to store
the operations it is possible to use a numerical value instead, with
each bit representing a different operation. It also allows us to
define available permissions for a particular domain object, which is
important when building management interfaces.
Let's say we have the following entity:
@Entity
@Permissions({
@Permission(operation="create"),
@Permission(operation="read"),
@Permission(operation="update"),
@Permission(operation="delete")
})
public class Customer
{
// snip
}
The @Permissions annotation tells the PermissionManager that we're
allowed to assign four specific permissions; create, read, update and
delete for the Customer entity. We can take this a step further and
define a bit mask value for each of these:
@Entity
@Permissions({
@Permission(operation="create", mask = 1),
@Permission(operation="read", mask = 2),
@Permission(operation="update", mask = 4),
@Permission(operation="delete", mask = 8)
})
public class Customer
{
// snip
}
By providing mask values, the PermissionManager knows that the
cumulative permissions for this entity will be stored in the database as
a numerical value. So a user with create, read and update permissions
for a particular customer will have a stored operation value of 1
(create) + 2 (read) + 4 (update) = 7.
public enum CrudOperation implements Operation
{
CREATE, READ, UPDATE, DELETE, ADMINISTER
}
I wanted to point this out, but I agree that for most cases is
type-safe approach with Operation interface probably better:-)
So after all, my opinion is to have two methods:
Identity.hasPermission(Object object, Operation operation) throws
AuthorizationException;
Identity.hasPermission(ResourceIdentifier resourceIdentifier,
Operation operation) throws AuthorizationException;
+1, I think that having two methods is the best solution, with the
caveat that overloading like this doesn't cause issues with EL. The
Object parameter version of this method will most likely delegate to the
ResourceIdentifier method anyway, as a ResourceIdentifier will be
required for all lookups. By the way, we should make this as
transparent as possible - out of the box, DeltaSpike should provide a
ResourceIdentifier implementation for entity beans that will build a
unique identifier based on the class name and the primary key value.
Another alternative that we should support is allowing the user to
specify which ResourceIdentifier to use on the domain class itself:
@Entity
@Identifier(CustomerResourceIdentifier.class)
public class Customer
{
}
Yet another alternative that we should support is the packaging of
additional ResourceIdentifier implementations with an application, that
are automatically discovered and iterated through when the permission
check can't determine which ResourceIdentifier to use. With that in
mind, the ResourceIdentifier interface should look like this:
public interface ResourceIdentifier
{
boolean canIdentify(Class targetClass);
String getIdentifier(Object resource);
}
The canIdentify() method will return true if the specified class is one
that this ResourceIdentifier is capable of generating identifier strings
for.
Thanks,
Marek
