I don't know whether the POLICY-26 proposal has been accepted. I think POLICY-26 is a bit clearer in conveying the meaning of the different choices than Venkat's proposal.
While POLICY-26 fixes the schema so that conflicting authorization elements cannot be specified within a policy set, it does not address what should happen when authorization policy is inherited across levels. The framework says policy sets are additive and clearly this can result in conflicts. I guess one could say that this is an error in the composite. However that limits the use of inheritance for this type of policy because then one can't establish a default policy for the composite and override for particular components. On Mon, Apr 21, 2008 at 7:30 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I assume you are implementing the syntax in OSOA SCA spec 1.0. Do we know > if http://www.osoa.org/jira/browse/POLICY-26 is an officially accepted > proposal? > > Thanks, > Raymond > -------------------------------------------------- > From: "Venkata Krishnan" <[EMAIL PROTECTED]> > Sent: Monday, April 21, 2008 12:20 AM > To: <tuscany-dev@ws.apache.org> > Subject: Re: Authentication & Authorization across wsBinding & java > Implementation - was : Using security policies in the Bigbank scenario > > > Hi, > > > > With r650032, I have committed some simple additions to support the > > model > > and StaX processor for the bunch of policy assertions specified in > > section > > 1.7.3-Implementation-Security-Policy of the PolicyFwk Specs. > > > > I'd wish to optimize this a bit and cut down on some classes in the > > future. > > As a start for this here is a question related to the specs and hope > > somebody is able to help me with some clarity... > > > > - Do we need three assertions viz. permitAll, denyAll, allow. Why not > > just > > the one as follows: - > > <allow roles="listOfNCNames" permitAll="xs:boolean"/> > > > > So if permitAll is 'true' then all roles is permitted. If it is false > > then > > only those roles in the 'roles' attribute is permitted. If it is false > > and > > there aren't any roles specified then it is equivalent to 'denyAll'. > > > > Thanks > > > > - Venkat > > > > On Thu, Mar 6, 2008 at 11:43 PM, Greg Dritschler < > > [EMAIL PROTECTED]> > > wrote: > > > > Ok. Please be aware there is an errata associated with the > > > authorization > > > elements. > > > http://www.osoa.org/jira/browse/POLICY-26 > > > > > > On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan < > > > [EMAIL PROTECTED]> > > > wrote: > > > > > > > +1. I will start looking into this after I am done with some > > > > half-finished > > > > things on my plate at the moment. Thanks. > > > > > > > > - Venkat > > > > > > > > On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino < > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > Greg Dritschler wrote: > > > > > > Is the authentication policy going to bear any resemblance to > > > the > > > > policy > > > > > > described in section 1.7.3.1 of the Policy spec, or is it > > > > > > completely > > > > > > different? > > > > > > > > > > > > Greg > > > > > > > > > > > > > > > > I think that Tuscany should implement the authorization - I guess > > > that's > > > > > what you meant :) - and security identity policies as described in > > > > > section 1.7.3.1 of the Policy spec, at least. > > > > > > > > > > We could start with just implementing the model and XML reading > > > for > > > the > > > > > elements described in 1.7.3.1 and let the various component > > > > > implementation extensions handle them (or not) in their own way, > > > but > > > > > having the model and XML processors would be a good start IMO. > > > > > > > > > > Any thoughts? > > > > > -- > > > > > Jean-Sebastien > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
