On Aug 10, 2007, at 2:14 PM, Alex Karasulu wrote:
Hi David,
I just wanted to list some ideas that I have on how we can bridge
this gap
between simple language agnostic permissions presently in Triplesec
with
Java permissions.
First I want to stress why it is important to remain language and
platform
neutral and I think you will agree with this line of thought. Even
though the
server is written in Java on top of ApacheDS we want it to be
applicable for
use on any platform with any language. This way .NET, PHP and many
other clients can leverage the same system.
However as you noted, and I agree fully, in Java we need more than the
presence of a permission to determine if someone is authorized to
access
a resource or perform some operation. This is due to the open
ended nature
of evaluating the implies() method of a Java permission.
We can easily accommodate both this simplified use of permissions
while
allowing for the more complex cases where the implies() method is more
involved by extending the policyPermission objectClass. As you may
already
know we can create objectClass subtypes. I'm thinking we can create a
javaPermission subtype which inherits from policyPermission which
contains
the fully qualified class name of the permission implementation
along with
parameters used to initialize it. This can be used with the implies
() method
of the permission to reach access control decisions.
This looks a lot like what I did in my branch:
#
------------------------------------------------------------------------
-----
# Java permission support
#
------------------------------------------------------------------------
-----
attributetype ( 1.3.6.1.4.1.18060.0.4.6.2.208
NAME 'permJavaClass'
DESC 'the java class for a permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.18060.0.4.6.2.209
NAME 'permJavaName'
DESC 'the name of a java permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.18060.0.4.6.2.210
NAME 'permJavaActions'
DESC 'the actions of a java permission'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
objectclass ( 1.3.6.1.4.1.18060.0.4.6.3.205 NAME 'javaPermission'
SUP top
AUXILIARY
MUST ( permJavaClass $ permJavaName )
MAY ( permJavaActions )
)
but I don't think I understand the "subtype" idea. What would I do
to make this a subtype of policyPermission? What is the advantage of
making this a subtype of policyPermission rather than an independent
objectclass?
thanks
david jencks
n.b. the oids are not final, obviously :-)
This is something I would like to do along with reading and fully
evaluating
that NIST paper so I can then look into the best way to model roles/
groups
in Triplesec.
Alex
