On Aug 11, 2007, at 12:59 AM, Alex Karasulu wrote:
Hi David,
On 8/10/07, David Jencks <[EMAIL PROTECTED]> wrote:
SNIP ...
> 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.
Yeah I think you missed it here. Basically your javaPermission
class would
extend the policyPermission objectClass using the SUP property
above and
hence would not need to have permJavaName like so:
objectclass ( 1.3.6.1.4.1.18060.0.4.6.3.205 NAME 'javaPermission'
SUP policyPermission
AUXILIARY
MUST ( permJavaClass )
MAY ( permJavaActions )
)
What would I do
to make this a subtype of policyPermission?
Answer is above.
What is the advantage of
making this a subtype of policyPermission rather than an independent
objectclass?
This would allow the system to treat all permissions the same when
a non-java
client is pulling policy information. Depending on the permission
implementation
this may result in correct or incorrect evaluation by a non-java
client which may
just ignore this information. However nothing would break because
schema wise
it would still be a policy permission and handled accordingly
instead of requiring
special handling code in non-Java clients.
Java clients may then recognize special JSE based permissions and
handle them
accordingly in addition to handling simple policy permissions in
the guardian API.
The divide we're dealing with here comes from the fact that we have
two kinds of
permissions which can be considered by Java clients:
1). Simple binary permissions whose evaluation is based on their
existing or not existing
to authorize access
2). JSE permissions which require implies() evaluation to
authorize access
Some applications will never need JSE permissions and would most
likely prefer this
simpler model. However in your case with the JACC implementation
we need to factor
in the J2E permission's implies() method to evaluate authorization
decisions.
Many will choose the simpler route especially if the same policy
information needs to
be accessed through different languages since the implies() method
cannot be evaluated
by non-Java clients.
I'm not sure this is the whole picture. My impression was that the
policyPermission name attribute had to uniquely identify the
permission within its parent. This would mean that it can't be the
same as the permJavaName which is definitely not a unique id under
any circumstances: you actually need the permJavaClass, the
permJavaName, and the permJavaActions to completely identify a
permission. So, in my copy of the schema, permName is described as
likely to be meaningless:
attributetype ( 1.3.6.1.4.1.18060.0.4.6.2.201
NAME 'permName'
DESC 'the case sensitive name of a permission within the
system, often a meaningless unique id'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
Given this, what advantage is it to have javaPermission subclass
policyPermission? It seems to me that the only effect is to prevent
using javaPermission in other contexts where it might turn out to be
useful.
thanks
david jencks
HTH,
Alex
