h2. Overview
This project is based on my experience with a number of home built solutions for RBAC and standard J2EE solutions. However, it adds instance based security or context based security that adds dynamic access control. The role based security consists of following components:
Though, domain is strictly not part of role based security but RBAC provides segregation of security policies by domains, where a domain can represent a security realm or an application.
The subject represents users who are defined in an application.
A role represents job title or function. A subject or user belongs to one or more roles. One of key feature of PlexRBAC is that roles support inheritance where a role can have one or more roles. This helps define security policies that follow “don’t repeat yourself” or DRY.
A permission consists of two sub parts: operation and target, where operation is a “verb” that describes action and target represents “object” that is acted upon. All permissions are assigned to roles. In PlexRBAC, permissions also contains an expression which is evaluated to check dynamic security. PlexRBAC allows Javascript based expressions and provides access to runtime request parameters. Finally, PlexRBAC offers regular expressions for both operations and target, so you can define operations like “(read|write|create|delete)” or “read*”, etc.
Following diagram shows the relationship between these components:
PlexRBAC consists of following layers
h3. Business Domain Layer
This layer defines core classes that are part of the RBAC based security domain such as:
- Domain – – The domain allows you to support multiple applications or realms.
- Subject – The subject represents users who are defined in an application.
- Role – A role represents job title or function.
- Permission – A permission is composed of operation, target and an expression that is used for dynamic or instance based security.
- SecurityError – Upon a permission failure, you can choose to store them in the database using SecurityError.
This layer is responsible for accessing or storing above objects in the database. PlexRBAC uses Berkley DB for persistence and each domain is stored as a separate database, which allows you to segregate permissions and roles for distinct domains. Following are list of repositories supported by PlexRBAC:
- DomainRepository – provides database access for Domains.
- PermissionRepository – provides database access for Permissions.
- SubjectRepository – provides database access for Subjects.
- SecurityErrorRepository – provides database access for SecurityErrors.
- RoleRepository – provides database access for Roles.
- SecurityMappingRepository – provides APIs to map permissions with roles and to map subject with roles.
- RepositoryFactory – provides factory methods to create above repositories.
This class defines PermissionManager for authorizing permissions.
This layer proivdes evaluation engine for instance based security.
This layer defines REST services such as:
- DomainService – this service provides REST APIs for accessing Domains.
- PermissionService – this service provides REST APIs for accessing Permissions.
- SubjectService – this service provides REST APIs for accessing Subjects.
- RoleService – this service provides REST APIs for accessing Roles.
- AuthenticationService – this service provides REST APIs for authenticating users.
- AuthorizationService – this service provides REST APIs for authorizing permissions.
- RolePermissionService – this service provides REST APIs for mapping permissions with roles.
- SubjectRolesService – this service provides REST APIs for mapping subjects with roles.
This layer defines JMX helper classes for managing services and configuration remotely.
This layer provides caching security permissions to improve performance.
This layer provides performance measurement classes such as Timing class to measure method invocation benchmarks.
This layer provides helper classes.
This layer provides filters for enforcing authentication and authorization when accessing REST APIs.
Let’s start with a banking example where a bank-object can be account, general-ledger-report or ledger-posting-rules and account is further grouped into customer account or loan account. Further, Let’s assume there are five roles: Teller, Customer-Service-Representative (CSR), Account, AccountingManager and LoanOfficer, where
- A teller can modify customer deposit accounts — but only if customer and teller live in same region
- A customer service representative can create or delete customer deposit accounts — but only if customer and teller live in same region
- An accountant can create general ledger reports — but only if year is h2. current year
- An accounting manager can modify ledger-posting rules — but only if year is h2. current year
- A loan officer can create and modify loan accounts – but only if account balance is < 10000
In addition, following classes will be used to add domain specific security:
1
2 class User { 3 4 private String id; 5 private String region; 6 7 User() { 8 } 9 10 public User(String id, String region) { 11 this.id = id; 12 this.region = region; 13 } 14 15 public void setRegion(String region) { 16 this.region = region; 17 } 18 19 public String getRegion() { 20 return region; 21 } 22 23 public void setId(String id) { 24 this.id = id; 25 } 26 27 public String getId() { 28 return id; 29 } 30 } 31 32 class Customer extends User { 33 34 public Customer(String id, String region) { 35 super(id, region); 36 } 37 } 38 39 class Employee extends User { 40 41 public Employee(String id, String region) { 42 super(id, region); 43 } 44 } 45 46 class Account { 47 48 private String id; 49 private double balance; 50 51 Account() { 52 } 53 54 public Account(String id, double balance) { 55 this.id = id; 56 this.balance = balance; 57 } 58 59 /** 60 * return the id 61 */ 62 public String getId() { 63 return id; 64 } 65 66 /** 67 * @param id 68 * the id to set 69 */ 70 public void setId(String id) { 71 this.id = id; 72 } 73 74 public void setBalance(double balance) { 75 this.balance = balance; 76 } 77 78 public double getBalance() { 79 return balance; 80 } 81 } 82 83
Let’s create handle to repository-factory as:
1
2 private static final String TEST_DB_DIR = “test_db_dir_perms”; 3 RepositoryFactory repositoryFactory = new RepositoryFactoryImpl(TEST_DB_DIR);
And instance of permission manager as:
1 PermissionManager permissionManager = new PermissionManagerImpl(repositoryFactory, 2 new JavascriptEvaluator());
Now, let’s create a domain for banking:
1 private static final String BANKING = “banking”; 2 repositoryFactory.getDomainRepository().save(new Domain(BANKING, ""));
Next step is to create users for the domain or application so let’s define accounts for tom, cassy, ali, mike and larry, i.e.,
1 final SubjectRepository subjectRepo = repositoryFactory 2 .getSubjectRepository(BANKING); 3 Subject tom = subjectRepo.save(new Subject(“tom”, “pass”)); 4 Subject cassy = subjectRepo.save(new Subject(“cassy”, “pass”)); 5 Subject ali = subjectRepo.save(new Subject(“ali”, “pass”)); 6 Subject mike = subjectRepo.save(new Subject(“mike”, “pass”)); 7 Subject larry = subjectRepo.save(new Subject(“larry”, “pass”));
Now, we will create roles for Teller, CSR, Accountant, AccountManager and LoanManager:
1 final RoleRepository roleRepo = repositoryFactory 2 .getRoleRepository(BANKING); 3 Role employee = roleRepo.save(new Role(“Employee”)); 4 Role teller = roleRepo.save(new Role(“Teller”, employee)); 5 Role csr = roleRepo.save(new Role(“CSR”, teller)); 6 Role accountant = roleRepo.save(new Role(“Accountant”, employee)); 7 Role accountantMgr = roleRepo.save(new Role(“AccountingManager”, 8 accountant)); 9 Role loanOfficer = roleRepo 10 .save(new Role(“LoanOfficer”, accountantMgr));
We can then create new permissions and save them in the database as follows:
1 final PermissionRepository permRepo = repositoryFactory 2 .getPermissionRepository(BANKING); 3 Permission cdDeposit = permRepo.save(new Permission(“(create|delete)”, 4 “DepositAccount”, 5 “employee.getRegion().equals(customer.getRegion())”)); // 1 6 Permission ruDeposit = permRepo.save(new Permission(“(read|modify)”, 7 “DepositAccount”, 8 “employee.getRegion().equals(customer.getRegion())”)); // 2 9 Permission cdLoan = permRepo.save(new Permission(“(create|delete)”, 10 “LoanAccount”, “account.getBalance() < 10000”)); // 3 11 Permission ruLoan = permRepo.save(new Permission(“(read|modify)”, 12 “LoanAccount”, “account.getBalance() < 10000”)); // 4 13 14 Permission rdLedger = permRepo.save(new Permission(“(read|create)”, 15 “GeneralLedger”, “year h2. new Date().getFullYear()”)); // 5 16 17 Permission rGlpr = permRepo 18 .save(new Permission(“read”, “GeneralLedgerPostingRules”, 19 “year h2. new Date().getFullYear()”)); // 6 20 21 Permission cmdGlpr = permRepo.save(new Permission( 22 “(create|modify|delete)”, “GeneralLedgerPostingRules”, 23 “year h2. new Date().getFullYear()”)); // 7
Now we will map subjects to roles as follows:
1 final SecurityMappingRepository smr = repositoryFactory 2 .getSecurityMappingRepository(BANKING); 3 4 // Mapping Users to Roles 5 smr.addRolesToSubject(tom, teller); 6 smr.addRolesToSubject(cassy, csr); 7 smr.addRolesToSubject(ali, accountant); 8 smr.addRolesToSubject(mike, accountantMgr); 9 smr.addRolesToSubject(larry, loanOfficer);
Then we will map permissions to roles as follows:
1 smr.addPermissionsToRole(teller, ruDeposit);
2 smr.addPermissionsToRole(csr, cdDeposit); 3 smr.addPermissionsToRole(accountant, rdLedger); 4 smr.addPermissionsToRole(accountant, ruLoan); 5 smr.addPermissionsToRole(accountantMgr, cdLoan); 6 smr.addPermissionsToRole(accountantMgr, rGlpr); 7 smr.addPermissionsToRole(loanOfficer, cmdGlpr);
Now the fun part of authorization, let’s check if user “tom” can view deposit-accounts, e.g.
1 public static Map<String, Object> toMap(final Object… keyValues) { 2 Map<String, Object> map = new HashMap<String, Object>(); 3 for (int i = 0; i < keyValues.length – 1; i += 2) { 4 map.put(keyValues[i].toString(), keyValues[i + 1]); 5 } 6 return map; 7 } 8 @Test 9 public void testReadDepositByTeller() { 10 initDatabase(); 11 permissionManager.check(new PermissionRequest(BANKING, “tom”, “read”, 12 “DepositAccount”, toMap(“employee”, new Employee(“tom”, 13 “west”), “customer”, new Customer(“zak”, “west”)))); 14 } 15 16
Note that above test method builds a PermissionRequest that encapsulates domain, subject, operation, target and context and then calls check method of SecurityManager, which throws SecurityException if permission fails.
Then we check if tom, the teller can delete deposit-account, e.g.
1 @Test(expected = SecurityException.class) 2 public void testDeleteByTeller() { 3 initDatabase(); 4 permissionManager.check(new PermissionRequest(BANKING, “tom”, “delete”, 5 “DepositAccount”, toMap(“employee”, new Employee(“tom”, 6 “west”), “customer”, new Customer(“zak”, “west”)))); 7 }
Which would throw security exception.
Now let’s check if cassy, the CSR can delete deposit-account, e.g.
1 @Test
2 public void testDeleteByCsr() { 3 initDatabase(); 4 permissionManager.check(new PermissionRequest(BANKING, “cassy”, 5 “delete”, “DepositAccount”, toMap(“employee”, 6 new Employee(“cassy”, “west”), “customer”, 7 new Customer(“zak”, “west”))));
Which works as CSR have permissions for deleting deposit-account. Now, let’s check if ali, the accountant can view general-ledger, e.g.
1 @Test
2 public void testReadLedgerByAccountant() { 3 initDatabase(); 4 permissionManager.check(new PermissionRequest(BANKING, “ali”, “read”, 5 “GeneralLedger”, toMap(“year”, 2010, “account”, 6 new Account(“zak”, 500)))); 7 }
Which works as expected. Next we check if ali can delete general-ledger:
1 @Test(expected = SecurityException.class) 2 public void testDeleteLedgerByAccountant() { 3 initDatabase(); 4 permissionManager.check(new PermissionRequest(BANKING, “ali”, “delete”, 5 “GeneralLedger”, toMap(“year”, 2010, “account”, 6 new Account(“zak”, 500)))); 7 }
Which would fail as only account-manager can delete. Next we check if mike, the account-manager can create general-ledger, e.g.
1 @Test
2 public void testCreateLedgerByAccountantManager() { 3 initDatabase(); 4 permissionManager.check(new PermissionRequest(BANKING, “mike”, 5 “create”, “GeneralLedger”, toMap(“year”, 2010, 6 “account”, new Account(“zak”, 500)))); 7 } 8
Which works as expected. Now we check if mike can create posting-rules of general-ledger, e.g.
1 @Test(expected = SecurityException.class) 2 public void testPostLedgingRulesByAccountantManager() { 3 initDatabase(); 4 permissionManager.check(new PermissionRequest(BANKING, “mike”, 5 “create”, “GeneralLedgerPostingRules”, toMap(“year”, 6 2010, “account”, new Account(“zak”, 500)))); 7 } 8
Which fails authorization. Then we check if larry, the loan officer can create posting-rules of general-ledger, e.g.
1 @Test
2 public void testPostLedgingRulesByLoanManager() { 3 initDatabase(); 4 permissionManager.check(new PermissionRequest(BANKING, “larry”, 5 “create”, “GeneralLedgerPostingRules”, toMap(“year”, 6 2010, “account”, new Account(“zak”, 500)))); 7 } 8
Which works as expected. Now, let’s check the same permission but with different year, e.g.
1 @Test(expected = SecurityException.class) 2 public void testPostLedgingRulesByLoanManagerWithExceededAmount() { 3 initDatabase(); 4 permissionManager.check(new PermissionRequest(BANKING, “larry”, 5 “create”, “GeneralLedgerPostingRules”, IDUtils.toMap(“year”, 6 2011))); 7 } 8
Which fails as year doesn’t match.
PlexRBAC depends on Java 1.6+ and Maven 2.0+. You can download the project using git:
- git clone git@github.com:bhatti/PlexRBAC.git
Type mvn command to build, e.g.
mvn
Building REST services, deploying them into Jetty and starting Jetty
Then you can start the REST based web service within Jetty by typing:
mvn jetty:run-war
mvn jetty:run-war
The service will listen on port 8080 and you can test it with curl.
Though, PlexRBAC is not designed for authentication but it provides Basic authentication and all administration APIs are protected with the authentication. By default, it uses an account “super_admin” with password “changeme”, which you can modify with configurations.
REST APIs
Following are APIs defined in PlexRBAC:
Domains
- GET /api/security/domains – returns list of all domains in JSON format.
- GET /api/security/domains/{domain-id} – returns details of given domain in JSON format.
- PUT /api/security/domains/{domain-id} with body of domain details in JSON format.
- DELETE /api/security/domains – deletes all domains.
- DELETE /api/security/domains/{domain-id} – deletes domain identified by domain-id.
Subjects
- GET /api/security/subjects/{domain-id} – returns list of all subjects in domain identified by domain-id in JSON format.
- GET /api/security/subjects/{domain-id}/{id} – returns details of given subject identified by id in given domain.
- PUT /api/security/subjects/{domain-id}/{id} with body of subject details in JSON format.
- DELETE /api/security/subjects/{domain-id} – deletes all subjects in given domain.
- DELETE /api/security/subjects/{domain-id}/{id} – deletes subject identified by id.
Roles
- GET /api/security/roles/{domain-id} – returns list of all roles in domain identified by domain-id in JSON format.
- GET /api/security/roles/{domain-id}/{id} – returns details of given role identified by id in given domain.
- PUT /api/security/roles/{domain-id}/{id} with body of role details in JSON format.
- DELETE /api/security/roles/{domain-id} – deletes all roles in given domain.
- DELETE /api/security/roles/{domain-id}/{id} – deletes role identified by id.
Permissions
- GET /api/security/permissions/{domain-id} – returns list of all permissions in domain identified by domain-id in JSON format.
- GET /api/security/permissions/{domain-id}/{id} – returns details of given permission identified by id in given domain.
- POST /api/security/permissions/{domain-id} with body of permission details in JSON format. Note that this API uses POST instead of PUT as the id will be assigned by the server.
- DELETE /api/security/permissions/{domain-id} – deletes all permissions in given domain.
- DELETE /api/security/permissions/{domain-id}/{id} – deletes permission identified by id.
Mapping of Roles and Permissions
- PUT /api/security/role_perms/{domain-id}/{role-id} – adds permissions identified by permissionIds that stores list of permission-ids in JSON format. Note that permissionIds is passed as a form parameter.
- DELETE /api/security/role_perms/{domain-id}/{role-id} – removes permissions identified by permissionIds that stores list of permission-ids in JSON format. Note that permissionIds is passed as a form parameter.
Mapping of Subjects and Roles
- PUT /api/security/subject_roles/{domain-id}/{subject-id} – adds roles identified by rolenames that stores list of role-ids in JSON format. Note that rolenames is passed as a form parameter.
- DELETE /api/security/subject_roles/{domain-id}/{subject-id} – removes roles identified by rolenames that stores list of role-ids in JSON format. Note that rolenames is passed as a form parameter.
Authorization
- GET /api/security/authorize/{domain-id} – with query parameter of operation and target.
Let’s start with a banking example where a bank-object can be account, general-ledger-report or ledger-posting-rules and account is further grouped into customer account or loan account, e.g.
Let’s assume there are five roles: Teller, Customer-Service-Representative (CSR), Account, AccountingManager and LoanOfficer, where
- A teller can modify customer deposit accounts.
- A customer service representative can create or delete customer deposit accounts.
- An accountant can create general ledger reports.
- An accounting manager can modify ledger-posting rules.
- A loan officer can create and modify loan accounts.
The first thing is to create a security domain for your application. As we are dealing with banking domain, let’s call our domain “banking”.
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/domains/banking” -d ‘{"id":"banking"}’
It will return response:
{"id":“banking”,“ownerSubjectNames”:"super_admin"}
The first thing to note that we are passing user and password using Basic authentication as all accesses to administration APIs require login. Now, you can find out available domains via
curl -v —user “super_admin:changeme” “http://localhost:8080/api/security/domains”
which would return something like:
[{"id":“banking”,“ownerSubjectNames”:"super_admin"},{"description":“default”,“id”:“default”,“ownerSubjectNames”:"super_admin"}]
Next step is to create users for the domain or application so let’s define accounts for tom, cassy, ali, mike and larry, i.e.,
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subjects/banking” -d ‘{"id":“tom”,“credentials”:"pass"}’
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subjects/banking” -d ‘{"id":“cassy”,“credentials”:"pass"}’
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subjects/banking” -d ‘{"id":“ali”,“credentials”:"pass"}’
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subjects/banking” -d ‘{"id":“mike”,“credentials”:"pass"}’
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subjects/banking” -d ‘{"id":“larry”,“credentials”:"pass"}’
Note that each user is identified by an id or username and credentials.
As I mentioned, a role represents job title or responsibilities and each role can have one or more parents. By default, PlexRBAC defines an “anonymous” role, which is used for users who are not logged in and all user-defined roles extend “anonymous” role.
First, we create a role for bank employee called “Employee”:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/roles/banking” -d ‘{"id":"Employee"}’
which returns
{"id":“Employee”,“parentIds”:[“anonymous”]}
As you can see the “Employee” role is created with parent of “anonymous”. Next, we create “Teller” role:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/roles/banking” -d ‘{"id":“Teller”,“parentIds”:[“Employee”]}’
which returns:
{"id":“Teller”,“parentIds”:[“Employee”]}
Then we create role for customer-service-representative called “CSR” that is extended by Teller e.g.
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/roles/banking” -d ‘{"id":“CSR”,“parentIds”:[“Teller”]}’
which returns:
{"id":“CSR”,“parentIds”:[“Teller”]}
Then we create role for “Accountant”:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/roles/banking” -d ‘{"id":“Accountant”,“parentIds”:[“Employee”]}’
which returns:
{"id":“Accountant”,“parentIds”:[“Employee”]}
Then we create role for “AccountingManager”, which is extended by “Accountant”, e.g.
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/roles/banking” -d ‘{"id":“AccountingManager”,“parentIds”:[“Accountant”]}’
which returns:
{"id":“AccountingManager”,“parentIds”:[“Accountant”]}
Finally, we create role for “LoanOfficer”, e.g.
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/roles/banking” -d ‘{"id":“LoanOfficer”,“parentIds”:[“Employee”]}’
which returns:
{"id":“LoanOfficer”,“parentIds”:[“Employee”]}
As described above, a permission is composed of operation, target and expression, where an operation and target can be any regular expression and expression can be any Javascript expression. However following permissions don’t define any expressions for simplicity. First, we create a permission to create or delete deposit-account, e.g.
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X POST “http://localhost:8080/api/security/permissions/banking” -d ‘{"operation":“(create|delete)”,“target”:“DepositAccount”,“expression”:""}’
which returns:
{"expression":"",“id”:“1”,“operation”:“(create|delete)”,“target”:"DepositAccount"}
Each permission is automatically assigned a unique numeric id. Next, we create permission to read or modify deposit-account, e.g.
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X POST “http://localhost:8080/api/security/permissions/banking” -d ‘{"operation":“(read|modify)”,“target”:“DepositAccount”,“expression”:""}’
which returns:
{"expression":"",“id”:“2”,“operation”:“(read|modify)”,“target”:"DepositAccount"}
Then, we create a permission to create or delete loan-account
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X POST “http://localhost:8080/api/security/permissions/banking” -d ‘{"operation":“(create|delete)”,“target”:“LoanAccount”,“expression”:""}’
which returns:
{"expression":"",“id”:“3”,“operation”:“(create|delete)”,“target”:"LoanAccount"}
Then we create a permission to read or modify loan-account, e.g.
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X POST “http://localhost:8080/api/security/permissions/banking” -d ‘{"operation":“(read|modify)”,“target”:“LoanAccount”,“expression”:""}’
which returns:
{"expression":"",“id”:“4”,“operation”:“(read|modify)”,“target”:"LoanAccount"}
Then we create role to view and create general-ledger, e.g.
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X POST “http://localhost:8080/api/security/permissions/banking” -d ‘{"operation":“(read|create)”,“target”:“GeneralLedger”,“expression”:""}’
which returns:
{"expression":"",“id”:“5”,“operation”:“(read|create)”,“target”:"GeneralLedger"}
Finally, we create permission for modifying posting rules of general-ledger, e.g.
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X POST “http://localhost:8080/api/security/permissions/banking” -d ‘{"operation":“(read|create|modify|delete)”,“target”:“GeneralLedgerPostingRules”,“expression”:""}’
which returns:
{"expression":"",“id”:“6”,“operation”:“(read|create|modify|delete)”,“target”:"GeneralLedgerPostingRules"}
Next task is to map permissions to roles. First we assign permission to view or modify customer deposit accounts:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/role_perms/banking/Teller” -d ‘permissionIds=[“2”]’
which returns all permission-ids for given role, e.g.
[“2”]
Then we assign permission to view, create, modify or delete customer deposit accounts:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/role_perms/banking/CSR” -d ‘permissionIds=[“1”]’
Then we assign permissions to create general ledger to accountant:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/role_perms/banking/Accountant” -d ‘permissionIds=[“5”]’
Then we assign permission to modify ledger-posting rules to accounting manager:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/role_perms/banking/AccountingManager” -d ‘permissionIds=[“6”]’
A role is associated with one or more permissions and each user is assigned one or more role. First, we assign subject “tom” to Teller role:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subject_roles/banking/tom” -d ‘rolenames=[“Teller”]’
which returns list of all roles for given subject or user, e.g.
[“Teller”]
Then we assign subject “cassy” to CSR role:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subject_roles/banking/cassy” -d ‘rolenames=[“CSR”]’
Next we assign subject “ali” to role of Accountant:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subject_roles/banking/ali” -d ‘rolenames=[“Accountant”]’
Then we assign role AccountingManager to “mike”:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subject_roles/banking/mike” -d ‘rolenames=[“AccountingManager”]’
Finally we assign subject “larry” to LoanOfficer role:
curl -H “Content-Type: application/json” —user “default:super_admin:changeme” -X PUT “http://localhost:8080/api/security/subject_roles/banking/larry” -d ‘rolenames=[“LoanOfficer”]’
Now we are ready to validate authorization based on above security policies. For example, let’s check if user “tom” can view deposit-accounts, e.g.
curl -v —user “banking:tom:pass” “http://localhost:8080/api/authorize/banking?operation=read&target=DepositAccount”
On successful authorization, the API returns 200 http responose-code and on failure it returns 401 http response-code, e.g.
< HTTP/1.1 200 OK
Then we check if tom, the teller can delete deposit-account, e.g.
curl -v —user “banking:tom:pass” “http://localhost:8080/api/authorize/banking?operation=delete&target=DepositAccount”
which returns http-response-code 401, e.g.
< HTTP/1.1 401 Unauthorized
Then we create if cassy, the CSR can delete deposit-account, e.g.
curl -v —user “banking:cassy:pass” “http://localhost:8080/api/authorize/banking?operation=delete&target=DepositAccount”
which returns:
< HTTP/1.1 200 OK
Then we check if ali, the accountant can view general-ledger, e.g.
curl -v —user “banking:ali:pass” “http://localhost:8080/api/authorize/banking?operation=read&target=GeneralLedger”
which returns:
< HTTP/1.1 200 OK
Next we check if mike, the accounting-manager can create general-ledger, e.g.
curl -v —user “banking:mike:pass” “http://localhost:8080/api/authorize/banking?operation=create&target=GeneralLedger”
which returns:
< HTTP/1.1 200 OK
Then we check if larry, the loan officer can create posting-rules of general-ledger, e.g.
curl -v —user “banking:mike:pass” “http://localhost:8080/api/authorize/banking?operation=create&target=GeneralLedgerPostingRules”
which returns:
< HTTP/1.1 200 OK
Next, ali tries to create posting rules via
curl -v —user “banking:ali:pass” “http://localhost:8080/api/authorize/banking?operation=create&target=GeneralLedgerPostingRules”
which is denied:
< HTTP/1.1 401 Unauthorized
Let me know if you are interesteed in contributing this project or trying out in your application.
References
http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/Intro_role_based_access.htm
http://hissa.nist.gov/rbac/poole/ir5820/ir5820s31.htm
http://www.developer.com/article.php/10915_3841046_3/Real-World-REST-Using-Jersey-AJAX-and-JSON.htm
http://wikis.sun.com/display/Jersey/Overview+of+JAX-RS+1.0+Features
http://www.coresecuritypatterns.com/patterns.htm
http://cwiki.apache.org/confluence/display/SHIRO/Index
http://www.secs.oakland.edu/~kim2/papers/FASE04.pdf
// perl -pi -e ‘s/yy/xx/g’ // `find src/ -name “*.java”`