You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fortress@directory.apache.org by Chris Pike <cl...@psu.edu> on 2016/01/14 17:07:32 UTC
Fortress Constraints
We want to be able to store attributes/constraints in fortress so that we can do fine grained security checks. We would like to get thoughts/feedback on this proposal. Our goal is to store permission attributes and role constraints based on those attribute in fortress, but not necessarily have fortress make the decision. In our applications, we pull back the list of roles and permissions when the user logs in, not on every security check, so we would have the application interpret the constraints. That being said, here is the proposal...
1. Add a new ldap attribute type (ftPA) to store 0 to many attributes about a permission and other metadata about the attribute (required, valid values, etc...). It would be up to each application to define it's permissions and any attributes that are relevant to each permission. In this example, we have an account.withdraw permission that needs constraints for the account id and a withdraw limit for each user.
Permission: account.withdraw
- ftPA: AccountId?dataType=int&required=true&validValues=SELF,ANY,int&comparator=equals&default=SELF
- ftPA: WithdrawLimit?dataType=int&comparator=max
2. Role creation and permission assignment would stay the same.
3. When a user is assigned to a role that has a permission with a ftPA, we would allow adding of role constraints to the user-role assignment. In this example, we are changing ftRC so that it can specify a type of constraint (temporal or filter). There could be many "filter" ftRC entries if the ftPA were different. We may also want to add a "seq" to allow grouping ftRCs together.
User: chris
- ftRA: BANK_USER
- ftRC: BANK_USER$seq$0$type$temporal$role1$0$1000$0000$none$none$none$none$all
- ftRC: BANK_USER$seq$0type$filter$AccountId=12345&WithdrawLimit=500
4. When getting roles or session permissions for a user, the additional constraints would need to be returned.
{
"objName": "account",
"opName": "withdraw",
"constraints": [ "AccountId=12345&WithdrawLimit=500" ]
}
5. Once our application had the list of permissions and constraints, it would then do it's own checks, potentially something like...
@PermissionRequired("account.withdraw") //coarse grained check
public void withdraw(Account account, float amount){
Map map = new HashMap();
map.put("WithdrawLimit", amount);
map.put("AccountId", account.getId());
doesUserHavePermission("account.withdraw", map); //fine grained check
}
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
> On Feb 1, 2016, at 11:52 AM, Chris Pike <cl...@psu.edu> wrote:
>
> When running the load test for A, there doesn't seem to be a profile for loadtest-ftca.
>
Thanks for pointing this out. I sent the wrong command. Here is the corrected:
A. Fortress CheckAccess:
```
mvn -Ploadtest-fortress jmeter:jmeter
```
> On Feb 1, 2016, at 11:52 AM, Chris Pike <cl...@psu.edu> wrote:
>
> B and C run successfully, but JVM has problems exiting when they are done, is this normal behaviour?
>
> B. [info] summary + 3624 in 23s = 159.9/s Avg: 50 Min: 4 Max: 481 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0
> [info] summary + 6376 in 29.2s = 218.0/s Avg: 42 Min: 3 Max: 330 Err: 0 (0.00%) Active: 0 Started: 10 Finished: 10
> [info] summary = 10000 in 52s = 193.3/s Avg: 45 Min: 3 Max: 481 Err: 0 (0.00%)
>
> C. [info] summary = 500 in 8.3s = 60.4/s Avg: 10 Min: 2 Max: 104 Err: 0 (0.00%)
>
> Error after runs
>
> [info] The JVM should have exitted but did not.
> [info] The following non-daemon threads are still running (DestroyJavaVM is OK):
> ...
>
Yes, it needs fixing, but haven’t gotten around to it…. speaking of fixing… the section in the readme needs to explain the usage better. e.g. how to modify the # of threads, iterations, warmup time, etc...
Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Shawn,
When running the load test for A, there doesn't seem to be a profile for loadtest-ftca.
B and C run successfully, but JVM has problems exiting when they are done, is this normal behaviour?
B. [info] summary + 3624 in 23s = 159.9/s Avg: 50 Min: 4 Max: 481 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0
[info] summary + 6376 in 29.2s = 218.0/s Avg: 42 Min: 3 Max: 330 Err: 0 (0.00%) Active: 0 Started: 10 Finished: 10
[info] summary = 10000 in 52s = 193.3/s Avg: 45 Min: 3 Max: 481 Err: 0 (0.00%)
C. [info] summary = 500 in 8.3s = 60.4/s Avg: 10 Min: 2 Max: 104 Err: 0 (0.00%)
Error after runs
[info] The JVM should have exitted but did not.
[info] The following non-daemon threads are still running (DestroyJavaVM is OK):
...
~Chris
----- Original Message -----
From: "Chris Pike" <cl...@psu.edu>
To: fortress@directory.apache.org
Sent: Sunday, January 31, 2016 1:01:27 PM
Subject: Re: Fortress Constraints
Shawn,
1. You need to clone the repo, then checkout the branch you want, so
git clone https://github.com/PennState/directory-fortress-core-1.git
git checkout feature/addPermAttrAndUserRoleConstraints
2. The audit tests still fail in my environment, I'll look through your updated documentation, might be a problem with how I am installing openldap
3. Right now, addRoleConstraint is a two step process, but would be easy to do it as part of the "assignUser( UserRole uRole )" method as well
4. I'll work on running the performance tests.
Thanks for taking a look!
~Chris
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Sunday, January 31, 2016 12:45:55 PM
Subject: Re: Fortress Constraints
> On Jan 31, 2016, at 10:49 AM, Shawn McKinney <sm...@apache.org> wrote:
>
> Let’s get before & after performance impacts of these changes (once inserted into access mgr). There is a short section in the README of how to run the jmeter tests. I recommend tests A & B. We’ll definitely want same for sessionPermissions but I’ll need to add the test case. Let me know if you need help getting this running.
Added the perf test for sessionPerms:
2. The .jmx files located in [.src/test/jmeter](.src/test/jmeter) folder are used to control test settings for the following:
C. Fortress SessionPermissions:
[src/test/jmeter/ftSessionPerms.jmx](src/test/jmeter/ftSessionPerms.jmx)
3. From **FORTRESS_HOME** folder, enter the following command from a system prompt:
C. Fortress SessionPermissions:
```
mvn -Ploadtest-fortress-sessperms jmeter:jmeter
```
Shawn
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
> On Feb 9, 2016, at 2:02 PM, Chris Pike <cl...@psu.edu> wrote:
>
> Looks like I had some settings wrong in my slapd.conf, mainly I didn't have the maxsize set on the dbs. Down to 2 tests not passing. The "DelegatedMgrImplTest.testAddAdminUser" only fails on the first test run.
>
>
> Tests run: 113, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 209.148 sec <<< FAILURE! - in org.apache.directory.fortress.core.impl.FortressJUnitTest
> testAddAdminUser(org.apache.directory.fortress.core.impl.DelegatedMgrImplTest) Time elapsed: 0.216 sec <<< FAILURE!
> junit.framework.AssertionFailedError: org.apache.directory.fortress.core.impl.DelegatedMgrImplTestassignAdminUsers list size check
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at org.apache.directory.fortress.core.impl.DelegatedMgrImplTest.assignAdminUsers(DelegatedMgrImplTest.java:306)
> at org.apache.directory.fortress.core.impl.DelegatedMgrImplTest.testAddAdminUser(DelegatedMgrImplTest.java:174)
>
> testSearchAuthZs(org.apache.directory.fortress.core.impl.AuditMgrImplTest) Time elapsed: 2.706 sec <<< FAILURE!
> junit.framework.AssertionFailedError: org.apache.directory.fortress.core.impl.AuditMgrImplTestsearchAuthZs failedOnly=true, search authorizations user [jtsUser1], objName [TOB3_1], opName [TOP3_1], objId []
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at org.apache.directory.fortress.core.impl.AuditMgrImplTest.searchAuthZs(AuditMgrImplTest.java:288)
> at org.apache.directory.fortress.core.impl.AuditMgrImplTest.testSearchAuthZs(AuditMgrImplTest.java:253)
>
>
> Results :
>
> Failed tests:
> AuditMgrImplTest.testSearchAuthZs:253->searchAuthZs:288 org.apache.directory.fortress.core.impl.AuditMgrImplTestsearchAuthZs failedOnly=true, search authorizations user [jtsUser1], objName [TOB3_1], opName [TOP3_1], objId []
> DelegatedMgrImplTest.testAddAdminUser:174->assignAdminUsers:306 org.apache.directory.fortress.core.impl.DelegatedMgrImplTestassignAdminUsers list size check
>
> Tests run: 113, Failures: 2, Errors: 0, Skipped: 0
There were some problems with the ACL’s in the slapd.conf base config that may have caused you problems with the audits.
Try these (with appropriate substitutions on the uid/dn):
# Begin ACLS:
access to dn.base=""
by * read
# LDAPv3 Schema
access to dn.base="cn=subschema"
by * read
# Internal OpenLDAP config backend
access to dn.subtree="cn=config"
by * none
# Generic overall privilege
access to *
by anonymous auth
by dn.base="cn=Manager,dc=example,dc=com" manage
by * break
# Password should be protected, allow user to modify their own audit attributes.
access to attrs=userPassword,ftModifier,ftModCode,ftModId
by self =wx
by * none
# Self-readable password policy info
access to attrs=pwdFailureTime,pwdChangedTime,pwdGraceUseTime,pwdReset,pwdPolicySubentry
by self read
by * none
# Admin-only password policy info
access to attrs=pwdAccountLockedTime,pwdHistory
by * none
# Users may read their own attributes
access to attrs=@inetorgperson
by users read
by * none
access to attrs=@shadowAccount
by * none
access to * by users read
# *** end ACL's
Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Looks like I had some settings wrong in my slapd.conf, mainly I didn't have the maxsize set on the dbs. Down to 2 tests not passing. The "DelegatedMgrImplTest.testAddAdminUser" only fails on the first test run.
Tests run: 113, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 209.148 sec <<< FAILURE! - in org.apache.directory.fortress.core.impl.FortressJUnitTest
testAddAdminUser(org.apache.directory.fortress.core.impl.DelegatedMgrImplTest) Time elapsed: 0.216 sec <<< FAILURE!
junit.framework.AssertionFailedError: org.apache.directory.fortress.core.impl.DelegatedMgrImplTestassignAdminUsers list size check
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.TestCase.assertTrue(TestCase.java:192)
at org.apache.directory.fortress.core.impl.DelegatedMgrImplTest.assignAdminUsers(DelegatedMgrImplTest.java:306)
at org.apache.directory.fortress.core.impl.DelegatedMgrImplTest.testAddAdminUser(DelegatedMgrImplTest.java:174)
testSearchAuthZs(org.apache.directory.fortress.core.impl.AuditMgrImplTest) Time elapsed: 2.706 sec <<< FAILURE!
junit.framework.AssertionFailedError: org.apache.directory.fortress.core.impl.AuditMgrImplTestsearchAuthZs failedOnly=true, search authorizations user [jtsUser1], objName [TOB3_1], opName [TOP3_1], objId []
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.TestCase.assertTrue(TestCase.java:192)
at org.apache.directory.fortress.core.impl.AuditMgrImplTest.searchAuthZs(AuditMgrImplTest.java:288)
at org.apache.directory.fortress.core.impl.AuditMgrImplTest.testSearchAuthZs(AuditMgrImplTest.java:253)
Results :
Failed tests:
AuditMgrImplTest.testSearchAuthZs:253->searchAuthZs:288 org.apache.directory.fortress.core.impl.AuditMgrImplTestsearchAuthZs failedOnly=true, search authorizations user [jtsUser1], objName [TOB3_1], opName [TOP3_1], objId []
DelegatedMgrImplTest.testAddAdminUser:174->assignAdminUsers:306 org.apache.directory.fortress.core.impl.DelegatedMgrImplTestassignAdminUsers list size check
Tests run: 113, Failures: 2, Errors: 0, Skipped: 0
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Tuesday, February 9, 2016 12:23:45 PM
Subject: Re: Fortress Constraints
> On Feb 9, 2016, at 9:52 AM, Chris Pike <cl...@psu.edu> wrote:
>
>
> Looks like I'm running Symas OpenLDAP 2.4.42. There are lots of audit logs being populated in openldap, so probably not a configuration issue. I'm trying to step through one of the tests to see why it is failing...
>
> AuditManagerImplTest.testSearchBinds first searches for binds for "jtsUser1" and doesn't find any. Can you point me to where this bind audit entry should be getting populated?
Betting it’s a config issue. Look at your fortress.properties. Here are ones that must be set:
# Options are openldap or apacheds (default):
ldap.server.type=openldap
# Audit only works if ldap.server.type == openldap:
disable.audit=false
> On Feb 9, 2016, at 9:52 AM, Chris Pike <cl...@psu.edu> wrote:
>
>
> Also, where in the fortress API are the audit logs populated?
These audits are generated by OpenLDAP’s access log overlay. You can view that config inside the slapd.conf file:
logops bind writes compare
That directive instructs the overlay to store all ldap bind, updates and compares ops into the access log automatically. In order to get the audit for checkAccess to go we must make an extra call to server in the authZ flow to ldap compare. The first ldap call reads the permission record, the 2nd pushes the result of authZ into access log (compare).
But we only want to make the 2nd call to compare if the server is OpenLDAP, and it’s not otherwise disabled. (Doing call to another directory, e.g. apachds, would be wasteful)
You can view how the code works inside the permdao checkpermission method where there’s a call to addAuthZAudit method:
private void addAuthZAudit( LdapConnection ld, String permDn, String userDn, String attributeValue )
throws FinderException
{
// Audit can be turned off here with fortress config param: 'disable.audit=true'
if ( GlobalIds.IS_OPENLDAP && ! GlobalIds.IS_AUDIT_DISABLED )
{
try
{
// The compare method uses OpenLDAP's Proxy Authorization Control to assert identity of end user onto connection:
// LDAP Operation #2: Compare:
compareNode( ld, permDn, userDn, new DefaultAttribute( GlobalIds.POP_NAME, attributeValue ) );
}
catch ( UnsupportedEncodingException ee )
{
String error = "addAuthZAudit caught UnsupportedEncodingException=" + ee.getMessage();
throw new FinderException( GlobalErrIds.PERM_COMPARE_OP_FAILED, error, ee );
}
catch ( LdapException e )
{
if ( !( e instanceof LdapNoSuchObjectException ) )
{
String error = "addAuthZAudit caught LdapException=" + e.getMessage();
throw new FinderException( GlobalErrIds.PERM_COMPARE_OP_FAILED, error, e );
}
}
}
}
The check above, verifies that audit is enabled, before doing the ldapcompare.
Shawn
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
> On Feb 9, 2016, at 9:52 AM, Chris Pike <cl...@psu.edu> wrote:
>
>
> Looks like I'm running Symas OpenLDAP 2.4.42. There are lots of audit logs being populated in openldap, so probably not a configuration issue. I'm trying to step through one of the tests to see why it is failing...
>
> AuditManagerImplTest.testSearchBinds first searches for binds for "jtsUser1" and doesn't find any. Can you point me to where this bind audit entry should be getting populated?
Betting it’s a config issue. Look at your fortress.properties. Here are ones that must be set:
# Options are openldap or apacheds (default):
ldap.server.type=openldap
# Audit only works if ldap.server.type == openldap:
disable.audit=false
> On Feb 9, 2016, at 9:52 AM, Chris Pike <cl...@psu.edu> wrote:
>
>
> Also, where in the fortress API are the audit logs populated?
These audits are generated by OpenLDAP’s access log overlay. You can view that config inside the slapd.conf file:
logops bind writes compare
That directive instructs the overlay to store all ldap bind, updates and compares ops into the access log automatically. In order to get the audit for checkAccess to go we must make an extra call to server in the authZ flow to ldap compare. The first ldap call reads the permission record, the 2nd pushes the result of authZ into access log (compare).
But we only want to make the 2nd call to compare if the server is OpenLDAP, and it’s not otherwise disabled. (Doing call to another directory, e.g. apachds, would be wasteful)
You can view how the code works inside the permdao checkpermission method where there’s a call to addAuthZAudit method:
private void addAuthZAudit( LdapConnection ld, String permDn, String userDn, String attributeValue )
throws FinderException
{
// Audit can be turned off here with fortress config param: 'disable.audit=true'
if ( GlobalIds.IS_OPENLDAP && ! GlobalIds.IS_AUDIT_DISABLED )
{
try
{
// The compare method uses OpenLDAP's Proxy Authorization Control to assert identity of end user onto connection:
// LDAP Operation #2: Compare:
compareNode( ld, permDn, userDn, new DefaultAttribute( GlobalIds.POP_NAME, attributeValue ) );
}
catch ( UnsupportedEncodingException ee )
{
String error = "addAuthZAudit caught UnsupportedEncodingException=" + ee.getMessage();
throw new FinderException( GlobalErrIds.PERM_COMPARE_OP_FAILED, error, ee );
}
catch ( LdapException e )
{
if ( !( e instanceof LdapNoSuchObjectException ) )
{
String error = "addAuthZAudit caught LdapException=" + e.getMessage();
throw new FinderException( GlobalErrIds.PERM_COMPARE_OP_FAILED, error, e );
}
}
}
}
The check above, verifies that audit is enabled, before doing the ldapcompare.
Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Shawn,
Looks like I'm running Symas OpenLDAP 2.4.42. There are lots of audit logs being populated in openldap, so probably not a configuration issue. I'm trying to step through one of the tests to see why it is failing...
AuditManagerImplTest.testSearchBinds first searches for binds for "jtsUser1" and doesn't find any. Can you point me to where this bind audit entry should be getting populated?
Also, where in the fortress API are the audit logs populated?
Thanks,
~Chris
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Monday, February 1, 2016 1:12:02 PM
Subject: Re: Fortress Constraints
> On Jan 31, 2016, at 12:01 PM, Chris Pike <cl...@psu.edu> wrote:
>
>
> 1. You need to clone the repo, then checkout the branch you want, so
>
> git clone https://github.com/PennState/directory-fortress-core-1.git
> git checkout feature/addPermAttrAndUserRoleConstraints
Ah yes this works perfectly, thanks.
>
> On Jan 31, 2016, at 12:01 PM, Chris Pike <cl...@psu.edu> wrote:
>
> 2. The audit tests still fail in my environment, I'll look through your updated documentation, might be a problem with how I am installing openldap
What version of OpenLDAP are you using? There are (soon to be released) Symas OpenLDAP install packages I can share. Here are the most recent setup instructions:
https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-SLAPD.md
Shawn
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
> On Jan 31, 2016, at 12:01 PM, Chris Pike <cl...@psu.edu> wrote:
>
>
> 1. You need to clone the repo, then checkout the branch you want, so
>
> git clone https://github.com/PennState/directory-fortress-core-1.git
> git checkout feature/addPermAttrAndUserRoleConstraints
Ah yes this works perfectly, thanks.
>
> On Jan 31, 2016, at 12:01 PM, Chris Pike <cl...@psu.edu> wrote:
>
> 2. The audit tests still fail in my environment, I'll look through your updated documentation, might be a problem with how I am installing openldap
What version of OpenLDAP are you using? There are (soon to be released) Symas OpenLDAP install packages I can share. Here are the most recent setup instructions:
https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-SLAPD.md
Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Shawn,
1. You need to clone the repo, then checkout the branch you want, so
git clone https://github.com/PennState/directory-fortress-core-1.git
git checkout feature/addPermAttrAndUserRoleConstraints
2. The audit tests still fail in my environment, I'll look through your updated documentation, might be a problem with how I am installing openldap
3. Right now, addRoleConstraint is a two step process, but would be easy to do it as part of the "assignUser( UserRole uRole )" method as well
4. I'll work on running the performance tests.
Thanks for taking a look!
~Chris
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Sunday, January 31, 2016 12:45:55 PM
Subject: Re: Fortress Constraints
> On Jan 31, 2016, at 10:49 AM, Shawn McKinney <sm...@apache.org> wrote:
>
> Let’s get before & after performance impacts of these changes (once inserted into access mgr). There is a short section in the README of how to run the jmeter tests. I recommend tests A & B. We’ll definitely want same for sessionPermissions but I’ll need to add the test case. Let me know if you need help getting this running.
Added the perf test for sessionPerms:
2. The .jmx files located in [.src/test/jmeter](.src/test/jmeter) folder are used to control test settings for the following:
C. Fortress SessionPermissions:
[src/test/jmeter/ftSessionPerms.jmx](src/test/jmeter/ftSessionPerms.jmx)
3. From **FORTRESS_HOME** folder, enter the following command from a system prompt:
C. Fortress SessionPermissions:
```
mvn -Ploadtest-fortress-sessperms jmeter:jmeter
```
Shawn
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
> On Jan 31, 2016, at 10:49 AM, Shawn McKinney <sm...@apache.org> wrote:
>
> Let’s get before & after performance impacts of these changes (once inserted into access mgr). There is a short section in the README of how to run the jmeter tests. I recommend tests A & B. We’ll definitely want same for sessionPermissions but I’ll need to add the test case. Let me know if you need help getting this running.
Added the perf test for sessionPerms:
2. The .jmx files located in [.src/test/jmeter](.src/test/jmeter) folder are used to control test settings for the following:
C. Fortress SessionPermissions:
[src/test/jmeter/ftSessionPerms.jmx](src/test/jmeter/ftSessionPerms.jmx)
3. From **FORTRESS_HOME** folder, enter the following command from a system prompt:
C. Fortress SessionPermissions:
```
mvn -Ploadtest-fortress-sessperms jmeter:jmeter
```
Shawn
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
> On Jan 30, 2016, at 9:20 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Here are the new methods I've added to the manager. I added documentation for each (https://github.com/PennState/directory-fortress-core-1/tree/feature/addPermAttrAndUserRoleConstraints).
Chris, I downloaded a tarball using this link: https://github.com/PennState/directory-fortress-core-1/tree/feature/addPermAttrAndUserRoleConstraints. But how do I pull a local copy of this tree using the ‘git clone’ command? I wasn’t able to do it. Not a big deal, but can’t synch as easily, using 'git pull’.
> On Jan 30, 2016, at 9:20 AM, Chris Pike <cl...@psu.edu> wrote:
>
> I started adding new unit tests, but they are not complete yet and I have some validation checks to add, but basic functionality is working.
>
Good. Can you run the full unit tests in your local env yet, i.e. are tests still failing?
> On Jan 30, 2016, at 9:20 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Additionally, reading permissions will populate the attributeSetName (just name, does not load ftAttributeSet object) and reading roles will populate the roleConstraints (from ftRCs).
Code looks good. When does the addRoleConstraint method get called? Will assigning a role to a user now be a two-step process?
> On Jan 30, 2016, at 9:20 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Let me know if you have any issue or concerns.
Let’s get before & after performance impacts of these changes (once inserted into access mgr). There is a short section in the README of how to run the jmeter tests. I recommend tests A & B. We’ll definitely want same for sessionPermissions but I’ll need to add the test case. Let me know if you need help getting this running.
___________________________________________________________________________________
## SECTION 14. Instructions to performance test
This section describes the Apache Fortress jmeter test programs.
1. Load the security policy and users required by the jmeter test routines:
```
mvn install -Dload.file=./ldap/setup/LoadTestUsers.xml
```
2. The .jmx files located in [.src/test/jmeter](.src/test/jmeter) folder are used to control test settings for the following:
A. Fortress CheckAccess:
[src/test/jmeter/ftCheckAccess.jmx](src/test/jmeter/ftCheckAccess.jmx)
B. Fortress CreateSession:
[src/test/jmeter/ftCreateSession.jmx](src/test/jmeter/ftCreateSession.jmx)
3. From **FORTRESS_HOME** folder, enter the following command from a system prompt:
A. Fortress CheckAccess:
```
mvn -Ploadtest-ftca jmeter:jmeter
```
B. Fortress CreateSession:
```
mvn -Ploadtest-fortress-createsess
```
Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Shwan,
Here are the new methods I've added to the manager. I added documentation for each (https://github.com/PennState/directory-fortress-core-1/tree/feature/addPermAttrAndUserRoleConstraints). I started adding new unit tests, but they are not complete yet and I have some validation checks to add, but basic functionality is working.
AdminManager
- RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException;
- void removeRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException;
- PermissionAttributeSet addPermissionAttributeSet( PermissionAttributeSet permAttributeSet ) throws SecurityException;
- void deletePermissionAttributeSet( PermissionAttributeSet permAttributeSet ) throws SecurityException;
- PermissionAttribute addPermissionAttributeToSet( PermissionAttribute permAttribute, String attributeSetName ) throws SecurityException;
- void removePermissionAttributeFromSet( PermissionAttribute permAttribute, String attributeSetName ) throws SecurityException;
ReviewManager
- PermissionAttributeSet readPermAttributeSet( PermissionAttributeSet permAttributeSet ) throws SecurityException;
Additionally, reading permissions will populate the attributeSetName (just name, does not load ftAttributeSet object) and reading roles will populate the roleConstraints (from ftRCs). Let me know if you have any issue or concerns.
Thanks!
~Chris
----- Original Message -----
From: "Chris Pike" <cl...@psu.edu>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 2:49:55 PM
Subject: Re: Fortress Constraints
Maybe, there are many places where we still need to add ability to down select what data is returned, which ties into the ARBAC discussions.
That method will be called when managing user / role assignments, so what PermissionAttributes get returned might be driven by the users current ARBAC role.
----- Original Message -----
From: "SHAWN E SMITH" <se...@psu.edu>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 12:11:34 PM
Subject: Re: Fortress Constraints
Would it be beneficial to indicate application in the permission attribute?
We've talked about roles being cross application, can we do something like
Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance, String application) throws SecurityException;
and for the non-qualified (as below)
Map<String, Set<PermissionAttribute>> rolePermissionAttributes( Role role, boolean noInhertiance, String application) throws SecurityException;
where the map key is application the attribute(s) applies to.
I think there are administrative reasons why we would want to see cross app ftPA's, but as a single client app it would be nice to be able to just grab what's relevant to me.
Just a thought....
"The programmer … works only slightly removed from pure thought-stuff.
He builds his castles in the air, from air, creating by exertion of the imagination."
— Fred Brooks
Shawn Smith
Director of Software Engineering
Administrative Information Services
Penn State University
814-321-5227
ses44@psu.edu
----- Original Message -----
From: "CHRISTOPHER PIKE" <cl...@psu.edu>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 10:29:15 AM
Subject: Re: Fortress Constraints
Yes, it is easy to get lost, I'm on the IRC chat if you want to jump on, here are basics of what I am proposing...
AdminManager - I have this coded on my branch minus the ftAttributeSet change
+ PermissionAttribute addPermissionAttribute( PermissionAttribute permAttribute ) throws SecurityException;
- Create a new object "ftAttributeSet" object and add a the "ftPA" entry to permission which would just have the name of the ftAttributeSet object (i.e. ftPA=ATTRIBUTE_SET_NAME)
- Still need to add remove and update methods
+ RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException;
- Adds a role constraint ftRC, to a User (i.e. ftRC=ROLE_NAME$type$filter$ATTRIBUTE_SET_NAME$value)
- Still need to add remove and update methods
Review Manager - I have the first method coded, not the second
+ Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance ) throws SecurityException;
- Inspects all permissions for a given role and returns a set of PermissionAttribute applicable to the role
+ PermissionAttribute readPermissionAttribute( Permission permission ) throws SecurityException;
- Returns the permission attribute for a given permission
UserRole - I have this coded on my branch
+ private Set<RoleConstraint> roleConstraints;
- Any unloading of a role would populate this using the ftRC entries that weren't temporal
Permission - This is not coded yet
+ private String attributeSet;
- Any unloading of a permission would read the ftPA entry and populate this field
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 10:01:54 AM
Subject: Re: Fortress Constraints
> On Jan 28, 2016, at 8:50 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Every application could define several permission attributes, and since we plan on using this for many applications, it could become a large list.
>
> Our paradigm of use might be a slightly different than yours, so please correct me if I'm wrong, but is it fair to say we are mostly worried about adding extra read operations on the access manager operations not to the review and admin manager calls? Regardless of where the ftPA information is stored, it shouldn't affect access manager other than access manager reading the additional ftRC and ftPA attribute values. I don't think the sessionPermissions check would need to read the ftPA reference object.
>
> Also, couldn't the ftPAs be cached regardless of where they are stored?
Correct, we must avoid adding extra ldap ops to the accessmgr apis. But we also must be careful, reviewmgr methods are sometimes called during policy enforcement too.
Caching the entry is an option. But I may have lost the forest from the trees. Can you (re)outline the approach, which apis to change, and how they must be changed according to where you are right now?
(If this gets tedious we can hop on IRC channel to discuss.)
Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Maybe, there are many places where we still need to add ability to down select what data is returned, which ties into the ARBAC discussions.
That method will be called when managing user / role assignments, so what PermissionAttributes get returned might be driven by the users current ARBAC role.
----- Original Message -----
From: "SHAWN E SMITH" <se...@psu.edu>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 12:11:34 PM
Subject: Re: Fortress Constraints
Would it be beneficial to indicate application in the permission attribute?
We've talked about roles being cross application, can we do something like
Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance, String application) throws SecurityException;
and for the non-qualified (as below)
Map<String, Set<PermissionAttribute>> rolePermissionAttributes( Role role, boolean noInhertiance, String application) throws SecurityException;
where the map key is application the attribute(s) applies to.
I think there are administrative reasons why we would want to see cross app ftPA's, but as a single client app it would be nice to be able to just grab what's relevant to me.
Just a thought....
"The programmer … works only slightly removed from pure thought-stuff.
He builds his castles in the air, from air, creating by exertion of the imagination."
— Fred Brooks
Shawn Smith
Director of Software Engineering
Administrative Information Services
Penn State University
814-321-5227
ses44@psu.edu
----- Original Message -----
From: "CHRISTOPHER PIKE" <cl...@psu.edu>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 10:29:15 AM
Subject: Re: Fortress Constraints
Yes, it is easy to get lost, I'm on the IRC chat if you want to jump on, here are basics of what I am proposing...
AdminManager - I have this coded on my branch minus the ftAttributeSet change
+ PermissionAttribute addPermissionAttribute( PermissionAttribute permAttribute ) throws SecurityException;
- Create a new object "ftAttributeSet" object and add a the "ftPA" entry to permission which would just have the name of the ftAttributeSet object (i.e. ftPA=ATTRIBUTE_SET_NAME)
- Still need to add remove and update methods
+ RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException;
- Adds a role constraint ftRC, to a User (i.e. ftRC=ROLE_NAME$type$filter$ATTRIBUTE_SET_NAME$value)
- Still need to add remove and update methods
Review Manager - I have the first method coded, not the second
+ Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance ) throws SecurityException;
- Inspects all permissions for a given role and returns a set of PermissionAttribute applicable to the role
+ PermissionAttribute readPermissionAttribute( Permission permission ) throws SecurityException;
- Returns the permission attribute for a given permission
UserRole - I have this coded on my branch
+ private Set<RoleConstraint> roleConstraints;
- Any unloading of a role would populate this using the ftRC entries that weren't temporal
Permission - This is not coded yet
+ private String attributeSet;
- Any unloading of a permission would read the ftPA entry and populate this field
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 10:01:54 AM
Subject: Re: Fortress Constraints
> On Jan 28, 2016, at 8:50 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Every application could define several permission attributes, and since we plan on using this for many applications, it could become a large list.
>
> Our paradigm of use might be a slightly different than yours, so please correct me if I'm wrong, but is it fair to say we are mostly worried about adding extra read operations on the access manager operations not to the review and admin manager calls? Regardless of where the ftPA information is stored, it shouldn't affect access manager other than access manager reading the additional ftRC and ftPA attribute values. I don't think the sessionPermissions check would need to read the ftPA reference object.
>
> Also, couldn't the ftPAs be cached regardless of where they are stored?
Correct, we must avoid adding extra ldap ops to the accessmgr apis. But we also must be careful, reviewmgr methods are sometimes called during policy enforcement too.
Caching the entry is an option. But I may have lost the forest from the trees. Can you (re)outline the approach, which apis to change, and how they must be changed according to where you are right now?
(If this gets tedious we can hop on IRC channel to discuss.)
Shawn
Re: Fortress Constraints
Posted by SHAWN E SMITH <se...@psu.edu>.
Would it be beneficial to indicate application in the permission attribute?
We've talked about roles being cross application, can we do something like
Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance, String application) throws SecurityException;
and for the non-qualified (as below)
Map<String, Set<PermissionAttribute>> rolePermissionAttributes( Role role, boolean noInhertiance, String application) throws SecurityException;
where the map key is application the attribute(s) applies to.
I think there are administrative reasons why we would want to see cross app ftPA's, but as a single client app it would be nice to be able to just grab what's relevant to me.
Just a thought....
"The programmer … works only slightly removed from pure thought-stuff.
He builds his castles in the air, from air, creating by exertion of the imagination."
— Fred Brooks
Shawn Smith
Director of Software Engineering
Administrative Information Services
Penn State University
814-321-5227
ses44@psu.edu
----- Original Message -----
From: "CHRISTOPHER PIKE" <cl...@psu.edu>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 10:29:15 AM
Subject: Re: Fortress Constraints
Yes, it is easy to get lost, I'm on the IRC chat if you want to jump on, here are basics of what I am proposing...
AdminManager - I have this coded on my branch minus the ftAttributeSet change
+ PermissionAttribute addPermissionAttribute( PermissionAttribute permAttribute ) throws SecurityException;
- Create a new object "ftAttributeSet" object and add a the "ftPA" entry to permission which would just have the name of the ftAttributeSet object (i.e. ftPA=ATTRIBUTE_SET_NAME)
- Still need to add remove and update methods
+ RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException;
- Adds a role constraint ftRC, to a User (i.e. ftRC=ROLE_NAME$type$filter$ATTRIBUTE_SET_NAME$value)
- Still need to add remove and update methods
Review Manager - I have the first method coded, not the second
+ Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance ) throws SecurityException;
- Inspects all permissions for a given role and returns a set of PermissionAttribute applicable to the role
+ PermissionAttribute readPermissionAttribute( Permission permission ) throws SecurityException;
- Returns the permission attribute for a given permission
UserRole - I have this coded on my branch
+ private Set<RoleConstraint> roleConstraints;
- Any unloading of a role would populate this using the ftRC entries that weren't temporal
Permission - This is not coded yet
+ private String attributeSet;
- Any unloading of a permission would read the ftPA entry and populate this field
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 10:01:54 AM
Subject: Re: Fortress Constraints
> On Jan 28, 2016, at 8:50 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Every application could define several permission attributes, and since we plan on using this for many applications, it could become a large list.
>
> Our paradigm of use might be a slightly different than yours, so please correct me if I'm wrong, but is it fair to say we are mostly worried about adding extra read operations on the access manager operations not to the review and admin manager calls? Regardless of where the ftPA information is stored, it shouldn't affect access manager other than access manager reading the additional ftRC and ftPA attribute values. I don't think the sessionPermissions check would need to read the ftPA reference object.
>
> Also, couldn't the ftPAs be cached regardless of where they are stored?
Correct, we must avoid adding extra ldap ops to the accessmgr apis. But we also must be careful, reviewmgr methods are sometimes called during policy enforcement too.
Caching the entry is an option. But I may have lost the forest from the trees. Can you (re)outline the approach, which apis to change, and how they must be changed according to where you are right now?
(If this gets tedious we can hop on IRC channel to discuss.)
Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
I haven't dug into the access manager method too closely yet, but I don't think anything is different in the flows other than the unloading of role (ftRC) or permission (ftPA) attributes.
For example, I had to modify UserDAO.unloadUserRoles to handle multiple ftRCs, which gets called on both reviewManager.assignedRoles and accessManager.createSession.
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 10:46:15 AM
Subject: Re: Fortress Constraints
This is good. Now can you describe the sequence of events during usage?
For example:
1. createSession does these ops:
a. readUser
b. bind
2. sessionPermissions
a. searchPermissions
what changes within these sequences?
No changes to accessmgr other than these two methods?
Shawn
> On Jan 28, 2016, at 9:29 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Yes, it is easy to get lost, I'm on the IRC chat if you want to jump on, here are basics of what I am proposing...
>
>
> AdminManager - I have this coded on my branch minus the ftAttributeSet change
>
> + PermissionAttribute addPermissionAttribute( PermissionAttribute permAttribute ) throws SecurityException;
> - Create a new object "ftAttributeSet" object and add a the "ftPA" entry to permission which would just have the name of the ftAttributeSet object (i.e. ftPA=ATTRIBUTE_SET_NAME)
> - Still need to add remove and update methods
> + RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException;
> - Adds a role constraint ftRC, to a User (i.e. ftRC=ROLE_NAME$type$filter$ATTRIBUTE_SET_NAME$value)
> - Still need to add remove and update methods
>
> Review Manager - I have the first method coded, not the second
>
> + Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance ) throws SecurityException;
> - Inspects all permissions for a given role and returns a set of PermissionAttribute applicable to the role
> + PermissionAttribute readPermissionAttribute( Permission permission ) throws SecurityException;
> - Returns the permission attribute for a given permission
>
> UserRole - I have this coded on my branch
>
> + private Set<RoleConstraint> roleConstraints;
> - Any unloading of a role would populate this using the ftRC entries that weren't temporal
>
> Permission - This is not coded yet
>
> + private String attributeSet;
> - Any unloading of a permission would read the ftPA entry and populate this field
>
>
>
>
>
> ----- Original Message -----
> From: "Shawn McKinney" <sm...@apache.org>
> To: fortress@directory.apache.org
> Sent: Thursday, January 28, 2016 10:01:54 AM
> Subject: Re: Fortress Constraints
>
>> On Jan 28, 2016, at 8:50 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>> Every application could define several permission attributes, and since we plan on using this for many applications, it could become a large list.
>>
>> Our paradigm of use might be a slightly different than yours, so please correct me if I'm wrong, but is it fair to say we are mostly worried about adding extra read operations on the access manager operations not to the review and admin manager calls? Regardless of where the ftPA information is stored, it shouldn't affect access manager other than access manager reading the additional ftRC and ftPA attribute values. I don't think the sessionPermissions check would need to read the ftPA reference object.
>>
>> Also, couldn't the ftPAs be cached regardless of where they are stored?
>
> Correct, we must avoid adding extra ldap ops to the accessmgr apis. But we also must be careful, reviewmgr methods are sometimes called during policy enforcement too.
>
> Caching the entry is an option. But I may have lost the forest from the trees. Can you (re)outline the approach, which apis to change, and how they must be changed according to where you are right now?
>
> (If this gets tedious we can hop on IRC channel to discuss.)
>
> Shawn
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
This is good. Now can you describe the sequence of events during usage?
For example:
1. createSession does these ops:
a. readUser
b. bind
2. sessionPermissions
a. searchPermissions
what changes within these sequences?
No changes to accessmgr other than these two methods?
Shawn
> On Jan 28, 2016, at 9:29 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Yes, it is easy to get lost, I'm on the IRC chat if you want to jump on, here are basics of what I am proposing...
>
>
> AdminManager - I have this coded on my branch minus the ftAttributeSet change
>
> + PermissionAttribute addPermissionAttribute( PermissionAttribute permAttribute ) throws SecurityException;
> - Create a new object "ftAttributeSet" object and add a the "ftPA" entry to permission which would just have the name of the ftAttributeSet object (i.e. ftPA=ATTRIBUTE_SET_NAME)
> - Still need to add remove and update methods
> + RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException;
> - Adds a role constraint ftRC, to a User (i.e. ftRC=ROLE_NAME$type$filter$ATTRIBUTE_SET_NAME$value)
> - Still need to add remove and update methods
>
> Review Manager - I have the first method coded, not the second
>
> + Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance ) throws SecurityException;
> - Inspects all permissions for a given role and returns a set of PermissionAttribute applicable to the role
> + PermissionAttribute readPermissionAttribute( Permission permission ) throws SecurityException;
> - Returns the permission attribute for a given permission
>
> UserRole - I have this coded on my branch
>
> + private Set<RoleConstraint> roleConstraints;
> - Any unloading of a role would populate this using the ftRC entries that weren't temporal
>
> Permission - This is not coded yet
>
> + private String attributeSet;
> - Any unloading of a permission would read the ftPA entry and populate this field
>
>
>
>
>
> ----- Original Message -----
> From: "Shawn McKinney" <sm...@apache.org>
> To: fortress@directory.apache.org
> Sent: Thursday, January 28, 2016 10:01:54 AM
> Subject: Re: Fortress Constraints
>
>> On Jan 28, 2016, at 8:50 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>> Every application could define several permission attributes, and since we plan on using this for many applications, it could become a large list.
>>
>> Our paradigm of use might be a slightly different than yours, so please correct me if I'm wrong, but is it fair to say we are mostly worried about adding extra read operations on the access manager operations not to the review and admin manager calls? Regardless of where the ftPA information is stored, it shouldn't affect access manager other than access manager reading the additional ftRC and ftPA attribute values. I don't think the sessionPermissions check would need to read the ftPA reference object.
>>
>> Also, couldn't the ftPAs be cached regardless of where they are stored?
>
> Correct, we must avoid adding extra ldap ops to the accessmgr apis. But we also must be careful, reviewmgr methods are sometimes called during policy enforcement too.
>
> Caching the entry is an option. But I may have lost the forest from the trees. Can you (re)outline the approach, which apis to change, and how they must be changed according to where you are right now?
>
> (If this gets tedious we can hop on IRC channel to discuss.)
>
> Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Yes, it is easy to get lost, I'm on the IRC chat if you want to jump on, here are basics of what I am proposing...
AdminManager - I have this coded on my branch minus the ftAttributeSet change
+ PermissionAttribute addPermissionAttribute( PermissionAttribute permAttribute ) throws SecurityException;
- Create a new object "ftAttributeSet" object and add a the "ftPA" entry to permission which would just have the name of the ftAttributeSet object (i.e. ftPA=ATTRIBUTE_SET_NAME)
- Still need to add remove and update methods
+ RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException;
- Adds a role constraint ftRC, to a User (i.e. ftRC=ROLE_NAME$type$filter$ATTRIBUTE_SET_NAME$value)
- Still need to add remove and update methods
Review Manager - I have the first method coded, not the second
+ Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance ) throws SecurityException;
- Inspects all permissions for a given role and returns a set of PermissionAttribute applicable to the role
+ PermissionAttribute readPermissionAttribute( Permission permission ) throws SecurityException;
- Returns the permission attribute for a given permission
UserRole - I have this coded on my branch
+ private Set<RoleConstraint> roleConstraints;
- Any unloading of a role would populate this using the ftRC entries that weren't temporal
Permission - This is not coded yet
+ private String attributeSet;
- Any unloading of a permission would read the ftPA entry and populate this field
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 10:01:54 AM
Subject: Re: Fortress Constraints
> On Jan 28, 2016, at 8:50 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Every application could define several permission attributes, and since we plan on using this for many applications, it could become a large list.
>
> Our paradigm of use might be a slightly different than yours, so please correct me if I'm wrong, but is it fair to say we are mostly worried about adding extra read operations on the access manager operations not to the review and admin manager calls? Regardless of where the ftPA information is stored, it shouldn't affect access manager other than access manager reading the additional ftRC and ftPA attribute values. I don't think the sessionPermissions check would need to read the ftPA reference object.
>
> Also, couldn't the ftPAs be cached regardless of where they are stored?
Correct, we must avoid adding extra ldap ops to the accessmgr apis. But we also must be careful, reviewmgr methods are sometimes called during policy enforcement too.
Caching the entry is an option. But I may have lost the forest from the trees. Can you (re)outline the approach, which apis to change, and how they must be changed according to where you are right now?
(If this gets tedious we can hop on IRC channel to discuss.)
Shawn
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
> On Jan 28, 2016, at 8:50 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Every application could define several permission attributes, and since we plan on using this for many applications, it could become a large list.
>
> Our paradigm of use might be a slightly different than yours, so please correct me if I'm wrong, but is it fair to say we are mostly worried about adding extra read operations on the access manager operations not to the review and admin manager calls? Regardless of where the ftPA information is stored, it shouldn't affect access manager other than access manager reading the additional ftRC and ftPA attribute values. I don't think the sessionPermissions check would need to read the ftPA reference object.
>
> Also, couldn't the ftPAs be cached regardless of where they are stored?
Correct, we must avoid adding extra ldap ops to the accessmgr apis. But we also must be careful, reviewmgr methods are sometimes called during policy enforcement too.
Caching the entry is an option. But I may have lost the forest from the trees. Can you (re)outline the approach, which apis to change, and how they must be changed according to where you are right now?
(If this gets tedious we can hop on IRC channel to discuss.)
Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Every application could define several permission attributes, and since we plan on using this for many applications, it could become a large list.
Our paradigm of use might be a slightly different than yours, so please correct me if I'm wrong, but is it fair to say we are mostly worried about adding extra read operations on the access manager operations not to the review and admin manager calls? Regardless of where the ftPA information is stored, it shouldn't affect access manager other than access manager reading the additional ftRC and ftPA attribute values. I don't think the sessionPermissions check would need to read the ftPA reference object.
Also, couldn't the ftPAs be cached regardless of where they are stored?
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Thursday, January 28, 2016 8:52:22 AM
Subject: Re: Fortress Constraints
> On Jan 27, 2016, at 3:17 PM, Chris Pike <cl...@psu.edu> wrote:
>
> started implementing this and one of the things I am concerned with is duplicate ftPA entries. Most of our permissions will likely share the same attribute(s), so the ftPA entires will be duplicated across several permissions in what I proposed. I am considering creating an objectclass, something like ftAttributeSet to store the attribute(s), then have ftPA point to the attribute set. Then in the ftRC, for the filter type, I can specify the attribute set instead of trying to infer which one is applicable. Any thoughts or concerns with that change?
>
> FYI - My plan is to provide an ldif export with some sample data once I have it all implemented, but if you are interested in what I've done so far you can take a look here (https://github.com/PennState/directory-fortress-core-1/tree/feature/addPermAttrAndUserRoleConstraints).
My first thoughts are storing the ftpa attribute set in a separate node or tree adds at least one read to every operation and should be avoided at all costs. What we’re talking about here are rules. And these rules can be used across many permissions. My question is how many of these rules can we expect to be using? Maybe we store them as properties:
ftPa1:xyz
ftPa2:abc
ftPa3:def
ftPa4:ghi
Now your ftPa attribute on the permission needs to store the name of specific rule it is using.
Those config parameters will eventually be stored in the tree under node, ou=Config. The difference being here, those parameters are all read, and cached by the config subsystem when process fires up.
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
> On Jan 27, 2016, at 3:17 PM, Chris Pike <cl...@psu.edu> wrote:
>
> started implementing this and one of the things I am concerned with is duplicate ftPA entries. Most of our permissions will likely share the same attribute(s), so the ftPA entires will be duplicated across several permissions in what I proposed. I am considering creating an objectclass, something like ftAttributeSet to store the attribute(s), then have ftPA point to the attribute set. Then in the ftRC, for the filter type, I can specify the attribute set instead of trying to infer which one is applicable. Any thoughts or concerns with that change?
>
> FYI - My plan is to provide an ldif export with some sample data once I have it all implemented, but if you are interested in what I've done so far you can take a look here (https://github.com/PennState/directory-fortress-core-1/tree/feature/addPermAttrAndUserRoleConstraints).
My first thoughts are storing the ftpa attribute set in a separate node or tree adds at least one read to every operation and should be avoided at all costs. What we’re talking about here are rules. And these rules can be used across many permissions. My question is how many of these rules can we expect to be using? Maybe we store them as properties:
ftPa1:xyz
ftPa2:abc
ftPa3:def
ftPa4:ghi
Now your ftPa attribute on the permission needs to store the name of specific rule it is using.
Those config parameters will eventually be stored in the tree under node, ou=Config. The difference being here, those parameters are all read, and cached by the config subsystem when process fires up.
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Shawn,
I started implementing this and one of the things I am concerned with is duplicate ftPA entries. Most of our permissions will likely share the same attribute(s), so the ftPA entires will be duplicated across several permissions in what I proposed. I am considering creating an objectclass, something like ftAttributeSet to store the attribute(s), then have ftPA point to the attribute set. Then in the ftRC, for the filter type, I can specify the attribute set instead of trying to infer which one is applicable. Any thoughts or concerns with that change?
FYI - My plan is to provide an ldif export with some sample data once I have it all implemented, but if you are interested in what I've done so far you can take a look here (https://github.com/PennState/directory-fortress-core-1/tree/feature/addPermAttrAndUserRoleConstraints).
Thanks,
~Chris P.
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Monday, January 18, 2016 8:31:37 AM
Subject: Re: Fortress Constraints
Chris I’m not concerned with loading the user object with new multi-occurring attributes as much as the runtime complexity of joining with the ftPA’s during sessionPermissions call.
Having said that I believe your proposal has merit due to its potential of reducing the number of roles needed to manage complex security use cases.
Runtime performance is a critical concern and we’ll need to optimize this algorithm to the extent possible. Our runtime complexity target should be O(log N). That means we’ll need to find an efficient way to join without (much) looping. We’ll also need to ensure the complexity doesn’t leak into areas where the attribute feature isn’t used / needed.
Shawn
> On Jan 17, 2016, at 7:04 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Shawn,
>
> Thanks for taking a look!
>
> 1. Yes, I think that is correct.
>
> 3a. I think the assignUser operation will optionally accept a list of ftPAs. There will need to be a way to return the list of possible ftPA, either as part of readRole, or a new method.
>
> 3b. Either the "filter" ftRC would be left as raw string, or we could create a new object to represent that data. Either way, the data would need attached to UserRole and also possibly Permission. Currently, our application runs the accessMgr_.sessionPermissions(session) to get permissions for a user, so would also need a way to return them there as well. (see #4)
>
> 3c. Potentially yes, would this cause performance issues?
>
> 4. Yes, I'll have to look at how the code works, but perhaps something like
>
> for(UserRole userRole : roles)
> {
> List<FilterConstraint> constraints = userRole.getFilterConstraints();
> for (Permission permission : perms)
> {
> if (perms.attributes != null)
> for(PermAttribute attribute : perm.attributes)
> {
> if(constraints.contains(attribute)
> perm.addConstraint(attribute);
> }
> }
> }
>
>
> Thanks!
>
> ~Chris
>
>
>
> ----- Original Message -----
> From: "Shawn McKinney" <sm...@apache.org>
> To: fortress@directory.apache.org
> Sent: Thursday, January 14, 2016 1:09:24 PM
> Subject: Re: Fortress Constraints
>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>> We want to be able to store attributes/constraints in fortress so that we can do fine grained security checks. We would like to get thoughts/feedback on this proposal. Our goal is to store permission attributes and role constraints based on those attribute in fortress, but not necessarily have fortress make the decision. In our applications, we pull back the list of roles and permissions when the user logs in, not on every security check, so we would have the application interpret the constraints. That being said, here is the proposal...
>>
>
> Sounds like an interesting idea. I’ve got a few questions/comments below….
>
>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>> 1. Add a new ldap attribute type (ftPA) to store 0 to many attributes about a permission and other metadata about the attribute (required, valid values, etc...). It would be up to each application to define it's permissions and any attributes that are relevant to each permission. In this example, we have an account.withdraw permission that needs constraints for the account id and a withdraw limit for each user.
>>
>> Permission: account.withdraw
>> - ftPA: AccountId?dataType=int&required=true&validValues=SELF,ANY,int&comparator=equals&default=SELF
>> - ftPA: WithdrawLimit?dataType=int&comparator=max
>>
>
> The LDAP schema would look like this?
>
> # A15: User Role Constraints, type STRING, MULTI VALUE
> attributetype ( 1.3.6.1.4.1.1.38088.1.31
> NAME 'ftPA'
> DESC 'Fortress Permission Attribute Constraints'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
>
> ftPA is added to
>
> ## OC3: Fortress Operation Structural Object Class
> objectclass ( 1.3.6.1.4.1.38088.2.3
> NAME 'ftOperation'
> DESC 'Fortress Permission Operation Structural Object Class'
> SUP organizationalrole
> STRUCTURAL
> MUST (
> ftId $
> ftPermName $
> ftObjNm $
> ftOpNm
> )
> MAY (
> ftObjId $
> ftRoles $
> ftUsers $
> ftType $
> ftPA
> )
> )
>
> The new attribute ftPA is a multi-value string that is optionally attached to the ftOperation structural object class. Furthermore this attribute will not undergo any constraint checking when being added or modified.
>
>>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>> 3. When a user is assigned to a role that has a permission with a ftPA, we would allow adding of role constraints to the user-role assignment. In this example, we are changing ftRC so that it can specify a type of constraint (temporal or filter). There could be many "filter" ftRC entries if the ftPA were different. We may also want to add a "seq" to allow grouping ftRCs together.
>>
>> User: chris
>> - ftRA: BANK_USER
>> - ftRC: BANK_USER$seq$0$type$temporal$role1$0$1000$0000$none$none$none$none$all
>> - ftRC: BANK_USER$seq$0type$filter$AccountId=12345&WithdrawLimit=500
>>
>
> a. The opening phrase, when a user is assigned a role that has a permission with a ftPA, needs to be clarified. Do you mean that the admin function assignUser operation, will interrogate the role-permissions dataset and determine if one of those permissions has a ftPA attribute assigned?
>
> b. wrt to ftRC’s. Currently fortress parses the ftRC (temporal data) into user-role entities and adds to session (List<UserRole> roles) during createSession. How does it map the data stored in ftRC if the type is filter? Will it be parsed by fortress or left as raw data inside of a list, (i.e. List<String> filters) that is a member attribute of UserRole or User?
>
> The same is true in reverse. When a temporal constraint is added to an entity it uses the Constraint entity to store the data. If the data passes the validations, i.e. valid date ranges, the DAO will convert to raw data format before adding the ldap entry.
>
> With our filter attributes are we just going to accept raw data from the caller and persist that directly to the entry in ldap?
>
> c. What if there are a 1000 permissions associated with this user that have the ftPA attribute. Will there be potentially that many ftRC filter strings on a user object?
>
>>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>>
>> 4. When getting roles or session permissions for a user, the additional constraints would need to be returned.
>>
>> {
>> "objName": "account",
>> "opName": "withdraw",
>> "constraints": [ "AccountId=12345&WithdrawLimit=500" ]
>> }
>>
>
> Did fortress join the data found here:
>
>> Permission: account.withdraw
>> - ftPA: AccountId?dataType=int&required=true&validValues=SELF,ANY,int&comparator=equals&default=SELF
>> - ftPA: WithdrawLimit?dataType=int&comparator=max
>>
>
>
> with the data found here:
>
>> User: chris
>> - ftRA: BANK_USER
>> - ftRC: BANK_USER$seq$0$type$temporal$role1$0$1000$0000$none$none$none$none$all
>> - ftRC: BANK_USER$seq$0type$filter$AccountId=12345&WithdrawLimit=500
>
> and add that combined data into the Permission entity?
>
> If ‘yes’, how will that join happen?
>
> for(UserRole role : roles)
> {
> for (Permission permission : perms)
> {
> if (perms.attributes != null)
> for(PermAttribute attribute : perm.attributes)
> {
> // if attribute.contains (what?) add value to role
> }
> }
> }
>
>>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>>
>> 5. Once our application had the list of permissions and constraints, it would then do it's own checks, potentially something like...
>>
>> @PermissionRequired("account.withdraw") //coarse grained check
>> public void withdraw(Account account, float amount){
>> Map map = new HashMap();
>> map.put("WithdrawLimit", amount);
>> map.put("AccountId", account.getId());
>>
>> doesUserHavePermission("account.withdraw", map); //fine grained check
>> }
>
> Yes this is fine, or we could add a callback module here that allows your app to be plugged into the flow.
>
> Shawn
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
Chris I’m not concerned with loading the user object with new multi-occurring attributes as much as the runtime complexity of joining with the ftPA’s during sessionPermissions call.
Having said that I believe your proposal has merit due to its potential of reducing the number of roles needed to manage complex security use cases.
Runtime performance is a critical concern and we’ll need to optimize this algorithm to the extent possible. Our runtime complexity target should be O(log N). That means we’ll need to find an efficient way to join without (much) looping. We’ll also need to ensure the complexity doesn’t leak into areas where the attribute feature isn’t used / needed.
Shawn
> On Jan 17, 2016, at 7:04 AM, Chris Pike <cl...@psu.edu> wrote:
>
> Shawn,
>
> Thanks for taking a look!
>
> 1. Yes, I think that is correct.
>
> 3a. I think the assignUser operation will optionally accept a list of ftPAs. There will need to be a way to return the list of possible ftPA, either as part of readRole, or a new method.
>
> 3b. Either the "filter" ftRC would be left as raw string, or we could create a new object to represent that data. Either way, the data would need attached to UserRole and also possibly Permission. Currently, our application runs the accessMgr_.sessionPermissions(session) to get permissions for a user, so would also need a way to return them there as well. (see #4)
>
> 3c. Potentially yes, would this cause performance issues?
>
> 4. Yes, I'll have to look at how the code works, but perhaps something like
>
> for(UserRole userRole : roles)
> {
> List<FilterConstraint> constraints = userRole.getFilterConstraints();
> for (Permission permission : perms)
> {
> if (perms.attributes != null)
> for(PermAttribute attribute : perm.attributes)
> {
> if(constraints.contains(attribute)
> perm.addConstraint(attribute);
> }
> }
> }
>
>
> Thanks!
>
> ~Chris
>
>
>
> ----- Original Message -----
> From: "Shawn McKinney" <sm...@apache.org>
> To: fortress@directory.apache.org
> Sent: Thursday, January 14, 2016 1:09:24 PM
> Subject: Re: Fortress Constraints
>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>> We want to be able to store attributes/constraints in fortress so that we can do fine grained security checks. We would like to get thoughts/feedback on this proposal. Our goal is to store permission attributes and role constraints based on those attribute in fortress, but not necessarily have fortress make the decision. In our applications, we pull back the list of roles and permissions when the user logs in, not on every security check, so we would have the application interpret the constraints. That being said, here is the proposal...
>>
>
> Sounds like an interesting idea. I’ve got a few questions/comments below….
>
>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>> 1. Add a new ldap attribute type (ftPA) to store 0 to many attributes about a permission and other metadata about the attribute (required, valid values, etc...). It would be up to each application to define it's permissions and any attributes that are relevant to each permission. In this example, we have an account.withdraw permission that needs constraints for the account id and a withdraw limit for each user.
>>
>> Permission: account.withdraw
>> - ftPA: AccountId?dataType=int&required=true&validValues=SELF,ANY,int&comparator=equals&default=SELF
>> - ftPA: WithdrawLimit?dataType=int&comparator=max
>>
>
> The LDAP schema would look like this?
>
> # A15: User Role Constraints, type STRING, MULTI VALUE
> attributetype ( 1.3.6.1.4.1.1.38088.1.31
> NAME 'ftPA'
> DESC 'Fortress Permission Attribute Constraints'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
>
> ftPA is added to
>
> ## OC3: Fortress Operation Structural Object Class
> objectclass ( 1.3.6.1.4.1.38088.2.3
> NAME 'ftOperation'
> DESC 'Fortress Permission Operation Structural Object Class'
> SUP organizationalrole
> STRUCTURAL
> MUST (
> ftId $
> ftPermName $
> ftObjNm $
> ftOpNm
> )
> MAY (
> ftObjId $
> ftRoles $
> ftUsers $
> ftType $
> ftPA
> )
> )
>
> The new attribute ftPA is a multi-value string that is optionally attached to the ftOperation structural object class. Furthermore this attribute will not undergo any constraint checking when being added or modified.
>
>>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>> 3. When a user is assigned to a role that has a permission with a ftPA, we would allow adding of role constraints to the user-role assignment. In this example, we are changing ftRC so that it can specify a type of constraint (temporal or filter). There could be many "filter" ftRC entries if the ftPA were different. We may also want to add a "seq" to allow grouping ftRCs together.
>>
>> User: chris
>> - ftRA: BANK_USER
>> - ftRC: BANK_USER$seq$0$type$temporal$role1$0$1000$0000$none$none$none$none$all
>> - ftRC: BANK_USER$seq$0type$filter$AccountId=12345&WithdrawLimit=500
>>
>
> a. The opening phrase, when a user is assigned a role that has a permission with a ftPA, needs to be clarified. Do you mean that the admin function assignUser operation, will interrogate the role-permissions dataset and determine if one of those permissions has a ftPA attribute assigned?
>
> b. wrt to ftRC’s. Currently fortress parses the ftRC (temporal data) into user-role entities and adds to session (List<UserRole> roles) during createSession. How does it map the data stored in ftRC if the type is filter? Will it be parsed by fortress or left as raw data inside of a list, (i.e. List<String> filters) that is a member attribute of UserRole or User?
>
> The same is true in reverse. When a temporal constraint is added to an entity it uses the Constraint entity to store the data. If the data passes the validations, i.e. valid date ranges, the DAO will convert to raw data format before adding the ldap entry.
>
> With our filter attributes are we just going to accept raw data from the caller and persist that directly to the entry in ldap?
>
> c. What if there are a 1000 permissions associated with this user that have the ftPA attribute. Will there be potentially that many ftRC filter strings on a user object?
>
>>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>>
>> 4. When getting roles or session permissions for a user, the additional constraints would need to be returned.
>>
>> {
>> "objName": "account",
>> "opName": "withdraw",
>> "constraints": [ "AccountId=12345&WithdrawLimit=500" ]
>> }
>>
>
> Did fortress join the data found here:
>
>> Permission: account.withdraw
>> - ftPA: AccountId?dataType=int&required=true&validValues=SELF,ANY,int&comparator=equals&default=SELF
>> - ftPA: WithdrawLimit?dataType=int&comparator=max
>>
>
>
> with the data found here:
>
>> User: chris
>> - ftRA: BANK_USER
>> - ftRC: BANK_USER$seq$0$type$temporal$role1$0$1000$0000$none$none$none$none$all
>> - ftRC: BANK_USER$seq$0type$filter$AccountId=12345&WithdrawLimit=500
>
> and add that combined data into the Permission entity?
>
> If ‘yes’, how will that join happen?
>
> for(UserRole role : roles)
> {
> for (Permission permission : perms)
> {
> if (perms.attributes != null)
> for(PermAttribute attribute : perm.attributes)
> {
> // if attribute.contains (what?) add value to role
> }
> }
> }
>
>>
>> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>>
>>
>> 5. Once our application had the list of permissions and constraints, it would then do it's own checks, potentially something like...
>>
>> @PermissionRequired("account.withdraw") //coarse grained check
>> public void withdraw(Account account, float amount){
>> Map map = new HashMap();
>> map.put("WithdrawLimit", amount);
>> map.put("AccountId", account.getId());
>>
>> doesUserHavePermission("account.withdraw", map); //fine grained check
>> }
>
> Yes this is fine, or we could add a callback module here that allows your app to be plugged into the flow.
>
> Shawn
Re: Fortress Constraints
Posted by Chris Pike <cl...@psu.edu>.
Shawn,
Thanks for taking a look!
1. Yes, I think that is correct.
3a. I think the assignUser operation will optionally accept a list of ftPAs. There will need to be a way to return the list of possible ftPA, either as part of readRole, or a new method.
3b. Either the "filter" ftRC would be left as raw string, or we could create a new object to represent that data. Either way, the data would need attached to UserRole and also possibly Permission. Currently, our application runs the accessMgr_.sessionPermissions(session) to get permissions for a user, so would also need a way to return them there as well. (see #4)
3c. Potentially yes, would this cause performance issues?
4. Yes, I'll have to look at how the code works, but perhaps something like
for(UserRole userRole : roles)
{
List<FilterConstraint> constraints = userRole.getFilterConstraints();
for (Permission permission : perms)
{
if (perms.attributes != null)
for(PermAttribute attribute : perm.attributes)
{
if(constraints.contains(attribute)
perm.addConstraint(attribute);
}
}
}
Thanks!
~Chris
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
Sent: Thursday, January 14, 2016 1:09:24 PM
Subject: Re: Fortress Constraints
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
> We want to be able to store attributes/constraints in fortress so that we can do fine grained security checks. We would like to get thoughts/feedback on this proposal. Our goal is to store permission attributes and role constraints based on those attribute in fortress, but not necessarily have fortress make the decision. In our applications, we pull back the list of roles and permissions when the user logs in, not on every security check, so we would have the application interpret the constraints. That being said, here is the proposal...
>
Sounds like an interesting idea. I’ve got a few questions/comments below….
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
> 1. Add a new ldap attribute type (ftPA) to store 0 to many attributes about a permission and other metadata about the attribute (required, valid values, etc...). It would be up to each application to define it's permissions and any attributes that are relevant to each permission. In this example, we have an account.withdraw permission that needs constraints for the account id and a withdraw limit for each user.
>
> Permission: account.withdraw
> - ftPA: AccountId?dataType=int&required=true&validValues=SELF,ANY,int&comparator=equals&default=SELF
> - ftPA: WithdrawLimit?dataType=int&comparator=max
>
The LDAP schema would look like this?
# A15: User Role Constraints, type STRING, MULTI VALUE
attributetype ( 1.3.6.1.4.1.1.38088.1.31
NAME 'ftPA'
DESC 'Fortress Permission Attribute Constraints'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
ftPA is added to
## OC3: Fortress Operation Structural Object Class
objectclass ( 1.3.6.1.4.1.38088.2.3
NAME 'ftOperation'
DESC 'Fortress Permission Operation Structural Object Class'
SUP organizationalrole
STRUCTURAL
MUST (
ftId $
ftPermName $
ftObjNm $
ftOpNm
)
MAY (
ftObjId $
ftRoles $
ftUsers $
ftType $
ftPA
)
)
The new attribute ftPA is a multi-value string that is optionally attached to the ftOperation structural object class. Furthermore this attribute will not undergo any constraint checking when being added or modified.
>
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
> 3. When a user is assigned to a role that has a permission with a ftPA, we would allow adding of role constraints to the user-role assignment. In this example, we are changing ftRC so that it can specify a type of constraint (temporal or filter). There could be many "filter" ftRC entries if the ftPA were different. We may also want to add a "seq" to allow grouping ftRCs together.
>
> User: chris
> - ftRA: BANK_USER
> - ftRC: BANK_USER$seq$0$type$temporal$role1$0$1000$0000$none$none$none$none$all
> - ftRC: BANK_USER$seq$0type$filter$AccountId=12345&WithdrawLimit=500
>
a. The opening phrase, when a user is assigned a role that has a permission with a ftPA, needs to be clarified. Do you mean that the admin function assignUser operation, will interrogate the role-permissions dataset and determine if one of those permissions has a ftPA attribute assigned?
b. wrt to ftRC’s. Currently fortress parses the ftRC (temporal data) into user-role entities and adds to session (List<UserRole> roles) during createSession. How does it map the data stored in ftRC if the type is filter? Will it be parsed by fortress or left as raw data inside of a list, (i.e. List<String> filters) that is a member attribute of UserRole or User?
The same is true in reverse. When a temporal constraint is added to an entity it uses the Constraint entity to store the data. If the data passes the validations, i.e. valid date ranges, the DAO will convert to raw data format before adding the ldap entry.
With our filter attributes are we just going to accept raw data from the caller and persist that directly to the entry in ldap?
c. What if there are a 1000 permissions associated with this user that have the ftPA attribute. Will there be potentially that many ftRC filter strings on a user object?
>
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
>
> 4. When getting roles or session permissions for a user, the additional constraints would need to be returned.
>
> {
> "objName": "account",
> "opName": "withdraw",
> "constraints": [ "AccountId=12345&WithdrawLimit=500" ]
> }
>
Did fortress join the data found here:
> Permission: account.withdraw
> - ftPA: AccountId?dataType=int&required=true&validValues=SELF,ANY,int&comparator=equals&default=SELF
> - ftPA: WithdrawLimit?dataType=int&comparator=max
>
with the data found here:
> User: chris
> - ftRA: BANK_USER
> - ftRC: BANK_USER$seq$0$type$temporal$role1$0$1000$0000$none$none$none$none$all
> - ftRC: BANK_USER$seq$0type$filter$AccountId=12345&WithdrawLimit=500
and add that combined data into the Permission entity?
If ‘yes’, how will that join happen?
for(UserRole role : roles)
{
for (Permission permission : perms)
{
if (perms.attributes != null)
for(PermAttribute attribute : perm.attributes)
{
// if attribute.contains (what?) add value to role
}
}
}
>
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
>
> 5. Once our application had the list of permissions and constraints, it would then do it's own checks, potentially something like...
>
> @PermissionRequired("account.withdraw") //coarse grained check
> public void withdraw(Account account, float amount){
> Map map = new HashMap();
> map.put("WithdrawLimit", amount);
> map.put("AccountId", account.getId());
>
> doesUserHavePermission("account.withdraw", map); //fine grained check
> }
Yes this is fine, or we could add a callback module here that allows your app to be plugged into the flow.
Shawn
Re: Fortress Constraints
Posted by Shawn McKinney <sm...@apache.org>.
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
> We want to be able to store attributes/constraints in fortress so that we can do fine grained security checks. We would like to get thoughts/feedback on this proposal. Our goal is to store permission attributes and role constraints based on those attribute in fortress, but not necessarily have fortress make the decision. In our applications, we pull back the list of roles and permissions when the user logs in, not on every security check, so we would have the application interpret the constraints. That being said, here is the proposal...
>
Sounds like an interesting idea. I’ve got a few questions/comments below….
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
> 1. Add a new ldap attribute type (ftPA) to store 0 to many attributes about a permission and other metadata about the attribute (required, valid values, etc...). It would be up to each application to define it's permissions and any attributes that are relevant to each permission. In this example, we have an account.withdraw permission that needs constraints for the account id and a withdraw limit for each user.
>
> Permission: account.withdraw
> - ftPA: AccountId?dataType=int&required=true&validValues=SELF,ANY,int&comparator=equals&default=SELF
> - ftPA: WithdrawLimit?dataType=int&comparator=max
>
The LDAP schema would look like this?
# A15: User Role Constraints, type STRING, MULTI VALUE
attributetype ( 1.3.6.1.4.1.1.38088.1.31
NAME 'ftPA'
DESC 'Fortress Permission Attribute Constraints'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
ftPA is added to
## OC3: Fortress Operation Structural Object Class
objectclass ( 1.3.6.1.4.1.38088.2.3
NAME 'ftOperation'
DESC 'Fortress Permission Operation Structural Object Class'
SUP organizationalrole
STRUCTURAL
MUST (
ftId $
ftPermName $
ftObjNm $
ftOpNm
)
MAY (
ftObjId $
ftRoles $
ftUsers $
ftType $
ftPA
)
)
The new attribute ftPA is a multi-value string that is optionally attached to the ftOperation structural object class. Furthermore this attribute will not undergo any constraint checking when being added or modified.
>
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
> 3. When a user is assigned to a role that has a permission with a ftPA, we would allow adding of role constraints to the user-role assignment. In this example, we are changing ftRC so that it can specify a type of constraint (temporal or filter). There could be many "filter" ftRC entries if the ftPA were different. We may also want to add a "seq" to allow grouping ftRCs together.
>
> User: chris
> - ftRA: BANK_USER
> - ftRC: BANK_USER$seq$0$type$temporal$role1$0$1000$0000$none$none$none$none$all
> - ftRC: BANK_USER$seq$0type$filter$AccountId=12345&WithdrawLimit=500
>
The opening phrase, when a user is assigned a role that has a permission with a ftPA, needs to be clarified. Do you mean that the admin function assignUser operation, will interrogate the role-permissions dataset and determine if one of those permissions has a ftPA attribute assigned?
wrt to ftRC’s. Currently fortress parses the ftRC (temporal data) into user-role entities and adds to session (List<UserRole> roles) during createSession. How does it map the data stored in ftRC if the type is filter? Will it be parsed by fortress or left as raw data inside of a list, (i.e. List<String> filters) that is a member attribute of UserRole or User?
The same is true in reverse. When a temporal constraint is added to an entity it uses the Constraint entity to store the data. If the data passes the validations, i.e. valid date ranges, the DAO will convert to raw data format before adding the ldap entry.
With our filter attributes are we just going to accept raw data from the caller and persist that directly to the entry in ldap?
What if there are a 1000 permissions associated with this user that have the ftPA attribute. Will there be potentially that many ftRC filter strings on a user object?
>
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
>
> 4. When getting roles or session permissions for a user, the additional constraints would need to be returned.
>
> {
> "objName": "account",
> "opName": "withdraw",
> "constraints": [ "AccountId=12345&WithdrawLimit=500" ]
> }
>
Did fortress join the data found here:
> Permission: account.withdraw
> - ftPA: AccountId?dataType=int&required=true&validValues=SELF,ANY,int&comparator=equals&default=SELF
> - ftPA: WithdrawLimit?dataType=int&comparator=max
>
with the data found here:
> User: chris
> - ftRA: BANK_USER
> - ftRC: BANK_USER$seq$0$type$temporal$role1$0$1000$0000$none$none$none$none$all
> - ftRC: BANK_USER$seq$0type$filter$AccountId=12345&WithdrawLimit=500
and add that combined data into the Permission entity?
If ‘yes’, how will that join happen?
for(UserRole role : roles)
{
for (Permission permission : perms)
{
if (perms.attributes != null)
for(PermAttribute attribute : perm.attributes)
{
// if attribute.contains (what?) add value to role
}
}
}
>
> On Jan 14, 2016, at 10:07 AM, Chris Pike <cl...@psu.edu> wrote:
>
>
> 5. Once our application had the list of permissions and constraints, it would then do it's own checks, potentially something like...
>
> @PermissionRequired("account.withdraw") //coarse grained check
> public void withdraw(Account account, float amount){
> Map map = new HashMap();
> map.put("WithdrawLimit", amount);
> map.put("AccountId", account.getId());
>
> doesUserHavePermission("account.withdraw", map); //fine grained check
> }
Yes this is fine, or we could add a callback module here that allows your app to be plugged into the flow.
Shawn