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 2007/11/26 11:51:15 UTC
Policy Framework Scenarios.
Hi,
Most part of the core policy framework now implemented except for the thing
that deals with evaluating the 'appliesTo' xpath against the SCDL which is a
bit incomplete. I hope to wrap this too in a week.
Meanwhile, I'd like to whet and evolve whatever has been done with different
user perspectives... so here are some perspectives I could think of... could
people kindly help with their opinions and inputs on this, please.... also
if any of you have other scenarios or ways of approaching this... please
pitch in...
A) Perspective of Policy Administrator ....
------------------------------------------------------------
- defines a bunch of intents and policysets for the domain, in the
definitions.xml
- profiles the various binding-types and implementation-types for the
various intents it 'mustProvide' and 'mayProvide'
1) How does the Policy-Admin know from a binding/impl type about the
intents that it provides for ? Should every binding/impl type have its own
definitions.xml file where it publishes this information ? The specs says
that there is just this one file for the entire SCA domain - have I got it
wrong?
2)What about the bunch of intents that the spec states as something that
would be supported by every SCA Runtime such as authentication,
confidentiality, integrity etc. Since it makes no sense to have every
binding/impl type to define this as well, should we have a global
definitions.xml in the core module where we define these ?
3) A binding / implementation type could have its own custom model of
representing policies within policysets and interpretting them. For example
the ws-binding-axis2 use config param model (which is custom made) and
ws-policy assertion model (which is a standard) to represent policies. How
should this model information be communicated to the Policy Admin in a
standard way that is consistent across binding/impl types? If we allow
every binding/impl type to have its own definitions.xml then could this also
contain the xsd for the policy model?
B) Perspective of Binding/Impl type developer ...
---------------------------------------------------------------------
- defines the intents and xsds for the policy model that the binding/impl
type will use
- defines the StAX processors for loading the policy model that the
binding/impl type will use
- adds code to interpret various policies and exercise them.
1) Do we leave the design for this to every binding / implementation
type or do we put in a programming model that is to be common across all
binding/impl types? I'd feel it would be better to leave it to the
bindings/impl extension because each extension will have its own way of
implementing various QoS and how it would interface with a QoS
infrastructure as part of its (i.e. the extension's) lifecycle. For example
the binding-ws-axis2 injects security related policies into the axis2-config
during the service and client creation time and does nothing specific during
invocation of service operations.
Sorry about making this very long.
Thanks
- Venkat
Re: Policy Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Venkata Krishnan"
> <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Monday, November 26, 2007 2:51 AM
> Subject: Policy Framework Scenarios.
>
>
>> Hi,
>>
>> Most part of the core policy framework now implemented except for the
>> thing
>> that deals with evaluating the 'appliesTo' xpath against the SCDL
>> which is a
>> bit incomplete. I hope to wrap this too in a week.
>
> IMO, it's a bit challenging from two perspectives to apply the xpath:
> 1) The xpath needs to apply to an XML sub tree in the SCDL.
> 2) We need to deal with XML inheritance/subsitutionGroup, for example,
> the xpath "sca:implementation" will match "sca:implementation.java".
>
My suggestion: let's get a concrete scenario working first (a little
more concrete than helloworld, I'm going to propose one in a separate
email to this thread), and let's see how appliesTo is used in this
context before engaging in a struggle to complete its implementation.
Who knows, maybe we'll find that we don't need it, maybe we'll raise
issues to the spec that will cause it to change, or maybe we'll find
that we really need that xpath... but I think we'll have a much better
understanding of this after we go through a concrete policy usage scenario.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Framework Scenarios.
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Monday, November 26, 2007 2:51 AM
Subject: Policy Framework Scenarios.
> Hi,
>
> Most part of the core policy framework now implemented except for the
> thing
> that deals with evaluating the 'appliesTo' xpath against the SCDL which is
> a
> bit incomplete. I hope to wrap this too in a week.
IMO, it's a bit challenging from two perspectives to apply the xpath:
1) The xpath needs to apply to an XML sub tree in the SCDL.
2) We need to deal with XML inheritance/subsitutionGroup, for example, the
xpath "sca:implementation" will match "sca:implementation.java".
>
> Meanwhile, I'd like to whet and evolve whatever has been done with
> different
> user perspectives... so here are some perspectives I could think of...
> could
> people kindly help with their opinions and inputs on this, please.... also
> if any of you have other scenarios or ways of approaching this... please
> pitch in...
>
> A) Perspective of Policy Administrator ....
> ------------------------------------------------------------
> - defines a bunch of intents and policysets for the domain, in the
> definitions.xml
> - profiles the various binding-types and implementation-types for the
> various intents it 'mustProvide' and 'mayProvide'
> 1) How does the Policy-Admin know from a binding/impl type about the
> intents that it provides for ? Should every binding/impl type have its
> own
> definitions.xml file where it publishes this information ? The specs says
> that there is just this one file for the entire SCA domain - have I got it
> wrong?
> 2)What about the bunch of intents that the spec states as something
> that
> would be supported by every SCA Runtime such as authentication,
> confidentiality, integrity etc. Since it makes no sense to have every
> binding/impl type to define this as well, should we have a global
> definitions.xml in the core module where we define these ?
> 3) A binding / implementation type could have its own custom model of
> representing policies within policysets and interpretting them. For
> example
> the ws-binding-axis2 use config param model (which is custom made) and
> ws-policy assertion model (which is a standard) to represent policies.
> How
> should this model information be communicated to the Policy Admin in a
> standard way that is consistent across binding/impl types? If we allow
> every binding/impl type to have its own definitions.xml then could this
> also
> contain the xsd for the policy model?
I don't think a global definitions.xml will fly. There are a few players in
the picture:
a) Intent: Define the abstract requirements
b) PolicySet: Define the concrete configuration of policies that can be used
to realized one or more intents
c) ImplementationType and BindingType: Define the intents that an
implementation or binding type always provides or may provide.
a) should be provided by Tuscany core runtime and extensions, for example,
the policy-transaction module will package the intent definitions for
transactions.
b) should be contribution-based. Different contributions should be able to
configure an intent differently. For example, for authentication, we may
configure different userid/password pairs and for authorization, we may
select different roles.
c) should be provided by the Implementation/Binding extensions
>
> B) Perspective of Binding/Impl type developer ...
> ---------------------------------------------------------------------
> - defines the intents and xsds for the policy model that the binding/impl
> type will use
> - defines the StAX processors for loading the policy model that the
> binding/impl type will use
> - adds code to interpret various policies and exercise them.
> 1) Do we leave the design for this to every binding / implementation
> type or do we put in a programming model that is to be common across all
> binding/impl types? I'd feel it would be better to leave it to the
> bindings/impl extension because each extension will have its own way of
> implementing various QoS and how it would interface with a QoS
> infrastructure as part of its (i.e. the extension's) lifecycle. For
> example
> the binding-ws-axis2 injects security related policies into the
> axis2-config
> during the service and client creation time and does nothing specific
> during
> invocation of service operations.
>
> Sorry about making this very long.
>
> Thanks
> - Venkat
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien, am working on this and should be done today. Am just about
taking a bit of time to fit this into our existing ContributionService
implementation.
- Venkat
On Feb 6, 2008 12:49 PM, Venkata Krishnan <fo...@gmail.com> wrote:
> Ok, let me go try this and post back. I'd like to vary this a bit - but
> let me have some code to talk about.
>
> Meanwhile, I did get ahead with my proposal but did not quite like the way
> I had to pass the CompositeProcessor all the way from the Runtime down to
> the builders. It seemed very hacky.
>
> - Venkat
>
>
> On Feb 6, 2008 5:54 AM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
> > >> Jean-Sebastien Delfino wrote:
> > >> Reading the composite file / building its model / re-writing it to
> > >> finally apply the xpath sounds very complicated.
> > >>
> > >> As an application developer I'll write the appliesTo xpath to match
> > what
> > >> I see in a composite XML file. Why can't we simply run the xpath on
> > that
> > >> original XML file before doing all the other steps?
> > >>
> > > Venkata Krishnan wrote:
> > >
> > > We will not be writing the entire composite, but only a fragment that
> > is the
> > > parent of the intentAttachPoint. Here is what the spec says : -
> > >
> > > 283 ..................................................Note that the
> > XPath
> > > expression will always be evaluated
> > > 284 within the context of an attachment considering elements where
> > binding
> > > instances or
> > > 285 implementations are allowed to be present. The expression is
> > evaluated
> > > against the parent element
> > > 286 of any binding or implementation element.
> > > ..........................................................
> > >
> > > But then, it seems like we may have to look beyond the immediate
> > parent or
> > > maybe the entire composite if your proposal is to be taken.
> >
> > Yes, but it's not incompatible. Here are some examples:
> > appliesTo="binding.ws"
> > appliesTo="service[@name='AccountService']"
> > appliesTo="../component[@name='AccountServiceComponent']"
> >
> > appliesTo="/composite[@name='bigbank']/component[@name='AccountServiceComponent']"
> >
> > By default you are in the parent of a binding or implementation, but can
> > use .. or / to go up.
> >
> > > I'd like to hear some perspectives from the specs folks on this.
> > >
> > > Now, getting to your question more specifically on why this must be
> > done
> > > post-build phase, here it is....
> > > - Firstly we need the PolicySet definitions to get hold of the
> > > 'appliesTo'.
> > > - For PolicySets that are specified in the composite, they are
> > resolved
> > > during the resolution phase.
> > > - For those that have to be calculated based on the Intents
> > specified,
> > > there needs to be a complete assembly model that is wired, since we
> > also
> > > need to take into account the target's intents. This wiring is being
> > done
> > > on the 'wireComposite' method of the CompositeWireBuilder.
> > > - So the calculation of PolicySets is pushed to this point i.e. its
> > being
> > > done as part of the 'wireComposite' method, the moment the model has
> > all its
> > > connections resolved.
> > > - Only after the PolicySets are calculated, do we have a handle on
> > the
> > > 'appliesTo' attribute of the PolicySets.
> > >
> >
> > How about this:
> > load the definitions.xml files declaring policySets.
> > for each policyset
> > prepend /*/*/ to its appliesTo xpath
> > for each composite XML file
> > run the xpath expression against the file
> > for each matching element
> > add the policySet to an imaginary "applicablePolicySets" attribute
> > end
> > end
> > end
> >
> > Then later when you run the composite processors, builders etc, use the
> > intents + policySets + applicablePolicySets attributes to figure the
> > effective policySets.
> >
> > This should provide the best of both worlds:
> > - xpath expressions evaluated against the real authored XML artifacts
> > - support for the intent/policySet matching algorithm from the spec
> >
> > Makes sense?
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Ok, let me go try this and post back. I'd like to vary this a bit - but let
me have some code to talk about.
Meanwhile, I did get ahead with my proposal but did not quite like the way I
had to pass the CompositeProcessor all the way from the Runtime down to the
builders. It seemed very hacky.
- Venkat
On Feb 6, 2008 5:54 AM, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >> Jean-Sebastien Delfino wrote:
> >> Reading the composite file / building its model / re-writing it to
> >> finally apply the xpath sounds very complicated.
> >>
> >> As an application developer I'll write the appliesTo xpath to match
> what
> >> I see in a composite XML file. Why can't we simply run the xpath on
> that
> >> original XML file before doing all the other steps?
> >>
> > Venkata Krishnan wrote:
> >
> > We will not be writing the entire composite, but only a fragment that is
> the
> > parent of the intentAttachPoint. Here is what the spec says : -
> >
> > 283 ..................................................Note that the
> XPath
> > expression will always be evaluated
> > 284 within the context of an attachment considering elements where
> binding
> > instances or
> > 285 implementations are allowed to be present. The expression is
> evaluated
> > against the parent element
> > 286 of any binding or implementation element.
> > ..........................................................
> >
> > But then, it seems like we may have to look beyond the immediate parent
> or
> > maybe the entire composite if your proposal is to be taken.
>
> Yes, but it's not incompatible. Here are some examples:
> appliesTo="binding.ws"
> appliesTo="service[@name='AccountService']"
> appliesTo="../component[@name='AccountServiceComponent']"
>
> appliesTo="/composite[@name='bigbank']/component[@name='AccountServiceComponent']"
>
> By default you are in the parent of a binding or implementation, but can
> use .. or / to go up.
>
> > I'd like to hear some perspectives from the specs folks on this.
> >
> > Now, getting to your question more specifically on why this must be done
> > post-build phase, here it is....
> > - Firstly we need the PolicySet definitions to get hold of the
> > 'appliesTo'.
> > - For PolicySets that are specified in the composite, they are resolved
> > during the resolution phase.
> > - For those that have to be calculated based on the Intents specified,
> > there needs to be a complete assembly model that is wired, since we also
> > need to take into account the target's intents. This wiring is being
> done
> > on the 'wireComposite' method of the CompositeWireBuilder.
> > - So the calculation of PolicySets is pushed to this point i.e. its
> being
> > done as part of the 'wireComposite' method, the moment the model has all
> its
> > connections resolved.
> > - Only after the PolicySets are calculated, do we have a handle on the
> > 'appliesTo' attribute of the PolicySets.
> >
>
> How about this:
> load the definitions.xml files declaring policySets.
> for each policyset
> prepend /*/*/ to its appliesTo xpath
> for each composite XML file
> run the xpath expression against the file
> for each matching element
> add the policySet to an imaginary "applicablePolicySets" attribute
> end
> end
> end
>
> Then later when you run the composite processors, builders etc, use the
> intents + policySets + applicablePolicySets attributes to figure the
> effective policySets.
>
> This should provide the best of both worlds:
> - xpath expressions evaluated against the real authored XML artifacts
> - support for the intent/policySet matching algorithm from the spec
>
> Makes sense?
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
.. meanwhile... I have started to make some changes locally to see if what I
am proposing about pulling the builder into a module and using the wirters
to write relevant fragments of SCDL, is feasible...
- Venkat
On Feb 5, 2008 3:52 PM, Venkata Krishnan <fo...@gmail.com> wrote:
> On Feb 5, 2008 2:38 PM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
> > Venkata Krishnan wrote:
> > > From the history of this mail, I suspect that you haven't got my post
> > in
> > > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html.
> > I am
> > > certainly eager to fix this. Let me know your thoughts on what I
> > have
> > > asked there. Thanks.
> > >
> >
> > Sorry, it's weird, I never received your post.
> >
> > > Venkata Krishnan wrote:
> > > The only issue standing in the way is of how we get hold of the SCDL
> > > over which the xpath in 'appliesTo' can be applied. I'd like to use
> > > our assembly model writers to write back an SCA artifact (component
> > or
> > > service ... ) as XML and then apply the xpath in appliesTo over this
> > > XML. All this must be done in the policyset matching phase.
> >
> > Reading the composite file / building its model / re-writing it to
> > finally apply the xpath sounds very complicated.
> >
>
> > As an application developer I'll write the appliesTo xpath to match what
> > I see in a composite XML file. Why can't we simply run the xpath on that
> > original XML file before doing all the other steps?
> >
>
> We will not be writing the entire composite, but only a fragment that is
> the parent of the intentAttachPoint. Here is what the spec says : -
>
> 283 ..................................................Note that the XPath
> expression will always be evaluated
> 284 within the context of an attachment considering elements where binding
> instances or
> 285 implementations are allowed to be present. The expression is evaluated
> against the parent element
> 286 of any binding or implementation element.
> ..........................................................
>
> But then, it seems like we may have to look beyond the immediate parent or
> maybe the entire composite if your proposal is to be taken. I'd like to
> hear some perspectives from the specs folks on this.
>
> Now, getting to your question more specifically on why this must be done
> post-build phase, here it is....
> - Firstly we need the PolicySet definitions to get hold of the
> 'appliesTo'.
> - For PolicySets that are specified in the composite, they are resolved
> during the resolution phase.
> - For those that have to be calculated based on the Intents specified,
> there needs to be a complete assembly model that is wired, since we also
> need to take into account the target's intents. This wiring is being done
> on the 'wireComposite' method of the CompositeWireBuilder.
> - So the calculation of PolicySets is pushed to this point i.e. its being
> done as part of the 'wireComposite' method, the moment the model has all its
> connections resolved.
> - Only after the PolicySets are calculated, do we have a handle on the
> 'appliesTo' attribute of the PolicySets.
>
> Let me know if you like me to explain a little more. Thanks
>
> - Venkat
>
>
>
>
> >
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
>> Jean-Sebastien Delfino wrote:
>> Reading the composite file / building its model / re-writing it to
>> finally apply the xpath sounds very complicated.
>>
>> As an application developer I'll write the appliesTo xpath to match what
>> I see in a composite XML file. Why can't we simply run the xpath on that
>> original XML file before doing all the other steps?
>>
> Venkata Krishnan wrote:
>
> We will not be writing the entire composite, but only a fragment that is the
> parent of the intentAttachPoint. Here is what the spec says : -
>
> 283 ..................................................Note that the XPath
> expression will always be evaluated
> 284 within the context of an attachment considering elements where binding
> instances or
> 285 implementations are allowed to be present. The expression is evaluated
> against the parent element
> 286 of any binding or implementation element.
> ..........................................................
>
> But then, it seems like we may have to look beyond the immediate parent or
> maybe the entire composite if your proposal is to be taken.
Yes, but it's not incompatible. Here are some examples:
appliesTo="binding.ws"
appliesTo="service[@name='AccountService']"
appliesTo="../component[@name='AccountServiceComponent']"
appliesTo="/composite[@name='bigbank']/component[@name='AccountServiceComponent']"
By default you are in the parent of a binding or implementation, but can
use .. or / to go up.
> I'd like to hear some perspectives from the specs folks on this.
>
> Now, getting to your question more specifically on why this must be done
> post-build phase, here it is....
> - Firstly we need the PolicySet definitions to get hold of the
> 'appliesTo'.
> - For PolicySets that are specified in the composite, they are resolved
> during the resolution phase.
> - For those that have to be calculated based on the Intents specified,
> there needs to be a complete assembly model that is wired, since we also
> need to take into account the target's intents. This wiring is being done
> on the 'wireComposite' method of the CompositeWireBuilder.
> - So the calculation of PolicySets is pushed to this point i.e. its being
> done as part of the 'wireComposite' method, the moment the model has all its
> connections resolved.
> - Only after the PolicySets are calculated, do we have a handle on the
> 'appliesTo' attribute of the PolicySets.
>
How about this:
load the definitions.xml files declaring policySets.
for each policyset
prepend /*/*/ to its appliesTo xpath
for each composite XML file
run the xpath expression against the file
for each matching element
add the policySet to an imaginary "applicablePolicySets" attribute
end
end
end
Then later when you run the composite processors, builders etc, use the
intents + policySets + applicablePolicySets attributes to figure the
effective policySets.
This should provide the best of both worlds:
- xpath expressions evaluated against the real authored XML artifacts
- support for the intent/policySet matching algorithm from the spec
Makes sense?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
On Feb 5, 2008 2:38 PM, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Venkata Krishnan wrote:
> > From the history of this mail, I suspect that you haven't got my post in
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html.
> I am
> > certainly eager to fix this. Let me know your thoughts on what I have
> > asked there. Thanks.
> >
>
> Sorry, it's weird, I never received your post.
>
> > Venkata Krishnan wrote:
> > The only issue standing in the way is of how we get hold of the SCDL
> > over which the xpath in 'appliesTo' can be applied. I'd like to use
> > our assembly model writers to write back an SCA artifact (component or
> > service ... ) as XML and then apply the xpath in appliesTo over this
> > XML. All this must be done in the policyset matching phase.
>
> Reading the composite file / building its model / re-writing it to
> finally apply the xpath sounds very complicated.
>
> As an application developer I'll write the appliesTo xpath to match what
> I see in a composite XML file. Why can't we simply run the xpath on that
> original XML file before doing all the other steps?
>
We will not be writing the entire composite, but only a fragment that is the
parent of the intentAttachPoint. Here is what the spec says : -
283 ..................................................Note that the XPath
expression will always be evaluated
284 within the context of an attachment considering elements where binding
instances or
285 implementations are allowed to be present. The expression is evaluated
against the parent element
286 of any binding or implementation element.
..........................................................
But then, it seems like we may have to look beyond the immediate parent or
maybe the entire composite if your proposal is to be taken. I'd like to
hear some perspectives from the specs folks on this.
Now, getting to your question more specifically on why this must be done
post-build phase, here it is....
- Firstly we need the PolicySet definitions to get hold of the
'appliesTo'.
- For PolicySets that are specified in the composite, they are resolved
during the resolution phase.
- For those that have to be calculated based on the Intents specified,
there needs to be a complete assembly model that is wired, since we also
need to take into account the target's intents. This wiring is being done
on the 'wireComposite' method of the CompositeWireBuilder.
- So the calculation of PolicySets is pushed to this point i.e. its being
done as part of the 'wireComposite' method, the moment the model has all its
connections resolved.
- Only after the PolicySets are calculated, do we have a handle on the
'appliesTo' attribute of the PolicySets.
Let me know if you like me to explain a little more. Thanks
- Venkat
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> From the history of this mail, I suspect that you haven't got my post in
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html. I am
> certainly eager to fix this. Let me know your thoughts on what I have
> asked there. Thanks.
>
Sorry, it's weird, I never received your post.
> Venkata Krishnan wrote:
> The only issue standing in the way is of how we get hold of the SCDL
> over which the xpath in 'appliesTo' can be applied. I'd like to use
> our assembly model writers to write back an SCA artifact (component or
> service ... ) as XML and then apply the xpath in appliesTo over this
> XML. All this must be done in the policyset matching phase.
Reading the composite file / building its model / re-writing it to
finally apply the xpath sounds very complicated.
As an application developer I'll write the appliesTo xpath to match what
I see in a composite XML file. Why can't we simply run the xpath on that
original XML file before doing all the other steps?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien,
>From the history of this mail, I suspect that you haven't got my post in
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html. I am
certainly eager to fix this. Let me know your thoughts on what I have
asked there. Thanks.
On Feb 3, 2008 12:50 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Jean-Sebastien Delfino wrote:
> > Venkata Krishnan wrote:
> >>> - Why did you need two authentication and wsAuthentication intents? is
> >>> it because you needed different policy sets on the client and service
> >>> side?
> >>>
> >>
> >> Yes, that's the reason. Since the policysets encapsulate things like
> the
> >> username, password callback hander etc. which could be different for
> the
> >> client and the server there needed to be different policysets. Having
> >> the
> >> same intent does no guarantee that the right policyset will be matched
> >> i.e.
> >> the client's policyset for the reference and the server's policyset
> >> for the
> >> service. Having unique intents will ensure this mapping.
> >
> > After looking at this again today I think that having different custom
> > authentication intents defeats the purpose of intents, turning them into
> > disguised policySets as they become specific to the particular config of
> > authentication in parts of your network.
> >
> > We need a different approach:
> > - keep intents abstract (authentication)
> > - declare where different policySets providing authentication should be
> > applied in the composition.
> >
> > PolicySet/appliesTo already provides a way to scope the application of a
> > policySet. Can we just use that?
> >
> > Some examples:
> > appliesTo="binding.ws"
> > appliesTo="service[@name='AccountService']"
> > appliesTo="../component[@name='AccountServiceComponent']"
> >
> > Thoughts?
>
> Following up as nobody has posted any further thoughts.
>
> Is the above proposal clear?
>
> Does anybody want to try to fix the policy story or do you want me to do
> it?
>
> Also, in my opinion having two bigbank samples is overkill. I think we
> should just add the policy configuration to the original bigbank instead
> of having a secure-bigbank duplicating bigbank. Any objections?
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Venkata Krishnan wrote:
>>> - Why did you need two authentication and wsAuthentication intents? is
>>> it because you needed different policy sets on the client and service
>>> side?
>>>
>>
>> Yes, that's the reason. Since the policysets encapsulate things like the
>> username, password callback hander etc. which could be different for the
>> client and the server there needed to be different policysets. Having
>> the
>> same intent does no guarantee that the right policyset will be matched
>> i.e.
>> the client's policyset for the reference and the server's policyset
>> for the
>> service. Having unique intents will ensure this mapping.
>
> After looking at this again today I think that having different custom
> authentication intents defeats the purpose of intents, turning them into
> disguised policySets as they become specific to the particular config of
> authentication in parts of your network.
>
> We need a different approach:
> - keep intents abstract (authentication)
> - declare where different policySets providing authentication should be
> applied in the composition.
>
> PolicySet/appliesTo already provides a way to scope the application of a
> policySet. Can we just use that?
>
> Some examples:
> appliesTo="binding.ws"
> appliesTo="service[@name='AccountService']"
> appliesTo="../component[@name='AccountServiceComponent']"
>
> Thoughts?
Following up as nobody has posted any further thoughts.
Is the above proposal clear?
Does anybody want to try to fix the policy story or do you want me to do it?
Also, in my opinion having two bigbank samples is overkill. I think we
should just add the policy configuration to the original bigbank instead
of having a secure-bigbank duplicating bigbank. Any objections?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I agree to your views on intents and I also like the proposal you are making
with respect to making use of 'appliesTo'. Sounds like a clean way out.
The only issue standing in the way is of how we get hold of the SCDL over
which the xpath in 'appliesTo' can be applied. I'd like to use our assembly
model writers to write back an SCA artifact (component or service ... ) as
XML and then apply the xpath in appliesTo over this XML. All this must be
done in the policyset matching phase.
However, matching of policysets happen in the Builders which is in the
assembly module and referring back to the assembly-xml for the writers
causes a cyclic dependency.
Will moving the builders out to a separate module like assembly-builder be a
good way out. Or, is there any other better way of getting hold of the SCDL
or accessing the assembly model writers ?
Thanks
- Venkat
On Jan 25, 2008 9:52 AM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Venkata Krishnan wrote:
> >> - Why did you need two authentication and wsAuthentication intents? is
> >> it because you needed different policy sets on the client and service
> >> side?
> >>
> >
> > Yes, that's the reason. Since the policysets encapsulate things like
> the
> > username, password callback hander etc. which could be different for the
> > client and the server there needed to be different policysets. Having
> the
> > same intent does no guarantee that the right policyset will be matched
> i.e.
> > the client's policyset for the reference and the server's policyset for
> the
> > service. Having unique intents will ensure this mapping.
>
> After looking at this again today I think that having different custom
> authentication intents defeats the purpose of intents, turning them into
> disguised policySets as they become specific to the particular config of
> authentication in parts of your network.
>
> We need a different approach:
> - keep intents abstract (authentication)
> - declare where different policySets providing authentication should be
> applied in the composition.
>
> PolicySet/appliesTo already provides a way to scope the application of a
> policySet. Can we just use that?
>
> Some examples:
> appliesTo="binding.ws"
> appliesTo="service[@name='AccountService']"
> appliesTo="../component[@name='AccountServiceComponent']"
>
> 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: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
>> - Why did you need two authentication and wsAuthentication intents? is
>> it because you needed different policy sets on the client and service
>> side?
>>
>
> Yes, that's the reason. Since the policysets encapsulate things like the
> username, password callback hander etc. which could be different for the
> client and the server there needed to be different policysets. Having the
> same intent does no guarantee that the right policyset will be matched i.e.
> the client's policyset for the reference and the server's policyset for the
> service. Having unique intents will ensure this mapping.
After looking at this again today I think that having different custom
authentication intents defeats the purpose of intents, turning them into
disguised policySets as they become specific to the particular config of
authentication in parts of your network.
We need a different approach:
- keep intents abstract (authentication)
- declare where different policySets providing authentication should be
applied in the composition.
PolicySet/appliesTo already provides a way to scope the application of a
policySet. Can we just use that?
Some examples:
appliesTo="binding.ws"
appliesTo="service[@name='AccountService']"
appliesTo="../component[@name='AccountServiceComponent']"
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: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by ant elder <an...@gmail.com>.
Wonderful, thats really good!
..ant
On Jan 3, 2008 4:41 PM, Venkata Krishnan <fo...@gmail.com> wrote:
> Hi,
>
> I have now changed things to allow for multiple definitions.xml file.
> The
> contents of the various definitions.xml file for a domain are all
> aggregated. The runtime and extensions can contribute sca definitions
> with
> a definitions.xml in the META-INF/services directory while contributions
> can
> also have their definitions.xml as any other artifact.
>
> With this contributions need not redefine the intents supported by the
> Tuscany runtime and can assume them to be available to them.
>
> Thanks
>
> - Venkat
>
> On Dec 26, 2007 4:56 PM, Venkata Krishnan <fo...@gmail.com> wrote:
>
> > Hi Sebastien,
> >
> > Please find my comments inline. Thanks.
> >
> > - Venkat
> >
> > On Dec 15, 2007 2:52 AM, Jean-Sebastien Delfino <jsdelfino@apache.org >
> > wrote:
> >
> > > Venkata Krishnan wrote:
> > > >
> > > >> - Why did you need two authentication and wsAuthentication intents?
> > > is
> > > >> it because you needed different policy sets on the client and
> service
> > > >> side?
> > > >>
> > > >
> > > > Yes, that's the reason. Since the policysets encapsulate things
> like
> > > the
> > > > username, password callback hander etc. which could be different for
>
> > > the
> > > > client and the server there needed to be different policysets.
> Having
> > > the
> > > > same intent does no guarantee that the right policyset will be
> matched
> > > i.e.
> > > > the client's policyset for the reference and the server's policyset
> > > for the
> > > > service. Having unique intents will ensure this mapping.
> > > >
> > >
> > > I'm not getting it sorry :)
> > >
> > > Why are the wired reference and target service policysets different?
> > >
> > > If they are different how do you validate that wiring the reference to
>
> > > the service is allowed?
> > >
> >
> > First, the comparison of policysets is dependent on the mechanisms
> > supported by the policies that they embed. For example WS-Policy has
> > prescribed mechanism to calculate intersection of two policy instances
> to
> > see if they are compatible or match. So the policysets could be
> different
> > on either sides, but the policies embedded within need to compatible.
> > Having said that, the policysets on the target is available for locally
> > wired services. For services that are in a different runtime, I suppose
> the
> > service interfaces must publish this information for example as some
> > extensions to the wsdl. This is something that need further study and
> > exploration.
> >
> > >
> > > >
> > > >> - Did you have to change the WS binding code to support your new
> user
> > >
> > > >> defined wsAuthentication intent?
> > > >>
> > > >
> > > > No. Just to clarify, the mapping of policysets to intents is done by
> > > the
> > > > core runtime.
> > >
> > > Good
> > >
> > > >
> > > >
> > > >> - Is there a way to not repeat the core intents defined by the spec
> > > in
> > > >> all contributions?
> > > >
> > > > No. This is one of the concerns I have and could be resolved by
> > > having
> > > > multiple definitions.xml files.
> > >
> > > OK, here are some suggestions to improve that:
> > >
> > > To allow an admin to configure policies on a domain basis and on a
> > > contribution basis:
> > > - Package Definitions.xml files in SCA contributions contributed to
> the
> > > domain.
> > > - Assume that definitions in the SCA namespace are available in the
> > > whole domain.
> > > - Import definitions from user namespaces using the standard SCA XML
> > > <import> mechanism.
> > >
> > > To describe the capabilities of binding and implementation runtimes:
> > > - Package a definitions.xml file in their JARs
> > > - Containing relevant bindingType and implementationType definitions.
> >
> >
> > Thanks :). I'll work on this. Infact for a first cut I could just
> about
> > see if I can aggregate definitions.xml in a way similar to our service
> > configuration files.
> >
> >
> > >
> > > We should ask the policy spec folks how they envision definitions.xml
> > > being authored and used.
> > >
> > > Also the various artifacts in a composite
> > > > would like to enforce a particular intent say 'authentication' in
> > > their own
> > > > respective ways for which there may be appropriate policysets
> defined.
> > >
> > > > Mapping authentication to different policysets for different
> artifacts
> > > is
> > > > not possible. Am not sure if the specs meant that all artifacts
> > > should use
> > > > just about one type of realization of an intent.
> > > >
> > >
> > > Not sure, that's a good question for the spec folks.
> > >
> > > >>
> > > >> - Where are the bindingType definitions listing the intents
> provided
> > > by
> > > >> the bindings?
> > > >
> > > >
> > > > I had deliberately kept this out of this scenario to help us arrive
> at
> > > its
> > > > usage. The 'constrains' attribute of Intents is what is being used
> to
> > > > figure out the intents supported by the bindingType or ImplType.
> Now
> > > as I
> > > > am writing this I see that a right way to see if an intent is
> > > supported on a
> > > > bindingtype or implTyp is to check against the BindingType or
> > > > ImplementationType definitions.
> > >
> > > My understanding was different:
> > > - if alwaysProvided -> the binding always assumes that the intent is
> set
> > > - if mayProvide -> you can set the intent without specifying a
> policySet
> > > - else, you are allowed to set the intent on a binding if there is a
> > > policyset that says provides = that intent and appliesTo = that
> binding.
> > >
> > > This also leads me to think that for every
> > > > intent 'mayProvided' by a bindingType there is just one mapping
> > > policyset
> > > > that will be used.
> > > >
> > >
> > > I thought that mayProvide didn't require a policyset. I may have
> > > mis-understood, that's another question for the spec folks.
> > >
> >
> > I think your interpretation is convincing. So I'll go an change the
> > policyset resolution codes to skip looking for policysets if an intent
> is
> > found either in the alwaysProvided or mayProvided list.
> >
> > >
> > > >> - What are the security callback handlers responsible for?
> > > >>
> > > >
> > > > Until I looked at JAAS yesterday, I thought they are the hooks that
> > > the
> > > > bindings will call to enable applications to go off into user
> > > registries and
> > > > perform authentication. Looking at JAAS it seems like the callback
> > > handlers
> > > > are typically used to 'fetch' the username and password. There is a
> > > > LoginModule that actually encapsulates how and against what sort of
> > > user
> > > > registry these things are authenticated and its the LoginModule that
>
> > > calls
> > > > these handlers to simply fetch the user or client inputs. I must
> dig
> > > up
> > > > Rampart to see if this is what it also intends.
> > > >
> > >
> > > Not sure I like that. Doing all this policy stuff to provide
> declarative
> > > policies in XML and then eventually say "you have to write to
> > > javax.security aware piece of code to provide a user and password" [1]
>
> > > doesn't sound like a great story to me. Thoughts?
> > >
> >
> > :). Here is how I see it since I didn't see a choice with this ;-).
> The
> > 'handler' code is typically a hook for plugging in 'userid verification'
>
> > mechanisms. These mechanisms could vary from one application to the
> other -
> > one might use a simply xml user registry, one a rdbms, another a LDAP
> > registry and so on, each of which need to be accessed and operated in a
> > specific way. The security administrator is the one who might code
> these
> > handlers with the required logic. The policy administrators might
> simply
> > formulate a policyset that includes the name of this handler. The
> composite
> > assembler will continue to declaratively use the defined policyset.
> >
> > The funny thing is, this callback handler has a completely different
> role
> > in pure JAAS based authentication. Its a hook that goes and fetches the
>
> > userid and password like displaying prompts and so on. Its function is
> not
> > to 'verify' the userid and password. The verification is done by a
> > LoginModule in JAAS.
> >
> >
> > >
> > > [1]
> > >
> > >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/AccountsDataPasswordCallbackHandler.java
> > > --
> > > Jean-Sebastien
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I have now changed things to allow for multiple definitions.xml file. The
contents of the various definitions.xml file for a domain are all
aggregated. The runtime and extensions can contribute sca definitions with
a definitions.xml in the META-INF/services directory while contributions can
also have their definitions.xml as any other artifact.
With this contributions need not redefine the intents supported by the
Tuscany runtime and can assume them to be available to them.
Thanks
- Venkat
On Dec 26, 2007 4:56 PM, Venkata Krishnan <fo...@gmail.com> wrote:
> Hi Sebastien,
>
> Please find my comments inline. Thanks.
>
> - Venkat
>
> On Dec 15, 2007 2:52 AM, Jean-Sebastien Delfino <jsdelfino@apache.org >
> wrote:
>
> > Venkata Krishnan wrote:
> > >
> > >> - Why did you need two authentication and wsAuthentication intents?
> > is
> > >> it because you needed different policy sets on the client and service
> > >> side?
> > >>
> > >
> > > Yes, that's the reason. Since the policysets encapsulate things like
> > the
> > > username, password callback hander etc. which could be different for
> > the
> > > client and the server there needed to be different policysets. Having
> > the
> > > same intent does no guarantee that the right policyset will be matched
> > i.e.
> > > the client's policyset for the reference and the server's policyset
> > for the
> > > service. Having unique intents will ensure this mapping.
> > >
> >
> > I'm not getting it sorry :)
> >
> > Why are the wired reference and target service policysets different?
> >
> > If they are different how do you validate that wiring the reference to
> > the service is allowed?
> >
>
> First, the comparison of policysets is dependent on the mechanisms
> supported by the policies that they embed. For example WS-Policy has
> prescribed mechanism to calculate intersection of two policy instances to
> see if they are compatible or match. So the policysets could be different
> on either sides, but the policies embedded within need to compatible.
> Having said that, the policysets on the target is available for locally
> wired services. For services that are in a different runtime, I suppose the
> service interfaces must publish this information for example as some
> extensions to the wsdl. This is something that need further study and
> exploration.
>
> >
> > >
> > >> - Did you have to change the WS binding code to support your new user
> >
> > >> defined wsAuthentication intent?
> > >>
> > >
> > > No. Just to clarify, the mapping of policysets to intents is done by
> > the
> > > core runtime.
> >
> > Good
> >
> > >
> > >
> > >> - Is there a way to not repeat the core intents defined by the spec
> > in
> > >> all contributions?
> > >
> > > No. This is one of the concerns I have and could be resolved by
> > having
> > > multiple definitions.xml files.
> >
> > OK, here are some suggestions to improve that:
> >
> > To allow an admin to configure policies on a domain basis and on a
> > contribution basis:
> > - Package Definitions.xml files in SCA contributions contributed to the
> > domain.
> > - Assume that definitions in the SCA namespace are available in the
> > whole domain.
> > - Import definitions from user namespaces using the standard SCA XML
> > <import> mechanism.
> >
> > To describe the capabilities of binding and implementation runtimes:
> > - Package a definitions.xml file in their JARs
> > - Containing relevant bindingType and implementationType definitions.
>
>
> Thanks :). I'll work on this. Infact for a first cut I could just about
> see if I can aggregate definitions.xml in a way similar to our service
> configuration files.
>
>
> >
> > We should ask the policy spec folks how they envision definitions.xml
> > being authored and used.
> >
> > Also the various artifacts in a composite
> > > would like to enforce a particular intent say 'authentication' in
> > their own
> > > respective ways for which there may be appropriate policysets defined.
> >
> > > Mapping authentication to different policysets for different artifacts
> > is
> > > not possible. Am not sure if the specs meant that all artifacts
> > should use
> > > just about one type of realization of an intent.
> > >
> >
> > Not sure, that's a good question for the spec folks.
> >
> > >>
> > >> - Where are the bindingType definitions listing the intents provided
> > by
> > >> the bindings?
> > >
> > >
> > > I had deliberately kept this out of this scenario to help us arrive at
> > its
> > > usage. The 'constrains' attribute of Intents is what is being used to
> > > figure out the intents supported by the bindingType or ImplType. Now
> > as I
> > > am writing this I see that a right way to see if an intent is
> > supported on a
> > > bindingtype or implTyp is to check against the BindingType or
> > > ImplementationType definitions.
> >
> > My understanding was different:
> > - if alwaysProvided -> the binding always assumes that the intent is set
> > - if mayProvide -> you can set the intent without specifying a policySet
> > - else, you are allowed to set the intent on a binding if there is a
> > policyset that says provides = that intent and appliesTo = that binding.
> >
> > This also leads me to think that for every
> > > intent 'mayProvided' by a bindingType there is just one mapping
> > policyset
> > > that will be used.
> > >
> >
> > I thought that mayProvide didn't require a policyset. I may have
> > mis-understood, that's another question for the spec folks.
> >
>
> I think your interpretation is convincing. So I'll go an change the
> policyset resolution codes to skip looking for policysets if an intent is
> found either in the alwaysProvided or mayProvided list.
>
> >
> > >> - What are the security callback handlers responsible for?
> > >>
> > >
> > > Until I looked at JAAS yesterday, I thought they are the hooks that
> > the
> > > bindings will call to enable applications to go off into user
> > registries and
> > > perform authentication. Looking at JAAS it seems like the callback
> > handlers
> > > are typically used to 'fetch' the username and password. There is a
> > > LoginModule that actually encapsulates how and against what sort of
> > user
> > > registry these things are authenticated and its the LoginModule that
> > calls
> > > these handlers to simply fetch the user or client inputs. I must dig
> > up
> > > Rampart to see if this is what it also intends.
> > >
> >
> > Not sure I like that. Doing all this policy stuff to provide declarative
> > policies in XML and then eventually say "you have to write to
> > javax.security aware piece of code to provide a user and password" [1]
> > doesn't sound like a great story to me. Thoughts?
> >
>
> :). Here is how I see it since I didn't see a choice with this ;-). The
> 'handler' code is typically a hook for plugging in 'userid verification'
> mechanisms. These mechanisms could vary from one application to the other -
> one might use a simply xml user registry, one a rdbms, another a LDAP
> registry and so on, each of which need to be accessed and operated in a
> specific way. The security administrator is the one who might code these
> handlers with the required logic. The policy administrators might simply
> formulate a policyset that includes the name of this handler. The composite
> assembler will continue to declaratively use the defined policyset.
>
> The funny thing is, this callback handler has a completely different role
> in pure JAAS based authentication. Its a hook that goes and fetches the
> userid and password like displaying prompts and so on. Its function is not
> to 'verify' the userid and password. The verification is done by a
> LoginModule in JAAS.
>
>
> >
> > [1]
> >
> > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/AccountsDataPasswordCallbackHandler.java
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I have changed this now to put the computed intents back into the
binding/implementation instance. So the bindings and implementations can
now parse the intents and filter the mayProvided ones and take appropriate
actions. I'm trying to see if I can get this demonstrated on our axis2
binding.
I've also made some changes to now get the bindingType and
implementationType definitions in order. Here is how things should work
from now on : -
- every binding and implementation type has a definitions.xml file in the
META-INF/services directory in which will be defined a bindingType or
implementationType element that contains all the intents mayProvided and
alwaysProvided by the binding / implementation type.
- ever binding / implementation instance will have reference to this
corresponding type bindingType or implementationType definition.
All this under r614447.
Thanks
- Venkat
On Jan 16, 2008 12:52 AM, Greg Dritschler <gr...@gmail.com> wrote:
> I agree that intents that are listed in mayProvide do not require a policy
> set. The binding/implementation provides the functionality of the intent
> if
> the intent is present on the relevant composite element. It looks to me
> that CompositeWireBuilderImpl, as part of the process of trying to find
> matching policy sets, removes intents that are found in mayProvide from
> the
> model object. In that case, how would the binding/implementation know it
> should provide the intent functionality if the intent isn't present in the
> model anymore?
>
> Greg Dritschler
>
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Greg Dritschler <gr...@gmail.com>.
I agree that intents that are listed in mayProvide do not require a policy
set. The binding/implementation provides the functionality of the intent if
the intent is present on the relevant composite element. It looks to me
that CompositeWireBuilderImpl, as part of the process of trying to find
matching policy sets, removes intents that are found in mayProvide from the
model object. In that case, how would the binding/implementation know it
should provide the intent functionality if the intent isn't present in the
model anymore?
Greg Dritschler
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien,
Please find my comments inline. Thanks.
- Venkat
On Dec 15, 2007 2:52 AM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Venkata Krishnan wrote:
> >
> >> - Why did you need two authentication and wsAuthentication intents? is
> >> it because you needed different policy sets on the client and service
> >> side?
> >>
> >
> > Yes, that's the reason. Since the policysets encapsulate things like
> the
> > username, password callback hander etc. which could be different for the
> > client and the server there needed to be different policysets. Having
> the
> > same intent does no guarantee that the right policyset will be matched
> i.e.
> > the client's policyset for the reference and the server's policyset for
> the
> > service. Having unique intents will ensure this mapping.
> >
>
> I'm not getting it sorry :)
>
> Why are the wired reference and target service policysets different?
>
> If they are different how do you validate that wiring the reference to
> the service is allowed?
>
First, the comparison of policysets is dependent on the mechanisms supported
by the policies that they embed. For example WS-Policy has prescribed
mechanism to calculate intersection of two policy instances to see if they
are compatible or match. So the policysets could be different on either
sides, but the policies embedded within need to compatible. Having said
that, the policysets on the target is available for locally wired services.
For services that are in a different runtime, I suppose the service
interfaces must publish this information for example as some extensions to
the wsdl. This is something that need further study and exploration.
>
> >
> >> - Did you have to change the WS binding code to support your new user
> >> defined wsAuthentication intent?
> >>
> >
> > No. Just to clarify, the mapping of policysets to intents is done by the
> > core runtime.
>
> Good
>
> >
> >
> >> - Is there a way to not repeat the core intents defined by the spec in
> >> all contributions?
> >
> > No. This is one of the concerns I have and could be resolved by having
> > multiple definitions.xml files.
>
> OK, here are some suggestions to improve that:
>
> To allow an admin to configure policies on a domain basis and on a
> contribution basis:
> - Package Definitions.xml files in SCA contributions contributed to the
> domain.
> - Assume that definitions in the SCA namespace are available in the
> whole domain.
> - Import definitions from user namespaces using the standard SCA XML
> <import> mechanism.
>
> To describe the capabilities of binding and implementation runtimes:
> - Package a definitions.xml file in their JARs
> - Containing relevant bindingType and implementationType definitions.
Thanks :). I'll work on this. Infact for a first cut I could just about
see if I can aggregate definitions.xml in a way similar to our service
configuration files.
>
> We should ask the policy spec folks how they envision definitions.xml
> being authored and used.
>
> Also the various artifacts in a composite
> > would like to enforce a particular intent say 'authentication' in their
> own
> > respective ways for which there may be appropriate policysets defined.
> > Mapping authentication to different policysets for different artifacts
> is
> > not possible. Am not sure if the specs meant that all artifacts should
> use
> > just about one type of realization of an intent.
> >
>
> Not sure, that's a good question for the spec folks.
>
> >>
> >> - Where are the bindingType definitions listing the intents provided by
> >> the bindings?
> >
> >
> > I had deliberately kept this out of this scenario to help us arrive at
> its
> > usage. The 'constrains' attribute of Intents is what is being used to
> > figure out the intents supported by the bindingType or ImplType. Now as
> I
> > am writing this I see that a right way to see if an intent is supported
> on a
> > bindingtype or implTyp is to check against the BindingType or
> > ImplementationType definitions.
>
> My understanding was different:
> - if alwaysProvided -> the binding always assumes that the intent is set
> - if mayProvide -> you can set the intent without specifying a policySet
> - else, you are allowed to set the intent on a binding if there is a
> policyset that says provides = that intent and appliesTo = that binding.
>
> This also leads me to think that for every
> > intent 'mayProvided' by a bindingType there is just one mapping
> policyset
> > that will be used.
> >
>
> I thought that mayProvide didn't require a policyset. I may have
> mis-understood, that's another question for the spec folks.
>
I think your interpretation is convincing. So I'll go an change the
policyset resolution codes to skip looking for policysets if an intent is
found either in the alwaysProvided or mayProvided list.
>
> >> - What are the security callback handlers responsible for?
> >>
> >
> > Until I looked at JAAS yesterday, I thought they are the hooks that the
> > bindings will call to enable applications to go off into user registries
> and
> > perform authentication. Looking at JAAS it seems like the callback
> handlers
> > are typically used to 'fetch' the username and password. There is a
> > LoginModule that actually encapsulates how and against what sort of user
> > registry these things are authenticated and its the LoginModule that
> calls
> > these handlers to simply fetch the user or client inputs. I must dig up
> > Rampart to see if this is what it also intends.
> >
>
> Not sure I like that. Doing all this policy stuff to provide declarative
> policies in XML and then eventually say "you have to write to
> javax.security aware piece of code to provide a user and password" [1]
> doesn't sound like a great story to me. Thoughts?
>
:). Here is how I see it since I didn't see a choice with this ;-). The
'handler' code is typically a hook for plugging in 'userid verification'
mechanisms. These mechanisms could vary from one application to the other -
one might use a simply xml user registry, one a rdbms, another a LDAP
registry and so on, each of which need to be accessed and operated in a
specific way. The security administrator is the one who might code these
handlers with the required logic. The policy administrators might simply
formulate a policyset that includes the name of this handler. The composite
assembler will continue to declaratively use the defined policyset.
The funny thing is, this callback handler has a completely different role in
pure JAAS based authentication. Its a hook that goes and fetches the userid
and password like displaying prompts and so on. Its function is not to
'verify' the userid and password. The verification is done by a LoginModule
in JAAS.
>
> [1]
>
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/AccountsDataPasswordCallbackHandler.java
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
>
>> - Why did you need two authentication and wsAuthentication intents? is
>> it because you needed different policy sets on the client and service
>> side?
>>
>
> Yes, that's the reason. Since the policysets encapsulate things like the
> username, password callback hander etc. which could be different for the
> client and the server there needed to be different policysets. Having the
> same intent does no guarantee that the right policyset will be matched i.e.
> the client's policyset for the reference and the server's policyset for the
> service. Having unique intents will ensure this mapping.
>
I'm not getting it sorry :)
Why are the wired reference and target service policysets different?
If they are different how do you validate that wiring the reference to
the service is allowed?
>
>> - Did you have to change the WS binding code to support your new user
>> defined wsAuthentication intent?
>>
>
> No. Just to clarify, the mapping of policysets to intents is done by the
> core runtime.
Good
>
>
>> - Is there a way to not repeat the core intents defined by the spec in
>> all contributions?
>
> No. This is one of the concerns I have and could be resolved by having
> multiple definitions.xml files.
OK, here are some suggestions to improve that:
To allow an admin to configure policies on a domain basis and on a
contribution basis:
- Package Definitions.xml files in SCA contributions contributed to the
domain.
- Assume that definitions in the SCA namespace are available in the
whole domain.
- Import definitions from user namespaces using the standard SCA XML
<import> mechanism.
To describe the capabilities of binding and implementation runtimes:
- Package a definitions.xml file in their JARs
- Containing relevant bindingType and implementationType definitions.
We should ask the policy spec folks how they envision definitions.xml
being authored and used.
Also the various artifacts in a composite
> would like to enforce a particular intent say 'authentication' in their own
> respective ways for which there may be appropriate policysets defined.
> Mapping authentication to different policysets for different artifacts is
> not possible. Am not sure if the specs meant that all artifacts should use
> just about one type of realization of an intent.
>
Not sure, that's a good question for the spec folks.
>>
>> - Where are the bindingType definitions listing the intents provided by
>> the bindings?
>
>
> I had deliberately kept this out of this scenario to help us arrive at its
> usage. The 'constrains' attribute of Intents is what is being used to
> figure out the intents supported by the bindingType or ImplType. Now as I
> am writing this I see that a right way to see if an intent is supported on a
> bindingtype or implTyp is to check against the BindingType or
> ImplementationType definitions.
My understanding was different:
- if alwaysProvided -> the binding always assumes that the intent is set
- if mayProvide -> you can set the intent without specifying a policySet
- else, you are allowed to set the intent on a binding if there is a
policyset that says provides = that intent and appliesTo = that binding.
This also leads me to think that for every
> intent 'mayProvided' by a bindingType there is just one mapping policyset
> that will be used.
>
I thought that mayProvide didn't require a policyset. I may have
mis-understood, that's another question for the spec folks.
>> - What are the security callback handlers responsible for?
>>
>
> Until I looked at JAAS yesterday, I thought they are the hooks that the
> bindings will call to enable applications to go off into user registries and
> perform authentication. Looking at JAAS it seems like the callback handlers
> are typically used to 'fetch' the username and password. There is a
> LoginModule that actually encapsulates how and against what sort of user
> registry these things are authenticated and its the LoginModule that calls
> these handlers to simply fetch the user or client inputs. I must dig up
> Rampart to see if this is what it also intends.
>
Not sure I like that. Doing all this policy stuff to provide declarative
policies in XML and then eventually say "you have to write to
javax.security aware piece of code to provide a user and password" [1]
doesn't sound like a great story to me. Thoughts?
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/AccountsDataPasswordCallbackHandler.java
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien,
Thanks for taking a look and thinking about this. Please find my answers
inline.
- Venkat
On Dec 14, 2007 3:36 AM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Venkata Krishnan wrote:
> > Hi,
> >
> > Heres what I am intending to do for the secure-bigbank into which I have
> > copied over the exiting calculator, stockquote and account demos into
> > secure-bigbank...
> >
> > - The Calculator and StockQuote services need to exchange data that
> cannot
> > be tampered with since the AccountService heavily 'relies' on their
> > results. So interaction with these two services should have
> 'integrity'. I
> > don't think there is a need for authentication or confidentiality for
> the
> > interactions with these services.
> > - The AccountData service is right now accessed only by the
> AccountService.
> > I'd like to open this out and put in the following security constraints
> :-
> > - just keep authentication when accessed from the AccoutService
> > locally say over binding.sca
> > - enforce authentication, confidentiality and integrity when
> accessed
> > from outside say over binding.ws
> > - Finally the AccountService should enforce authentication,
> confidentiality
> > and integrity.
> >
> > Does this sound ok ?
> >
> > After an iteration with interaction policies, I'll start working on some
> > implementation policies. For example having 'authorization' enforced on
> the
> > AccountDataService's operations.
> >
> > Thanks
> >
> > - Venkat
> >
>
> I took a look at secure-bigbank. It's a good start which helps
> understand how to use the policy framework, and triggers some questions:
>
> - The accountDataService reference is bound to 8084, while the
> AccountDataService is bound to 8085? aren't they supposed to be wired
> together?
Sorry, that's a bug. I was using the TCPMonitor to intercept client-server
communications for a bit of debugging. This monitor was listening on 8084
on one side and forwarding the packets to 8085. I'll fix that.
> - Why did you need two authentication and wsAuthentication intents? is
> it because you needed different policy sets on the client and service
> side?
>
Yes, that's the reason. Since the policysets encapsulate things like the
username, password callback hander etc. which could be different for the
client and the server there needed to be different policysets. Having the
same intent does no guarantee that the right policyset will be matched i.e.
the client's policyset for the reference and the server's policyset for the
service. Having unique intents will ensure this mapping.
>
> - Did you have to change the WS binding code to support your new user
> defined wsAuthentication intent?
>
No. Just to clarify, the mapping of policysets to intents is done by the
core runtime. Now, how a policyset or what is mentioned in it needs to be
affected is what is done in the binding code. So the wsBinding knows to
what is to be done with wsConfigParam based PolicySets and WS-Policy based
PolicySets to enable security.
>
> - Is there a way to not repeat the core intents defined by the spec in
> all contributions?
No. This is one of the concerns I have and could be resolved by having
multiple definitions.xml files. Also the various artifacts in a composite
would like to enforce a particular intent say 'authentication' in their own
respective ways for which there may be appropriate policysets defined.
Mapping authentication to different policysets for different artifacts is
not possible. Am not sure if the specs meant that all artifacts should use
just about one type of realization of an intent.
>
>
> - Where are the bindingType definitions listing the intents provided by
> the bindings?
I had deliberately kept this out of this scenario to help us arrive at its
usage. The 'constrains' attribute of Intents is what is being used to
figure out the intents supported by the bindingType or ImplType. Now as I
am writing this I see that a right way to see if an intent is supported on a
bindingtype or implTyp is to check against the BindingType or
ImplementationType definitions. This also leads me to think that for every
intent 'mayProvided' by a bindingType there is just one mapping policyset
that will be used.
>
> - What are the security callback handlers responsible for?
>
Until I looked at JAAS yesterday, I thought they are the hooks that the
bindings will call to enable applications to go off into user registries and
perform authentication. Looking at JAAS it seems like the callback handlers
are typically used to 'fetch' the username and password. There is a
LoginModule that actually encapsulates how and against what sort of user
registry these things are authenticated and its the LoginModule that calls
these handlers to simply fetch the user or client inputs. I must dig up
Rampart to see if this is what it also intends.
>
> Thanks
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi,
>
> Heres what I am intending to do for the secure-bigbank into which I have
> copied over the exiting calculator, stockquote and account demos into
> secure-bigbank...
>
> - The Calculator and StockQuote services need to exchange data that cannot
> be tampered with since the AccountService heavily 'relies' on their
> results. So interaction with these two services should have 'integrity'. I
> don't think there is a need for authentication or confidentiality for the
> interactions with these services.
> - The AccountData service is right now accessed only by the AccountService.
> I'd like to open this out and put in the following security constraints :-
> - just keep authentication when accessed from the AccoutService
> locally say over binding.sca
> - enforce authentication, confidentiality and integrity when accessed
> from outside say over binding.ws
> - Finally the AccountService should enforce authentication, confidentiality
> and integrity.
>
> Does this sound ok ?
>
> After an iteration with interaction policies, I'll start working on some
> implementation policies. For example having 'authorization' enforced on the
> AccountDataService's operations.
>
> Thanks
>
> - Venkat
>
I took a look at secure-bigbank. It's a good start which helps
understand how to use the policy framework, and triggers some questions:
- The accountDataService reference is bound to 8084, while the
AccountDataService is bound to 8085? aren't they supposed to be wired
together?
- Why did you need two authentication and wsAuthentication intents? is
it because you needed different policy sets on the client and service side?
- Did you have to change the WS binding code to support your new user
defined wsAuthentication intent?
- Is there a way to not repeat the core intents defined by the spec in
all contributions?
- Where are the bindingType definitions listing the intents provided by
the bindings?
- What are the security callback handlers responsible for?
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi,
>
> Heres what I am intending to do for the secure-bigbank into which I have
> copied over the exiting calculator, stockquote and account demos into
> secure-bigbank...
Could you commit that? it doesn't have to work, I'm sure it's going to
take a few weeks before it does, but that'll allow everybody to take a look.
I'd suggest to have multiple modules similar to the existing module
structure and in addition to that split the account module in three
(account, savings-accountdata and checking-accountdata) representing
different divisions in the bank.
>
> - The Calculator and StockQuote services need to exchange data that cannot
> be tampered with since the AccountService heavily 'relies' on their
> results. So interaction with these two services should have 'integrity'. I
> don't think there is a need for authentication or confidentiality for the
> interactions with these services.
Yes makes sense
> - The AccountData service is right now accessed only by the AccountService.
> I'd like to open this out and put in the following security constraints :-
> - just keep authentication when accessed from the AccoutService
> locally say over binding.sca
> - enforce authentication, confidentiality and integrity when accessed
> from outside say over binding.ws
OK
> - Finally the AccountService should enforce authentication, confidentiality
> and integrity.
>
> Does this sound ok ?
>
Sounds good. More ideas will probably pop up as the scenario matures,
but I can think of two other dimensions to this:
- Use different confidentiality levels between divisions of the bank and
communication with the external world.
- Think about the security aspects of the JSP that implements the UI.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
So to summarize what's been done upto now - the interactions between Bigbank
and StockQuote have been enabled for integrity. The Bigbank's dependency on
the AccountsDataService has been changed from a inner composite
implementation to a binding.ws reference and then this interaction has been
enable for authentication. Here is a summary of my observations upto
now....
- In this demo I've had to define two definitions.xml one for the bigbank
application and another for the stock quote application. Each of these
files has a bunch of standard sca intents that had to be copied over. Maybe
we could define the standard ones elsewhere and allow the app.developer or
policy admin to assume that these intents will be made available by the SCA
runtime itself.
- Assume there are two instances of a binding.ws and that they both
specified 'authentication'. However the policyset to be applied each of
them is different say policySetOne and policySetTwo then there is currently
no way of making sure that when the matching policysets are worked out it
these two instances get assigned the right policySet. The only way of
getting this done is by specifying the policySet itself in the
binding.wsdeclaration in the composite. An alternative might be to
use the
'appliesTo' xpath attribute of the PolicySet to include the binding uri so
that only a policyset that must apply to a binding instance gets matched. I
faced this issue with the Bigbank and AccoutsData services both specifying
authentication but needed different policyset as one was a client and
another was a server.
- I did not have to do anything with policy-handlers since I was working
only with binding.ws where policy handling code was already in place. Also
we had decided not to parallely go about enabling the extensions for policy
handling.
Do others have additional observations about the policy fwk ? Any other
thoughts ?
Thanks
- Venkat
On Dec 3, 2007 9:12 PM, Venkata Krishnan <fo...@gmail.com> wrote:
> Hi,
>
> Any further modifications to this demo will require additions to our
> binding extensions to handle policies. Since this is something that we'd
> prefer not to do in patches I have made the AccountsDataService to use
> binding.ws and have enforced 'authentication'.
>
> The Bigbank application must now authenticate itself with the
> AccountsDataService to obtain accounts data. The Bigbank and the
> AccountsDataService have a 'password callback handler' (think of it as a
> hook) implemented where they work out means of setting and retrieving
> userids and passwords to be used for this authentication.
>
> Since we need two policysets one for the server side (AccoutsData) and
> another for the client side(Bigbank) I've had to create two intents
> 'authentication' and 'wsAuthentication' so that these different policysets
> match. If it had been just 'authenticatoin' for both client and server
> there is no criteria that we can use to match to the server side or client
> side policy set appropriately.
>
> Thanks
>
> - Venkat
>
>
>
> On Dec 1, 2007 9:12 PM, Venkata Krishnan <fo...@gmail.com> wrote:
>
> > Hi,
> >
> > I have now committed a first cut of the secure-bigbank demo under
> > r600142. Sorry couldn't do this yesterday itself as I was not doing well.
> >
> > For now I have enabled the StockQuote webservice for 'integrity'...
> > - First to be able to enforce 'integrity' the Bigbank and StockQuote
> > applications define the integrity intent and the policyset that would
> > realize this intent, in each of thier definitions.xml file
> > - Since integrity involves signing of the soap messages the Bigbank and
> > StockQuote setup their keystores. They decide on their individual user ids
> > whose key would be used for the signing.
> > - Each of them then imports the other's key into its keystore so that
> > when message are exchanged between the two the signatures can be verified.
> > - Since Rampart is the module that is going to facilitate integrity, the
> > Bigbank and StockQuote forumlate policysets that encapsulate the necessary
> > inputs for Rampart to enforce integrity. Typically the policyset includes
> > details related to the keystore and the userid used for signing.
> > - Then the Bigbank marks the 'stockQuote reference' as requiring
> > integrity and the StockQuote marks the 'stockQuote service' as requiring
> > integrity
> > - The Bigbank and the StockQuote implement a PassworkCallBackHandler
> > class from where they manage the userid and passwords. For example when a
> > message is to be signed Rampart would like to retrieve the key to be used
> > for such signing from the keystore. To retrieve this key, a userid and
> > password is required. While the userid to be used is picked up from the
> > policyset, the password for this userid is obtained from te
> > PasswordCallBackHandler.
> >
> > When you run this demo, you'd notice some prints that I have included in
> > the PasswordCallbackHandler being displayed in the bigbank-accound and
> > stockquote consoles. This is just for time being to ensure that the
> > PasswordCallBankHanlder is looped in and also to verify the userids that are
> > being used for the signing.
> >
> > Thanks
> >
> > - Venkat
> >
> >
> > On Dec 1, 2007 3:47 PM, Venkata Krishnan <for.svkrish@gmail.com > wrote:
> >
> > > Thanks and point taken :). I am also comfortable with tinkering the
> > > runtime and extensions to make this scenario work. I'd rather take note of
> > > the gaps and discuss them to resolution in a wholistic manner.
> > >
> > > - Venkat
> > >
> > >
> > > On Nov 30, 2007 11:50 PM, Raymond Feng <en...@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > I suggest that we not expand too quickly into other bindings such as
> > > > RMI.
> > > > Let's focus on getting your previous proposal (StockQuote,
> > > > AccountData
> > > > services) implemented first.
> > > >
> > > > Thanks,
> > > > Raymond
> > > >
> > > > ----- Original Message -----
> > > > From: "Venkata Krishnan" <fo...@gmail.com>
> > > > To: < tuscany-dev@ws.apache.org>
> > > > Sent: Friday, November 30, 2007 7:41 AM
> > > > Subject: Re: Using security policies in the Bigbank scenario, was
> > > > Re: Policy
> > > > Framework Scenarios.
> > > >
> > > >
> > > > > Hi,
> > > > >
> > > > > Going ahead, I am starting with the calculator service. Since we
> > > > have our
> > > > > calculator service hosted as an rmi service, I have started to
> > > > look into
> > > > > how
> > > > > security could be provided in an RMI Binding.
> > > > >
> > > > > - Venkat
> > > > >
> > > > > On Nov 30, 2007 1:17 PM, Venkata Krishnan <for.svkrish@gmail.com >
> > > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> Heres what I am intending to do for the secure-bigbank into which
> > > > I have
> > > > >> copied over the exiting calculator, stockquote and account demos
> > > > into
> > > > >> secure-bigbank...
> > > > >>
> > > > >> - The Calculator and StockQuote services need to exchange data
> > > > that
> > > > >> cannot
> > > > >> be tampered with since the AccountService heavily 'relies' on
> > > > their
> > > > >> results. So interaction with these two services should have
> > > > 'integrity'.
> > > > >> I
> > > > >> don't think there is a need for authentication or confidentiality
> > > > for the
> > > > >> interactions with these services.
> > > > >> - The AccountData service is right now accessed only by the
> > > > >> AccountService. I'd like to open this out and put in the
> > > > following
> > > > >> security
> > > > >> constraints :-
> > > > >> - just keep authentication when accessed from the
> > > > AccoutService
> > > > >> locally say over binding.sca
> > > > >> - enforce authentication, confidentiality and integrity
> > > > when
> > > > >> accessed from outside say over binding.ws
> > > > >> - Finally the AccountService should enforce authentication,
> > > > >> confidentiality and integrity.
> > > > >>
> > > > >> Does this sound ok ?
> > > > >>
> > > > >> After an iteration with interaction policies, I'll start working
> > > > on some
> > > > >> implementation policies. For example having 'authorization'
> > > > enforced on
> > > > >> the
> > > > >> AccountDataService's operations.
> > > > >>
> > > > >> Thanks
> > > > >>
> > > > >> - Venkat
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino <
> > > > jsdelfino@apache.org>
> > > > >> wrote:
> > > > >>
> > > > >> > Raymond Feng wrote:
> > > > >> > > Hi,
> > > > >> > >
> > > > >> > > I propose to add the following to the BigBank scenario too to
> > > > cover
> > > > >> > > transaction policies and JMS binding.
> > > > >> > >
> > > > >> > > 1) Have separate components to represent the
> > > > SavingsAccountService
> > > > >> > > and
> > > > >> >
> > > > >> > > CheckingAccountService. The two services will be backed by
> > > > two
> > > > >> > different
> > > > >> > > resource managers (Database or JMS queue). Please see the
> > > > code at [1]
> > > > >> > > and diagrams at [2].
> > > > >> > >
> > > > >> > > 2) Add a TransferService to transfer money between accounts.
> > > > The
> > > > >> > > operations will be executed in a global transaction.
> > > > >> > >
> > > > >> > > 3) The TransferService will be exposed over binding.jms. The
> > > > request
> > > > >> > of
> > > > >> > > money transfer from the web front will be served by the
> > > > >> > TransferService
> > > > >> > > over JMS.
> > > > >> > >
> > > > >> > > [1]
> > > > >> > >
> > > > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
> > > > >> >
> > > > >> > >
> > > > >> > > [2]
> > > > >> > >
> > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > Raymond
> > > > >> > >
> > > > >> >
> > > > >> > Sounds good to me. The other aspect that this scenario will
> > > > allow us to
> > > > >> > explore is interaction between the JMS binding and databindings
> > > > (as
> > > > >> > Bigbank flows complex types).
> > > > >> >
> > > > >> > I'd suggest to work on these two versions of Bigbank in
> > > > parallel in
> > > > >> > different modules:
> > > > >> > a) secure bigbank with security policies
> > > > >> > b) reliable transfers with JMS and transactions
> > > > >> > i.e. two different copies of BigBank.
> > > > >> >
> > > > >> > And then bring the two together at some point later.
> > > > >> > --
> > > > >> > 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: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Any further modifications to this demo will require additions to our binding
extensions to handle policies. Since this is something that we'd prefer not
to do in patches I have made the AccountsDataService to use binding.ws and
have enforced 'authentication'.
The Bigbank application must now authenticate itself with the
AccountsDataService to obtain accounts data. The Bigbank and the
AccountsDataService have a 'password callback handler' (think of it as a
hook) implemented where they work out means of setting and retrieving
userids and passwords to be used for this authentication.
Since we need two policysets one for the server side (AccoutsData) and
another for the client side(Bigbank) I've had to create two intents
'authentication' and 'wsAuthentication' so that these different policysets
match. If it had been just 'authenticatoin' for both client and server
there is no criteria that we can use to match to the server side or client
side policy set appropriately.
Thanks
- Venkat
On Dec 1, 2007 9:12 PM, Venkata Krishnan <fo...@gmail.com> wrote:
> Hi,
>
> I have now committed a first cut of the secure-bigbank demo under
> r600142. Sorry couldn't do this yesterday itself as I was not doing well.
>
> For now I have enabled the StockQuote webservice for 'integrity'...
> - First to be able to enforce 'integrity' the Bigbank and StockQuote
> applications define the integrity intent and the policyset that would
> realize this intent, in each of thier definitions.xml file
> - Since integrity involves signing of the soap messages the Bigbank and
> StockQuote setup their keystores. They decide on their individual user ids
> whose key would be used for the signing.
> - Each of them then imports the other's key into its keystore so that when
> message are exchanged between the two the signatures can be verified.
> - Since Rampart is the module that is going to facilitate integrity, the
> Bigbank and StockQuote forumlate policysets that encapsulate the necessary
> inputs for Rampart to enforce integrity. Typically the policyset includes
> details related to the keystore and the userid used for signing.
> - Then the Bigbank marks the 'stockQuote reference' as requiring integrity
> and the StockQuote marks the 'stockQuote service' as requiring integrity
> - The Bigbank and the StockQuote implement a PassworkCallBackHandler class
> from where they manage the userid and passwords. For example when a message
> is to be signed Rampart would like to retrieve the key to be used for such
> signing from the keystore. To retrieve this key, a userid and password is
> required. While the userid to be used is picked up from the policyset, the
> password for this userid is obtained from te PasswordCallBackHandler.
>
> When you run this demo, you'd notice some prints that I have included in
> the PasswordCallbackHandler being displayed in the bigbank-accound and
> stockquote consoles. This is just for time being to ensure that the
> PasswordCallBankHanlder is looped in and also to verify the userids that are
> being used for the signing.
>
> Thanks
>
> - Venkat
>
>
> On Dec 1, 2007 3:47 PM, Venkata Krishnan <fo...@gmail.com> wrote:
>
> > Thanks and point taken :). I am also comfortable with tinkering the
> > runtime and extensions to make this scenario work. I'd rather take note of
> > the gaps and discuss them to resolution in a wholistic manner.
> >
> > - Venkat
> >
> >
> > On Nov 30, 2007 11:50 PM, Raymond Feng <en...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I suggest that we not expand too quickly into other bindings such as
> > > RMI.
> > > Let's focus on getting your previous proposal (StockQuote, AccountData
> > > services) implemented first.
> > >
> > > Thanks,
> > > Raymond
> > >
> > > ----- Original Message -----
> > > From: "Venkata Krishnan" <fo...@gmail.com>
> > > To: < tuscany-dev@ws.apache.org>
> > > Sent: Friday, November 30, 2007 7:41 AM
> > > Subject: Re: Using security policies in the Bigbank scenario, was Re:
> > > Policy
> > > Framework Scenarios.
> > >
> > >
> > > > Hi,
> > > >
> > > > Going ahead, I am starting with the calculator service. Since we
> > > have our
> > > > calculator service hosted as an rmi service, I have started to look
> > > into
> > > > how
> > > > security could be provided in an RMI Binding.
> > > >
> > > > - Venkat
> > > >
> > > > On Nov 30, 2007 1:17 PM, Venkata Krishnan <for.svkrish@gmail.com >
> > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Heres what I am intending to do for the secure-bigbank into which I
> > > have
> > > >> copied over the exiting calculator, stockquote and account demos
> > > into
> > > >> secure-bigbank...
> > > >>
> > > >> - The Calculator and StockQuote services need to exchange data that
> > > >> cannot
> > > >> be tampered with since the AccountService heavily 'relies' on their
> > > >> results. So interaction with these two services should have
> > > 'integrity'.
> > > >> I
> > > >> don't think there is a need for authentication or confidentiality
> > > for the
> > > >> interactions with these services.
> > > >> - The AccountData service is right now accessed only by the
> > > >> AccountService. I'd like to open this out and put in the following
> > > >> security
> > > >> constraints :-
> > > >> - just keep authentication when accessed from the
> > > AccoutService
> > > >> locally say over binding.sca
> > > >> - enforce authentication, confidentiality and integrity when
> > > >> accessed from outside say over binding.ws
> > > >> - Finally the AccountService should enforce authentication,
> > > >> confidentiality and integrity.
> > > >>
> > > >> Does this sound ok ?
> > > >>
> > > >> After an iteration with interaction policies, I'll start working on
> > > some
> > > >> implementation policies. For example having 'authorization'
> > > enforced on
> > > >> the
> > > >> AccountDataService's operations.
> > > >>
> > > >> Thanks
> > > >>
> > > >> - Venkat
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino <
> > > jsdelfino@apache.org>
> > > >> wrote:
> > > >>
> > > >> > Raymond Feng wrote:
> > > >> > > Hi,
> > > >> > >
> > > >> > > I propose to add the following to the BigBank scenario too to
> > > cover
> > > >> > > transaction policies and JMS binding.
> > > >> > >
> > > >> > > 1) Have separate components to represent the
> > > SavingsAccountService
> > > >> > > and
> > > >> >
> > > >> > > CheckingAccountService. The two services will be backed by two
> > > >> > different
> > > >> > > resource managers (Database or JMS queue). Please see the code
> > > at [1]
> > > >> > > and diagrams at [2].
> > > >> > >
> > > >> > > 2) Add a TransferService to transfer money between accounts.
> > > The
> > > >> > > operations will be executed in a global transaction.
> > > >> > >
> > > >> > > 3) The TransferService will be exposed over binding.jms. The
> > > request
> > > >> > of
> > > >> > > money transfer from the web front will be served by the
> > > >> > TransferService
> > > >> > > over JMS.
> > > >> > >
> > > >> > > [1]
> > > >> > >
> > > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
> > > >> >
> > > >> > >
> > > >> > > [2]
> > > >> > >
> > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
> > > >> >
> > > >> > >
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Raymond
> > > >> > >
> > > >> >
> > > >> > Sounds good to me. The other aspect that this scenario will allow
> > > us to
> > > >> > explore is interaction between the JMS binding and databindings
> > > (as
> > > >> > Bigbank flows complex types).
> > > >> >
> > > >> > I'd suggest to work on these two versions of Bigbank in parallel
> > > in
> > > >> > different modules:
> > > >> > a) secure bigbank with security policies
> > > >> > b) reliable transfers with JMS and transactions
> > > >> > i.e. two different copies of BigBank.
> > > >> >
> > > >> > And then bring the two together at some point later.
> > > >> > --
> > > >> > 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: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I have now committed a first cut of the secure-bigbank demo under r600142.
Sorry couldn't do this yesterday itself as I was not doing well.
For now I have enabled the StockQuote webservice for 'integrity'...
- First to be able to enforce 'integrity' the Bigbank and StockQuote
applications define the integrity intent and the policyset that would
realize this intent, in each of thier definitions.xml file
- Since integrity involves signing of the soap messages the Bigbank and
StockQuote setup their keystores. They decide on their individual user ids
whose key would be used for the signing.
- Each of them then imports the other's key into its keystore so that when
message are exchanged between the two the signatures can be verified.
- Since Rampart is the module that is going to facilitate integrity, the
Bigbank and StockQuote forumlate policysets that encapsulate the necessary
inputs for Rampart to enforce integrity. Typically the policyset includes
details related to the keystore and the userid used for signing.
- Then the Bigbank marks the 'stockQuote reference' as requiring integrity
and the StockQuote marks the 'stockQuote service' as requiring integrity
- The Bigbank and the StockQuote implement a PassworkCallBackHandler class
from where they manage the userid and passwords. For example when a message
is to be signed Rampart would like to retrieve the key to be used for such
signing from the keystore. To retrieve this key, a userid and password is
required. While the userid to be used is picked up from the policyset, the
password for this userid is obtained from te PasswordCallBackHandler.
When you run this demo, you'd notice some prints that I have included in the
PasswordCallbackHandler being displayed in the bigbank-accound and
stockquote consoles. This is just for time being to ensure that the
PasswordCallBankHanlder is looped in and also to verify the userids that are
being used for the signing.
Thanks
- Venkat
On Dec 1, 2007 3:47 PM, Venkata Krishnan <fo...@gmail.com> wrote:
> Thanks and point taken :). I am also comfortable with tinkering the
> runtime and extensions to make this scenario work. I'd rather take note of
> the gaps and discuss them to resolution in a wholistic manner.
>
> - Venkat
>
>
> On Nov 30, 2007 11:50 PM, Raymond Feng <en...@gmail.com> wrote:
>
> > Hi,
> >
> > I suggest that we not expand too quickly into other bindings such as
> > RMI.
> > Let's focus on getting your previous proposal (StockQuote, AccountData
> > services) implemented first.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message -----
> > From: "Venkata Krishnan" <fo...@gmail.com>
> > To: < tuscany-dev@ws.apache.org>
> > Sent: Friday, November 30, 2007 7:41 AM
> > Subject: Re: Using security policies in the Bigbank scenario, was Re:
> > Policy
> > Framework Scenarios.
> >
> >
> > > Hi,
> > >
> > > Going ahead, I am starting with the calculator service. Since we have
> > our
> > > calculator service hosted as an rmi service, I have started to look
> > into
> > > how
> > > security could be provided in an RMI Binding.
> > >
> > > - Venkat
> > >
> > > On Nov 30, 2007 1:17 PM, Venkata Krishnan <fo...@gmail.com>
> > wrote:
> > >
> > >> Hi,
> > >>
> > >> Heres what I am intending to do for the secure-bigbank into which I
> > have
> > >> copied over the exiting calculator, stockquote and account demos into
> > >> secure-bigbank...
> > >>
> > >> - The Calculator and StockQuote services need to exchange data that
> > >> cannot
> > >> be tampered with since the AccountService heavily 'relies' on their
> > >> results. So interaction with these two services should have
> > 'integrity'.
> > >> I
> > >> don't think there is a need for authentication or confidentiality for
> > the
> > >> interactions with these services.
> > >> - The AccountData service is right now accessed only by the
> > >> AccountService. I'd like to open this out and put in the following
> > >> security
> > >> constraints :-
> > >> - just keep authentication when accessed from the
> > AccoutService
> > >> locally say over binding.sca
> > >> - enforce authentication, confidentiality and integrity when
> > >> accessed from outside say over binding.ws
> > >> - Finally the AccountService should enforce authentication,
> > >> confidentiality and integrity.
> > >>
> > >> Does this sound ok ?
> > >>
> > >> After an iteration with interaction policies, I'll start working on
> > some
> > >> implementation policies. For example having 'authorization' enforced
> > on
> > >> the
> > >> AccountDataService's operations.
> > >>
> > >> Thanks
> > >>
> > >> - Venkat
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org>
> > >> wrote:
> > >>
> > >> > Raymond Feng wrote:
> > >> > > Hi,
> > >> > >
> > >> > > I propose to add the following to the BigBank scenario too to
> > cover
> > >> > > transaction policies and JMS binding.
> > >> > >
> > >> > > 1) Have separate components to represent the
> > SavingsAccountService
> > >> > > and
> > >> >
> > >> > > CheckingAccountService. The two services will be backed by two
> > >> > different
> > >> > > resource managers (Database or JMS queue). Please see the code at
> > [1]
> > >> > > and diagrams at [2].
> > >> > >
> > >> > > 2) Add a TransferService to transfer money between accounts. The
> > >> > > operations will be executed in a global transaction.
> > >> > >
> > >> > > 3) The TransferService will be exposed over binding.jms. The
> > request
> > >> > of
> > >> > > money transfer from the web front will be served by the
> > >> > TransferService
> > >> > > over JMS.
> > >> > >
> > >> > > [1]
> > >> > >
> > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
> > >> >
> > >> > >
> > >> > > [2]
> > >> > >
> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
> > >> >
> > >> > >
> > >> > >
> > >> > > Thanks,
> > >> > > Raymond
> > >> > >
> > >> >
> > >> > Sounds good to me. The other aspect that this scenario will allow
> > us to
> > >> > explore is interaction between the JMS binding and databindings (as
> > >> > Bigbank flows complex types).
> > >> >
> > >> > I'd suggest to work on these two versions of Bigbank in parallel in
> > >> > different modules:
> > >> > a) secure bigbank with security policies
> > >> > b) reliable transfers with JMS and transactions
> > >> > i.e. two different copies of BigBank.
> > >> >
> > >> > And then bring the two together at some point later.
> > >> > --
> > >> > 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: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Thanks and point taken :). I am also comfortable with tinkering the runtime
and extensions to make this scenario work. I'd rather take note of the gaps
and discuss them to resolution in a wholistic manner.
- Venkat
On Nov 30, 2007 11:50 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I suggest that we not expand too quickly into other bindings such as RMI.
> Let's focus on getting your previous proposal (StockQuote, AccountData
> services) implemented first.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Venkata Krishnan" <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Friday, November 30, 2007 7:41 AM
> Subject: Re: Using security policies in the Bigbank scenario, was Re:
> Policy
> Framework Scenarios.
>
>
> > Hi,
> >
> > Going ahead, I am starting with the calculator service. Since we have
> our
> > calculator service hosted as an rmi service, I have started to look into
> > how
> > security could be provided in an RMI Binding.
> >
> > - Venkat
> >
> > On Nov 30, 2007 1:17 PM, Venkata Krishnan <fo...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> Heres what I am intending to do for the secure-bigbank into which I
> have
> >> copied over the exiting calculator, stockquote and account demos into
> >> secure-bigbank...
> >>
> >> - The Calculator and StockQuote services need to exchange data that
> >> cannot
> >> be tampered with since the AccountService heavily 'relies' on their
> >> results. So interaction with these two services should have
> 'integrity'.
> >> I
> >> don't think there is a need for authentication or confidentiality for
> the
> >> interactions with these services.
> >> - The AccountData service is right now accessed only by the
> >> AccountService. I'd like to open this out and put in the following
> >> security
> >> constraints :-
> >> - just keep authentication when accessed from the AccoutService
> >> locally say over binding.sca
> >> - enforce authentication, confidentiality and integrity when
> >> accessed from outside say over binding.ws
> >> - Finally the AccountService should enforce authentication,
> >> confidentiality and integrity.
> >>
> >> Does this sound ok ?
> >>
> >> After an iteration with interaction policies, I'll start working on
> some
> >> implementation policies. For example having 'authorization' enforced
> on
> >> the
> >> AccountDataService's operations.
> >>
> >> Thanks
> >>
> >> - Venkat
> >>
> >>
> >>
> >>
> >>
> >> On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino <js...@apache.org>
> >> wrote:
> >>
> >> > Raymond Feng wrote:
> >> > > Hi,
> >> > >
> >> > > I propose to add the following to the BigBank scenario too to cover
> >> > > transaction policies and JMS binding.
> >> > >
> >> > > 1) Have separate components to represent the SavingsAccountService
> >> > > and
> >> >
> >> > > CheckingAccountService. The two services will be backed by two
> >> > different
> >> > > resource managers (Database or JMS queue). Please see the code at
> [1]
> >> > > and diagrams at [2].
> >> > >
> >> > > 2) Add a TransferService to transfer money between accounts. The
> >> > > operations will be executed in a global transaction.
> >> > >
> >> > > 3) The TransferService will be exposed over binding.jms. The
> request
> >> > of
> >> > > money transfer from the web front will be served by the
> >> > TransferService
> >> > > over JMS.
> >> > >
> >> > > [1]
> >> > >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
> >> >
> >> > >
> >> > > [2]
> >> > >
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
> >> >
> >> > >
> >> > >
> >> > > Thanks,
> >> > > Raymond
> >> > >
> >> >
> >> > Sounds good to me. The other aspect that this scenario will allow us
> to
> >> > explore is interaction between the JMS binding and databindings (as
> >> > Bigbank flows complex types).
> >> >
> >> > I'd suggest to work on these two versions of Bigbank in parallel in
> >> > different modules:
> >> > a) secure bigbank with security policies
> >> > b) reliable transfers with JMS and transactions
> >> > i.e. two different copies of BigBank.
> >> >
> >> > And then bring the two together at some point later.
> >> > --
> >> > 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: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I suggest that we not expand too quickly into other bindings such as
> RMI. Let's focus on getting your previous proposal (StockQuote,
> AccountData services) implemented first.
>
> Thanks,
> Raymond
>
+1 to try to work through the actual scenario first.
When I brought up the scenario I was thinking about the following steps:
1. Copy the bigbank-* modules into new bigbank-secure-* modules.
2. Split the AccountData component into two components in two different
composites representing two divisions of the bank (checking and savings
accounts).
3. At this point I'm not sure that the calculator component is so
interesting for this scenario, as it was there to show integration of
different scripting languages, not very relevant here. It's probably
more interesting to invoke a CurrencyConverter Web service running on a
separate node simulating an external service.
4. Discuss on this list what kind of policies (authentication,
confidentiality, integrity) make sense to apply where in the bigbank
solution.
5. Author the policy related application and
configuration/deployment related artifacts in the bigbank modules; I'm
sure that many questions will arise and help understand usage patterns
and good practices for policies.
6. Go through the steps that an application developer, assembler,
deployer, system administrator needs to perform to put the bigbank
solution together; this is not a theoretical exercise as we'll actually
have to perform these steps ourselves, and work on what can be done to
our policy support to facilitate them.
7. Bring the pieces of the bigbank solution together, get it working end
to end and work through any relevant technical issues.
I'm guessing that questions like...
- how many definitions.xml files to we need?
- what do we write in them?
- where do we place them?
- can "intent=confidentiality" represent different types of
confidentiality mechanisms used for different types of exchanges?
- do we put policysets in the composites or definitions.xml
- how do we use appliesTo?
- and probably 50 more questions like that :)
... will pop up right in our face when we develop the scenario, backed
by a concrete use case which will help think through them.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I suggest that we not expand too quickly into other bindings such as RMI.
Let's focus on getting your previous proposal (StockQuote, AccountData
services) implemented first.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Friday, November 30, 2007 7:41 AM
Subject: Re: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
> Hi,
>
> Going ahead, I am starting with the calculator service. Since we have our
> calculator service hosted as an rmi service, I have started to look into
> how
> security could be provided in an RMI Binding.
>
> - Venkat
>
> On Nov 30, 2007 1:17 PM, Venkata Krishnan <fo...@gmail.com> wrote:
>
>> Hi,
>>
>> Heres what I am intending to do for the secure-bigbank into which I have
>> copied over the exiting calculator, stockquote and account demos into
>> secure-bigbank...
>>
>> - The Calculator and StockQuote services need to exchange data that
>> cannot
>> be tampered with since the AccountService heavily 'relies' on their
>> results. So interaction with these two services should have 'integrity'.
>> I
>> don't think there is a need for authentication or confidentiality for the
>> interactions with these services.
>> - The AccountData service is right now accessed only by the
>> AccountService. I'd like to open this out and put in the following
>> security
>> constraints :-
>> - just keep authentication when accessed from the AccoutService
>> locally say over binding.sca
>> - enforce authentication, confidentiality and integrity when
>> accessed from outside say over binding.ws
>> - Finally the AccountService should enforce authentication,
>> confidentiality and integrity.
>>
>> Does this sound ok ?
>>
>> After an iteration with interaction policies, I'll start working on some
>> implementation policies. For example having 'authorization' enforced on
>> the
>> AccountDataService's operations.
>>
>> Thanks
>>
>> - Venkat
>>
>>
>>
>>
>>
>> On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino <js...@apache.org>
>> wrote:
>>
>> > Raymond Feng wrote:
>> > > Hi,
>> > >
>> > > I propose to add the following to the BigBank scenario too to cover
>> > > transaction policies and JMS binding.
>> > >
>> > > 1) Have separate components to represent the SavingsAccountService
>> > > and
>> >
>> > > CheckingAccountService. The two services will be backed by two
>> > different
>> > > resource managers (Database or JMS queue). Please see the code at [1]
>> > > and diagrams at [2].
>> > >
>> > > 2) Add a TransferService to transfer money between accounts. The
>> > > operations will be executed in a global transaction.
>> > >
>> > > 3) The TransferService will be exposed over binding.jms. The request
>> > of
>> > > money transfer from the web front will be served by the
>> > TransferService
>> > > over JMS.
>> > >
>> > > [1]
>> > > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
>> >
>> > >
>> > > [2]
>> > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
>> >
>> > >
>> > >
>> > > Thanks,
>> > > Raymond
>> > >
>> >
>> > Sounds good to me. The other aspect that this scenario will allow us to
>> > explore is interaction between the JMS binding and databindings (as
>> > Bigbank flows complex types).
>> >
>> > I'd suggest to work on these two versions of Bigbank in parallel in
>> > different modules:
>> > a) secure bigbank with security policies
>> > b) reliable transfers with JMS and transactions
>> > i.e. two different copies of BigBank.
>> >
>> > And then bring the two together at some point later.
>> > --
>> > 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: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Going ahead, I am starting with the calculator service. Since we have our
calculator service hosted as an rmi service, I have started to look into how
security could be provided in an RMI Binding.
- Venkat
On Nov 30, 2007 1:17 PM, Venkata Krishnan <fo...@gmail.com> wrote:
> Hi,
>
> Heres what I am intending to do for the secure-bigbank into which I have
> copied over the exiting calculator, stockquote and account demos into
> secure-bigbank...
>
> - The Calculator and StockQuote services need to exchange data that cannot
> be tampered with since the AccountService heavily 'relies' on their
> results. So interaction with these two services should have 'integrity'. I
> don't think there is a need for authentication or confidentiality for the
> interactions with these services.
> - The AccountData service is right now accessed only by the
> AccountService. I'd like to open this out and put in the following security
> constraints :-
> - just keep authentication when accessed from the AccoutService
> locally say over binding.sca
> - enforce authentication, confidentiality and integrity when
> accessed from outside say over binding.ws
> - Finally the AccountService should enforce authentication,
> confidentiality and integrity.
>
> Does this sound ok ?
>
> After an iteration with interaction policies, I'll start working on some
> implementation policies. For example having 'authorization' enforced on the
> AccountDataService's operations.
>
> Thanks
>
> - Venkat
>
>
>
>
>
> On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
> > Raymond Feng wrote:
> > > Hi,
> > >
> > > I propose to add the following to the BigBank scenario too to cover
> > > transaction policies and JMS binding.
> > >
> > > 1) Have separate components to represent the SavingsAccountService and
> >
> > > CheckingAccountService. The two services will be backed by two
> > different
> > > resource managers (Database or JMS queue). Please see the code at [1]
> > > and diagrams at [2].
> > >
> > > 2) Add a TransferService to transfer money between accounts. The
> > > operations will be executed in a global transaction.
> > >
> > > 3) The TransferService will be exposed over binding.jms. The request
> > of
> > > money transfer from the web front will be served by the
> > TransferService
> > > over JMS.
> > >
> > > [1]
> > > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
> >
> > >
> > > [2]
> > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
> >
> > >
> > >
> > > Thanks,
> > > Raymond
> > >
> >
> > Sounds good to me. The other aspect that this scenario will allow us to
> > explore is interaction between the JMS binding and databindings (as
> > Bigbank flows complex types).
> >
> > I'd suggest to work on these two versions of Bigbank in parallel in
> > different modules:
> > a) secure bigbank with security policies
> > b) reliable transfers with JMS and transactions
> > i.e. two different copies of BigBank.
> >
> > And then bring the two together at some point later.
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Heres what I am intending to do for the secure-bigbank into which I have
copied over the exiting calculator, stockquote and account demos into
secure-bigbank...
- The Calculator and StockQuote services need to exchange data that cannot
be tampered with since the AccountService heavily 'relies' on their
results. So interaction with these two services should have 'integrity'. I
don't think there is a need for authentication or confidentiality for the
interactions with these services.
- The AccountData service is right now accessed only by the AccountService.
I'd like to open this out and put in the following security constraints :-
- just keep authentication when accessed from the AccoutService
locally say over binding.sca
- enforce authentication, confidentiality and integrity when accessed
from outside say over binding.ws
- Finally the AccountService should enforce authentication, confidentiality
and integrity.
Does this sound ok ?
After an iteration with interaction policies, I'll start working on some
implementation policies. For example having 'authorization' enforced on the
AccountDataService's operations.
Thanks
- Venkat
On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Raymond Feng wrote:
> > Hi,
> >
> > I propose to add the following to the BigBank scenario too to cover
> > transaction policies and JMS binding.
> >
> > 1) Have separate components to represent the SavingsAccountService and
> > CheckingAccountService. The two services will be backed by two different
> > resource managers (Database or JMS queue). Please see the code at [1]
> > and diagrams at [2].
> >
> > 2) Add a TransferService to transfer money between accounts. The
> > operations will be executed in a global transaction.
> >
> > 3) The TransferService will be exposed over binding.jms. The request of
> > money transfer from the web front will be served by the TransferService
> > over JMS.
> >
> > [1]
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
> >
> > [2]
> >
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
> >
> >
> > Thanks,
> > Raymond
> >
>
> Sounds good to me. The other aspect that this scenario will allow us to
> explore is interaction between the JMS binding and databindings (as
> Bigbank flows complex types).
>
> I'd suggest to work on these two versions of Bigbank in parallel in
> different modules:
> a) secure bigbank with security policies
> b) reliable transfers with JMS and transactions
> i.e. two different copies of BigBank.
>
> And then bring the two together at some point later.
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I propose to add the following to the BigBank scenario too to cover
> transaction policies and JMS binding.
>
> 1) Have separate components to represent the SavingsAccountService and
> CheckingAccountService. The two services will be backed by two different
> resource managers (Database or JMS queue). Please see the code at [1]
> and diagrams at [2].
>
> 2) Add a TransferService to transfer money between accounts. The
> operations will be executed in a global transaction.
>
> 3) The TransferService will be exposed over binding.jms. The request of
> money transfer from the web front will be served by the TransferService
> over JMS.
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
>
> [2]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
>
>
> Thanks,
> Raymond
>
Sounds good to me. The other aspect that this scenario will allow us to
explore is interaction between the JMS binding and databindings (as
Bigbank flows complex types).
I'd suggest to work on these two versions of Bigbank in parallel in
different modules:
a) secure bigbank with security policies
b) reliable transfers with JMS and transactions
i.e. two different copies of BigBank.
And then bring the two together at some point later.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I propose to add the following to the BigBank scenario too to cover
transaction policies and JMS binding.
1) Have separate components to represent the SavingsAccountService and
CheckingAccountService. The two services will be backed by two different
resource managers (Database or JMS queue). Please see the code at [1] and
diagrams at [2].
2) Add a TransferService to transfer money between accounts. The operations
will be executed in a global transaction.
3) The TransferService will be exposed over binding.jms. The request of
money transfer from the web front will be served by the TransferService over
JMS.
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
[2]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, November 27, 2007 11:44 AM
Subject: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
> Jean-Sebastien Delfino wrote:
> [snip]
>>
>> I'll propose a scenario in a separate email.
>>
>
> Here it goes:
> - We have support for SCA security policies.
> - We have a Bigbank application.
> - A bank application should be secure.
> Looks like a perfect fit to me.
>
> Going through a real world like scenario and trying and showing how to use
> SCA policies in an application like Bigbank will help our users understand
> how to use policies. It will also help us improve what we have, mature our
> policy story and provide feedback to the spec if necessary.
>
> To make it real, I'd suggest to look at the Bigbank application and first
> think about where it'll make business sense to apply authentication,
> confidentiality, integrity or nothing.
>
> To make the scenario a little more interesting we could split checking and
> savings account management in two divisions of the Bank running different
> composites. We'll then have to consider:
> - exchanges within a department
> - exchanges across departments
> - exchanges with the outside world
>
> ...with different security requirements for each.
>
> --
> 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: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien,
Thanks for providing these hints. I'll get onto this as soon as I have done
with some clean up and minor modifications.
- Venkat
On Nov 28, 2007 1:14 AM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Jean-Sebastien Delfino wrote:
> [snip]
> >
> > I'll propose a scenario in a separate email.
> >
>
> Here it goes:
> - We have support for SCA security policies.
> - We have a Bigbank application.
> - A bank application should be secure.
> Looks like a perfect fit to me.
>
> Going through a real world like scenario and trying and showing how to
> use SCA policies in an application like Bigbank will help our users
> understand how to use policies. It will also help us improve what we
> have, mature our policy story and provide feedback to the spec if
> necessary.
>
> To make it real, I'd suggest to look at the Bigbank application and
> first think about where it'll make business sense to apply
> authentication, confidentiality, integrity or nothing.
>
> To make the scenario a little more interesting we could split checking
> and savings account management in two divisions of the Bank running
> different composites. We'll then have to consider:
> - exchanges within a department
> - exchanges across departments
> - exchanges with the outside world
>
> ...with different security requirements for each.
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Using security policies in the Bigbank scenario, was Re: Policy Framework
Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
[snip]
>
> I'll propose a scenario in a separate email.
>
Here it goes:
- We have support for SCA security policies.
- We have a Bigbank application.
- A bank application should be secure.
Looks like a perfect fit to me.
Going through a real world like scenario and trying and showing how to
use SCA policies in an application like Bigbank will help our users
understand how to use policies. It will also help us improve what we
have, mature our policy story and provide feedback to the spec if necessary.
To make it real, I'd suggest to look at the Bigbank application and
first think about where it'll make business sense to apply
authentication, confidentiality, integrity or nothing.
To make the scenario a little more interesting we could split checking
and savings account management in two divisions of the Bank running
different composites. We'll then have to consider:
- exchanges within a department
- exchanges across departments
- exchanges with the outside world
...with different security requirements for each.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Framework Scenarios.
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Meanwhile, I'd like to whet and evolve whatever has been done with different
> user perspectives... so here are some perspectives I could think of... could
> people kindly help with their opinions and inputs on this, please.... also
> if any of you have other scenarios or ways of approaching this... please
> pitch in...
I'll propose a scenario in a separate email.
>
> A) Perspective of Policy Administrator ....
> ------------------------------------------------------------
> - defines a bunch of intents and policysets for the domain, in the
> definitions.xml
> - profiles the various binding-types and implementation-types for the
> various intents it 'mustProvide' and 'mayProvide'
> 1) How does the Policy-Admin know from a binding/impl type about the
> intents that it provides for ? Should every binding/impl type have its own
> definitions.xml file where it publishes this information ? The specs says
> that there is just this one file for the entire SCA domain - have I got it
> wrong?
Good question for the spec group. On one hand it'd be nice to support
multiple definitions.xml files. On the other hand I trust that a system
administrator can do something like 'cat *.xml > definitions.xml' to put
multiple definitions in one file.
> 2)What about the bunch of intents that the spec states as something that
> would be supported by every SCA Runtime such as authentication,
> confidentiality, integrity etc. Since it makes no sense to have every
> binding/impl type to define this as well, should we have a global
> definitions.xml in the core module where we define these ?
I'd prefer one of the policy modules, but we need to clearly understand
(1) before going there I think.
> 3) A binding / implementation type could have its own custom model of
> representing policies within policysets and interpretting them. For example
> the ws-binding-axis2 use config param model (which is custom made) and
> ws-policy assertion model (which is a standard) to represent policies. How
> should this model information be communicated to the Policy Admin in a
> standard way that is consistent across binding/impl types? If we allow
> every binding/impl type to have its own definitions.xml then could this also
> contain the xsd for the policy model?
I'm not sure I understand the issue here, if there is an issue but it'd
be nice for a custom policy language to be described with an XSD or some
form useful to the administrator.
>
> B) Perspective of Binding/Impl type developer ...
> ---------------------------------------------------------------------
> - defines the intents and xsds for the policy model that the binding/impl
> type will use
In most cases the intents are probably defined separately, the binding
declares which ones it supports.
> - defines the StAX processors for loading the policy model that the
> binding/impl type will use
> - adds code to interpret various policies and exercise them.
> 1) Do we leave the design for this to every binding / implementation
> type or do we put in a programming model that is to be common across all
> binding/impl types? I'd feel it would be better to leave it to the
> bindings/impl extension because each extension will have its own way of
> implementing various QoS and how it would interface with a QoS
> infrastructure as part of its (i.e. the extension's) lifecycle. For example
> the binding-ws-axis2 injects security related policies into the axis2-config
> during the service and client creation time and does nothing specific during
> invocation of service operations.
+1 for leaving it to the binding/impl type.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org