David Jencks a écrit :
Right now triplesec is basically using strings as permissions, and
they are stored as multi-valued attributes like so:
objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.203 NAME 'policyRole'
SUP top
AUXILIARY
MUST ( roleName )
MAY ( grants $ denials $ description ) )
objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.204 NAME 'policyProfile'
SUP top
AUXILIARY
MUST ( profileId $ user )
MAY ( grants $ denials $ roles $ userPassword $ description $
safehausDisabled ) )
or as a bit of ldif:
dn:
roleName=mockRole5,ou=roles,appName=mockApplication,ou=applications,dc=e
xample,dc=com
objectClass: top
objectClass: policyRole
grants: mockPerm9
grants: mockPerm7
grants: mockPerm5
grants: mockPerm4
denials: mockPerm6
roleName: mockRole5
(this includes my local modification so roles can have denials).
After looking around at java.security.Permissions I think we can
store 99% of them with 3 strings:
className
permissionName
action
and possibly depending on how ldap datamodels work
grant/deny
Within a role or profile, these 3 or 4 strings are needed to get a
unique permission.
I've been trying to learn about ldap schemas, the data model, ldif,
etc by figuring out how to fit this info into ldap but I'm pretty
bewildered and maybe someone with non-zero experience could review
and improve my suggestion below or suggest how to proceed.
It looks to me as if one way to proceed would be to have the
className with permissionNames grouped under each labelled grant or
deny, then with the actions as attributes on the permission. Does
the following schema do this?
attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.abc
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.abc NAME 'className'
SUP top
AUXILIARY
objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.def NAME 'grant'
SUP top
AUXILIARY
MAY ( action )
objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.ghi NAME 'deny'
SUP top
AUXILIARY
MAY ( action )
I'm imagining a dn something like
grant=/servlet/
*,permissionClass=javax.security.jacc.WebResourcePermission,roleName=peo
n,applicationName=foo,....
with attributes like
action=POST,GET
action=INDEX
Some of my other questions are... AUXILIARY or STRUCTURAL?
Well, not easy... AUXILIARY is use for ObjectClasses that extends a
SRUCTURAL ObjectClass. Entries should implement a STRUCTURAL
ObjectClass. You are not supposed to instanciate an AUXILIARY
ObjectClass. So, basically, STRUCTURAL if you want to instanciate
entries from it.
What if anything ties the object classes together in a tree, so e.g.
grant and deny occur "inside" className? Should there be MAY ( grant
$ deny) in the className objectclass?
If Grant and Deny are ObjectClass, they can't be declared in MAY or
MUST, becuase MAY and MUST only contains attributes, not ObjectClasses
The actions and possibly the grant/deny are likely to have lots of
bizarre punctuation, such as the commas in the example above. How
does one deal with that in ldap?
It depends. Just pick the syntax that best fit your needs, and here, it
should be something like IA5String, OctetString or PrintableString. You
have a list of all syntaxes here :
http://cwiki.apache.org/confluence/display/DIRxSRVx11/Schema+Checking.
If you have commas, you will have to escape them using \ in a DN. You
can also use " " around the dn to avoid escaping special chars like ,
and + and ;
Many thanks for any help, and I hope this isn't too much of a user
list question :-)
np, and I hope it helps :)
thanks
david jencks
