The purpose of this meeting was to brainstorm the new permission model for
Carbon 5. This mail contain the summary of the meeting. We haven’t
finalized anything yet.
During the meeting we discussed on service permissions and resource
permissions. Service permissions are applied to micro services. These
services could be admin services or product specific services. Resource
permissions applies to all the resources in our platform. E.g Registry
resource, Topic, Queues etc.
Let me try to explain the difference using an example. Consider the
operation “addUserToGrop” in “UserMgtService”. Here we can define
permission at different levels. A user Bob can invoke this method, but Bob
cannot add users to group Foo. Granting privileges to invoke this method
can be done via service permissions. Restricting Bob from adding user to
group Foo can be done via resource permissions.
A permission has a name and optional list of actions. There are permissions
with just the name and they are usually called named permission. Either we
give users named permissions or we don’t. Above mentioned service
permissions are named permissions. E.g. Either we allow user to invoke the
addUserToGroup method or we don’t. There are no actions associated with
this permission. But for resource permissions , there are associated
actions. E.g. Registry resources can be added, deleted, updated etc.
*Declaring Permissions.*We discussed two ways to declare required
permissions in services.
*Solution 01*
@RequirePermission(“manage/users”)
public class UserMgtService {
@RequirePermission(“add-user”)
public void addUserToGropu(User user, String groupName) {
}
}
This is exactly same as Carbon 4 model. Permissions required invoke a
service is declared in the services.xml. With microservices based services
we can declare required permission with annotations.
*Solution 02*
@Secure
public class UserMgtService {
public void addUserToGropu(User user, String groupName) {
}
}
Here we calculate the permission string using the classname and the method
name. E.g. org.wso2.carbon.identity.mgt.UserMgtService.addUser. These
service permission can be checked with an microservice interceptor.
There are pros and cons of both of these methods. We need to discuss and
come to a conclusion soon.
Also we need to figure out how to declare resource permissions.
Thanks,
Sameera.
--
Sameera Jayasoma,
Software Architect,
WSO2, Inc. (http://wso2.com)
email: [email protected]
blog: http://blog.sameera.org
twitter: https://twitter.com/sameerajayasoma
flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
Mobile: 0094776364456
Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
