On Dec 28, 2006, at 1:55 PM, David Jencks wrote:
<big snip>
Not entirely.
First of all, I don't think I explained one of my thoughts, which
is that keeping a list of all permissions used in an application
doesn't really have any value. In general there's an infinite set
of possible permissions for an application and there's no practical
way to enumerate all of them. To my eyes the only thing the
permissions are currently used for is to construct the admin role,
and this is not something that is generally useful: it certainly
has no universal definition in jacc or j2ee. I would prefer to
have some button on a gui to collect all the permissions in defined
roles and profiles and add them to a particular role (or profile)
Assuming you agree with this, we will be storing permissions
associated with role and profile. To construct a permission
instance we need:
permission class
permission name
permission action
grant/deny
In relational terms, these are all part of the primary key. IIUC
to directly express this in ldap you get dns with something like
a=foo+b=bar+c=baz,ou=groupId,....... which I have not yet seen in
practice and looks confusing to me. I thought it would be easier
to deal with if instead we treated it as several levels:
role or profile
permission class
[grant,deny]= permission name
with actions as a multivalued attribute for the permission name.
This results IIUC in the ldif to install a StringPermission with no
actions looking something like:
dn:
roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc
=example, dc=com
objectClass: top
objectClass: policyRole
roleName: mockRole1
dn: permClassName=org.safehaus.triplesec.guardian.StringPermission,
roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc
=example, dc=com
objectClass: top
objectClass: permClass
permClassName: org.safehaus.triplesec.guardian.StringPermission
dn: grant=mockPerm0,
permClassName=org.safehaus.triplesec.guardian.StringPermission,
roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc
=example, dc=com
objectClass: top
objectClass: permGrant
grant: mockPerm0
It might be clearer to look at the schema and code to handle this
in guardian-ldap and admin-api in sandbox/triplesec-jacc. It's
entirely possible I've missing something basic and there's a better
way to handle this.... but (obviously :-) I haven't seen it yet.
so the schema for the above is
attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.208
NAME 'permClassName'
DESC 'java class for a set of permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.209
NAME 'grant'
DESC 'name for a granted permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.210
NAME 'deny'
DESC 'name for a denied permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.211
NAME 'action'
DESC 'action for a permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.205 NAME 'permClass'
SUP top
AUXILIARY
MUST ( permClassName )
)
objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.206 NAME 'permGrant'
SUP top
AUXILIARY
MUST ( grant )
MAY ( action )
)
objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.207 NAME 'permDeny'
SUP top
AUXILIARY
MUST ( deny )
MAY ( action )
)
Note that there are two objectClasses that are the same structure,
permGrant and permDeny. This doesn't thrill me.
I guess another way to handle this is with another component in the
dn, something like:
dn:
roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc=e
xample, dc=com
objectClass: top
objectClass: policyRole
roleName: mockRole1
dn: permClassName=org.safehaus.triplesec.guardian.StringPermission,
roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc=e
xample, dc=com
objectClass: top
objectClass: permClass
permClassName: org.safehaus.triplesec.guardian.StringPermission
dn: permName=mockPerm0, ou=grants,
permClassName=org.safehaus.triplesec.guardian.StringPermission,
roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc=e
xample, dc=com
objectClass: top
objectClass: permName
grant: mockPerm0
with schema something like
attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.208
NAME 'permClassName'
DESC 'java class for a set of permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.209
NAME 'permName'
DESC 'name of a permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.211
NAME 'action'
DESC 'action for a permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.205 NAME 'permClass'
SUP top
AUXILIARY
MUST ( permClassName )
)
objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.206 NAME 'permName'
SUP top
AUXILIARY
MUST ( permName )
MAY ( action )
)
Is this a better design? I'm not convinced:
- it has the same number of object classes (we've replaced one of
permGrant and permDeny with the already existing ou)
- there's one more part in the dn
- there's nothing constraining ou to be grants or denials
- we're leaning on an object class we don't control (ou)
However since I'm a complete beginner here I'd certainly like to hear
more opinions.
many thanks
david jencks
<another big snip>
