Anyway, I checked in the updated model and processors under
http://svn.apache.org/viewvc?rev=650652&view=rev. The processors can handle
both syntax. Please see the ProcessorTestCase.
Thanks,
Raymond
--------------------------------------------------
From: "Greg Dritschler" <[EMAIL PROTECTED]>
Sent: Wednesday, April 23, 2008 8:26 AM
To: <tuscany-dev@ws.apache.org>
Subject: Re: Authentication & Authorization across wsBinding & java
Implementation - was : Using security policies in the Bigbank scenario
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]
