You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2008/04/21 09:20:33 UTC
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 <gr...@gmail.com>
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 <fo...@gmail.com>
> 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 <
> > jsdelfino@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Posted by Raymond Feng <en...@gmail.com>.
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" <gr...@gmail.com>
Sent: Wednesday, April 23, 2008 8:26 AM
To: <tu...@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 <en...@gmail.com> 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" <fo...@gmail.com>
>> Sent: Monday, April 21, 2008 12:20 AM
>> To: <tu...@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 <
>> > greg.dritschler@gmail.com>
>> > 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 <
>> > > for.svkrish@gmail.com>
>> > > 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 <
>> > > > jsdelfino@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> >
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Posted by Greg Dritschler <gr...@gmail.com>.
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 <en...@gmail.com> 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" <fo...@gmail.com>
> Sent: Monday, April 21, 2008 12:20 AM
> To: <tu...@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 <
> > greg.dritschler@gmail.com>
> > 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 <
> > > for.svkrish@gmail.com>
> > > 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 <
> > > > jsdelfino@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Posted by Raymond Feng <en...@gmail.com>.
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" <fo...@gmail.com>
Sent: Monday, April 21, 2008 12:20 AM
To: <tu...@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
> <gr...@gmail.com>
> 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 <fo...@gmail.com>
>> 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 <
>> > jsdelfino@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > >
>> > >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org