Issue 4282: Inability to specify per method target security requirements (csiv2-ftf) Source: Oracle (Mr. Ron Monzillo, ronald.monzillo(at)east.sun.com) Nature: Uncategorized Issue Severity: 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 without 1. 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 can 3. causing failed attempts because the client does not know that the target requires authentication that is, mark the target as authentication supported and let the client authenticate if it wants to Would 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. Resolution: Close issue with no change as this does not apply to CSIv2 Revised Text: Actions taken: April 24, 2001: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== Date: Tue, 24 Apr 2001 19:36:02 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org CC: csiv2-ftf@omg.org Subject: Inability to specify per method target security requirements Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: HI2e9ObWd9d\0e9HY4!! base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf 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 without 1. 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 can 3. causing failed attempts because the client does not know that the target requires authentication that is, mark the target as authentication supported and let the client authenticate if it wants to Would 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. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 26 Apr 2001 03:56:15 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: , Subject: Re: Inability to specify per method target security requirements In-Reply-To: <3AE60DE2.96CD7EAC@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: H]8!!k<@e9jQ`!!;Yn!! We have worked on systems (research) that had the capability that Sun is stating in this issue. They way we solved this problem was for the target to advertise it:s security mechanisms in its IOR as it is down now. The policy in which governes the by method characteristices of talking to a method was handled by a third party, as the characteristics for speaking at different methods could change without changing the IORs. Also putting this kind of information into an IOR would really make it blow up. Cheers from Paris. Man the food is great here! -Polar On Tue, 24 Apr 2001, Ron Monzillo wrote: > base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf > > 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 without > > 1. 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 can > > 3. causing failed attempts because the client does not know that > the target requires authentication > > that is, mark the target as authentication supported and let the > client authenticate if it wants to > > Would 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. > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com > 8. I'd like to have a little more discussion on Issue 4282: Inability to > specify per method target security requirements, however, it might be > prudent at this stage to > just defer this issue. If we chose to discuss it further, I would like > us to consider > the merit of adding an ability to mark an IOR as leading to an object > whose methods are differentially protected with respect to > authentication. Doing so, might allow us > to affect client side authentication policy, when authentication is not > required by the target.