-
Key: CSIV2-18
-
Legacy Issue Number: 4282
-
Status: closed
-
Source: Oracle ( Ron Monzillo)
-
Summary:
The CSIv2 mechanism definition schema, soes not provide a way to
associate mechanisms with subsets of the methods of an object.Discussion
EJB method-permissions may be associated with subsets of methods, such
that a class of EJB objects may have some protected and some unprotected
methods. Where by protection I mean, the caller must be authenticated
and be in a authorized role, to access the method. Some methods of an
EJB may be available to unauthenticated callers, while others may limit
access to only specific authenticated callers.Given a mixed protection object, how would one define its IOR such that
it could be affectively accessed by its clients without1. eliminating unauthenticated access to the object
that is, mark the target as authentication required
2. causing unnecessary authentications and usurping the
clients perogative to only authenticate when it is required to or
chooses to.that is, mark the target as authentication supported and tell the
client to authenticate if it can3. causing failed attempts because the client does not know that
the target requires authenticationthat is, mark the target as authentication supported and let the
client authenticate if it wants toWould it be appropriate to add information to the IOR, that indicates
that whether the object will check permissions, such that a client
normally operating in mode 3, would know when it would probably do
better in mode 2?Should a CSIv2 IOR which principally defines (authentication and msg
protection mechanisms) carry additional information about the
authorization policy of the object? There is obviously some precedent
for doing so in the privilege authorities field. -
Reported: CSIv2 1.0b1 — Tue, 24 Apr 2001 04:00 GMT
-
Disposition: Resolved — CSIv2 1.0
-
Disposition Summary:
Close issue with no change as this does not apply to CSIv2
-
Updated: Fri, 6 Mar 2015 20:58 GMT