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: <[email protected]>
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]
